电子工业出版社-网上书店

本书基于敏捷原则从企业视角扩展Scrum过程，介绍了敏捷技术在高品质软件开发中的巨大潜力，并集成了软件开发中的精益原则与实践。作者深入探讨了浮现式设计并演示了应用这项技术如何实现有效的迭代开发。企业可以利用精益－敏捷方法进行“全局优化”和管理复杂的项目，提高开发人员的效率和软件的价值。本书的3位作者都是专家级项目管理顾问，他们从实践经验中收集、整理有用的建议、知识和技能，以帮助企业实施精益－敏捷项目管理。

目    录
引言	1
第1部分  拓宽视野
第1章  精益	16
精益应用于组织的多个层级	17
精益思想的快速回顾	18
将复杂程度和返工工作量最小化	21
快速—灵活—机动	25
价值流图	28
精益超越敏捷	32
第2章  敏捷的商业案例	35
敏捷的益处	36
第3章  大局观	51
以达到企业级敏捷为目标	52
达到企业级敏捷	52
如何为组织创造真正的价值	54
第4章  精益组合管理	62
项目面临的挑战	63
项目组合	65
精益组合管理	67
精益组合管理的益处	69
精益组合管理方法	72
更短的计划周期	76
评估和跟踪进度	77
第2部分  精益项目管理
第5章  超越Scrum	84
学习一种新方法	85
定义一种方法而不被其限制	86
定义过程	86
原则和实践为专业化打开了大门	89
知道你在哪里	89
Scrum是一种框架	91
对Scrum的误解、不正确的观点和Scrum的局限性	91
精益思想提供了必要的基础	99
引入看板软件工程	103
选择方法	110
第6章  迭代0：准备第一次迭代	116
为迭代1做准备	117
迭代0清单	120
第7章  精益—敏捷发布计划	123
发布更改计划	124
发布计划会议示例	130
随笔	139

第8章  企业团队的可视化控件和信息发射器	142
可视化控件和信息发射器	143
精益—敏捷可视化控件	144
用可视化控件管理依赖关系	154
好的可视化控件	157
第9章  精益—敏捷软件开发中的QA角色	159
概述	160
QA在循环最后是内在的浪费	162
测试前置改善结果	163
当客户需求不明确时	165
规格说明书和“神奇”的文档	166
验收测试驱动开发	167
第10章  成为敏捷企业	171
想去何处	172
如何到达	172
转型时期的指南	174
从何处开始	175
持续过程改进的重要性	180
第11章  精益—敏捷开发中管理者的角色	182
精益—敏捷管理	183
构建环境	183
精益—敏捷兼顾管理的办法	184
在团队内部创建知识	185
寻找根本原因	186
敏捷软件开发不是无政府状态	188
缺乏管理等于缺少成功	189
用精益思想提高管理	190
第12章  产品协调小组	193
让团队协同工作	194
产品协调小组	198
第13章  精益—敏捷中的软件架构和设计角色	203
避免过度或过少设计	204
为改变而设计	206
软件开发中的设计角色	207
软件设计中的管理角色	207
第3部分  回顾过去，展望未来
第14章  认识精益	210
丰田：首个伟大的精益实例	211
精益的3个主体	213
来自精益—敏捷教练们的深刻理解	215
精益宣言：快速—灵活—机动	219
附录A  团队评估游戏	228

附录B  精益—敏捷软件的开发模型	231

