敏捷建模（AM：agilemodeling.org）极限编程（XP：extremprogramming.org）

来源：互联网发布：中标数据网手机版编辑：程序博客网时间：2024/05/22 01:27

AM，是关于使用简单工具进行有效建模和记录文档的方法。XP，是一个软件开发的完整的生命周期。

XP和AMDD这两种方法并不是以线性的方式进行的，而在现实世界中事物并不是按照线性的方式发展的。在那些严格的线性方法中，所有的需求必须事先定好，无法满足较大的客户需求变化。改变是不可避免的，所以我们最好在开发方法中容忍这种变化。

附带提一下，敏捷是软件开发方法的一个很大的范畴。2001年，敏捷被很多软件方法论的代表集体讨论通过，这些方法有：XP、SCRUM、DSDM、适应性软件开发、水晶、功能驱动开发、集体编程等（在agilemanifesto.org上查看敏捷历史信息）。agilemodeling.org网站提供关于各种软件开发方法的丰富信息，在你指尖的点击中，就可以得到它们。

成功的项目是那些用户能够积极参与的项目。

探索阶段

一般的探索阶段包括一组探索性的活动，它能够帮你更好地理解客户的需求和接下来该怎么设计和构建程序，下面是一些在本阶段中可能发生的活动的例子。

n 域建模——领域建模可以帮助你来定义主要的业务概念（实体）和它们之间的关系。

n 用户接口原形和故事板——有些最初版本的页面可以使我们清楚地知道用户对产品界面的要求。而一组相关的界面流程图就是故事板。

n 用户故事——一些用户故事的完成标志着项目的开始，它们组成了发布的第一个版本。用户故事（从某种意义上与要做的事相似）由用户编写，用简短的语言描述出用户定义的产品功能。注意，虽然之前你所收集的用户故事的数量由项目来决定，但是应该努力确保它是足够好的并且是有用的。

n 范围定义——预先定义项目的范围可以使你知道什么需求是需要开发的，什么是可以延期的。它也阐述了用户对软件的期望。

n 分析——这是个综合性的活动。例如，需要在白板上画出一个非正式的程序架构图，列出术语，进行分析。

计划阶段

计划对于不同的人来说具有不同的意义，对于我来说，至少要包括以下部分：

n 版本发布计划——它实际上是为系统的下一版本所做的计划。它可以很容易地被表单程序、字处理程序或HTML表格汇总在一起。它列出了在下一版本中将要包括的所有用户故事，并且按照不同的迭代分组。一般地，一个发布是有固定时间要求的，最短1个月、最长3个月，两个月一般是比较好的选择。

n 迭代计划——在每一次迭代之前都要有一个迭代计划，包括在下一次迭代中客户希望实现的用户故事。迭代时间一般也是固定的，最短一周、最长3周，两周一般是比较好的选择。

n 规范定义（代码、数据库、过程）——在开始任何开发之前，为一些东西制定规范来统一化是非常好的做法。例如，这些规范包括：编码约定、数据库命名约定和过程（包括构建、继承和发布）约定等。

产品的迭代开发阶段（渐进式构建软件）

迭代开发也许是一个你很熟悉的术语，但是不同的人使用不同的软件开发方法，对迭代和每个迭代过程所包含的内容的理解是不同的。

在我看来，迭代开发意味着每一次迭代中都要有设计、编码、用户验收和生产就绪代码的部署。生产就绪的代码要部署到生产环境中，如果在一个大公司，经常部署到生产环境并不是很现实，需要把它先部署到验收环境中，只要用户验收通过，就可以进入到下一个迭代过程中了。总之，每次迭代需要有以下的事件：

n 开发人员对开发任务进行评估，制定下次的迭代计划；

n 客户和开发人员事先的沟通交流；

n 设计——包括CRC卡、UML图等；

n 编码——测试先行，按照要求重构代码/数据库/程序架构，在最后阶段优化；

n 用户验收测试（UAT）。

n 将迭代后的版本部署到生产环境或验收环境中，这个过程也叫做发布一个小版本。

按照这样的方式进行迭代，可以不断地建立项目的下一个版本。假定一个项目，我们估计会在3个月内完成，我们会把它分解成每两周一次的迭代，所以会有大约6次的迭代开发。

每一次迭代的截止时间是工程可以进入下一个阶段的时候，换句话说，迭代的小版本成为了生产就绪的代码（稳定的代码），即使它只是完整系统的一个子集。