敏捷软件开发（三）：计划

       这是对XP(极限编程)中计划游戏部分的描述。相比其他敏捷方法，更加详细、精确。开发人员看到的是基于他们自己的估算并且由他们自己度量的开发速度控制的合理计划。管理人员从每次迭代中获取数据，使用这些数据来控制和管理项目。客户可以经常看到项目的进展，度量开发速度，拥有他们需要的所有数据和控制权，按照他们的意愿管理项目。

1. 初始探索

       项目开始，客户和开发人员尽量确定所有最重要（我们希望是所有最重要的，但也有可能有变化）的user  case（不是所有），这些user  case随项目进展可能由用户修改、扩充。

       开发人员对这些user  case进行相对估算，用点数表示）因子。例如“2天实现一个user  case点”通常需要花几天时间去原型化一个到两个user  case这个user  case所需的相对时间。

       为了知道user  case的绝对大小，需要速度（velocity来了解团队速度，这个过程称作探究（spike）

2. 发布计划

       客户了解每个user  case的商业价值和成本，据此，他们选择那些想要最先完成的素材。开发人员和客户对项目的首次发布时间达成一致（一般2到4个月）

3. 迭代计划

       迭代期间开发人员采用最具技术意义的顺序来实现这些素材。迭代开始后客户就不再改变本次迭代的user  case。迭代期间进行速度反馈。

4. 任务计划

       迭代开始，开发人员将user  case分解为开发任务，一个任务就是一个开发人员能够在4到16个小时内完成的一些功能。

       迭代中点：在迭代进行一半时，本次迭代中所安排的半数user  case期待被完成。否则会设法重新分配没有完成的任务和职责。

5. 迭代

       每次迭代结束，给客户演示当前可运行的程序。客户对外观、感觉和性能进行评价并以新的user  case方式提供反馈。

 

 

 

       这是对XP(极限编程)中计划游戏（http://blog.csdn.net/xiaoyong322/archive/2010/05/12/5581109.aspx）部分的描述。相比其他敏捷方法，更加详细、精确。开发人员看到的是基于他们自己的估算并且由他们自己度量的开发速度控制的合理计划。管理人员从每次迭代中获取数据，使用这些数据来控制和管理项目。客户可以经常看到项目的进展，度量开发速度，拥有他们需要的所有数据和控制权，按照他们的意愿管理项目。

1. 初始探索

       项目开始，客户和开发人员尽量确定所有最重要（我们希望是所有最重要的，但也有可能有变化）的user  case（不是所有），这些user  case随项目进展可能由用户修改、扩充。

       开发人员对这些user  case进行相对估算，用点数表示）因子。例如“2天实现一个user  case点”通常需要花几天时间去原型化一个到两个user  case这个user  case所需的相对时间。

       为了知道user  case的绝对大小，需要速度（velocity来了解团队速度，这个过程称作探究（spike）

2. 发布计划

       客户了解每个user  case的商业价值和成本，据此，他们选择那些想要最先完成的素材。开发人员和客户对项目的首次发布时间达成一致（一般2到4个月）

3. 迭代计划

       迭代期间开发人员采用最具技术意义的顺序来实现这些素材。迭代开始后客户就不再改变本次迭代的user  case。迭代期间进行速度反馈。

4. 任务计划

       迭代开始，开发人员将user  case分解为开发任务，一个任务就是一个开发人员能够在4到16个小时内完成的一些功能。

       迭代中点：在迭代进行一半时，本次迭代中所安排的半数user  case期待被完成。否则会设法重新分配没有完成的任务和职责。

5. 迭代

       每次迭代结束，给客户演示当前可运行的程序。客户对外观、感觉和性能进行评价并以新的user  case方式提供反馈。