[转帖]浅谈敏捷开发之Scrum

浅谈敏捷开发之Scrum

一、前言

敏捷开发有各种形式，其中的一种叫做Scrum。本文将详细阐述Scrum的开发方式。在此不讨论其他敏捷开发形式，一方面因为我对Scrum更熟悉些，另一方面我认为Scrum是比较实用，相对来说更有项目价值的一种开发方法。下面就我个人在项目中的经验谈一下这种开发方式。



二、Scrum的开发形式

同很多其他开发流程一样，Scrum首先要进行需求分析，把所有的需求放在所谓的Backlog中，然后开会为所有的需求定出“Story Points”，即难度系数，一般以人天为单位。

需求清楚了，下一步就要把整个项目开发周期分为一个一个的Sprint，一般每个Sprint时间为半个月到一个月，然后从requirement backlog中根据优先级（需求的迫切性和可行性)高低和所需时间挑出需求填入每个Sprint。在填入Sprint时，每个需求还需要细分，定义出一个一个的小任务。

之后每个开发人员就可以“认领”这些task item了，选择了一个task，就要负责该任务的设计编码和测试，当然只是单元测试。要注意的是往往，尤其是敏捷编程更强调这一点，需要对代码进行review，这部分工作当然不能由作者来做，也需要作为一个subtask分配给个人。

Scrum强调开发团队成员之间的沟通，所以在开发的过程中，每天都需要开例会，沟通今天的进度，记录在什么任务上花了多长时间，讨论开发过程中遇到的问题等等。例会不必太长，但是要有效率，要言之有物。

最后，当一个Sprint结束后，需要对这个Sprint进行review，看进度是否良好，看是否有未完成的任务需要移到下一个Sprint，看原来的计划是否可行等等等等。特别强调的是，Scrum强调跟客户需求的沟通，所以需要注意看需求是否有变化。Scrum强调每个sprint出一个能release的版本，所以可能每个sprint需要安排出专门的时间做集成测试，不过这点不是必需的，要看这种需要有多强。之所以要出一个release版本，也是为了及时把结果反馈给客户，从而进一步跟客户明确需求。



三、要注意的问题

1、Scrum虽然是敏捷开发，但并不意味着我们不需要文档，不需要计划。实际上在Sprint开始之前要有很长时间的需求分析的时间，并且在这段时间内要形成需求文档（Requirement Specification）和功能定义文档(Functional Specification)，在此基础上才能制定Scrum plan。当然Sprint开始后免不了出来新的需求或者原来的计划不切合实际，要根据情况作出适当调整。中间可能还需要花时间来完成设计文档（Design Specification）。

2、如何对组员进行绩效评定是一个很重要的问题。在这点上不但要凭项目经理的主观经验，而且要形成客观的纪录，每天对所使用的时间进行记录就是为了这个目的。以下方面可以作为评定的因素：（1）实际工作时间，这个是纪录下来的。如果每个人工作效率都一样的话，那绩效评估应该纯粹基于这个因素。（2）工作效率。这个是一个主观评价。需要项目经理根据工程师在项目过程中的积极程度、工作态度、解决问题的速度、产生问题的数量、做的事情的难度和该事情完成的速度等进行打分。（3）项目完成的质量和总体时间也是要评估的内容。

3、要准确地计算时间。以一个月为一个sprint为例，假如这个月有20个工作日，共同思考总结计划5天，则还剩15天的开发时间。假如每天工作8个小时，则每个人有120个小时。当然如果其中某些人还需要花时间在其他project上则需要去掉那些时间。那么我们首先要估计每项工作的工作量，然后安排工作就要就着每个人的available time来。在以后的每天汇报中，要详细的纪录这天的8个小时都用到什么地方去了。假如加班了，则需要填加班单，同时这个人的available time相当于变成了120+加班时间。这样就能让每个人的available time都能尽其用而且清楚明晰。

4、各种开发模式并不是绝对的，都有其相通的地方，在项目开发中要灵活运用。



四、总结

瀑布开发模型适用于需求很清楚，经验很充足的情况。可是除了对成熟软件进行升级的项目，大多数项目都有或多或少的待定需求，这就要借助于敏捷开发，尤其是其中的迭代和需求沟通理念。Scrum是敏捷开发中可塑性非常大的一种，适合于小项目，也适用于大项目。Scrum在每个Sprint中包含了瀑布开发模型的整个流程，所以本质上是一种迭代开发。相信将来的软件开发会越来越多地借鉴Scrum的思想和流程。