Scrum介绍——续
四、 Scrum过程
Scrum的过程如图4-1所示
图4-1 Scrum过程
4.1 建立Product Backlog
Product Backlog是Product Owner把客户的商业需求按照优先级排出来的列表，整个项目存在一个唯一的Backlog，Backlog的内容由Product Owner随时按照客户的需求进行更新，并且做出粗略的工作量评估，供开发团队进行参考。一个典型的Product Backlog如图4-2所示。
图4-2 Product Backlog
4.2 Sprint计划会议
Sprint会议用来确定Sprint backlog，Sprint会议计划会议是Scrum中最重要的一部分，在会议中，产品负责人告诉Scrum团队产品backlog中优先级较高的项，Scrum团队共同讨论产品backlog，一起决定接下来的一个Sprint中开发哪些功能，形成Sprint backlog，并估算Sprint backlog中每一项的开发时间。有一下事情在该会议中需要明确：
- Sprint的长度，Sprint的长度是一个trade-off的结果，Sprint越短，越"敏捷"，越能更早的看到成果，但是过短的sprint会使团队处于频繁的sprint机会会议、演示，发布等压力之下，目前建议的sprint长度为"三个星期"。
- Sprint的目标，每一个Sprint都应该确定一个目标，如果目标没有价值，就不应该开始这个Sprint。
- Sprint要包含的故事（story），就是要确定讲那些story从Product Backlog中放入Sprint Backlog中。
- 对每个Story的时间估算，scrum使用"纸牌"的方式，让每一个团队成员都参与到每一个Story的时间评估当中，具体操作是：买个成员都在纸牌上写下自己对当前story的评估时间，牌面朝下，等大家都已经完成后，所有团队成员把纸牌翻开，显示出自己对story的评估时间，如果团队成员评估的时间差距非常大，就需要大家再次进行评估，使用纸牌的好处是团队成员都可以对story的工作量进行评估，且不会受到其他人的影响，这样子得出的数据会更加的准确。
- 明确故事内容，确保让Product Owner和团队对故事有同样的理解，可以尝试将大的Story分解成不同的task从而便于理解。
4.3编写Sprint Backlog
在完成Sprint会议的基础上，由Scrum Master编写Sprint Backlog，Sprint Backlog可以由多种方式进行保存，excel等，本文推荐通过任务板来保存Sprint Backlog（将其挂在墙壁上），一个任务板的例子如图4-3所示。
图4-3 任务板Sprint Backlog
在每次例会后由Scrum Master更新该Backlog，可以看出，使用任务板的方式使得整个项目的进展情况一目了然，并且方便维护。
4.3.1燃尽图（burndown chart）
燃尽图清楚的表示在当前sprint中已经完成的story point和剩余工作时间的关系，燃尽图由scrum master在每日例会后进行更新，一个典型的燃尽图如图4-4所示。
图4-4燃尽图
4.4每日例会
每日例会在Scrum中叫"站立会议"，一般都不会超过15分钟，在每日例会后由scrum master更新任务板（包括燃尽图），在例会中每个人都会描述昨天已经完成的事情和今天要做的事情，以及自己遇到的问题（Scrum将会记录问题，在后续会解决这些问题），每日例会的主要功能就是update整个团队以及进度，它是一个汇报会议，每日例会不需要讨论具体细节，如果有细节需要讨论，单独发起会议，一个典型的每日例会如图4-5所示。
图4-5每日例会
4.5 Sprint演示
也叫Sprint评审，这只是简单的展示工作结果，所有与会人员可以提出问题和建议。会议可以持续10分钟，也可以是两个小时——会议目的只是对工作结果的展示和听取反馈在scrum中，所有的sprint都结束与演示，通过演示，团队的成果可以得到认可，其他人可以了解到团队在做什么事情，演示可以得到更多的反馈，通过演示会迫使团队真正完成一些工作。
4.6 Sprint回顾
在Sprint评审会议结束之后和下个Sprint计划会议之前，Scrum团队需要举行Sprint回顾会议。在回顾会议上，Scrum团队会一起讨论当前Sprint有哪些成功的经验，有什么地方去要改进。在回顾会议的最后，Scrum团队应该确定将要在下个Sprint中实现的改进方法。
回顾是scrum中非常重要的事情之一，因为这是改进的最佳时机，回顾主要做一下三件事情：
- Good 如果我们可以重做同一个Sprint，那些做法是可以保留的？
- Could have done better 如果我们可以重做同一个Sprint，哪些做法需要改变？
- Improvements 有关将来如何改进的具体想法？
五、 Scrum的挑战
Scrum不是流程－而是提供给团队可视性的框架，并且容许他们相应的"检验和适应"的技巧。Scrum试图让许多存在于开发团队中的问题显现出来。比如，大多数的开发团队并不擅长于估算在固定期间内完成的工作量，因此在第一个Sprint结束时不可能交付他们预计完成的工作。
对于开发团队来说，这个是工作的失败。事实上，这个经验正是能更好预计工作量所需的第一步，并促使其对承诺的任务更加负责。这种模式－Scrum可以使机能失调更易显现出来，让团队切实可以解决问题－是使用基础的技巧产生出最有意义的收益，是团队使用Scrum的经验之一。
一个开发团队普遍犯的错误是，当他们在Scrum实践中遇到挑战，他们会改变实践方法，而不是改变自身的问题。比如，开发团队有困难完成Sprint任务时，会延长Sprint的周期，这样他们就会有充足的时间完成任务——在流程中，确保自身不用提高工作预测的技能和更好的管理时间。这样，在没有经验丰富的Scrum培训师的指导下，开发团队只会将Scrum作为自身弱点和机能失调的映射，并破坏了Scrum真正的意义：使优点和缺点都显现出来，给开发团队自我的提高提供机会。
另一个普遍存在的错误是，人们以为某一实践方法是被禁止或不提倡的，只是因为Scrum没有明确的提出此方法。比如，Scrum并不特别要求产品所有者 (Product Owner)对于他或她的产品作出长远的目标计划；也没有要求工程师请教更有经验的人员关于比较复杂的技术问题。Scrum将这些问题留给个人作出正确的处理；在很多情况下，以上两个方法（和其他许多的方法）会被建议。做个正确的比喻："因为Scrum没有提到早餐的问题，并不意味着你就得挨饿！"另一个需要留意的问题是有时经理会强制开发团队使用Scrum；Scrum是为开发团队提供自我组织的空间和工具，由上层强加于开发团队恐怕不是取得成功的良方。 比较好的方法是让开发团队从同事或经理处了解到Scrum，并通过专业系统的培训，在开发团队实验此方法（比如90天）后作出决定；在实验周期后，开发团队通过经验的总结来决定是否继续采用此方法。
参考文献:
［1］ Henric Kniberg．硝烟中的Scrum和XP-我们如何实施Scrum．清华大学出版社，2011.1．
［2］ Pete Deemer，Gabrielle Benefield．SCRUM 简介-使用Scrum的Agile（敏捷）项目管理介绍
