敏捷认为小团队的人数规模应该是在魔法数字 7 上加减 2。敏捷也推荐完整团队概念,就是说团队内部要有足够的技能以完成工作。因此,开发团队除了具备核心的开发技能,还要具有测试技能、数据库技能、用户界面技能。然而,很多组织仍然纠结于最佳的团队规模和有效的团队构成。
Scott Ambler 建议:根据项目需要,可以有敏捷小团队和敏捷大团队。小团队有标准的 Scrum 角色,比如 scrum master、开发团队和产品负责人。小团队还可以使用支持队伍,包括 DBA、领域专家和测试人员这样的技术专家。大型团队需要“团队的团队(team of teams)”这样的方式。Scott 认为:
典型策略是:把多个相关小团队组织起来,形成更大规模的团队,最有效的方式是围绕着系统架构的方式组织。每个子团队应该负责一个或几个子系统,让他们可以像小敏捷团队那样,负责按时交付可工作的软件。这个策略常被称为“Conway 法则”,因为是 Melvin Conway 在二十世纪六十年代后期提出来的,也是精益开发管理策略之一。
Steve Miller 认为:除了 Scrum 推荐的角色之外,要想让团队做好质量保证和文档相关工作并不现实。他们改进了团队构成,增加了两个角色。软件质量工程师负责一个sprint 的产出的质量,文档专家负责创建用户指南、管理员指南和培训材料。
同样地,Michael F. Dwyer 在回应 Scrum Development 讨论组中一个有关团队大小的讨论时指出:
趁着 Ron Jeffries 还没说,我先借用他那个著名的话 **“2+2=5,因为这两个粗略的‘2’要比数字 2 更大一点。”** 团队规模可以是 1 个人这么小,也可以是 500 人这么大,完全基于你对团队的定义和成员的投入程度。
因此有一个共识:团队的规模和构成要根据各个项目具体情况调整。然而,我们应该如何评价我们的团队结构是否最高效呢?
Mike Cohn 建议回答下列 9 个问题,而且都能得到肯定回答,那就是一个结构优秀的团队。问题列表包括:
- 团队的结构是否强调自身的长处,支撑短处,而且支持、激励团队成员?团队某个成员的弱点应该可以被其他成员的优势所补足。
- 团队结构是否将必须同时属于两个团队的人员数目降到最低(而且避免有人同时属于三个团队)?试图同时着手多个并行项目、或是多个任务,都会损害进度。
- 团队结构是否能将团队保持在一起的时间延至最长?应该更倾向于让成员能够在长期内保持在一起的团队设计,这能让团队的感觉和联系保持长久。
- 组件团队的结构是不是只在有限而且易于处理的情况下使用?团队应该是功能团队,围绕着端到端交付可工作功能的方式构建。
- 是不是两个 pizza 这样的食物数量足够多数团队食用?大多数设计良好的团队应该有 7±2 个人。
- 团队结构能够将团队之间的沟通路径数目最小化?如果在待开发应用中做一个小更改,就会带来大量团队之间的沟通,那么就得好好看看团队结构了。
- 现有结构是否鼓励团队沟通?如果换个结构,团队就不愿意这么做?高效的团队设计鼓励团队或个人之间的沟通,可能他们本来不想这么做。
- 团队设计是否支持对于责任的明确理解?结构应该推进共享所有权和共同成功的理念。
- 团队成员是否可以对团队设计提出建议?他们应该感到这是他们构建起来的团队。
在回答完上述问题后,您是否相信您有高效的团队架构?为了让敏捷的做法帮您实现高效团队架构,您过去采取了哪些必要措施?
查看英文原文: Most Effective Team Structure
评论