SCRUM的七经八络

一个完整的SCRUM的项目周期可以由一组迭代周期“Sprints”组成， 这个周期也可以与极限开发（XP）的迭代周期类比， 一般典型的迭代周期为2-4周或者最多一个自然月，太长就没有了敏捷的字面意义，但这只是一般而言，迭代真正Sprint长短是由Product Owner能够保障多久需求变化不影响到产品研发来决定的。一个固定的周期能够创造出项目的更优美的节奏感，我们会在以后出现的一个单词“TimeBox”来形象描述这个节奏，而所有关的产品的设计，开发，测试全部都需在一个迭代内完成，TimeBox严格执行，每个迭代都是如此。

图3. SCRUM的标准流程

SCRUM的重要参与角色由产品责任人（Product Owner）， Scrum Master和团队（Team ）组成。

 

其中ProductOwner主要之职责是需要定义产品的功能，并决定产品发布的日期和内容，在和投资人的谈判中，ProductOwner需要负责规划产品的投入和对产出负责；ProductOwner始终保持着对市场和来自客户阶段性需求和反馈的敏感度，需要根据这些变化对产品所需开发的功能模块进行优先顺序排列，在拥有多位业务人员的团队中，ProductOwner尤其需要统一团队对需求的定义和优先级排列。在迭代开发的流程定义，和产品的发布计划时ProductOwner需要合理的调整迭代主题和迭代周期长短；在产品阶段性验收时，ProductOwner还需要参与并决定迭代成果的通过或者拒绝迭代的交付。

 

SCRUM Master 主要之职责需要对项目直接的管理，领导团队掌握SCRUM的方法和实践，并体现其价值；当团队在产品研发过程中遇到问题，SCRUMMaster首要的责任是利用资源直接或者协助其解决问题，以确保团队胜任其工作并保持高效的生产率。SCRUMMaster需要保护团队不受外来的无端影响，让团队能够在良好的工作流程和环境中紧密合作，发挥出团队中各成员各自职能的价值。

 

团队主要之职责是完成迭代中的设计、构件、测试、维护等工作。所有成员均分享团队一致目标，懂得如何配合，且无需外界过多监管而独立完成其工作，也愿意在需要的时候帮助团队其他成员完成艰巨的工作。最佳的SCRUM团队成员由5-9名成员组成，虽各司其职，如开发、测试、需求分析、图形界面设计等，在工作中均表现为能力综合的多面手。良好的团队能够自我管理和有较强的自知力、自制力。而在一个迭代、甚至多个迭代中团队成员均应该为全职工作，即全心全意的从事一个项目，个人职能在当下迭代最好是固定的，而在新的迭代开始后可以转换角色。

图3. SCRUM团队的组成

在SCRUM的游戏规则里，主要有”迭代计划、SCRUM例行会议、迭代验收和迭代回顾会议”主要的活动；

SCRUM 迭代计划会议 –  计划会议标志着一个迭代的开始，所有成员都需要参加这样的会议，目的是1. 通过分析、评估已有的产品Backlog，选择一些成为当前迭代的目标；2. 决定如何通过协作完成当前计划，从选出的Backlog中细分，可以以人时为单位、或者故事点为单位，团队成员领取工作项和评估所需要的工作量。在这个会上，Productowner和ScrumMaster领导会议的进行，其中

Product Owner需要确认哪些工作项最有商业价值，参考团队在技术角度的复杂度和可实现分析，设定当前的迭代目标。

SCRUM Master则主要负责记录和协调团队工作项、计划的认领，在已有产品之上构建新的迭代内容，或者迭代认领的工作项产生了相互依赖时，SCRUMMaster一定非常清晰的引导团队做出合理的工作项评估和必要的风险评估，并及时同团队和ProductOwner沟通；

团队的主要目的是根据所需要的最有价值的目标，尽可能按照价值队列来完成工作项目。而当团队成员认领的工作相互之间有依赖关系和关联关系时，需要考虑可行的计划和方案让自身的工作能够在不受干扰的环境中开展，且使被依赖工作项提交时间点尽可能对其他人产生小的影响。再者，就是将工作量细分，最好不要超过32个工作小时（如果以4周为迭代周期），而越是详细的细分，对工作量的评估也越是准确。

 图3. 迭代计划中迭代工作项的计划展开

 

 

SCRUM 例会 – 例会是一个禁止闲聊和说废话的会，所以要求大家每天都站着开，这个会不是为了解决问题，是为了给团队一个完整的画面- “我们在哪里，我们将去向哪里？”；同时无关的人，即使你是经理，只要不是团队、SCRUMMaster和ProductOwner都不需要发言，会上大家会交换彼此的承诺，而这个将通过以下几个问题的回答来执行：

1.        在过去的24小时，我做了什么？

2.        在将来的24小时，我要做什么

3.        我有什么工作现在被阻碍，或者我可能有什么工作会影响到其他人？

会议时间尽量控制在最短，说话的时间控制在1-3分钟，不需要对细节阐述，也不值得利用这个会议对事展开讨论；在队员回答三个问题的时候，尽量不要打断，SCRUMMaster如果没有很好的协同工具，则需要即刻记录，投影出来，让每个人都看得到。

 

迭代评审会议 – 迭代评审会议意味着迭代结束；经典的评审会议需要团队演示新增部分的功能，还要和技术的Stakeholder演示底层架构的实现；如果非正式评审会议，即没有客户参与的情况下，仍然需要提前准备这个评审会议，但是时间最好不要超过2-3小时；所有的关系人（stakeholders）、团队成员都需要参加，团队需要将ProductOwner和其各位Stakeholder的意见虚心接纳，在时间允许的情况下，尽可能做出充分的相应，即使没有能力回答和需要调查研究给出的反馈也需要在会上给出回复的时间期限；在最后，通常ProductOwner将会给出结论此次迭代是否完成了计划的工作，迭代是否成功。在累积了一定基础的功能后，客户将被邀请加入评审会议，则这样的评审会议更需要正式。

 

迭代回顾会议 – 迭代回顾会议是为了总结工作中的经验和教训，是团队持续性改进和提高的重要工作，一般在1-2迭代完成后，团队成员、ProductOwner、SCRUMMaster 会通过讨论和自我剖析，分析在当前环境下最迫切解决的问题和所需提高的实践；大家尽可能针对自己的工作如何改进提出意见和方案；SCRUMMaster需要做好调解会议气氛的准备，避免讨论陷入僵局或者争吵。