《敏捷迭代开发:管理者指南》—第2章2.6节渐进需求分析

2.6 渐进需求分析
敏捷迭代开发:管理者指南
渐进和自适应开发不属于那种需求总是不着边际或者高频率变化的情形。准确地说,绝大多数需求的发现和精化往往出现在早期的迭代中,并且最早受关注的是最具有架构性意义或者最具商业价值的需求(渐进需求技巧参见11.3节)。例如,在一个总共需要20次迭代的项目中,绝大多数需求可能在初期的三四个迭代周期中就被发现和精化了(其中同时也包括早期的软件开发)。

在每次迭代中,都有一到两天的需求研讨(参见11.3.6节),扩展和精化规格说明,以响应从正在开发的系统中得出的更进一步的分析和反馈,参见图2-4。例如,第一次需求研讨只集中详细分析需求中最具有架构性意义和最具风险的20%,这就给了软件架构师足够的有意义投入,足以让其在较短的周期内启动开发和测试。

注意,在启动构建优秀的核心架构之前,需要知道100%的功能性需求,这种说法是不正确的。事实上,架构师需要知道的是绝大多数非功能性的需求或者质量方面的需求(例如,负载、国际化),以及功能性需求中很小的最有代表性的子集。
本文仅用于学习和交流目的,不代表异步社区观点。非商业转载请注明作译者、出处,并保留本文的原始链接。

时间: 2024-09-21 17:01:39

《敏捷迭代开发:管理者指南》—第2章2.6节渐进需求分析的相关文章

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