2008年下旬公司开始培训Agile－我的笔记

公司流程的改变，这周主要对敏捷的Scrum培训和Daptiv工具 的培训，因为是英语培训，许多东西自己要整理一下。

首先是和开发传统模型（Waterfall）的对比，传统模型随着系统因素（内部和外部因素）的复杂度增加，项目成功的可能性就迅速降低。而scrum模型非常灵活，是一个增量迭代的开发过程。在这个框架整个开发周期由若干个小的迭代周期（Iteration Cycle），每个小的迭代周期称为一个Sprint，每个sprint的周期是14到30天。每个sprint 由inspection process 组成，各个team的成员每天碰一次头review项目进行的活动并做适当的修改。推进迭代过程的需求来自Product Backlog，scrum的开发团队拿到一个排列好优先级的需求列表，因此开发的是对客户就有较高价值的需求。每个迭代结束后，都会完成可交付的产品。

 

这里先解释两个术语：

Product Backlog：在项目开始的时候，product owner要准备一个根据商业价值排好序的客户需求列表，这个列表就是product backlog，一个最终会交付给客户的产品特性列表，它们根据商业价值来排列优先级别。Scrum team会根据这个来做工作量的估计。

Product Backlog应该涵盖所有用来构建满足客户需求的产品特性，包括技术上的需求。高优先级的一些产品特性需要足够的细化以便我们做工作量估计和做测试。对于那些可以在下个Sprint中完成的Product Backlog功能点，大约10人天的工作量的粒度就不错了。对于那些以后将要实现的特性可以不够详细。

 

Sprint  Backlog：Sprint Backlog是Sprint规划会上产出的一个法宝。当Scrum team选择并承诺了Product Backlog 中要递交的一些高优先级的产品功能后，这些功能点就会被细化成为Sprint Backlog：一个完成Product Backlog功能点的必需的任务列表。这些点会被细化为更小的任务，工作量小于两天。Sprint Backlog完成后，scrum team会根据它重新估计工作量，如果这些工作量和原始设计的工作量有较大差异， scrum team和product owner协商，调整合理的工作量到sprint中，以确保sprint的成功实施。

 

Burndown Chart现实了sprint中累积剩余的工作量，它是一个反应工作量完成状况的趋势图。在sprint开始的时候，develop team会表示和估计在这个sprint需要完成的详细的任务。所有这个sprint需要完成，但没有完成的任务的工作量是累积工作量，scrum master会根据进展情况每天更新和积累工作量，如果在sprint结束时，累计工作量降低到0，sprint就成功结束。

 

Sprint的会议形式：

Daily Scrum 会议：Scrum组织成员每天要开Daily Scrum会议，用15分钟的时间让大家review项目的进度情况。在会上，每个团队成员需要问3个问题：（What have you done on the project since the last daily Scrum meeting?

What do you plan on doing on this project between now and the next daily Scrum meeting?

What impediments stand in the way of you meeting your commitments to this Sprint and to this project?）就是我昨天做了什么，今天做了什么，遇到哪些障碍。这个会议的目标是监测项目的全局，定位项目成员的要求，实时的调整当天开发计划。Note：不允许非项目内的人发言。

 

Sprint Planning Meeting（sprint规划会）：参加者有product owner，develop team，scrum master。需要要鸡的角色的人参与，第三方提供数据后就可以解散。第一个四个小时的会议来对product backlog进行选择，肯能否在sprint内完成。Product owner在会议之前准备好product backlog，product owner决定哪些要在sprint，develop team可以提出建议。然后team再从product owner选好的product backlog中决定哪些在在sprint。第二个四个小时，develop team列出所有的任务，进行时间的评估和分配。

 

Sprint Review meeting（sprint 评审会）：一个小时准备时间，四个小时的review时间。参加会议的developteam表明已经完成功能，没有完成的team不能参见。会议的开始是develop team演示完成的product backlog或sprint backlog，develop team的成员会讨论在这个sprint中哪些做得好需要保持，哪些需要改进。会议的大部分时间是产品的演示，以及回答stake-holder的问题。功能演示完之后，stakeholders会对此评价，并提出想要改变的东西以及优先级。接下来product owner会和develop team和stakeholders对product的backlog的反馈进行重现安排和规划。Stakeholders也许会发表自己对演示的想法，或是提出新要增加的product backlog。在会议的最后，会宣布下一次评审会议的时间和地点。

Sprint Retrospective Meeting：设定三个小时，参加者有，develop team，scrummaster， product owner可选。所有的develop team需要回答两个问题：上一个sprint哪里做得好，哪里需要改进。Scrummaster会记录所有的回答，并和team一起排列优先顺序。需要改进的项目添加到下一个sprint中作为高优先级非功能性product backlog。

 

 

Scrum定义了许多角色，根据Pig和chicken的笑话分为两组，pig和chicken。

猪是全身投入项目和scrum过程的人：Product owner，scrummaster，和Develop Team。

Product Owner的职责：

确定产品的功能；

决定发布日期和发布内容；

为产品的ROI负责；

根据市场价值确定功能优先级；

接受或拒绝接受开发团队的工作成果。

 

Develop Team

具有不同特长的团队成员，人数控制在7个左右；

确定sprint目标和具体说明工作成果；

在项目向导范围内有权利做任何事情已确保到sprint的目标。

高度的自我管理能力；

向product owner演示产品功能。

 

ScrumMaster

保证团队资源完全可被利用并且全部是高产出的。

保证各个角色及职责的良好协作。

解决团队开发中的障碍。

做为团队和外部的接口，屏蔽外界对团队成员的干扰。

保证开发过程按照计划进行，组织daily scrum，sprint review和sprint planning meetings。

Note：ScrumMaster is not a project manager， the team is self-managing.