Scrum 之 团队

开发团队

        在传统的工作方式下，开发团队会有很多不同的角色，比如项目经理、产品经理、架构师、设计师、用户体验设计师，程序员，测试人员，DBA等等。但是，在Scrum的工作方式下，总共只有三个角色， 这三个角色分别是产品负责人（PO）,Scrum Master和开发团队。

        我们通常可以以划龙舟的团队角色来类比Scrum的角色，划龙舟通常有舵手、鼓手、划桨团队三个角色。Scrum中的PO就是舵手的角色，他对产品的方向负责，对产品的Why和What负责，对产品的愿景，产品包括哪些主要的特性负责。Scrum中的Scrum Master鼓手的角色，他帮助团队保持高昂的士气，并进行良好的协作，他是一个Scrum的专家，团队的教练，团队的服务式领导。Scrum中的团队，对应到龙舟赛的划桨团队，团队必须协调一致，作为一个整体前进，在这样的环境下单打独斗，各自为政没有任何胜算。

        Scrum的开发团队对实现Sprint目标需要做的所有事情负责，包括技术方案和决策，团队分工（谁做什么），执行Sprint开发任务等，而且作为自组织的团队，他们也对他们的工作进度的跟踪和管理负责。Scrum开发团队的主要职责包括如下五个方面：

                1.执行Sprint

                2.梳理产品Backlog

                3.做Sprint计划

                4.每天跟进工作进展，并对他们的工作做检查和调整

                5.每个迭代对产品和团队的工作过程做检查和调整

开发团队的特征：

        自组织、多元化、跨职能的完整团队、团队成员符合T型技能，即一专多长、持续改进、最大限制的沟通、透明沟通、2个披萨的团队大小（5-9人）、专注、投入、按照可持续的节奏工作、团队长期存在，人员稳定

自组织团队

        自组织团队是敏捷软件开发的基本观念 。敏捷宣言的原则中提到 :“最好的架构、需求和设计出于自组织团队 ”。自组织团队也叫做自管理团队、或者被授权的团队。团队被授权自己管理他们的工作过程和进度、并且团队决定如何完成工作。

自组织团队和经理领导的团队的区别

        对于经理领导的团队来说，团队成员被分配任务，团队成员只有执行任务的权利。

        对于经理领导的团队来说，管理者除了要确定目标、方向，团队的上下文（组织结构、团队结构、团队组成），还需要监督和管理团队的过程和进度，分配任务即确定谁做什么。这种团队的管理方式，更多的是命令与控制，以及微观管理。

        对于自组织团队来说，他们拥有如下权利：

                1.团队决定谁做什么，即任务的分配

                2.团队决定如何做，如何实现目标，即团队做技术决策

                3.团队需要在确保目标的前提下制定团队内的行为准则

                4.团队有义务保持过程的透明性

                5.团队监督和管理他们的过程和进度

        在自组织团队的环境下，管理层关注在如下几个方面：

                1.确定团队目标和愿景

                2.确定团队上下文，组织结构、团队结构、团队组成

                3.提供环境和支持（安全感、良好的团队空间、氛围，技能辅导等）

                4.授权团队

                5.训练协作

        对于自组织团队的普遍误解：

                误解1：团队自己决定目标是什么 ； 纠正：管理层决定团队目标

                误解2：团队自己决定谁进入团队； 纠正：管理层决定团队上下文

                误解3：团队自己设计团队结构； 纠正：管理层决定团队上下文

                误解4：自组织团队不需要管理者； 纠正：管理者从微观管理转向目标驱动、授权团队的管理方式

                误解5：自组织团队需要员工更加主动； 纠正：自组织让团队更加主动，每个人都不喜欢被命令和控制，每个人期望有成就感、期望被认可

                误解6：自组织团队想干什么就干什么； 纠正：管理层决定团队目标，团队决定如何实现目标

        一个自组织的团队通常由不同职能专业、思考方式和行为模式的成员组成，也就是说它是跨职能的团队。

        自组织的团队不是与生俱来的，打造一个团队需要一个过程，打造一个组织团队也是一样。打造自组织团队，首先要让团队需要完全自主； 其次，有了自主，管理者需要引导团队持续改进，帮助团队持续地挑战更高的目标；第三，给团队提供环境和支持，引导团队往正确地方向迈进。

特性团队

        如果我们的产品开发团队只有在10人以内，我们使用一个跨职能的Scrum团队，可以很容易地按照scrum和敏捷的方式开发产品。 但是，如果产品团队规模较大，比如是几十人，甚至几百人的开发团队的时候，我们就需要考虑团队的结构和组织方式。

        在一个大的开发组织中，Scrum会把大的开发团队划分成多个5-9人的小团队，那么我们应该按照什么方式来划分呢？

        在传统的开发模式下，我们习惯于按照系统的架构模块，或者系统分层组织团队，也有的团队按照系统需求、开发、测试结合系统架构混合组织的方式。这种团队组织的方式，我们称之为组件团队，是指每个团队只是完成系统功能的某一个部件，而不是一个端到端用户可见的功能。

        组件团队看起来像这个样子：

        按照Scrum和敏捷的交付模式，组件团队有如下一些限制：

                第一：按照组件来组织团队，很难避免团队之间的依赖，跨团队的协调和依赖管理更加复杂，不利于跨组件或者各个层之间的沟通。

                第二：每个团队专注在自己的模块，由于各模块、或分层需求工作量的不同，很容易产生等待，并且容易产生低价值的交付。

                第三：由于职责单一，限制了学习，使得专业更加单一化

                第四：Sprint结束的时候无法提交可交付的增量产品功能，延迟价值交付

        按照Scrum和敏捷的交付模式，以用户为中心，按照用户场景作为边界来组织团队是比较推荐的做法。这种以用户为中心的团队叫做特性团队。

        特性团队的特点：

                1.长期稳定的团队，逐个端到端完成客户特性

                2.以客户为中心的特性驱动

                3.跨职能、完整团队

                4.共享代码库，统一的持续集成

                5.拥有通用型专家

        特性团队看起来像这个样子：

        特性团队的好处：

                1.团队内可以做到端到端，所以减少了等待，周期加快

                2.比较容易在一个Sprint中交付可用的产品增量

                3.减少了团队之间依赖，计划会更容易

                4.责任范围的扩大，各种不同领域的专家在一个团队，增加了

                5.个人学习和团队学习的机会