敏捷模型

最近正在看java敏捷开发这本书
摘抄了其中的一些内容并且简单的做一了些评价

AMDD更加专注于开发，本书之所以选择AMDD，除了它提出的观点和我的很一致外，还因为它的目的是只做那些足够好且必要的建模工作（例如，格式自由的结构图），也许AM网站上的这段话能很好地总结你对产生工件的感受：“你的目的是为了产生共享性的概念，而不是要写出很具体的文档。”我不需要再多说什么了。

对于XP，你会遇见很多概念，它们会在本章或整本书中遇到。例如，用户故事（user stories）、CRC卡片、测试先行设计、版本发布和迭代计划等。

你的团队每天都要构建程序并对它进行单元测试，程序经常要进行集成（也许随着单元测试的通过提交，会不断地进行），每两周（即一次迭代）一个独立的产品就会产生，可以进行部署。客户每两周就会测试驱动或使用新增的功能（每两个月发布一个新的版本）。

总之，这是一种软件开发者和用户双赢的局面。

以下是XP项目的生命周期


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

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

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

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

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

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



计划阶段

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

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

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

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


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

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

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

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

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

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

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

n   用户验收测试（UAT）。

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

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

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