第二部分 Scrum的角色 笔记和感想

Scrum团队包含3个角色：产品负责人，Scrum Master和开发团队.产品负责人负责最大化产品价值，是管理产品待办列表的唯一责任人。他负责回答“开发什么样产品”，是“What Person”。开发团队负责在每个冲刺结束的时候交付产品增量，负责回答“怎样开发这样的产品”，是”How Person”。Scrum Master负责确保Scrum被正确理解和执行，是Scrum团队的服务型领导，负责回答“Scrum Process”方面的问题，是“Process Person”。

结合Ken在第1章引言中用Cynefin框架分析分析问题域，不防分析一下Scrum团队的角色设计与Scrum适合解决的复杂问题有什么联系。复杂问题指不可预测性大于可预测性，需要采取创新的方法来探索答案的问题，例如开发一个创新型产品。复杂问题有三个子问题：第一个子问题“开发什么样的产品？”创新型产品的需求具有不可预测性，无法在开发早期明确，需要经历一边开发产品，一边收集反馈，一边调整，这样不断探索的过程。这个工作由产品负责人负责。第二个子问题“怎样开发这样的产品？”创新型产品的设计方案，使用的主要技术，具有不可预测性，难以在产品开发的早期完全确定，随着产品需求的变更，经过若干个冲刺，往往需要修改。这个工作当然由开发团队负责。第三个子问题，Ken指出Scrum特别适合复杂域，而Scrum这种敏捷方法本身“容易理解但难以掌握”，“怎样确保Scrum被正确理解和执行？”Scrum Master的角色就是专门来负责这个问题的。综上可见，Scrum团队的角色设计，与Scrum特别适合解决的问题类型是完全对应的。

当创新型产品的开发工作顺利进行，可以观察到产品负责人、开发团队、Scrum Master三个角色都工作的很好，“What”“How”“Process”三个子问题都找到了可行的答案。反之，当创新型产品的开发遇到困难，也可以从三个角色出发进行分析，看是哪个角色出了问题。

先举一个正面例子。某创新型项目，产品负贵人与客户沟通顺畅，总能在冲刺计划会议前准备足够多的产品待办项，在冲刺计划会议上清晰描述产品需求，在冲刺检视中得到客户对于本冲刺增量的认可和对于下一冲刺步需求。开发团队能够在冲刺计划时，集体讨论设计方案，在每日站会时，及时分享并解决开发中的问题，在冲刺结束时交付达到质量标准的产品增量。Scrum Master能够辅导Scrum团队践行Scrum价值观，辅导产品负责人处理产品待办项，辅导开发团队进行每日展会和回顾会议，推进Scrum团队的Process持续改进。这个项目的客户在一次重要展会上出色地展示了他们的产品，会后，客户给Scrum团队发来了表扬信，表达了希望长期合作的意愿。

举几个反面例子，第一个是关于产品负责人的。某创新型项目，冲刺计划会议前，冲刺待办列表常常空白。冲刺计划会议时，产品负责人能准备好的产品待办项也达不到一个冲刺工作量的一半。冲刺检视活动邀请客户参加，客户不予理睬。不出半年，这个项目就取消了。

第二个是开发团队的。产品负责人同时面对A、B两个开发团队。B没有完全理解需求，导致有些开发工作被浪费掉，虽然工作的很辛苦，但交付结果时有缺憾。相比之下，A团队比较聪明，先和产品负责人充分沟通，吃透需求再开发。

第三个是关于Process Person的。应客户要求，某项目的实际开发活动按照Scrum进行，但项目的Process Person并没有受到过Scrum方面的培训，不具备Scrum Master应有的知识，把该项目的流程裁剪为瀑布模型，要求项目组按照分析、设计、实现、测试分阶段提交产出物，过里程碑审批。这种情况导致两方面的问题：一方面，由于缺乏Scrum Master的辅导，这个项目的项目经理在需求的变更、排序等方面工作不到位，开发团队过度疲劳，交付质量出现问题，客户不满意，开发团队怨声载道。另一方面，项目组在所谓分析阶段写的需求规格书、在所谓设计阶段写的设计文档，与项目后期实际使用的需求规格和实际采用的软件架构大相径庭，无论对开发团队还是对干系人都毫无价值。