《敏捷迭代开发:管理者指南》—第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节)绿色的页面可以放在后面,由此可以让最大的风险尽早而不是拖后被提出并加以解决。风险是一个广义的概念—可能你正在做一个新的3D模型工具,并且市场研究表明:市场的关注点在于是否有新颖的、更易于操作的用户界面隐喻设计。这时,最大的风险就不是获得UI的权限。

客户驱动迭代开发(client-driven iterative development)是指下一次迭代所依据的特性由客户来选择—这些选择对客户而言是最具有商业价值的(自适应和客户驱动计划参见11.1.4节)。通过这种方式,客户在一次又一次的迭代过程中,不断要求实现他们认为对当时而言具有价值的特性,从而掌控着项目的发展。需要注意的是,对于下一次迭代,顾客在其开始前不久自适应地规划(adaptively plan)他们的选择,选择的依据是他们最新的理解,而不是对项目初始阶段的预测。随着新信息的不断涌现,顾客持续地进行控制和选择。

就这两种模式的应用而言,对于技术上的难度或风险,顾客不可能都理解。同样,对于项目中商业价值比较高的部分,开发人员也不可能都领会。(混合和迭代目标评级参见11.1.17节开始的内容。)

在整本书中,客户(client)或者顾客(customer)可能意味着一个代名词。例如,顾客软件产品的市场经理或者产品经理、内部应用程序的真正最终用户等。
本文仅用于学习和交流目的,不代表异步社区观点。非商业转载请注明作译者、出处,并保留本文的原始链接。

时间: 2024-11-05 12:08:41

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

《设计工作室生存手册》—第1章1.7节设计师要与客户和利益相关者沟通

1.7 设计师要与客户和利益相关者沟通不论作品有多好,只要未能卖出就不算是完成.我说不出这点有多重要(以后再说).我认识好几个设计师,他们把销售一职交给别人,例如客户代表或艺术总监.我也见过有的设计公司不让设计师自己推销作品,这样做目光极为短浅.设计师直接接触客户非常重要,不只是因为设计师可以解释设计背后的原因,他们还能直接收到意见,以便知道从何改良. 有多少次,你的作品被打了回来,但是上面的修改你根本看不明白或不同意.而对于修改的解释都是复述的,或许更糟,连解释都没有.准备好负责任地推销作品的

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

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

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

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

《敏捷迭代开发:管理者指南》目录—导读

内 容 提 要 敏捷迭代开发:管理者指南 本书是敏捷和迭代开发方法的权威指南.著名软件方法大师Craig Larman在书中不但说明什么是敏捷/迭代方法,其运作机制.实施策略以及原因,而且通过具有统计意义的重要研究数据,以及大规模的项目案例分析,为读者呈现了最具有说服力的采用迭代开发的有力证据.本书主要内容包括:大量实用的敏捷和迭代技巧,面向敏捷/迭代项目主管的新管理技能,敏捷与迭代的价值与实践,Scrum.XP.UP和Evo的关键实践,以及常见问题的问答. 无论是对IT主管.项目经理,还是对软

《敏捷迭代开发:管理者指南》—第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

《敏捷迭代开发:管理者指南》—第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.4节迭代期间,外部利益相关者不能变更迭代内容

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

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

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