跟我读Scrum Guide #8 “小”团队,大学问
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
徐东伟Jack
扫码关注公众号
扫码阅读
手机扫码阅读
文章讨论了团队规模对于工作效率的影响。首先指出,团队人数太少时,可能面临任务繁重、技能缺乏、盲点和偏见等问题,导致工作效率降低。(1// 人太少不好)
然而,团队人数过多也会带来沟通协调的成本增加,导致实际工作时间减少。此外,管理层的介入可能会降低生产率,而大团队更易出现摸鱼现象、人员流动大,以及难以了解每位成员的具体工作内容。(2// 人太多也不好)
有研究表明,团队规模在增大到一定程度后,绩效会下降。例如,4人的团队通常绩效最高,而超过9人的团队生产力会降低。还有研究发现3人是最小的、比单独工作效果更好的团队规模。由此,Scrum Guide推荐的开发团队人数为3-9人。(3// 究竟多大团队合适?)
在扩充团队方面,建议应从小团队开始,仅在必要时增加成员,因为交叉培训和学习新知识往往比增加人数更有效。(4// 团队增长的原则)
文章还警告了几个关于团队规模的常见误区:团队人数多不代表战斗力强;不应轻易采用规模化敏捷框架,而是应尽可能维持小团队的独立性。(5// 要格外注意的坑)
最后,文章由徐东伟敏捷教练公众号提供,此公众号关注敏捷转型、业务敏捷和敏捷组织等多个方面,旨在推动中国的敏捷事业发展。
徐东伟Jack
徐东伟Jack
扫码关注公众号
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
徐东伟Jack的其他文章
当你开始觉得自己现在一切都足够好时,你的好日子才刚刚开始
“当前已经足够好”,你值得拥有!
如何对软件项目经理进行量化考核?
本文934字,阅读约需3分钟。最近有小伙伴在问“如何对软件项目经理进行量化考核”,我非常想和大家交流一下我的
领导在专业上绝对碾压下属究竟有多重要?
领导在专业上绝对碾压下属会发生什么?
天哪,你们的迭代竟然是这么玩的!
“迭代”这个词现在简直是被用滥了,大家都在号称自己是在玩敏捷、跑迭代。然而走近一看,真可谓是“挂羊头,卖狗肉”!
跟我读Scrum Guide #2 Scrum真没要求那么多,是你想多了!
是时候重新审视《Scrum Guide》,是时候重新审视自己的Scrum实践,回归本源!
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线