《scrum敏捷软件开发》

第十章：团队结构

没有一个团队结构是永久的。如果当前的团队结构会影响项目使用scrum，这个问题需要在sprint结束时在回顾会上提出来。谁都不愿意频繁改结构，因为团队需要时间来形成凝聚力，但如果当前结构明显是错误的，请改变它。

1. 小团队优势

社会堕化现象程度更低。社会堕化是指当一个人相信其他人会同时参与的时候，他会有意偷懒。小团队的成员不容易出现社会堕化。

积极的互动更有可能发生在小团队。结论摘自《组织行为学精要》，一个团队如果超过10到12人，很难简历信任感、共同的责任感及凝聚力。

花在协调上的时间更少一些。一个简单例子：都知道为一个大团队安排一次会议就很麻烦。

没有人会消失在幕后。在大型团队中，团队活动和讨论的参与程度相比小团队相对较低。

小团队更满意他们的成员。在一个小团队中，一个人的贡献是很明显和有意义的。

过分专业化的不利因素不太可能发生。举例：小团队成员不可能只对一小部分工作负责。

2. 把正确的人放入团队

包括所有需要的专业。作为一个跨职的团队，囊括所有从功能的想法阶段到实现阶段必要的技能是很重要的。scrum团队成员学会其同事所拥有的一些技能，这些成员有了更广泛的技能之后，其他一些人可以转移到另外的团队。

平衡技术水平的等级。除了考虑团队的规模，应该力求团队技术能力的平衡。高级、中级、初级程序员都要有，团队技术的平衡不仅可以使不同经验的程序员找到喜欢的特性开发，通过相处也可以从经验丰富的程序员那里学到东西。

平衡领域知识。正如我们力求技术能力的平衡一样，我们要在我们工作的领域知识的深入方面或者在我们试图解决的问题方面找到一个平衡。

需求多样性。多样性可能意味着许多不同的事务，性别、种族以及文化只是其中的3个。

考虑持久性。团队成员学会很好的协作是要花时间的。因此，力求让原来有良好协作的团队成员保持在一起。

3. 一人一个项目

一个人如果被分派到多个项目工作，不可避免会完成得更少。

4.公司的多任务表

多项目同时进行，这样式多数情况是，项目很难如期完成。

《哈弗商业评论》对12家公司进行的8年研究后得出一结论：“如果企业每次做得少一些，项目就会更快做完。”

在未做好充分准备之前不要启动项目。把必备条件准备好，这样的研发周期预估才能更趋近真实。

企业计划中要包括启动和收尾时间。也就是我们项目研发一定要留出容错时间来解决那些不可预估的高优先级缺陷。

制定简单规则。在一些简单规则上获得一致意见有助于引导正确的组织行为。

总结：

本章其实更多将的是小团队有多好，和项目从开始到结束的重要注意事项。怎么说呢，还是给了自己很大帮助，一些关键问题，还是帮助自己整理出来，并强化到理论层面。最后给自己加个油，要更多去吸取前人经验，让自己所处团队之后可以走向敏捷，自己也要争做一个合格的scrummaster。