最高效的团队结构

敏捷认为小团队的人数规模应该是在魔法数字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
个问题
,而且都能得到肯定回答,那就是一个结构优秀的团队。问题列表包括:

  1. 团队的结构是否强调自身的长处,支撑短处,而且支持、激励团队成员?团队某个成员的弱点应该可以被其他成员的优势所补
    足。
  2. 团队结构是否将必须同时属于两个团队的人员数目降到最低(而且避免有人同时属于三个团队)?试图同时着手多个并行项目、或
    是多个任务,都会损害进度。
  3. 团队结构是否能将团队保持在一起的时间延至最长?应该更倾向于让成员能够在长期内保持在一起的团队设计,这能让团队的感
    觉和联系保持长久。
  4. 组件团队的结构是不是只在有限而且易于处理的情况下使用?团队应该是功能团队
    围绕着端到端交付可工作功能的方式构建。
  5. 是不是两个pizza这样的食物数量足够多数团队食用?大多数设计良好的团队应该有7±2个人。
  6. 团队结构能够将团队之间的沟通路径数目最小化?如果在待开发应用中做一个小更改,就会带来大量团队之间的沟通,那么就得好
    好看看团队结构了。
  7. 现有结构是否鼓励团队沟通?如果换个结构,团队就不愿意这么做?高效的团队设计鼓励团队或个人之间的沟通,可能他们本来不
    想这么做。
  8. 团队设计是否支持对于责任的明确理解?结构应该推进共享所有权和共同成功的理念。
  9. 团队成员是否可以对团队设计提出建议?他们应该感到这是他们构建起来的团队。

在回答完上述问题后,您是否相信您有高效的团队架构?为了让敏捷的做法帮您实现高效团队架构,您过去采取了哪些必要措施?

查看英文原文:
Most Effective Team Structure

This entry was posted in Agile. Bookmark the permalink.

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s