《敏捷迭代开发:管理者指南》—第2章2.8节渐进和自适应计划

2.8 渐进和自适应计划
敏捷迭代开发:管理者指南
同渐进需求一样,渐进和自适应计划并不属于那种估算和进度永远不确定或未知的情形(自适应计划和相关技巧参见11.1.4节开始的内容)。然而,由于早期需求的变更和其他一些因素,渐进和自适应计划的初始阶段具有高度的不确定性,这种不确定性随着时间的流逝和信息的积累不断降低。因而,这也被称为未确定性锥区(cone of uncertainty),参见图2-5 [McConnell98]。

渐进和自适应计划对这种不确定性的迭代响应,是为了延迟对估算的预期,直到项目经历了一些迭代,大约进行到整个项目10%或20%的地方时,才对成本、工作量或者日程安排进行有50%可靠性的估算。
这与其他新产品开发领域中的管理实践是一致的,它们都拥有相同的初始探索阶段。而且,与预见性计划(predictive planning)相比,更鼓励采用自适应计划(adaptive planning)的实践(自适应计划和预见性计划参见11.1.4节)。也就是说,只做短时间的详细日程安排,这样详细程度和承诺程度与信息质量就相当了。

固定价格的合同
关于固定价格的投标和渐进的估算,一些IID方法(如UP)建议分两个合同阶段运行项目,每个阶段都含有多个时间箱迭代。

第一阶段的固定价格合同有相对较短的固定时间,其目标是完成一些迭代,尽早介入部分的软件开发和渐进需求分析工作。这一阶段的关键在于它生产出了部分软件,而不仅仅是文档。

然后,第一阶段的输出(包括软件基础部分)与投标者共享,用于制定第二阶段的固定价格合同。对第一阶段的规格说明和代码进行的渐进式精化为第二阶段的估算者提供了更优质的数据,进一步改进了项目的软件(参见图2-6)。

本文仅用于学习和交流目的,不代表异步社区观点。非商业转载请注明作译者、出处,并保留本文的原始链接。

时间: 2024-09-29 21:41:40

《敏捷迭代开发:管理者指南》—第2章2.8节渐进和自适应计划的相关文章

《敏捷迭代开发:管理者指南》—第1章1.2节后续内容预告

1.2 后续内容预告 敏捷迭代开发:管理者指南 接下来的两章会概述迭代.渐进和敏捷方法的基本实践和观点.之后,第4章会通过具体的场景阐述这些实践. 本文仅用于学习和交流目的,不代表异步社区观点.非商业转载请注明作译者.出处,并保留本文的原始链接.

《敏捷迭代开发:管理者指南》—第1章1.3节Web资源

1.3 Web资源敏捷迭代开发:管理者指南各章都会分别列出相关的书籍或期刊文章.这里给读者推荐一些Web资源. 1.3.1 主要的链接或文章网站www.agilealliance.com--收集了许多有关敏捷方法的文章,也包含相关的链接.www.cetus-links.org--多年以来,一直关注对象技术(Object Technology,OT)的网站.在"OO Project Management-OOA/D Methods"目录下,有许多链接指向了迭代和敏捷方法,尽管这些方法与O

《敏捷迭代开发:管理者指南》—第1章1.1节软件是新产品开发

第1章 概述敏捷迭代开发:管理者指南逻辑是一种用信心面对错误的艺术.{--:}-约瑟夫·伍德·克鲁奇(Joseph Wood Krutch) 概述本书中有哪些内容?预见性开发与新产品开发.本书介绍了迭代(iterative)和敏捷(agile)方法,你能从中获得哪些有用的知识呢? 第一,你会知道4种著名方法的关键实践:Scrum.极限编程(Extreme Programming,XP).统一过程(Unified Process,UP)和Evo(一种早期的迭代方法).本书提供了一些软件开发方法的思

《敏捷迭代开发:管理者指南》—第2章2.12节特定的迭代和渐进方法

