Scrum
小规模实践心得
作者:KingFo 撰写日期:2008-6-30
“Scrum，源自英式橄榄球，团队成员在商定好战略后，按照预定章法向前冲。
在软件开发模型中，这个词代表了敏捷开发的一种。它主要强调的是重新开始迭代的过程，而不是企图补救问题，诸如某公司的产品的本身就是建立在客户的即使反馈上，这意味着在开发过程中需求总是不断的变化和交错的。”
一个典型的例子是，某公司接到一个项目，在这项目开始前谁都无法给出该项目具体的最终形态和功能需求，可能仅仅只知道该项目应该成为什么样子，或者应该向什么方向发展。在项目展开阶段过程中，无论创意、策划、研发都需要通过各种尝试性的错误，才能正确定位。这就好比是英式橄榄球中，除了明确知道最终目标是什么，谁都不知道过程中会发生什么，这就需要各队员间的高度配合，和高度自由的密切合作，以及拿到球就往前冲。
通常的Scrum开发流程一般以30天或更短为一个阶段，由于我们Adobe RIA技术团队具备相对其他开发组的人力及人员涉及面优势，故将迭代周期制定为一周，在这一周内我们所需要做的是
1. 尽量在这周内完成已定目标。
2. 每天通过昨天的目标是否完成、目标是否遇到障碍、今日如何开始的三个问题进行每日15分钟的例会，这些例会都是在上班开始后15分钟内举行。
3. 在周一召开的是未来一周内所需要的目标评估制定，和明确到每日的必完成事项。
4. 在周六召开的是这一整周下来的问题性团队解答，以及产品的回顾和评审。
下面将详细阐述整个周期从开始到结束，以及再开始的过程，我们可以把这样的周期看成为“开始->结束->再开始”的过程.
在开始的详细叙述之前，需要强调的几个关键词和解释按序号罗列如下：
1. 产品负责人(Product Owner)
一般是指由产品经理指派，或产品所有者指派的，负责跟踪和提出产品相关需求的人员，人数一般为1-2名。
2. Scrum管理员(Scrum Master)
一般是指了解和熟悉Scrum过程，或者愿意出面担当整个项目负责人，以及向产品负责人以及团队之间解释和帮助理解Scrum的利益，以获取整体的帮助和支持。他主要负责的是已定例会的及时召开，以及产品项目整体跟踪。一般指定1名。
3. 待办事项(Backlog)
就是对已知事项，通过三要素(重要性、优先级、要求目标)进行罗列的事项列表。以一项一条列出。
4. 已知产品事项(Product Backlog)
由产品负责人提出的产品上大致的功能性和非功能性的需求列表，按客户需求以重要性和优先级罗列的大致事项。这是给出方向性的第一步。
5. 选定产品事项(Selected Backlog)
这是由产品负责人和项目团队间，通过对已知产品事项(Product Backlog)及有效沟通，将最可能完成和相对成本较低的事项按次序罗列的表格。
6. 迭代冲刺期事项(Sprint Backlog)
这是仅仅由项目团队内部，自我选择和自主担任的事项列表，以确保在已制定的迭代期时间内能够完成的事项，按预计完成日期顺序排列的表格。
7. 障碍和问题事项(Obstacle Backlog)
这是由项目团队内部，通过策划，创意以及研发中失败以及在迭代期内暂时无法完成事项，按时间顺序罗列的表格。
关于开始：
首先，我们要做的就是关于产品的信息收集，这个时候可称为全员通报大会，主要是召集被选定的团队人员以及产品负责人(Product Owner)进行本次项目通报，收集尽可能多的信息。在这期间，除了明确产品的大致方向外，有必要向相关人员解释他们所在整个项目中的相应角色及作用。另外需要明确的是在整个周期过程中的例会次数和时间，以及指定出明确的集体交流场所。通过相关描述将产品的方向性内容罗列成为已知产品事项(Product Backlog)。
其次，由团队和产品负责人之间，相互沟通，以让彼此明确每个产品事项的重要性和优先级(即所谓的紧急性)，团队沟通的明确目标是将最重要的和最紧急的事项，通过工作量/工作成本一一罗列出，并让产品负责人明白哪些可以细分工作，哪些是可以更快完成，哪些是需要具备某些资源后才能开始。并按工作量或工作成本较低的几项纳入到选定产品事项(Selected Backlog)中，并罗列成表格。
再次，由团队内部，通过已有人力物力，从选定产品事项(Selected Backlog)中选出相关事项最佳负责人选。然后各相关事项负责人可以按自己的能力将事项再分为自己最小时间能达成的事项，这是最关键和最重要的部分。通过对该事项的工作量，工作时间，以及完成日期的确定，这时，迭代冲刺期事项(Sprint Backlog)就完成了。
接下来，就是冲刺期间的最小单位团队间的每日例会，依次按三个问题提问:
1. 昨天的目标是否完成？
如果已完成，则会后通知与此相关的责任人。且直接回答第三问。
未完成则讨论第二问。
2. 目标遇到什么困难和障碍？
将困难的特征描述，以获得团队内部其他人员的提示，以便于更好的进行。
如果该困难需要更多的资源支持，可尝试性的将问题拆分为若干子项。
如果该困难需要花费更多时间完成，则在预期周期内可以考虑选择，周期以外的，按紧急程度会后向产品负责人提出请求。并将该问题按发生事件和所在周期罗列入障碍和问题事项(Obstacle Backlog)中。
3. 今天如何开始？
这主要描述的是，障碍或者接下来要解决的事项如何开始，完成后向谁提交等等问题，以及可能在开发中涉及到的遗留问题。诸如，前项未完成，牵连到当前的几项，依次按障碍和问题事项(Obstacle Backlog)的要求罗列入该表中。如果当前迭代冲刺期事项(Sprint Backlog)在上述事项中已空，则再次从选定产品事项(Selected Backlog)选择自己相应能够完成的或者感兴趣能完成的事项，添加到当前迭代冲刺期事项(Sprint Backlog)中。
看上去可能整个敏捷体系比较复杂，其实，整体运行起来抓住以下几个关键词就相对来说会更容易些，当然，如果只是团队中的一员，这些完全都不用考虑，只需要知道直接感兴趣和能够最快完成的事项以及如何高效完成就可以了。
整个体系个关键词就是
a) Backlog
--- 罗列尽可能多的事项
b) Packets
--- 将Backlog单元分配及相关任务打包指派
c) Changes
--- 将变动反映到每个Packets中去
d) Problems
--- Changes产生的难题都必须具备对应的解决方案和解决链
e) Issue
--- 从Backlog到Packets指派过程中应该落实的事宜
f) Solutions
--- 针对Problems或Issue解决方案及产生的Changes
g) Risks
--- 针对时间、需求、竞争力、质量、可用资源、产品远景的风险评估
当然，本人也是仅仅是该方式的新手级人物，主要是感觉这样的思想很方式很适合像我们这样Adobe RIA技术的团队。
以以下网络摘录的心得作为本稿的结束：
“1.有商业价值的东西才是企业的目的。
2.团队有权限自行设定交付期限。
3.交付可以使用的软件是最为重要的目标。
4.预先建模和需求采集阶段则要求尽量简单。
5.需求采集并不是在项目早期便结束，而是会在项目开始后很长时间内一直进行的过程。
6.敏捷开发先交付最有用的部分。
7.敏捷注重的是反馈,反馈是双向的。你可以知道增量版本功能是否符合要求，而客户则可以知道你现在在干什么。
8.最好的构架、需求和设计出自于自组织的团队。
9.目标是明确的（不排除有些客户目标也不明确），但是具体怎么做，开始时是没有想法的。
10.敏捷强调的是自组织团队，发挥人的能动性，以动力代替压力，让人有绝对自由的错觉。
11.敏捷不是许多人独立负责开发项目的各个部分，而是大家联合起来，作为一个团队来开发某个部分。”
相关参考：
《Scrum And Xp From The Trenches --- How we do Scrum》
---Henrik Kniberg
《Microsoft .NET 技術代言人專欄：敏捷的軟體開發流程》
---作者：林耀珍 2003 年 11 月
《What is Scrum?》
---http://www.controlchaos.com/about/
《Scrum Checklists》
---http://www.sprint-it.com/scrum-checklists