现在，已经读完了这本书，下面将介绍一下如何使用Scrum方法启动一个项目，这里的介绍将比较宽泛，因为在前面的部分已经详细讲述了Scrum背后的来龙去脉，这里只是简单介绍如何实施。
1 挑选一位产品负责人。
这个人必须知道自己带领的团队需要做什么，制造什么产品以及取得什么结果，全面考虑到风险与回报，可行性，以及大家的热情所在。参见第八章。
2 挑选一个团队。
团队规模宜小不宜大。一般3-9个人比较合适。参见第三章。(我接手项目一部的时候，部门有28人左右，半年后我觉得必须要调整了，跟总经理沟通后单独拉出CMI，以后CMI就一直都是6到7人，明显感觉项目操作感跟老一部完全不可同日而语。在CMI步入正轨后，我在思考如何处理30人左右的团队。当时的想法是把手里的6个人至少培养3个PM，再慢慢一次加入2个新人，几轮新人补充进来之后，就让第一批合格的PM带几个优秀的新人组成团队，最终实现我只接触PM。但是如果按这种搞法，最后还是形成了金字塔结构。信息饱和度将大幅降低，变成1+1小于2的局面。也许这个事情，需要项目集管理的知识才能比较好的解决吧，或者可以解除扁平式管理吗？。在本书中，第八章有一段是“将来，我们如何工作”，里面详细介绍了Valve公司的做法，即扁平式管理。这个公司产出了半条命，传送门等划时代的游戏，创造了Steam平台，维持了300多名员工。可惜他们是产品公司，也许对于外包项目的公司，这种扁平的方式根本不合适。)
3 挑选Scrum主管。
主管对Scrum过程负责，负责培训团队其他成员，确保Scrum得到正确运用，帮助团队消除一切障碍。参见第四章。
4 拟定待办事项清单，并确定优先顺序。
这个清单高屋建瓴地列出了为了落实产品负责人的愿景而需要完成的所有事项。在产品的整个研发过程中，这个清单一直存在，并有所演变，相当于产品研发的路线图。无论在任何时间，想知道一个团队要做的所有事项及顺序，待办事项清单都是唯一的依据。待办事项清单只有一份，这意味着产品负责人从头到尾必须不断地调整，增加删除事项或者调整顺序。产品负责人应该与所有干系人以及团队进行协商，以确保产品待办事项清单既能反映用户的需求，又不会超出团队的能力范围。参见第八章。
5 改进和评估待办事项清单。
让负责市级开发工作的团队对待办事项做出评估，这是一个至关重要的环节。团队应该审视每个事项，看看是否切实可行，事项是否有价值等。不要用任务所需的小时数去评估，因为人们根本不擅长做出这么精确的评估。要用相对难度去评估，比如使用1，2，3，5，8，13这些系数，称为Dog Points。参见第六章。
(在CMI团队的项目WBS文件中，我是按照工作量来评估，单位是人天，但是我一直存在的问题是不同人每天的工作量是不同的，我们能够很准确的评估出工作量，是建立在我们长期合作已经非常有默契的前提下。如果按相对难度去评估，也一样存在这个问题，等级高的人认为是3，等级低的人认为是5。Scrum里是通过德尔菲法跟计划扑克来解决这个问题，CMI通常是通过专家判断来解决，我相信德尔菲和计划扑克也能解决按工作量评估的问题。我个人还是倾向于按工作量来评估。)
6 冲刺规划会。
这是第一场Scrum会议。团队成员，Scrum主管以及产品负责人坐到一起，规划冲刺内容。冲刺周期一般是固定的，不要超过一个月，一般是1到2周。团队要从待办事项清单的顶端着手，也就是最重要的事情，看看一个冲刺能完成多少Dog Points，这个数字相当于团队的速度。Scrum主管应该在每一个冲刺阶段中提高这个数字。
Scrum的基石之一在于，产品负责人告诉开发团队他需要完成待办事项清单中的哪些事项。开发团队决定在下一个冲刺中他们能够承诺完成多少待办事项。在冲刺中，任何人都不能变更冲刺内容。团队必须在冲刺阶段自主工作。参见第四章和第六章。
(在这里有三个疑问。
第一，如果冲刺规划会是第一个会议，那么之前团队都不清楚项目背景及详细内容，这个会议将涉及这些内容吗？还是直接讲用户故事？该怎么处理？科匠的做法是在产品经理完成原型并由客户确认后，跟团队开会交流项目背景及原型设计，称为需求说明会。这样做过几次后，我们发现客户对于审核原型并不专业，会遗留一些漏洞，而且原型中可能存在一个高内耗的设计。CMI的改进做法是要求产品经理完成原型后，先交由开发团队审核，迭代多次把内部疑问都排除后，再交付客户。这样一来客户明显通过率提高了，而且满意度也提高了。对于我们自己来说，也提前排除了问题，提前熟悉了项目，在产生相同价值的前提下减少了高成本的设计。
第二，如果冲刺规划会上，是靠开发人员自己承诺要完成多少任务，如果承诺无法实现怎么办？或者开发人员过于乐观怎么办？实际项目中，开发人员的预估过于乐观确实很常见。《快速软件开发》中着重提到要警惕基于承诺的计划。也许Scrum无论如何要基于满足Y理论的团队成员，或者说Scrum需要得到第一轮冲刺的速度数据，然后在后面作为参考，先放手去做。我认为是这样。
第三，如果任务完全由开发人员自己认领，不需要指派，怎么才能保证开发人员没有偷懒的嫌疑。难道还是要寄希望于Y理论吗？)
7 工作透明化
在Scrum中，最常见的做法是通过进度看板来增加工作透明度。另一个好工具就是燃尽图。
8 每日立会
这是Scrum的活力源泉。团队每天在固定时间进行内部沟通，时间一般不超过15分钟，且站立进行，Scrum主管向成员提出下列问题：
1 你昨天做了什么去帮助团队完成冲刺？
2 你今天打算做什么来帮助团队完成冲刺？
3 什么因素阻碍了团队的前进？
注意Scrum主要要防止每日立会变成每天每个人的工作汇报，而更要像是球队在一起鼓劲，相互帮助，分享信息和商量战术。
9 冲刺展示
在冲刺结束前，给产品负责人展示成果，也就是展示哪些事情已经被挪到了“已完成事项”里，并接受评价。这是一场公开的回忆，任何人都可以参与，不仅包括产品负责人，Scrum主管以及开发团队，还包括利益相关者，管理人员和客户。(就是PMP里说的任何干系人都可以参与。)
团队应该只展示符合“完成定义”的事项。一定要特别注意，事项的状态只有完成/未完成，绝对没有中间状态。
10 冲刺回顾。
团队展示之前冲刺中创造的成果，也就是展示所有已经完成的事项，看看能为客户传递哪些价值，并征求反馈意见，大家一起想想哪些事情执行得很顺利，哪些事情应该做得更好，以及在下一个冲刺中可以做出什么改善。
那么如何发现流程中的哪些环节可以改善呢？要使冲刺回顾有效，团队需要相互信任，不要把一个人当作责备对象，而是要将注意力集中在流程上，认真分析以下问题：为什么会发生那件事？为什么我们当时忽略了？怎么样才能加快工作进度？作为一个团队，要集思广益，寻求问题解决之道，这一点至关重要。
一旦团队确定一个最值得改善的地方，就将其设定为下一个冲刺的首要任务。当然，跟项目任务一样，你要保证这个改善被完成了，必须通过测试。你如何证明团队成功的完成了改善？你需要用具体的，可操作的方式界定什么是改善成功。参见第七章。
