【Scrum】敏捷软件开发——团队（1）
十、团队结构
给他们两个披萨
亚马逊团队的做法，指他们的团队吃两个披萨就够了
1、为什么两个披萨就够了
小团队有更多的优势：
1）社会惰化现象程度更低。当一个人相信其他人会同时参与的时候，不会轻易偷懒
2）积极的互动更有可能发生在小团队。容易简历信任感、共同的责任感以及凝聚力。
3）花在协调上的时间更少一些。小的团队在团队成员的协调方面花的时间会更少一些
4）没有人会消失在幕后
5）小团队会更满意他们的成员，因为一个人的贡献是很明显的
6）过分专业化的不利因素不太可能发生。规模小的团队成员在团队中表现得更活跃，更忠实于自己的团队，他们更深切体会到团队的目标，更熟悉其他团队成员的个性、工作角色和沟通的方式，并且关系更加融洽
2、小团队的效率
团队越小，每个团队成员的生产率越高
小团队完成项目需要的总的工作量更少
尽管如此，项目周期会拉长
在团队中有一些人只能有一个专业方向，但是有些人可以跨专业工作，这样的团队结构更容易平衡不同专业领域的工作量
支持特性团队
在一个多团队的项目中引入特性团队，有下面诸多优势
1）特性团队能够更好地评估设计决策带来的影响。
2）特性团队减少了交接带来的浪费
3）它确保了正确的人在讨论
4）组件团队会制造一些进度方面的风险
5）它保持着对交付特性的关注
1、保守地使用组件团队
组件团队，是指一个团队开发软件给项目的另外一个团队
组件团队在每个Sprint结束的时候还要交付高质量的、经过测试的、潜在可交付的代码
只有在特性团队要求的时候再构建组件
只要有机会，就应该组件特性团队，而不是组件团队，只有在如下条件都符合的时候才考虑组建组件团队
1）组件团队要开发供多个特性团队使用的功能。
2）使用组件团队可以减少共享的专家
3）多种方法的风险大于单个组件团队的不足
4）可以促进讨论，否则会保持沉默
5）可以看到不需要组件团队的那一天
2、谁来做这些决定？
理想情况下，应由团队自己决定他们的结构
但开始的时候，可能需要部门经理、项目经理、ScrumMaster或者其他想推动Scrum转型的人决定团队的结构和组织
3、今天对，明天可能错
没有一个团队结构是永久的，如果当前结构明显是错误的，改变它
自组织不等于随意组合
团队对指定目标的自组织能力使所有敏捷方法论的根本
不是所有的团队都选择同样的方式来组织，相比仅仅依靠人员管理者的智慧，使用团队的集体智慧通常是组织工作的最好方式
为项目选择正确的人，同时监测群体的动态变化，在必要的时候增加或是减少人手是一个关键的管理职责
人员管理者在组织团队时，应该考虑以下因素：
1）包括所有需要的专业
2）平衡技术水平的等级
3）平衡领域知识
4）寻求多样性
5）考虑持久性
一人一个项目
“哪个项目最厉害，就为那个项目工作”
1、任务太多的时候，花在单一任务上的时间会减少
任务切换会涉及一些成本，开始一个任务，然后切换到另外一个，然后再切换回来，这会有一个巨大的开销
2、何时可以多任务
1）一般来说需要避免大多数团队成员的多任务
2）如果一个人在一个项目上的工作量不太饱和，那么多任务也许是可以接受的
3）宁可让少数人承担更多一些的多任务，也不要让每个人都有少量的多任务
3、公司的多任务表
如果企业每次做的少一些，项目就会更快做完
如果希望团队如期完成项目，就必须限制工作量
4、立刻停止
1）在做好充分准备之前不要启动项目
2）企业计划中要包括启动和收尾时间
3）制定简单规则
4）虽慢也要前进
良好的团队结构指导原则
1）这个结构是否可以突出优势，弥补不足，并帮助团队成员提高积极性？
2）这个结构是否可以尽量减少被安排两个项目的人数，并且可以避免任何一个人被安排三个项目？
3）这个结构是否可以最大化团队成员的相处时间？
4）组件团队的使用是否是受限制的，并且只有在简单适当的情况下使用？
5）只有两个匹萨，你的团队是否够吃？
6）这个结构是否可以最小化团队之间的沟通路径？
7）这个结构是否可以鼓励那些不主动沟通的团队之间的沟通？
8）这个结构是否有助于清楚地理解责任制？
9）团队成员是否对团队结构的设计提供一些输入？
承前启后
在构建多个团队的时候，应该力求支持特性团队，尽量避免使用组件团队，但同时也承认，组件团队在某些情况是有好处的
对于任何团队，团队成员都需要花精力和心思去挑选
