敏捷的角色主要有三个：Product Owner、Scrum Master、Scrum Team，这些角色与传统开发都存在着一定差别，并主要体现在职责、工作方式、组织架构上。
又到了建立新组的时候了，老板提议和友组提议：开发组最（Yi）近（Zhi）人手有点不够，不如让小翅同学同时担任Scrum master和Product Owner吧？
友组老板特别紧张：不不不，Scrum master怎么可以同时担任Product Owner! 我们得想别的方案。
老板：那就让小条担任Scrum master吧！
友组老板：不不不，小条是开发人员，开发人员不能担任Scrum master，product Owner不能担任Scrum Master! 这些角色不能串！
老板：（干！）那我当Scrum master行了吧！
……
在上一篇《自从用了敏捷，天天在开会？ 4大Scrum会议如何才能有意义？》中，讲到Scrum之所以区别于传统开发，主要是体现在三个方面：角色（roles），会议（Ceremonies）和产物（Artefects）。
今天我们从如何组队来聊一聊Scrum角色，以及组建敏捷团队的那些事儿。
概要
角色的主要工作（会议主导+产物对应）
角色的误区是什么
敏捷有一个经典但不是很好笑的的鸡猪梗。
一天，一头猪和一只鸡在路上散步，鸡看了一下猪说，“嗨，我们合伙开一家餐馆怎么样？”。
猪回头看了一下鸡说，“好主意，那你准备给餐馆起什么名字呢？”
鸡想了想说“餐馆名字叫火腿和鸡蛋怎么样？”
“我不这么认为”，猪说, “我全身投入，而你只是参与而已。”
“猪”角色 是全身投入项目和Scrum过程的人。Scrum有3个“猪”角色：
Product Owner
Scrum Master
Scrum Team
“鸡”角色 鸡角色并不是实际Scrum过程的一部分，但是必须考虑他们。 敏捷方法的一个重要方面是使得用户和利益相关者参与到过程中的时间。参与每一个冲刺的评审和计划，并提供反馈对于这些人来说是非常重要的。这些角色包括：
用户：软件是为了某些人而创建！
利益所有者 (客户，提供商)： 影响项目成功的人, 但只直接参与冲刺评审过程。
管理者：为产品开发团体架起环境的人
一言蔽之，一个传统开发团队想要转化成敏捷开发团队，可以从以下的对应表格做出转型。
图片来源：一条翅膀
那么，这三大角色与传统开发相比有什么区别呢？我们来谈一谈：
2.1 Scrum Master：The protector护法大师
Scrum master的角色任务是服务型领导，相当于牧师给团队加血的萨满或者鸟德，他主要保证：
对内：确保团队友爱地协作，敏捷相关会议各种有效运行。
对外：为团队撑起保护伞，扫清障碍。
这个角色与项目经理的角色非常像，然而他们在工作战略上是有本质区别的：
SM的后缀是Master，俗称师傅。
师傅的目标就是让团队践行Scrum的思想，构成一个美丽的敏捷团队。他们熬好一碗碗鸡血，源源不断得供给团队，但是又独立于项目的实质内容，跳出生产之外。
项目经理的后缀是Manager，尊称经理。
经理的工作重点放在管理上，内容无非就是与项目相关的进度、成本、质量、范围、风险等等内容。
在具体落实上，他们气质的不同之处体现了团队文化——
图片来源：一条翅膀
2.2 Product owner：The hub of business value需求价值中心
Product Owner角色的定位和产品经理非常像，主要负责：
定位产品相关所有内容，包括做什么/优先级/发布时间/投资回报
判断团队的开发成果是不是所需
产品负责人可以是项目经理、业务分析师、系统设计师、用户体验架构师以及所有其他业务组……所有这些都集于一身。这个角色应该是无所不能和无所不在的。
由于PO是一个非常艰巨的角色，所以有时候可能PO是一个团队组成的，这个团队可以包括：
产品经理 – 与利益相关者合作，确定需求并确定优先级。
项目经理 – 保持对总体目标的看法。管理资源，资本支出，外部依赖等。
业务分析师 – 负责记录验收标准并记录围绕用户故事的对话。 sprint期间需求澄清的主要联系人。
设计师 – 准备一些屏幕截图，线框等。
PO和PM有什么区别呢？
理论上，PM会更加倾向外界沟通、市场和客户分析、指定长期产品战略。PO会比较倾向于内部的需求执行。
落实到具体操作，大型养老公司才把角色分那么细吧！
PO这个词被引入的时候大概是20年前，那时候PM的概念可能是偏向对外，但是放到现在，这两个角色的责任已经差别不大了。
2.3 The development team：懂更多的开发团队
Scrum的开发团队，差不多和传统还是同一批人。但是他们需要懂更多！
Scrum要求开发团队成员由一批跨职能的人组成，他们拥有完成每个产品增量所需的全部技能。
他们也需要以自组织的方式实现Sprint目标，根据Sprint的计划完成产品增量
他们要有能力和客户沟通讨论解决方案，也要和PO确定产品是什么
对比如下：
图片来源：一条翅膀
我们在敏捷指导的很多概念手册中， 可以看到很多一串串的角色任务。其实，团队的具体职责可以用会议（Ceremonies）和产出（Artefacts）来定位。
图片来源：一条翅膀
3.2 敏捷产物和工作的职责
图片来源：一条翅膀
案例1： 客户愿意花多少时间解决问题
敏捷开发试图构架一个美好的乌托邦：
客户和整个开发团队包括研發、測試、架構師把酒言需求，大家一起在白板上涂鸦，最后，在场的人统一，这是一个足够好的解决方案，虽然很有可能和一开始的图已经很不一样了。
整个方法最妙的地方是通过沟通，加分客户爸爸可以一起思考类似于五彩斑斓的黑的需求可能会怎样实现，前期定调，最后的产品大概率可以通过验收。
那么问题来了，客户爸爸很有时间吗？
很多时候，客户只希望透过几次的文件讨论，就能沟通好需求。
而开发团队也未必有那么多时间陪客户玩儿。
这时候就是考验一个PO是不是一个好PO的时候了！
他需要足够好的沟通能力，让客户理解既要马儿跑（需求被100%了解），又要马儿不吃草（又不想花时间好好讨论）」是不能解决问题的。
一个好的PO, 也需要有“忠实传达客户需求和即时决策”的能力，并平衡好客户和团队理解需求的数据！
传统的方法之所以会常常出问题，就是对客户的窗口（PO）经常被内部开发团队一问三不知，纠缠在需求的厘清中。在来来回回多趟之后，仍然是不清不楚，这才是最大的问题！
如果PO有能力领导一个小组（也许是2-5人不等）去跟客户/用户面对面地讨论需求，不论是在使用者经验（User Experience）的设计层次上，或是在系统分析、架构设计（Architecture Design）、实作性、验证性等技术层面上，都能考虑得够周详、够务实、够让客户/用户满意，那么这位PO就是一位成功的PO了。
此后，PO就有足够可靠的代表性来代表客户/用户做对内的沟通。这样小组能够做到即时又有效率的各层面决策，无形之中就大幅缩短了客户被不断打扰问需求的总时间，客户也会乐于接受这样的互动方式。
案例二：到底PO可不可以同时是Scrum master
我们在一开始聊到在组队之初很有可能因为人手不够，一个人安排两个职位。
这个提议会被很多把Scrum教材放到头顶的朋友阻挠。
事实上，很多岗位的操作是可以和Scrum的标准定义有些不一样。没人禁止PO带着DT的成员去跟客户见面讨论事情，更没人说专案经理不能是SM！也没有人规定DT人数一定要在9人以下！
一切的说法都只是“原则”（guideline），而不是“规定”。
只要组织能接受，效果能出来，谁管你有没有完全符合Scrum的标准定义？
敏捷开发的核心是什么？是敏捷呀！！！是解决任何问题是灵活的思路！
所以，请不要被任何人的定义绑住思维，只要能够符合组织现况，能够改善问题，甚至是彻底解决问题，这才是引用一个新方法架构的重点！
尤其是，当你想要解决一个组织内的陈疴之时，最好也能像Scrum的Sprint（冲刺）那样，逐步渐进式地，看看效果如何之后，再修正一下，然后再往前进一步。
就像你走路或开车一样，都是边走边修正脚步，或边开车边调整方向盘，最后才能准确地到达目的地。