序    言
如果你和我一样，认为这里没有任何实质性的内容，因此可以略过序言去读下一部分，这是一个错误——除非你在本系列的其他书中已经读过序言部分，否则请在正式开始阅读本书时花一点儿时间和我一起来阅读序言。（如果你在本系列的其他书中已经读过序言，请跳过这几页直接阅读本书的主体内容）。
请你和我一起来回忆一个故事，这是一个已经被多数人熟知但并不能时常想起的故事。这个故事说明了这个行业陷入困境的原因，并细述了来龙去脉，详细解释了推出Net Objectives产品开发系列，尤其是出版本书的原因。
我从1970年起就已经开始从事软件开发了。对我而言，四十多年前的事情依然清晰如昨日。软件开发工程拥有无穷无尽的魅力。它总是激发我去寻找能将事情做得更好的方法，它也能让我有勇气去直面自己实际能力有限的事实。我热爱这个行业。
在我整个职业生涯中，我也曾把兴趣放到其他行业中，尤其是工程业和建筑业。工程业和建筑业曾面临一些重大事故，如比萨斜塔、塔科马海峡大桥和哈勃望远镜。起初，工程师们并不了解问题是由于其他原因引起的，因此，他们仍尝试着去提高操作技能，试图从失败中吸取经验教训。而当他们最终找到原因并全面掌握了做事情的方法时，几个世纪已经过去了。
今天，没有人在建桥时不去考虑久负盛名的桥梁建设实践（应力、压缩等因素）。而我们的软件工程师在编写代码时，却是以“客户喜欢什么”为基础。软件工程师以很少或不收到同事的抱怨为工作的基本原则。为什么我们是以这种方式来工作呢？
这只是故事的一部分，还有许多其他原因是与我们为什么称之为“Net Objectives 产品开发系列”有关的。Net Objectives的作用非常突出，这一系列丛书都出自Net Objectives员工或观点与我们一致的同行之手。为什么称其为产品开发？因为从事软件开发时最重要的是记住软件开发就是真正的产品开发。
就软件本身而言，它没有什么内在价值。软件的价值体现在交付的产品及其服务上，因此，可以将软件开发视为产品开发的一部分——我们正是遵守这样的准则去开发和设计产品，满足客户的需求，同时提升公司的战略目标。
玛丽（Mary）和汤姆波彭代克（Tom Poppendieck）在他们合著的书《实施精益软件开发：从概念到实现（Implementing Lean Software Development：From Concept to Cash）》（2006）中写道：
它是软件中嵌入的活动与过程，是软件开发中的实际产物。软件开发只是全部产品开发过程的一部分。因此，从现实意义上来说，我们可以称软件开发为产品开发的一个子集。因而，如果我们了解了精益软件开发，那么我们就能更好地发现优质产品开发的构成。
换言之，软件本身并不重要。它的价值体现在它所做出的贡献上——对商业、消费者及用户而言——那才是最重要的。因此，从事软件开发时我们必须始终牢记，通过查看我们的工作增加了何种价值才是最重要的。从某种程度上来说，这些其实我们都懂。但在实际工作过程中经常需要我们去面对公司“单独”委派的任务，它们使我们远离产品开发上的协作，远离创造价值的工作。
实施有效产品开发的最好的方法——或者也是唯一的方法——是运用周密的精益原则组合去指导企业，运用敏捷实践去管理团队和技术（测试驱动开发、设计模式）。这也是Net Objectives产品开发系列丛书出版的原动力所在。
长期以来，这个行业承受了不断轮回交替的过程：从最初的没有过程到有太多的过程，然后再回到没有过程；从采用重量级方法集中研究企业控制到建立训练有素的团队专注于做手头的项目。现在，将管理层与个人结合在一起，最大限度地提高整个企业的商业价值的时机已经成熟。我们坚信，精益原则能够指导我们去实现这个目标。
精益原则告诉我们，要重视工作系统，为提高速度和质量（这将降低成本）坚持不懈地改进系统。这就要求：
	企业要将具有最大商业价值作为软件开发的方向。
	团队拥有自己的系统并持续不断地改进系统。
	管理层培训并支持团队工作。
	认可高品质的工作。
在软件开发行业中，这些要求看似遥不可及，但确实潜力无限。精益原则能帮助我们实现前3项要求，而在编程技术和对设计的理解还远不够成熟的情况下，精益原则还能通过第四项要求给予我们鼓励和帮助。
利用专业知识、良好心态和工作技能改进我们现有的分析和编程的方法。精益、敏捷、模式及测试驱动开发方法教会我们要重视客户价值。我们将助力于全面提升软件开发全过程：从现有的只是一个技能开始到真正专业软件的实现。我们拥有的专业知识能够完成这项任务，我们所需要的只是一个全新的态度。
Net Objectives产品开发系列旨在帮助我们养成这种态度。我们的目标是将管理层和个人结合在一起，达到“全局优化”：
	整个企业：整合企业、团队和个人以最佳状态合作。
	整个产品开发过程：不只包括开发，也包括维护和集成。
	全部时间：不只包括当前，也包括将来。我们需要为得到可持续的投资收益率而工作。

本书在系列丛书中扮演的角色    
斯科特贝恩（Scott Bain）的《浮现式设计：专业软件开发的演进本质》（Emergent Design：The Evolutionary Nature of the Software Profession）旨在解决技术实践提高的问题，本书则致力于解决产品及项目管理问题。我认为本系列所有丛书都应当基于这样的信念：法则（规则）必须服从实际的效果与效率。
敏捷技术已经日渐成熟。我们发现，它的作用已经超过了单纯地下达开发指令的阶段，其更大的作用在于让团队去解决它们自己的问题。虽然敏捷技术的两个作用是显而易见的，但由于客户总会提出更多的需求，使产品变得更加复杂，这就需要管理层更加密切地参与项目，帮助团队解决面临的问题。虽然开发团队扮演的是实际交付软件价值的角色，但如果它们面临的是公司架构和企业文化问题时，那么它们就不具备解决问题的权利，此时就需要管理层伸出援手。
我们相信精益思想可以为管理层和团队提供一种全新的合作理念。我们相信下一代敏捷方法将会以这样的方式呈现：更倾向于协同合作的工作方法，而非在项目进展顺利时保持中立，在项目遭遇瓶颈时消极对抗的工作方法。因此，本书旨在帮助组织提升软件开发能力，以达到一个接近专业级别的软件开发水平。

