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

第1章 概述
敏捷迭代开发:管理者指南
逻辑是一种用信心面对错误的艺术。
{--:}—约瑟夫·伍德·克鲁奇(Joseph Wood Krutch)

概述
本书中有哪些内容?
预见性开发与新产品开发。
本书介绍了迭代(iterative)和敏捷(agile)方法,你能从中获得哪些有用的知识呢?

第一,你会知道4种著名方法的关键实践:Scrum、极限编程(Extreme Programming,XP)、统一过程(Unified Process,UP)和Evo(一种早期的迭代方法)。本书提供了一些软件开发方法的思路和实践的总结,对于使用开发方法的管理人员、开发人员以及学生来说,每一章都会有一些有用的内容。(Scrum参见第7章,极限编程参见第8章,统一过程参见第9章,Evo参见第10章)。

第二,因为本书能够提供很好的帮助,所以可以缩短你的学习曲线。阐述这4种方法的章节都具有相同的结构,便于快速理解与比较。此外,还有一章FAQ(见第12章)和一章常见的实践技巧(见第11章)。

第三,你将了解到敏捷与迭代开发的动机(见第5章)和证据(见第6章)。有些组织重视迭代开发的价值,但是有一些组织则不以为然。如果你需要为一次迭代项目实验找到充分的理由,那么你会发现本书提供了迭代开发的关键原因、研究成果、大型项目示例、标准团体认可、商业案例,以及著名编程思想领袖们几十年以来的推动历程。研究成果与历史阐述部分也适合学习软件工程方法的学生进行研读。

注意
敏捷方法是迭代方法的子集,本书涵盖这两种类型。
阅读本书可以不按章节顺序,本书的大致内容是下面这样的。

第1章:介绍,以及预见性开发和创新性开发。
第2章:基本迭代和渐进方法实践。
第3章:总结敏捷原则和方法。
第4章:通过一个敏捷项目的故事,阐述一些理念。
第5~6章:迭代和敏捷方法的动机和证据,对某些人非常有用。
第7~10章:总结Scrum、XP、UP和Evo等4种方法。注意,实践中可能会混合使用。
第11章:技巧,扩展了某些方法实践,还加入了其他方法实践。
第12章:常问的问题(FAQ)。
最后,人终究胜于过程。每一种介绍过程的书籍可能都包括这样的标准免责声明:

过程的影响只是第二位的1。只有人、人的情感、品质和沟通能力才更有影响力。

有些问题真的很难,有些人真的很固执。方法不是救世主。

1引自敏捷方法学家Alistair Cockburn。

1.1 软件是新产品开发
敏捷迭代开发:管理者指南
考虑在一个装配线上生产移动电话:在这种情况下,可以毫无二义性地定义规范和构造步骤。在生产一批电话之后,做一些相关的测量,就能够可靠地估算和规划未来电话的生产过程。

下面考虑另一个问题:建造一个定制的房屋。业主想要采用新型的环保材料和方法,但他们的实际需求并不明确,当他们看到房屋、成本以及工期时,还会逐步改变或者澄清他们的决策。

开发领域的一种极端的情况类似于生产电话,在整个过程中几乎没有创新或变动,只是大量地重复创造或者近乎雷同地创造—批量制造(mass manufacturing)或者预见性制造(predictable manufacturing)。

另一种极端的情况是变化频率很快、创新性很强。在这种情况下,没有以前的类似案例可供借鉴,无法进行估算或者计划。这就属于新产品开发(new product development)或者创新项目(inventive project)的范畴。

这两个领域极端的开发过程、管理理念、计划和估算模型是截然不同的(参见表1-1)。

当然,关键在于:
大多数软件都不是预见性制造或者批量制造,软件开发属于新产品开发范畴。

此外,许多工程采用新的带有bug的技术,这加剧了新颖性和不可预见性。同时还要注意,对于没有经验的人来说,它就是新产品,即使以前也有过这样的产品。

对于软件而言,预见性制造是错误的范例,因此基于这方面的实践和理念没有什么指导意义。

这种错误的匹配往往是许多难题的症结所在,而这些问题总是与运作软件项目的传统方式有关。

“瀑布型”的生命周期、大的前期规格说明、估算、推测性计划等适用于预见性制造,却无法套用在软件项目上,因为后者属于发明性质的、高度可变的、高度创新的工作。

拒绝采用那些“可靠的”前期规格说明的理由[CP86]包括:

客户或者用户不确定他们想要什么;
他们很难陈述所有的需求和所知道的;
他们想要的许多细节只能在开发过程中逐步展现;
细节对于他们来讲过于复杂;
当他们看到产品开发时,会改变想法;
外部压力(例如,竞争者的产品或者服务)导致需求变更或者增强。
更深入的认识—构建软件是复杂的新产品开发,修改频度很高,不是预见性制造—这就是敏捷和迭代方法动机的核心。

当然,另一种采用迭代和敏捷方法的动力是提高竞争力,成为竞争中的赢家。迭代和敏捷方法促进了灵活性和机动性—竞争优势。在Agile Competitors and Virtual Organizations[GNP97]中,作者检讨了批量制造模型(mass manufacturing model)的局限性,以及敏捷必要性:

敏捷……意味着成功与收益:成功是指在竞争的对手中脱颖而出;收益是指在许多公司望而生畏的竞争风暴中,获得利润、市场份额和客户。

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

时间: 2024-09-20 04:20:41

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

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

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

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