敏捷软件开发(三):计划
2010-05-02 12:04
357 查看
这是对XP中计划游戏部分的描述。相比其他敏捷方法,更加详细、精确。开发人员看到的是基于他们自己的估算并且由他们自己度量的开发速度控制的合理计划。管理人员从每次迭代中获取数据,使用这些数据来控制和管理项目。客户可以经常看到项目的进展,度量开发速度,拥有他们需要的所有数据和控制权,按照他们的意愿管理项目。
1. 初始探索
项目开始,客户和开发人员尽量确定所有重要的user story(不是所有),这些story随项目进展可能由用户修改、扩充。
开发人员对这些story进行相对估算,用点数表示)因子。例如“2天实现一个story点”
通常需要花几天时间去原型化一个到两个story
这个story所需的相对时间。
为了知道story的绝对大小,需要速度(velocity
来了解团队速度,这个过程称作探究(spike)
2. 发布计划
客户了解每个story的商业价值和成本,据此,他们选择那些想要最先完成的素材。开发人员和客户对项目的首次发布时间达成一致(一般2到4个月)
3. 迭代计划
迭代期间开发人员采用最具技术意义的顺序来实现这些素材。迭代开始后客户就不再改变本次迭代的story。迭代期间进行速度反馈。
4. 任务计划
迭代开始,开发人员将story分解为开发任务,一个任务就是一个开发人员能够在4到16个小时内完成的一些功能。
迭代中点:在迭代进行一半时,本次迭代中所安排的半数story期待被完成。否则会设法重新分配没有完成的任务和职责。
5. 迭代
每次迭代结束,给客户演示当前可运行的程序。客户对外观、感觉和性能进行评价并以新的story方式提供反馈。
1. 初始探索
项目开始,客户和开发人员尽量确定所有重要的user story(不是所有),这些story随项目进展可能由用户修改、扩充。
开发人员对这些story进行相对估算,用点数表示)因子。例如“2天实现一个story点”
通常需要花几天时间去原型化一个到两个story
这个story所需的相对时间。
为了知道story的绝对大小,需要速度(velocity
来了解团队速度,这个过程称作探究(spike)
2. 发布计划
客户了解每个story的商业价值和成本,据此,他们选择那些想要最先完成的素材。开发人员和客户对项目的首次发布时间达成一致(一般2到4个月)
3. 迭代计划
迭代期间开发人员采用最具技术意义的顺序来实现这些素材。迭代开始后客户就不再改变本次迭代的story。迭代期间进行速度反馈。
4. 任务计划
迭代开始,开发人员将story分解为开发任务,一个任务就是一个开发人员能够在4到16个小时内完成的一些功能。
迭代中点:在迭代进行一半时,本次迭代中所安排的半数story期待被完成。否则会设法重新分配没有完成的任务和职责。
5. 迭代
每次迭代结束,给客户演示当前可运行的程序。客户对外观、感觉和性能进行评价并以新的story方式提供反馈。
相关文章推荐
- [最佳实践]在Scrum敏捷软件开发模式中,我们是如何开Sprint 计划会议的
- 《敏捷软件开发-原则、模式与实践》-第三章 计划
- 敏捷软件开发——迭代计划版本号
- 敏捷软件开发--计划
- 敏捷软件开发——计划
- 敏捷软件开发:原则、模式与实践——第3章 计划
- 敏捷开发:软件与文档
- 成功的软件开发过程 --迭代,进化和敏捷
- 嵌入式系统软件敏捷开发
- 敏捷软件开发模型--SCRUM (转载)
- 基于DotNet构件技术的企业级敏捷软件开发平台 - AgileEAS.NET平台开发指南 - 报表系统集成说明
- 敏捷软件开发
- 软件需求说明书 概要设计说明书 项目开发计划 详细设计说明书 模版
- 敏捷软件开发 12 原则
- 敏捷开发生态系统系列之二:敏捷生态系统-计划跟踪 I(跨职能团队-共同估算-每日立会-同行压力)
- 软件开发过程纵横谈(2):敏捷过程课程小记
- 抓包软件PowerSniff开发计划
- 敏捷开发生态系统系列之三:计划跟踪II(需求优先级排序-迭代期内无变更-团队承诺)
- 敏捷软件开发模型--SCRUM
- 敏捷软件开发的原则--希望即将走上工作岗位的朋友不要拒绝