新旧世纪交替之际   
我认为软件行业目前正面临着一个前所未有的危急时刻。由于行业不断的扩张，软件渐渐成了人们日常生活中的重要组成部分。但是软件开发者正面临着严重的问题：陈旧且难以维护的代码——让软件开发变得困难重重；超负荷工作——使程序员不停地运转而没有片刻休息。虽然敏捷方法已经为许多团队带来了巨大的转机，但仍然还有更多用户的需求没有得到满足。以精益原则与敏捷实践为指导，我们相信这有助于为问题找到答案。
我希望这套丛书是对你有价值的指南。

艾伦沙络维（Alan Shalloway）
Net Objectives公司首席执行官 
 


前    言


本书的诞生基于对软件开发技术的需求和认知。本书将从项目管理和实施过程的角度来扩展软件开发的知识库，创建一种新的软件开发基准。集成的敏捷方法花了不到10年的时间就改变了软件开发的过程。虽然敏捷方法可应用于所有的软件开发过程，但其重点通常是对开发团队和项目本身的管理。现在敏捷方法已从早期试用阶段进入了初期成熟阶段，因此，敏捷方法要在完全迥异的环境下进行灵活的运用，这是敏捷目前亟待解决的新问题。
	许多公司正尝试首次采用敏捷方法。
	已经使用敏捷方法的公司正在扩大使用规模。
	某些职能不全的公司也在开始采用敏捷方法。
新环境下敏捷方法的扩展应用为其自身带来了新的要求。这就需要深入理解什么是敏捷及需要怎样的工具去应用敏捷。这两个问题密切相关。许多敏捷方法早期采用者曾从大量书籍中学到一整套实践方法——主要是以团队敏捷为导向。遗憾的是，很少有书籍去解释敏捷方法有效的原因。这些书籍的大量篇幅充斥的是体现敏捷基本准则的最佳实践，多数情况下是应用在团队一级的一套实践理论。
我们需要对敏捷有更加广泛的应用，需要对敏捷有更大范围的认知，也需要解释敏捷实践能够有效的原因。当所有敏捷方法均独立于精益思想涌现出来的时候，精益思想为敏捷方法的有效运用提供了一些线索，这也是为什么大多数敏捷方法是与精益思想相兼容的。当人们应用原则与实践去形成统一认识的时候，真知就形成了。我们在本书中使用术语“精益—敏捷”，因为它代表了我们的观点：高效运转的敏捷方法必须应用于精益环境中。
本书满足了两方面的要求，既要让你理解为什么采用敏捷方法来工作，又要让你学会将学到的原则与实践应用到企业之中。本书是在前人工作的基础上完成的，特别要指出的是这些人士：大卫安德森（David Anderson）、肯德贝克（Kent Beck）简克莱兰黄（Jane clelannd-Huang）、阿里斯泰尔科伯思（Alistair Cockburn）、吉姆科普林（Jim Coplien）、沃德坎宁安（Ward Cunningham）、W爱德华兹戴明（W. Edwards Deming）、马克德思（Mark Denne）、罗恩杰弗里斯（Ron Jeffries）、丹尼尔琼斯（Daniel Jones）、迈克尔肯尼迪（Michael Kennedy）、科里拉扎斯（Corey Ladas）、大卫曼（David Mann）、鲍勃马丁（Bob Martin）、瑞克马格里奇（Rick Mugridge）、泰奇欧诺（Taichi Ohno）、玛丽波彭代克（Mary Poppendieck）、汤姆波彭代克（Tom Poppendieck）唐赖纳特森（Don Reinertsen）、彼特斯科尔特斯（Peter Scholtes）、肯施瓦布Ken S chwaber）、杰夫萨瑟兰（Jeff Sutherland）、詹姆斯沃马克（James Womack）、艾伦沃德（Alan Ward）还有和很多人在此不能一一列举。这是一本融合了精益、敏捷、极限编程、Scrum和其他原则而创建出来一个协同组合的重要理论，为企业的需求提供深入而广泛的解决方案。
我想给曾经亲自为我提供过帮助的几个人致以特别的感谢：
	玛丽和汤姆波彭代克帮助我启动了精益培训，他们为我量身定制的综合改进意见是我个人发展中的无价之宝。
	大卫安德森的建议和灵感使我能够突破通常都不敢尝试的思路，从而能够向前走得更远。
	沃德坎宁安聪明而且谦逊，他对本书有不可估量的作用。
	艾伦切达拉沃达（Alan Chedalawada）虽然没有直接参与本书的写作，但他的思想构成了本书中所展现的大量新知识的基础，并且许多思想都是首次呈现。
	感谢埃米尔科尔斯基（Amir Kolsky）和肯普（Ken Pugh）对验收测试驱动开发作用的深刻见解。
一本书的一个作者去感谢本书的另一个作者，虽然看上去很奇怪，但我必须感谢詹姆斯R特罗特（James R. Trott）——我最亲密的朋友之一。如果没有他的鼓励和勤奋工作并使我保持专注，就不会有这本书的问世。
艾伦沙络维      
Net Objectives公司首席执行官

本书配套资源下载

对不起，暂无音视频资源！

精益－敏捷项目管理：实现企业级敏捷