敏捷开发之Scrum(1)： 传统开发过程与Scrum

传统软件开发过程

传统软件开发过程中使用的较多的是顺序开发，其中的代表就是瀑布模型及其变种。它主要包括以下阶段：

计划阶段，产品经理开会研讨开发计划，产出一系列的甘特图和MSProject构建的项目计划图；在需求分析阶段详细分析所有的需求，由产品设计人员和需求分析人员根据市场需求以及客户反馈进行详细的需求分析，写出需求规格说明书，需求规格说明书在规定时间冻结，不再允许修改；设计阶段和开发阶段，几个高级工程师/架构师管理几个功能模块，进行相应的设计，形成设计文档并开发出整体框架，再由每个高级工程师/架构师带领初级工程师进行相应模块的具体开发工作，开发过程中由构建工程师不停的构建产品的可运行版本，测试人员根据这些可运行的产品进行测试，发现defect后交由相应的开发人员进行defect fixing，在到达CodeComplete这个项目里程碑时，一般不允许有严重的defect存在，比如主要流程的产品崩溃或数据丢失； CodeComplete时会提供一个可运行版本，测试人员在这个版本上进行进一步的测试以及比较需求规格说明书确认是否有功能丢失，这个阶段主要是测试人员找defect和开发人员fix defect，直到下两个主要的里程碑Feature Complete 和RTP(Read To Manufacture) 即产品的交付和生产； 再接下来就是开发组成员比较清闲的时间了，一般在这个阶段进行team building， training和一些defect fixing。

顺序开发的优点在于能够在分析阶段进行详细的考虑，进行风险评估和提出相应的解决策略；缺点是由于一切都要按计划进行以保证项目的正常进度，这在开发过程中项目工作人员一般都拒绝变化。但是，软件开发过程中经常遇到的就是变化——经济环境的变化比如经济危机，导致项目的预算减少或者公司裁员从而造成项目组成员的变动；市场的变化比如竞争对手提前推出类似的产品抢占了市场；技术风险，项目开始阶段的风险评估不可能预测到所有的风险以及技术难点，这可能会导致设计和实现上的变化。顺序开发的另外一个容易出现的问题是需求分析员/客户之间的理解误差和开发人员/需求分析人员之间的理解误差，尽管在项目的需求分析阶段形成了详细的需求规格说明书，这不能保证开发人员理解的需求确实是客户的需求，这样很容易在项目的晚期甚至项目结束时才发现项目早已偏离了方向，从而失去客户信任甚至流失客户。

敏捷开发之Scrum

Scrum是一种迭代渐进的软件开发过程，是敏捷开发使用的较多开发过程。传统开发过程的一个开发周期，在Scrum里会被分为多个阶段，每个阶段称为Sprint，每个阶段一般1～4周。在Sprint结束时，项目组必须交付可运行产品，由利益相关者比如客户进行验收，这样客户可以在早期就能拿到初期版本的产品，提高对项目组的信心；同时，由于每个Sprint时间很短，如果项目组对需求理解有偏差，可以在很短的时间内（最多4周）得到这样的信息，而不会像传统开发那样可能在几个月之后才发现开发的产品不是客户真正想要的。

Scrum不再过分强调详细的文档，如其他敏捷开发过程一样，注重源代码就是设计，判断每个Sprint是否成功的标准是交付的可运行产品，从而将项目组成员从繁杂的文档编写中解放出来。

在传统开发过程中，项目经理必须进行严格的管理，从而保证项目按计划进行。但是严格的管理会限制项目组成员的创新能力甚至生产力，Scrum在这方面提供了新的思路。

在对待变化上，Scrum与传统开发过程不同，不再拒绝变化，客户可以在两个Sprint之间提出新的需求。我们可以在后续的文章中看Scrum的具体流程以及它是如何处理变化的。