架构之道之软件开发过程的敏捷模型

        增量模型的提出，需要有一整套相应的项目管理理念与之匹配，人们通过多年的努力，从理论上和实践上作了艰苦的探索，提出了比较完整的敏捷项目管理方法。需要说明的是，敏捷开发并不是回归到当初混乱无计划开发状态，更不是赞成随意性。敏捷方法是在长期的实践中，对瀑布式模型存在问题的分析结果，也是从发现问题、分析问题到解决方案的过程。对管理水平上的要求是更高而不是更低。

一、敏捷开发的价值观

         实际上敏捷开发运动在数年前就开始了，但它正式开始的标志是 2001 年 2 月的“敏捷宣言”（Agile Manifesto），这项宣言是由 17 位当时称之为“轻量级方法学家”所编写签署的，他们的价值观是：

• 个人与交互重于开发过程与工具；
• 可用的软件重于复杂的文档；
• 寻求客户的合作重于对合同的谈判；
• 对变化的响应重于始终遵循固定的计划。

1. 个人与交互重于开发过程与工具的原因：

   一个由优秀的人员组成但使用普通的工具，要比使用优秀的工具但由普通人组成、紊乱的小组做得更好。多年来人们花了很多时间试图建立一种过程，以便把人当作机器上的一个可以替代

的齿轮，但结果却并不成功。敏捷过程是承认每个人都有特定的能力（以及缺点），并对之加以利用，而不是把所有的人当成一样来看待。更重要的是，在这样的理念下，几个项目做下来，每个人的能力都从中得以提高。

    2. 可用的软件重于复杂的文档的原因：

   可用的软件可以帮助开发人员在每次迭代结束的时候，获得一个稳定的、逐渐增强的版本。从而允许项目尽早开始，并且更为频繁的收集对产品和开发过程的反馈。随着每次迭代完成软件

的增长，以保证开发小组始终是处理最有价值的功能，而且这些功能可以满足用户的期待。

    3. 寻求客户的合作重于对合同的谈判的原因：

敏捷开发小组希望与项目有关的所有团体都在朝共同方向努力，合同谈判有时会在一开始就使小组和客户出于争执中。敏捷开发追求的是要么大家一起赢，要么大家一起输。换句话说，就

是希望开发小组和客户在面对项目的时候，以一种合作的态度共同向目标前进。当然，合同是必需的，但是如何起草条款，往往影响到不同的团体是进行合作式的还是对抗式的努力。

    4. 对变化的响应重于始终遵循固定的计划的原因：

敏捷开发认为对变化进行响应的价值重于始终遵循固定的计划。他们最终的焦点是向用户交付尽可能多的价值。除了最简单的项目以外，用户不可能知道他们所需要的所有功能的每个细节。不可避免地在过程中会产生新的想法，也许今天看起来是必需的功能，明天就会觉得不那么重要了。随着小组获得更多的知识和经验，他们的进展速度会比开始的时候期望值慢或者快。对敏捷开发来说，一个计划是从某个角度对未来的看法，而具有多个不同的角度看问题是有可能的。

二、项目的敏捷开发方法

        敏捷方法很多，包括 Scrum、极限编程、功能驱动开发以及统一过程等多种法，这些方法本质实际上是一样的，敏捷开发小组主要的工作方式可以归纳为：

• 作为一个整体工作；
• 按短迭代周期工作；
• 每次迭代交付一些成果；
• 关注业务优先级；
• 检查与调整。

1. 敏捷小组的角色

   尽管强调一个整体，小组中应该有一定的角色分配，各种敏捷开发方法角色的起名方案可能不同，但愿则基本上是一样的。

第一个角色是产品所有者，他的主要职责包括：

1. 确认小组成员都在追求一个共同的目标前景；
2. 确定功能的优先等级，以便总是处理最有价值的功能；
3. 作出可以使项目的投入产生良好回报的决定。

产品所有者通常是公司的市场部门或者产品管理部门的人员，在开发内部使用的软件的时候，产品所有者可能是用户、用户的上级、分析师，也可能是为项目提供资金的人。

第二个角色是客户：

