Feature Team vs. Component Team: 摘要

最新推荐文章于 2021-12-23 22:36:43 发布

chelsea

最新推荐文章于 2021-12-23 22:36:43 发布

阅读量259

点赞数

http://www.infoq.com/articles/scaling-lean-agile-feature-teams

Feature Team

long-lived—the team stays together so they can ‘jell’ for higher performance; they take on new features over time
cross-functional and cross-component
co-located
work on a complete customer-centric feature, across all components and disciplines (analysis, programming, testing, …)
composed of generalizing specialists

Feature teams work independently by being empowered and given the responsibility for a whole feature. Advantages include:

increased value throughput —focus on delivering what the customer or market values most

increased learning —individual and team learning increases because of broader responsibility and because of co-location with colleagues who are specialists in a variety of areas – critical for long-term improvement and acceleration; reduces the waste of underutilized people

simplified planning —by giving a whole feature to the team, organizing and planning become easier – for example, it is no longer necessary to coordinate between single-specialist functional and component teams

reduced waste of handoff —since the entire co-located feature team does all work (analysis, design, code, test), handoff is dramatically reduced

less waiting; faster cycle time —the waste of waiting is reduced because handoff is eliminated and because completing a customer feature does not have to wait on multiple parties each doing part of the work serially

self-managing; improved cost and efficiency —feature teams (and Scrum) do not require a project manager or matrix management for feature delivery, because coordination is trivial.The team has responsibility for end-to-end completion and for coordinating their work with others. Data shows an inverse relationship between the number of managers and development productivity, and also that teams with both an internal and external focus are more likely to be successful [AB07]. Feature teams are less expensive—there isn’t the need for extra overhead such as project managers.– For example [Jones01]: “ The matrix structure tends to raise the management head count for larger projects. Because software productivity declines as the management count goes up, this form of organization can be hazardous for software. ”

better code/design quality —multiple feature teams working on shared components creates pressure to keep the code clean, formatted to standards, constantly refactored, and surrounded by many unit tests—as otherwise it won’t be possible to work with. On the other hand, due to long familiarity, component teams live with obfuscated code only they can understand.

better motivation —research [HO80, Hackman02] shows that if a team feels they have complete end-to-end responsibility for a work item, and when the goal is customer-directed, then there is higher motivation and job satisfaction—important factors in productivity and success.

simple interface and module coordination —one person or team updates both sides of an interface (caller and called) and updates code in all modules; because the feature team works across all components; no need for inter-team coordination.

change is easier —changes in requirements or design ( we know it’s rare, but we heard it happened somewhere once ) are absorbed by one team; multi-team re-coordination and re-planning are not necessary.