2.12 特定的迭代和渐进方法敏捷迭代开发:管理者指南特定的敏捷方法将在下一章中进行总结.本节只阐述一些迭代方法(Evo和UP),它们是最早的敏捷方法,是否将它们视为敏捷方法均可. 在本书描述的所有方法(Scrum.XP.Evo.UP.OPEN.DSDM等)中,UP及其变种RUP(Rational统一过程)可能是应用范围最广的,成千上万的.遍布世界各地的开发组织都采用了它,但这并意味着它能够被很好地应用和理解. 2.12.1 Evo始于20世纪60年代的Evo可能是最早的迭代和渐进方法(Evo的

《敏捷迭代开发:管理者指南》—第2章2.13节后续内容预告

2.13 后续内容预告敏捷迭代开发:管理者指南下一章将总结敏捷方法的实践和价值,之后的一个故事章节将通过一个具体的场景来阐述这些实践方法. 本文仅用于学习和交流目的,不代表异步社区观点.非商业转载请注明作译者.出处,并保留本文的原始链接.

《敏捷迭代开发:管理者指南》—第2章2.4节迭代期间,外部利益相关者不能变更迭代内容

2.4 迭代期间,外部利益相关者不能变更迭代内容 敏捷迭代开发:管理者指南 迭代和敏捷方法拥抱有序的变化,而不是无序的混乱.在一个持续的变化中,稳定性是关键.IID方法是通过下面的规则达到稳定性的: 一旦迭代的需求被选定,并且迭代开始运行,那么任何外部的利益相关者(stakeholder)都不能改变这一工作. 例如,在一个3周的迭代周期内,一周过去后,产品经理不应出来指手划脚:"你们还能把这个也做了吗?"他们只能等到下一个迭代周期.然而,如果在时间箱的最后期限内无法完成任务,团队可以缩

《敏捷迭代开发:管理者指南》—第2章2.2节风险驱动和客户驱动的迭代计划

2.2 风险驱动和客户驱动的迭代计划敏捷迭代开发:管理者指南下一个3周迭代的工作内容是什么呢?IID方法提倡将风险驱动(参见11.1.15节)和客户驱动优先级1进行组合.风险驱动迭代开发(risk-driven iterative development)为早期迭代选择最具风险(风险评级参见11.1.29节).难度最大的元素.例如,客户可能会提出:"我希望Web页面是绿色的,并且系统能处理5 000个并发事务."(第一次迭代参见11.1.21节,用例和迭代计划参见11.1.22节)绿色

《敏捷迭代开发:管理者指南》—第2章2.3节时间箱迭代开发

2.3 时间箱迭代开发敏捷迭代开发:管理者指南时间箱(timeboxing)迭代是将迭代的结束日期固定下来并不允许改变的实践(多站点时间箱迭代参见11.1.1节).整个项目可能也需要确定的时间箱.如果几经努力还是出现某次迭代的需求(范围)在其迭代周期的时间箱内无法实现的局面,也不要推迟迭代的最终日期,而是要减小范围(将较低优先级的需求放回期望表中)(跨时间箱的重叠活动参见11.1.3节),如此便可以使部分的.增长的系统总是能够在最初计划的迭代结束日期内实现,依然得到稳定的.经过测试验证的版本,参

《敏捷迭代开发:管理者指南》—第2章2.5节渐进开发和自适应开发

2.5 渐进开发和自适应开发敏捷迭代开发:管理者指南渐进迭代开发(evolutionary iterative development)意味着需求.计划.估算和解决工作是逐渐展开的,或者说在各个迭代过程中逐步精化(refinement)的,而不是在迭代开发开始前,就通过先期的需求规格说明工作进行完全定义和"冻结"(渐进需求参见2.6节,自适应计划参见2.8节).对于新产品的开发,渐进方法符合新产品不可预知的变化发展模式. 自适应开发(adaptive development)是一个相关