客户是做出决定为项目提供资金或者购买软件的人，在一个开发内部使用的软件项目中，客户通常是来自另一个团组或者部门的代表，在这样的项目中，产品所有者和客户的角色往往是重合的。对一个商业软件来说，客户就是购买这个软件的人。客户可能是也可能不是软件的用户（user），用户当然也是一个主要角色。

一个值得注意的角色是开发人员（developer）：

   所有开发软件的人，包括程序员、测试人员、数据库工程师、可用性专家、技术文档编写者、架构师、设计师、分析师，等等。

最后一个角色是项目经理：

在所有的敏捷开发项目中，项目经理的角色发生了变化，他更注重的是教导、引导而不是管理和控制。在 Scrum 中，为了强调责任的变化，改称之为 ScrumMaster。在某些敏捷开发项目中，项目经理也承担其它的角色，通常是开发人员，少数的时候也会担任产品所有者。

2. 敏捷小组按短迭代周期工作

     在敏捷项目中，总体上并没有什么上游阶段、下游阶段，你可以根据需要定义开发过程。在初始阶段可以有一个简短的分析、建模、设计，但只要项目真正开始，每次迭代都会做同样的工

作（分析、设计、编码、测试。等等）。

   迭代是受时间框限制的，也就是说即使放弃一些功能，也必须结束迭代。时间框一般很短，大部分是 2～4 周，在 Scrum 中采用的是 30 个日历天，也就是 4 周。

迭代的时间长度一般是固定的，但也有报告说，有的小组在迭代开始的时候选择合适的时间长度。

3. 敏捷小组每次迭代交付一些成果

      比选择特定迭代长度更重要的，是开发小组在一次迭代中要把一个以上的不太精确的需求声明，经过分析、设计、编码、测试，变成可交付的软件（称之为功能增量）。当然并不需要把每次迭代的结果交付给用户，但目标是可以交付，这就意味着每次迭代都会增加一些小功能，但增加的每个功能都要达到发布质量。每次迭代结束的时候让产品达到可交付状态十分重要，但这并不意味着要完成发布的全部工作，因为迭代的结果并不是真正发布产品。

假定一个小组需要在发布产品之前对软硬件进行为期两个月的“平均无故障时间”（MTBF）测试，他们不可能缩短这两个月的时间，但这个小组仍然是按照 4 周迭代，除了 MTBF 测试，其它都达到了发布状态。

4. 敏捷小组关注业务优先级

       敏捷开发小组从两个方面显示出他们对业务优先级的关注。

首先，他们按照产品所有者制定的顺序交付功能，而产品所有者一般会按照组织在项目上的投资回报最大化的方式来确定优先级，并且把它组织到产品发布中去。要达到这个目的，需要综合考虑开发小组的能力，以及所需功能的优先级来建立发布计划。在编写功能的时候，需要使工能的依赖性最小化。如果开发一个功能必须依赖其它 3 个功能，那产品所有者这就很难确定功能

优先级。功能完全没有依赖是不太可能的，但把功能依赖性控制在最低程度还是相当可行的。

5. 敏捷小组检查与调整

      任何项目开始的时候所建立的计划，仅仅是一个当前的猜测。有很多事情可以让这样的计划失效：项目成员的增减，某种技术比预期的更好或更差，用户改变了想法，竞争者迫使我们做出不同的反应，等等。对此，敏捷小组不是害怕这种变化，而是把这种变化看成使最终软件更好地反映实际需要的一个机会。

      每次新迭代开始，敏捷小组都会结合上一次迭代中获得新知识做出相应调整。如果认为一些因素可能会影响计划的准确性，也可能更改计划。比如发现某项工作比预计的更耗费时间，可能就会调整进展速度。也许，用户看到交付的产品后改变了想法，这就产生反馈，比如他发现他更希望有另一项功能，或者某个功能并不像先前看得那么重。通过先期发布增加更多的用户希望的功能，或者减少某些低价值功能，就可以增加产品的价值。

       迭代开发是在变与不变中寻求平衡，在迭代开始的时候寻求变，而在迭代开发期间不能改变，以期集中精力完成已经确定的工作。由于一次迭代的时间并不长，所以就使稳定性和易变性得到很好的平衡。在两次迭代期间改变优先级甚至功能本身，对于项目投资最大化是有益处的。