使用最小化的软件开发过程

从《Java 敏捷开发》中获得的启发，为了敏捷开发需要使用最小化的软件开发过程，这个过程只要保证项目有效进行和满足客户需求即可。

书中给出了一个简单范例开发过程：

1. 项目初期
* 非正式业务需求和问题的讨论
* 项目开始
* 定义问题描述 (如，核心用例)

2. 项目探索阶段
* 探索业务主要的概念 (建立领域模型)
* 建立基本原形和故事板 (针对用户界面程序)
* 定义项目范围 (定义项目中应该做的事推迟做的事)
* 定义下个阶段的用户故事
* 建立非正式白板上的架构图

3. 计划
* 下个版本系统的计划
* 建立公共的业务词汇表
* 制定下个迭代中的迭代计划
* 建立系统规范 (命名规范，代码规范，check in / out 规范，集成规范)

4. 在迭代中进行渐进式的软件构建过程
* 进行周期大约为两周的迭代开发，在第 0 次迭代中进行环境安装和概念证明
* 每次迭代之前进行迭代计划会议，选择下次迭代中要实现的用户故事
* 基于用户故事对开发者任务进行最佳估算
* 用户对具体需求进行验收测试，开发者对这些需求都进行单元测试
* 开发者在设计和开发时需要用户的积极参与，便于沟通
* 在通过验收测试后，每两周发布一次成品代码

评论

4 楼 lokvin 2007-03-16  

项目的范围

定义项目的范围方式很多，有时是客户简单的描述的一两句话。也许会使用图示做为结构化的定义表述。有些组织还要进一步与开发团队签署服务水平协议书(SLA).还可以进行非功能性需求讨论，这也可以帮助定义项目的范围。

可以在一张表里面列出什么是范围里需要的，什么是范围中推迟的（甚至是派出的）

系统维护

它是指程序进入维护状态的阶段，这个阶段可能包括对用户的培训，按照需要进行小的性能增加和修改（以用户故事的方式）。可能客户还需要在开发一个版本，在这种情况下，你需要从项目的探索阶段从头开始。

3 楼 lokvin 2007-03-16  

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

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

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

* 开发人员对开发任务进行评估，制定下次的迭代计划；
* 客户和开发人员事先的沟通交流；
* 设计 -- 包括 CRC 卡，UML 图等
* 编码 -- 测试先行，按照要求重构代码，数据库，程序结构，进行系统优化；
* 用户验收测试(UTA)
* 迭代后的版本部署到生产环境或验收环境中，这个过程也叫做发布一个小版本。

按照这样的方式进行迭代，可以不断地建立项目的下一个版本，假定一个项目我们估计会在3个月内完成，我们会把它分解成每2周一次的迭代，所以大约会有6次迭代开发。每次迭代的截止时间是工程进入下一个阶段的时候，迭代的小版本成为了生产就绪的代码（稳定的代码），即使他只是完成系统的一个子集。

2 楼 lokvin 2007-03-16  

项目计划阶段

计划对于不同的人来说具有不同的意义，一般要包含以下部分：

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

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

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

建议应该经常和用户一起制定迭代和发布计划。记住，成功地项目是那些用户能够积极参与的项目。

1 楼 lokvin 2007-03-16  

项目探索阶段
一般探索阶段包含一组探索性活动，帮助你更好的理解客户需求和接下来该如何设计和构建程序。
* 域建模 -- 领域建模可以帮助你定义主要的业务概念（实体）和他们之间的关系。

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

* 用户故事 -- 一些用户故事的完成标志着项目的开始，他们组成了要发布的第一个版本的内容。用户故事(从某种意义上讲与要做的事相似)由用户编写，用简短的语言描述出用户定义的产品功能。注意，虽然你所收集的用户故事数量由项目来决定，但是应该保证他是足够好的并且是有用的。

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

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