当前位置: 沃微圈 > 互联网 > 电子商务 >

最高效的团队结构

来源:转载

敏捷认为小团队的人数规模应该是在魔法数字7上加减2。敏捷也推荐完整团队概念,就是说团队内部要有足够的技能以完成工作。因此,开发团队除了具备核心的开发技能,还要具有测试技能、数据库技能、用户界面技能。然而,很多组织仍然纠结于最佳的团队规模和有效的团队构成。

Scott-Ambler建议:根据项目需要,可以有敏捷小团队敏捷大团队。小团队有标准的Scrum角色,比如scrum-master、开发团队和产品负责人。小团队还可以使用支持队伍,包括DBA、领域专家和测试人员这样的技术专家。大型团队需要“团队的团队(team of teams)”这样的方式。Scott认为:精益开发管理策略之一。让团队做好质量保证和文档相关工作并不现实。他们改进了团队构成,增加了两个角色。软件质量工程师负责一个sprint的产出的质量,文档专家负责创建用户指南、管理员指南和培训材料。Scrum Development讨论组中一个有关团队大小的讨论时指出:Mike Cohn建议回答下列9个问题,而且都能得到肯定回答,那就是一个结构优秀的团队。问题列表包括:功能团队,围绕着端到端交付可工作功能的方式构建。

典型策略是:把多个相关小团队组织起来,形成更大规模的团队,最有效的方式是围绕着系统架构的方式组织。每个子团队应该负责一个或几个子系统,让他们可以像小敏捷团队那样,负责按时交付可工作的软件。这个策略常被称为“Conway法则”,因为是Melvin Conway在二十世纪六十年代后期提出来的,也是

Steve Miller认为:除了Scrum推荐的角色之外,要想

同样地,Michael F. Dwyer在回应

趁着Ron Jeffries还没说,我先借用他那个著名的话“2+2=5,因为这两个粗略的‘2’要比数字2更大一点。”团队规模可以是1个人这么小,也可以是500人这么大,完全基于你对团队的定义和成员的投入程度。

因此有一个共识:团队的规模和构成要根据各个项目具体情况调整。然而,我们应该如何评价我们的团队结构是否最高效呢?

 

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

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

分享给朋友:
您可能感兴趣的文章:
随机阅读: