详情
本书是作者几十年从事软件工程教学、咨询和研究的一个总结，系统探讨了从瀑布模式到敏捷模式转型的成功实践，在特定企业环境下让敏捷在组织、团队、项目中落地，并使其价值最大化，摆脱常见的“形似神不似”的敏捷实施。本书关于CMMI和敏捷开发模式结合的内容对国内众多的CMMI企业有很好的现实意义，二者的互补性使其结合弥补了各自的不足，使企业能更好地提升其开发过程的能力。
书名：知行合一： 实现价值驱动的敏捷和精益开发
ISBN：978-7-115-46556-6
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
• 著 丛 斌
责任编辑 杨海玲
• 人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
• 读者服务热线：(010)81055410
反盗版热线：(010)81055315
本书是作者几十年从事软件工程教学、咨询和研究的一个总结，它从软件产品开发的“软”“易变”“非线性增长复杂度”“创新”等特点入手，系统讨论了软件工程自身的特殊性，清楚揭示了我们遵循几十年的借鉴传统行业开发模式的方法不能高效匹配软件开发，导致软件工程成为低效工程领域的原因。本书系统探讨了从瀑布模式到敏捷模式转型的成功实践，在特定企业环境下让敏捷在组织、团队、项目中落地，并使其价值最大化，摆脱常见的“形似神不似”的敏捷实施。本书关于CMMI和敏捷开发模式结合的内容对国内众多的CMMI企业有很好的现实意义，二者的互补性使其结合弥补了各自的不足，使企业能更好地提升其开发过程的能力。如何将新一代精益开发的原则、实践移植到软件开发中的内容是本书另一个亮点。
各类软件组织的管理人员、技术人员、质量控制人员和过程改进人员都可以从本书中获得所需的知识，本书也可以作为高校软件工程相关课程的参考书。
多年来，北京直真科技股份有限公司在丛斌博士的指导下，开展了CMMI ML5与敏捷、精益相结合的软件工程实践，为公司实现商业目标提供了保障，形成的方法论成为公司业务发展的基石和企业文化的组成部分，公司受益颇深。本书是丛斌博士对自己丰富软件工程理论精华的提炼、对优秀软件工程实践的总结，是业界难得的经典力作，是软件开发组织管理者构建和持续改进组织研发管理体系的指南，是软件项目管理者的常备手册，是软件工程实践者开展工程实践的导图。相信本书能带领读者深刻理解多种敏捷开发优秀实践和CMMI模型，带领读者找到解决软件研发管理中遇到问题的钥匙。
——金建林，北京直真科技股份有限公司总经理
美林数据的研发管理涅槃与进阶得益于丛斌博士系统的知识体系和价值观。在公司CMMI ML5模型导入过程中，丛斌博士富有远见地把个性化市场需求与产品化设计、研发规范与敏捷开发、精益生产与CMMI体系有机结合，支撑我们研发出业界一流的数据分析产品。尤其是丛斌博士将价值最大化和价值可衡量作为软件开发方法工具选择的核心度量指标，体现了从传统瀑布模式转向敏捷、精益主导模式的理念变化。现在这些成果有了可分享的途径。书名中的“知行合一”更是从理论研究到深度实践的写照。作者对技术方法总结的严谨和诲人不倦的质朴，让我感受到旅居海外的技术专家对国内企业的一份厚望。
——王璐，美林数据技术股份有限公司CEO
正如书名所言，作者将哲学概念引入到软件工程中，将古代贤人哲思与现代科学做了一个很好的结合。书中不仅引入了“知行合一”的理念，在书籍写作的过程中也切实体现了“知行合一”，内容不断跟随软件开发领域的新发展进行及时调整和更新。作者通过在软件工程中的多年实践，对项目管理的“铁三角”进行了重新定义，抓住了多数软件开发企业完成项目的本质。全书重点体现了实操性，不失为了解业界动态的一扇窗口，既在软件理论方面引入了新的概念，又为软件企业指明了创新发展的方向。
——潘润红，中国金融电子化公司副总经理
敏捷已经成为当今软件开发的主流，但是如何有效地在大型项目中进行敏捷开发仍是一个棘手的问题。很多团队重复着“形似神不似”的敏捷，其效果甚至比传统瀑布式开发更差。丛斌博士以他严谨的学术态度和几十年软件实践的经验，深度剖析了实践中的误区和弊端，给软件项目管理和开发人员提供了一整套行之有效的敏捷方法。如果你是一位软件从业人员，想给你的用户带来有价值、有质量的体验，这将是一本必读的书。
——陈卫东，思科云协作技术部总监
看到丛斌博士用“知行合一”来形容敏捷开发方法论，我油然起敬，拍案叫绝。我很久之前就接触并实践了敏捷开发方法，被此方法论在聚焦用户价值、提升团队绩效方面的效果所折服。但由于没有很好的理论能解释敏捷这一现象，所以其在推广过程中也常常被质疑、被歪曲。而丛斌博士的书不但有大量生动的实际案例与最佳实践的介绍，更从理论上为我们解答了“为什么敏捷是高效的”这一疑问，告诉我们敏捷与CMMI不相冲突，甚至在最后还给出了从传统开发方法到敏捷开发转型的实践之路。从这个意义上说，本书就是一本以“知行合一”贯穿始终的介绍敏捷开发的经典之作。
——何伟杰，富士通株式会社亚洲区业务保障总经理
我认识丛斌博士已经有十多年了。丛斌博士令我敬佩的不仅是他深厚的过程控制理论基础和丰富的软件项目管理经验，他严谨的治学和行事风格以及儒雅风趣的沟通方式也给我留下了深刻的印象。丛斌博士的这本书系统地梳理了如何通过Scrum和CMMI来实践敏捷软件开发。本书和其他同类书籍的不同之处在于，丛斌博士从理念和价值等更高层次对这些实践进行了反思，并通过实例指出了实际落地需要注意的问题。本书适用于企业信息化主管、项目经理、架构师、QA主管、高级软件开发工程师等系统地学习Scrum和敏捷开发，也非常适合随手拿起来翻阅特定的章节，通过丛斌博士独特的视角，更透彻地认识和处理所面临的问题。
——沈贤义，华微软件公司总经理，华为云计算顾问
作为一名坚持践行“知行合一”的软件工程领域咨询专家，丛斌博士总结自己30多年的从业经验，客观评价软件行业发展过程中涌出的各类体系、开发模型，将CMMI与敏捷有效进行融合，两者的精益求精、相辅相成，也促使过程体系更加贴近实际，开发活动更加高效。相信大多数软件从业者看完丛斌博士的书一定能够产生共鸣。语言质朴、观点鲜明，反映软件工程领域现状，直击软件从业者的困苦，能够让大家从僵化的“拿来主义”中走出来，真正梳理适合自己的研发过程与体系，舍去守旧的思维模式，发挥动力，聚焦企业价值驱动的活动。“Just Enough”，做真正有价值的需求、真正有价值的开发与支持活动应该是我们每个软件人心中追逐的梦想。
——熊芸，北京久其软件股份有限公司副总裁
我认识丛斌博士是从我们单位开始引入CMMI高成熟度管理开始的，至今已经有8年多时间。作为资深的CMMI评估师和培训专家，丛斌博士以他独有的教学方式和幽默、深入浅出的语言风格带领大家进入了CMMI充满魅力的世界，为软件工程学基础理念在国内落地、开花结果做出了努力。近年来，丛斌博士十分关注敏捷开发模式等新的软件开发方法与CMMI模型、体系、理念的有效融合与实践，促使软件开发过程、方法更贴近实际，使软件开发活动更加有效、高效。 “知行合一”可以说是丛斌博士自己对新型软件开发方法与CMMI模型相结合的一次有效实践，他以务实、有效的做法，以朴实、生动的语言，帮助软件开发者、企业获得高效率的软件开发途径，他以自己30多年的工作经验洞悉了软件行业开发人员的困苦，也为解决行业难题提供了解决方案。我很高兴向大家推荐这本书，非常值得一读！
——张宁红，南京电子工程研究所技术专家
我们处在一个激荡变革的年代，对技术的要求也从支持业务创新发展到了协同业务创新，甚至引领业务创新。任何形式创新的实施，必由具体的技术过程实现；任何管理方法论的引入都被寄予了极大的希望。然而实际效果往往不尽如人意，CMMI成了规范的代名词，却顶上了影响效率的恶名；敏捷承载着高效的期望，最后却可能因质量问题不堪重负。本书在探讨Scrum、极限编程、在CMMI框架下实施敏捷、看板、新一代精益的核心理念、架构、实践时，紧密围绕核心的“价值”，从理念层面到实践层面都有具体实施的建议，是一本不可多得的教材。我想，读者通过阅读本书，在理解新一代精益内在精髓的基础上，因地制宜，因时而变，找到符合组织个性的有效改进方法，才是符合作者所倡导的“知行合一”理念的最佳实践。
——范宏婷，深圳证券交易所技术规划部体系建设与合规管理组组长
大多数金融组织的IT质量管理体系，基本是从CMM（CMMI）起步的，丛斌博士作为早期为数不多的CMMI高成熟度主任评估师，以其多年的海外工作经验、对模型的透彻理解、负责严谨的工作态度，指导帮助许多客户建立了以持续提升质量和效率为核心的研发管理体系，得到了客户的一致好评。近几年，敏捷、看板等一系列精益研发的实践开始流行，尤其在互联网与创新企业中被广泛采纳。面对瞬息万变的市场竞争，一些问题自然摆在我们面前：在始终要把防范风险放在首位的较为严格的金融监管大环境下，IT研发该如何转型？如何看待CMMI框架下的稳健的研发体系与探索式的敏捷开发模式之间的关系—是不可调和还是有融合的空间？我始终认为，任何管理变革都不应以颠覆为代价，这本书的意义正在于此，它不仅仅是一部敏捷开发的指导书，更是IT精益管理转型的点金石、指明灯。
——欧红，招商银行总行信息技术部EPG负责人、过程改进及管理变革资深专家
软件过程改进是一个复杂、系统的工程，因为在人、技术、流程三者中，人的因素在其中起着决定性的作用，唯有在不断的实践中提升人的认知水平，才能将软件过程改进渗透到企业的方方面面，最终达到“手中无剑，心中有剑”的游刃有余的境界。和丛斌博士合作4年有余，在复杂问题面前，他总是能够快速抽象出问题的关键要素；在具体的实践中，他总是能够提出精准有效的方法，带领我们一步步达到CMMI四级。非常高兴他将多年来的研究、实践和思考进行了系统的总结，形成了本书，从本书中读到的不仅仅是实践和方法，更多的是方法背后的“为什么”，而这正是促进人的认知水平快速提升的关键。
——徐凯健，中国航发控制系统研究所
本书点破了软件业的一个“行业之问”：符合进度和成本要求的项目就真正成功了吗？丛斌博士结合其丰富的软件行业实践和咨询经验，对Scrum、XP、看板、CMMI、精益等一系列行业最佳/优秀实践进行深入剖析，基于现实操作中存在的问题和解决方案，让读者知道实践背后的Know Why和Know How。对于软件企业的高层、EPG、项目经理、研发人员，这都是一本非常棒的“桌边读物”，相信我，当你遇到问题时，随手翻一翻，肯定能有一番收获。
——周成，614所软件工程部
CMMI体系究竟能够为公司带来什么样的价值和利益？这是每一个追求高品质的软件公司管理者应当高度关注的问题。作为资深的CMMI高成熟度主任评估师，丛斌博士拥有软件工程领域丰富的实践经验。他推崇价值驱动，在CMMI落地中倡导知行合一，将CMMI框架融合在公司经营目标、绩效管理与日常运营中，真正实现软件研发过程能力的提升；他倡导在CMMI框架下引入敏捷、精益的思想和优秀实践，并将二者有效结合，丰富和发展CMMI内容和方法，并使敏捷开发能够保持良好的稳定性。相信丛斌博士倾注心力的这本专业力作，将会令广大软件业同行受益匪浅。
——白静亚，中国电信系统集成公司质量控制部经理
作为一名过程改进、质量管理和项目管理的从业人员，丛斌博士这本新书升级了我的知识框架，也引发了我对敏捷价值的重新思考。我们的开发团队常徘徊在瀑布式开发和敏捷开发的交叉口处，对敏捷充满期待又面临诸多挑战。本书不是学术著作，也不同于许多只教授如何操作敏捷的书，它帮助我们回到初心—思考“为什么要这样做”，而不仅仅是“知道怎么做”。丛斌博士基于他几十年在教学、咨询、研究方面的丰富经验和深刻思考，从实践和理念层面提出具体实施建议，体现了业界对敏捷及精益的最新理解。如果你来自软件开发部门、质量部门、过程改进部门或者PMO，我愿意推荐本书给你。相信它可以帮助你找寻到软件开发的金钥匙，从“邯郸学步”的尴尬中走出来，步入“形神兼备”的境界，实现敏捷的真正价值。
——穆京丽，神华和利时信息技术有限公司项目管理办公室总经理
丛斌博士一直致力于商业价值最大化的过程改进，他总是能做得恰到好处。只要有机会，我都会去听丛斌博士在各种会议上的演讲，因为他的工作总是我所见到的最富于思想性和创造力的。他总是能把复杂问题讲得通俗易懂、深入浅出。丛斌博士在网络、建模和软件领域经验丰富。他的方法既实用又具有深厚的理论背景。他总能在帮助软件组织引入新方法时，做到时机恰当，经过深思熟虑，并考虑周详。作为一个CMMI研究院最优秀的CMMI主任评估师，丛斌博士擅长把组织能力和业界最佳实践做对比并做出评价。有些人只能把知识局限在很窄的专业领域，而丛斌博士却能从系统角度出发，看到产品、项目和组织的全貌。另外，丛斌博士是我见到的最乐于帮助组织和个人学习进步的人，有幸读到这本书的人，都会从中获益。希望丛斌博士尽快出本书的英文版。
——Bradley Bittorf，雷神公司（Raytheon）跨领域高级主任工程师
我认识丛斌博士是在20年前一起做CMM评估时，他掌握新东西并形成自己特点的能力及速度令人叹为观止。当Scrum出现时，丛斌博士从其创始人Jeff Sutherland处学到了其原则及实践，并迅速将其和CMMI结合，形成了一套有效的Scrum和CMMI五级结合的方法，很多中国企业都从中获得了益处。我很高兴丛斌博士终于有机会将其多年敏捷和CMMI的经验展现给大众，毫无疑问，这本书将极大地帮助读者避免过程改进中的众多误区，并通过他们让众多软件组织受益。
——John Ryskowski，SEI及CMMI研究院第一批主任评估师、高级主任评估师
探索软件开发方法和技术以提高计算机软件开发效率和质量是软件工程领域研究的主要话题。如何提升质量和产品功能的同时缩短开发周期、降低开发成本是许多优秀软件开发类企业不断追求、自我完善的重点，也是其在激烈市场竞争中生存的根本。这不只是简简单单的代码质量的问题，更是一个从管理学角度上不断优化、创新、面对需求调整适应的过程。因此，理解和研究新型的、现代化的开发管理模式对企业及其管理者来说具有非常重要的意义。为了解决这一问题，1987年前后，美国卡内基梅隆大学软件工程研究所（CMU/SEI）的Humphrey等人提出了软件能力成熟度模型CMM，2000年正式发布了能力成熟度模型集成（CMMI）。
丛斌博士是我们的老朋友，多年来一直身体力行地把科学、先进的软件工程学管理方法CMMI介绍到国内来，在国内各个行业落地生根，开花结果。有幸先行拜读了丛斌博士的新书《知行合一：实现价值驱动的敏捷和精益开发》，深有感触，软件开发的模式和方法很多，再好的方法还必须和企业自身的实际情况相结合，能给企业带来实实在在效率、效益的才是好的模式和方法。当然，具体到怎么做，还是有技术和技巧可言的，那些对自己企业目前所采用的开发模式、方法不满意，想要改进、变革的朋友们，花点儿时间读读丛斌博士的新书，一定会有不错的收获。这本书通过生动的语言、形象的故事以及实践案例分析向我们阐述了软件类产品开发模式从传统的瀑布式向敏捷型、迭代型的精益开发管理模式逐渐演变的原因以及带来的价值。软件（尤其是应用软件）不同于普通的制造行业产品，其生命周期各个阶段的投入与管理较为特殊。针对这一特点，本书以客观的态度对比分析了传统模式与新型开发模式各自的优势与存在问题，结合时代背景与市场竞争的转变，阐述了敏捷型精益开发模式出现的必然性，以及实际运用中所需要注意的关键环节、关键角色，为有效提升软件类产品开发效率指明了方向。
2004年开始，二十八所作为国防大型电子信息系统供应商率先引进了国际先进的CMMI模型作为软件研发过程能力提高的标准，近年来我们也不断总结、实践，以进一步提升研发能力，书中很多内容也是二十八所多年来过程改进的总结。作为一个实践者与使用者，我们觉得在CMMI框架下，不管是瀑布式开发还是敏捷开发，都有各自的特点与应用范围，在需求不确定或者频繁变动的情况下，敏捷与迭代的方法比较有助于快速跟进变化与需求。但是这种方式也需要一定的规范、在一定的原则下进行操作，保证响应速度的同时也要保证质量。沟通比流程更加重要，同时，在过程管理中也应加强团队能力的建设。开发方式是“道”，如何应用是“术”，我们的管理需要“术而载道”、根据实际情况在质量与速度中找到一个完美的平衡点，控制关键风险、提升效率。中国明代心学家王阳明提出的“知行合一”的思想，强调了思考与实践结合的重要性。“知”是基础、前提，“行”是重点、关键，“未有知而不行者；知而不行，只是未知”。必须知不弃行，行不离思，慎思之，笃行之。知行合一的思想、本书的精髓与我们贯彻CMMI模型的过程改进实践不谋而合。
本书面向项目管理与产品开发的操作实际，内容严谨缜密、逻辑清晰，引人思考，有非常高的科学理论指导意义与实践价值。虽然讲述与分析的对象抽象性、理论性很强，但整本书阅读、理解起来非常容易，内容生动有趣，有很强的可读性，是一本值得强烈推荐的科学与实践完美结合的书籍。
中国电子科技集团公司第二十八研究所过程改进组
丛斌博士是软件工程方面著名的专家、大师级人物。他在该领域工作30多年，有非常深厚的理论功底、开阔的视野，同时也具有丰富的企业咨询经验。
从2004年开始，丛斌博士就为华为的多个部门做过基于CMMI流程改进与效率提升的咨询、评估。2012年到2013年，我们有幸请丛斌博士辅导华为4G基站产品部（LTE PDU）的CMMI改进项目。当时LTE产品正处在快速部署和上量阶段，面对全球几百个电信运营商，产品开发遇到了很多困难和挑战：一方面是运营商的需求和网络问题如雪花而至，另一方面是研发团队和流程不够成熟，尚未经受过网络事故和问题的洗礼。这些问题主要表现在开发需求多、进度压力大；因为敏捷开发的推行，团队也有重代码轻流程的现象；产品质量问题变得更具挑战性，往往是修改了一个问题却带来更大的问题。在丛斌博士指导下，我们将CMMI评估项目变成了基于CMMI模型的研发效率与质量改进项目。我们在华为IPD及研发流程框架下，基于CMMI模型及敏捷开发方法，结合LTE业务实际，发起多个改进子项目，梳理改进了产品研发微流程，规范并建立了IT化的过程数据体系，建立了产品流程改进机制。通过一年多的努力，研发效率特别是研发质量获得很大提升，CMMI评估也获得了非常满意的结果。
近年来，我们4G开发团队持续开展改进活动，在原来CMMI和敏捷开发改进的基础上，积极试点精益看板开发。我们虽有多年从事CMMI、敏捷开发、精益开发的实践，但是对于这三者的渊源、发展以及在企业实践中的结合仍有很多困惑。知悉丛斌博士的扛鼎之作，我们非常欣喜。
我们从事新产品开发及软件工程领域20多年，一直在企业内部从事研发能力改进工作，见证了各种流派的发展：早期的新产品开发方法与模型，如PRTM的PACE，IBM和华为的IPD；项目管理的PMBOK；软件工程领域的CMMI，特性驱动开发、迭代开发、增量开发、Scrum等敏捷开发流派，以及近年来的大规模敏捷、精益软件开发、精益看板、精益创业方法。这些流派有各自的发展历史，有各自适用的业务场景与产品形态，有各自的突出特点及价值，但也往往代表各派利益，有时显得各说各话。不过，它们都可应用于软件开发，也都在持续创新、顽强生长。流派众多会对企业内部软件开发能力提升造成很大困惑：企业是要解决问题的，如何在各派中选择、如何结合自身情况形成解决方案，往往是一个大问题。丛斌博士作为软件工程领域的资深专家，对于CMMI、敏捷开发、精益开发有非常深刻的理论见解和丰富的咨询实践；他历经数年，把软件工程领域的主要代表思想和方法—CMMI、敏捷、精益在一本书中写出来，相信会对华为以及实施CMMI、敏捷开发、精益开发的软件开发企业有非常大的指导作用。
丛斌博士强调：“贯穿本书的一个主题是如何通过敏捷、精益实践，用低成本实现软件产品的高价值点，时刻把握住软件开发中的核心经济指标，避免盲目追求可能没有真正价值的替代度量指标。”这正是敏捷与精益软件开发的目标，我们非常认同。
丛斌博士强调本书不是一部学术著作，但本书包含许多软件工程领域的洞见和创新思想，绝不是市面上不少敏捷、精益开发类书籍的人云亦云。丛斌博士的书讲述敏捷、精益实践，讲述敏捷与CMMI结合，更讲述如何在企业中加以实施以提高企业的研发效率与质量，支持企业价值增长。这恰如书名—“知行合一：实现价值驱动的敏捷精益开发”。丛斌博士在软件工程领域耕耘30多年，既从事软件工程的教学、理论研究，又从事企业咨询实践，他的多年工作经历也正好体现了“知行合一”。
贾建国博士，华为上海研究所质量运营部主任工程师
张双国，原华为LTE产品部部长
与丛斌博士的相知源于中国银行软件中心CMMI4评估项目，丛斌博士是主任评估师。中国银行软件中心的唯一服务对象是中国银行，目标是为中国银行开发高质量的金融软件产品，支持中国银行业务的发展。和国内大部分软件企业引入CMMI评估不同，中国银行软件中心引入CMMI评估的主要目的是持续进行软件过程改进，提高软件开发过程能力，提升软件产品质量，更好地为中国银行的业务发展服务。顺利通过CMMI2、CMMI3的评估之后，CMMI4评估工作在2008年遇到了困难，SEI对CMMI高成熟级别的评估提出了更加严格的标准，原来的评估师无法满足要求，于是丛斌博士担任了CMMI4评估项目的主任评估师。事实证明，丛斌博士无论是在软件过程改进的理念和实践经验上，还是对SEI CMMI高成熟度级别评估标准的把握上，都是最优秀的几个评估师之一。经过一年多的辅导，中国银行软件中心于2009年8月正式通过CMMI4评估，成为中国金融IT企业中第一家通过CMMI4级评估的企业。
丛斌博士一直从事软件工程的教学、咨询和研究工作，既有美国软件企业的从业和咨询经验，也有较多的中国软件企业的咨询和评估经验。基于对软件工程管理改进的深刻理解和实践经验，丛斌博士总能够准确把握软件企业领导者真正关注的焦点，发现软件过程改进的误区，给出卓有成效的软件实践，为企业商业目标的达成带来巨大的帮助。
我很早就建议丛斌博士能够把他在软件开发、软件工程方面的经验撰写成书，以便帮助到更多的软件企业和软件管理人员少走弯路、实现价值最大化。今日受邀作序，欣然以从。
随着软件开发方法和软件工程理论的发展，从传统的瀑布式开发、迭代开发到敏捷开发和精益开发，恐怕很多大型软件企业都经历过一种或多种开发模式的实践。既体会了某种开发模式的好，也体会了单一开发模式的坏；既收获了开发模式转型带来的好处，也遇到了开发模式转型落地的困难。之所以如此，是因为每个企业面对的客户不同，客户的需求也不同。如何针对不同的客户需求，找到合适的软件开发模式和软件管理流程与之相匹，恐怕只有围绕着“价值驱动”才能找到最终的答案。
软件开发中永远不变的就是需求的变化，软件企业如何能够从纷繁多变的客户需求中解脱出来，从而赢得客户满意，只能从挖掘客户价值上做文章。从这个意义来讲，软件开发模式反而是实现客户价值的一种手段。传统的瀑布式开发适合需求较为清晰明确的开发，而敏捷开发模式则更适合对客户快速变化的需求的及时响应。
本书是丛斌博士对软件企业的一大贡献，粗读一遍，受益良多。本书既有对方法、思想、理念的要点解读，又有对错误理解的纠正；既有对不同企业在多种开发模式间转型的路线指导，也有行之有效的实践建议；更通过一个个的故事，形象具体地对比了不同实践中的得与失。正像作者所说：本书不是纯学术著作，而是一本结合实例讲解操作的书。本书应该会对大部分软件企业的软件开发工作具有指导作用。
软件开发没有统一的模式，不同企业、不同场景下会有不同的方案，唯有围绕“客户价值驱动”，才能找到软件开发方法之钥。
王铿，中国银行软件中心副总经理
从1968年第一次提出软件工程的概念，软件产品和系统改变了人类的生活方式，它们已经渗透到了社会的各个角落。巨大的新系统开发以及现有系统的维护需求都保证了计算机在相当长的时间内都会是个容易找工作的热门专业。令人遗憾的是，和其他工程（如电子工程、土木工程、机械工程等）相比，软件工程的开发是效率最低、浪费最大一个领域。Frederick Brooks（1987）在30年前就清楚地阐述了软件系统开发的特殊性及困难点，也建议了一些可能的突破点。软件从业者也在实践中不断尝试，可惜几十年来都没有真正突破参照制造业形成的计划驱动、接力开发、按预定过程执行的软件开发模式。越来越多的人意识到这种模式不能有效支持解决软件开发中存在的需求不确定性、技术创新要求的问题。
这几十年来我一直从事软件工程的教学、咨询和研究工作。在这个过程中，我深深体会到学校教的软件工程方法和企业实际用的开发模式都有不少不合理的地方。我们用来度量项目好坏的指标，很多时候并不能体现企业领导者真正关注的点，同时软件过程改进的一些误区也给企业、团队及个人带来了不同程度的危害，如盲目僵化地使用六西格玛方法指导软件过程改进；在不理解CMMI模型实践希望解决的问题的前提下，进行评估驱动的CMMI导入。这些做法使得过程改进对组织的质量文化起了负面作用，对企业商业目标的实现没有起到真正的支持作用。
老实说，我也发表过一些研究性的论文，在不少软件工程会议上也做过一些案例分享，却一直没有触发写书的念头，因为写书真的是一个重体力活。最近十几年来以敏捷和精益开发为代表的软件工程革命性变革，让我感觉到我们比以往任何时候都更加接近软件方法开发之匙。从大的框架角度，从开发管理原则角度，从具体实践角度，从企业实施效果角度，已经形成了一套相对完整、具备指导意义、具备系统性的新一代软件开发方法。
摸索出一些有效软件开发模式是我这些年投入很大精力在做的事情。如果有一本能够充分反映这几方面成果的书显然具有重要意义，这极大地促使了我忽略肩周炎、腰椎间盘突出的痛苦，下决心开始码字写书。本书不追求所谓纯粹的敏捷或精益，而是希望找到解决软件开发中长期没有很好解决问题的钥匙。我一贯相信存在必有其合理性，所以这把钥匙一定是各种模式中好的实践的结合物。
软件组织的管理人员、技术人员、质量人员和过程改进人员都可以从本书中获得他们需要的知识点。本书的一个特点是希望把原因讲清楚，回答好“为什么”的问题，因为理解“为什么”比知道“如何做”更重要。理解了“为什么”才能从“形似神不似”中走出第一步。贯穿本书的一个主题是如何通过敏捷、精益实践，用低成本实现软件产品的高价值点，时刻把握住软件开发中的核心经济指标，避免盲目追求可能没有真正价值的替代度量指标。
我在近几年做敏捷、精益培训及实施指导中发现，大部分Scrum、极限编程、看板（Kanban）实践者虽然接受过敏捷培训，阅读过一些敏捷和看板书籍，也有些实施经验，都会提一些类似的问题：什么是正确实施方法？如何在自己特定的企业让敏捷、精益在组织、团队、项目中落地，使其价值最大化？许多在CMMI框架下建立了开发体系的读者，都面临着和CMMI模型有效结合的挑战。希望本书能对持有类似疑问的读者有所帮助。
本书主要包含4部分内容，相互之间有一定的独立性。本书读者并不一定需要有敏捷和精益的背景知识，他们可以根据自己的需求获得有价值的帮助。前三部分的重点是讨论以Scrum和极限编程为代表的敏捷实施，第四部分则是深入探讨看板及新一代精益软件开发方法。在探讨Scrum、极限编程、看板、新一代精益的核心理念、架构、实践时，我会提出具体实施的建议。这些建议包含实践层面及理念层面的东西，体现了近年来业界对敏捷及精益的最新理解。有些建议也许会是有争议的，这些争议可能源于作者坚持敏捷、精益核心实践的完整执行以保证价值最大化，也可能源于对灵活度的把握的理解不一。
由于各种原因，本书的撰写耗时很久，未能按计划交付，在此向一直耐心等候的编辑致谢，向一直期待此书完成的读者致歉。作为延期的代价，我有必要将近几年软件开发模式及方法的新实践追加进去，同时将一些因时间推移而价值变低的内容做些删减。例如，新一代精益软件开发的内容本不在本书最初计划范围内，但今天它已经成为不可忽略的内容，因为新一代精益模式将敏捷革命带入了一个新的境界，它在方法论、原则、具体实践等方面大大丰富了软件工程的内容。
建议读者从第1章评价项目成功标准入手，真正理解传统开发方法和软件产品的不匹配之处，以及造成的低效后果。在这个基础上，读者可以从第2章和第3章中了解到敏捷方法价值观、框架、原则以及为何它能够在很大程度上解决传统开发模式的不匹配问题，并明确为什么从“先知后行”到“知行合一”是软件开发的必然之路。从传统的瀑布开发模式转向敏捷主导的模式是一件痛苦的事，如何管理这个转型也是第3章讨论的问题之一。例如，导入Scrum不能保证解决企业软件开发中的所有问题，但它会让这些问题突出地暴露出来。实施敏捷的企业有两种选择：一是面对问题，努力将敏捷中对应问题的实践作为解决方案的一部分；二是为了避免变革的痛苦，将问题埋在地毯下，仅仅引入容易在企业内部实施的实践。令人遗憾的是，许多引入敏捷的企业选择了第二种方式。它们也能取得一定效果的改进，但那些被忽略的实践，往往很可能是对它们最有价值的实践，敏捷的一些重要价值没有得到真正地实现。
本书第二部分重点讨论如何建立以Scrum为框架的软件开发管理体系，并从有效管控技术债务角度出发，形成和Scrum框架匹配的工程实践。我最近将业界常用的技术债务扩展成质量债务的概念（Cong，2017），这是一个非常重要的课题，是对敏捷、精益环境下的质量管理的一个新尝试。如何有效管理技术、质量债务，做到健康迭代而不是带病迭代，其实也是贯穿本书的一个主题。国内许多软件组织已经引入了Scrum开发模式，从第4章到第6章，我在Scrum布局准备、管理方法的落地以及和极限编程的结合等方面中做了比较系统的整理。不论是否具备敏捷实践经验，读者都可以通过一些实施案例及作者观察到的优秀实践，进一步理解这些章节中的内容。
本书第三部分详细描述了CMMI和敏捷开发模式结合的有效方法，其内容是许多软件企业非常关注的，因为目前许多国内的软件组织都引入了CMMI开发模型。许多政府、企业项目招标时，把CMMI资质作为一个重要的评分项。当这些组织实施敏捷时，就面临如何在CMMI框架下实施敏捷的挑战。第7章澄清了一些敏捷和CMMI的偏见，通过实例解释了二者的互补性。我也把CMMI研究院在敏捷和CMMI结合方面获得的最新成果纳入了相关章节中。读者在读第8章时，可以详细了解到如何在敏捷环境下实施CMMI开发模型中的所有过程域，做到在合理平衡稳定度与敏捷度的前提下，不断提升开发过程的能力。本书第三部分不仅能让读者对敏捷的不足之处有更深入的了解，也可以纠正一些业界常见的CMMI的价值及使用方法的偏见。为了保证让对CMMI开发模型不了解的读者也能看懂相关内容，我尽我的能力对模型做了通俗易懂的解释。
本书第四部分首先重新深入探讨了软件工程和其他工程的差异，特别是其“软”“易变”“非线性增长复杂度”“创新”等特点，读者可以更加深入理解为什么我们遵循几十年的，借鉴制造业的开发模式并不能高效匹配软件系统的开发。这有助于读者理解敏捷、精益存在的基础，同时读者也可以看到以Scrum和极限编程为代表的敏捷方法的一些不足之处。国内一些软件组织已经开始引入初级精益方法—看板，我在第10章首先澄清了一些看板实施的误区，然后重点阐述了如何把Don Reinertsen（2009）提出的支持创新的新一代精益开发方法移植到软件产品开发中，将其原则、实践作为精益软件工程的核心内容。软件的实践者其实已经用了其中不少原则，但他们只是凭直觉，只是支零破碎地在用些皮毛。第10章从系统角度全面探讨了软件开发应该遵循的原则，这对软件组织的管理者、工程人员、过程改进人员都会有很大的帮助。
本书不是纯学术著作，而是一本结合实例讲解操作方法的书。我同时希望将操作步骤背后的方法论、存在的价值解释清楚。引入敏捷、精益是一场变革，我想清楚地告诉读者：为什么要变？需要变什么？如何管理这些变化？如何实现价值？本书的续篇应该通过读者的实践来完成，如果阅读本书能让一些读者受到些启发，并开始在自己工作范围内做一些改进的尝试，我想，这也就达到了我写此书的初衷。
最后我特别感谢人民邮电出版社的编辑杨海玲女士，她对本书的编写给出了很多好的建议，付出了大量心血。再次谢谢我服务过的众多软件企业，这本书算是对你们的信任的一个小小回报。
第1章 从“先知后行”到“知行合一”——从传统开发模式到敏捷开发模式
第２章 敏捷开发方法——摸着石头过河的智慧
第３章 形神兼具——实现敏捷的核心价值
2001年2月11～13日，17位志同道合的软件开发的实践者自称为“中年白肤色男人帮”（middle-aged white guys，mawgs），聚集在美国犹他州著名的滑雪胜地雪鸟城（Snowbird）滑雪，享受美食，同时花两天时间讨论更好的软件开发方法。这17位软件开发的实践者有一个共同的理念：应该找到一个替代文档驱动的重量级软件开发过程的新方法。这17位软件工程师（现在应该称他们为敏捷的领军人物）代表了敏捷运动的各种流派：极限编程（Extreme Programming，XP）、Scrum（本书的重点）、动态系统开发方法（Dynamic System Development Management，DSDM）、自适应软件开发（Adaptive Software Development）、水晶项目管理（Crystal）、特性驱动开发（Feature-Driven Development）和实用编程（Pragmatic Programming）等。
虽然这些人都认同轻量软件开发过程，但让一群独立思维的聪明人在具体做法上达成一致是一件很难的事。聚会时间临近结束，大家还是争论不休，这时有人提出了一个求同存异的折中建议：把我们17个人都认同的理念整理出来，写在白板上。最后白板上只留下了4条，他们把这4条称为“敏捷宣言”，把自己的组织称为敏捷联盟。“敏捷”一词从此替代了轻量过程开发，成为软件业出现频率最高的词。选择敏捷（Agile）一词还是有些争议，有人担心这个词会被误解为无序（这个担心到现在来看还是有些道理的）。一位来自英国的绅士甚至担心美国人不知道如何发Agile的音。当然最终大家都非常满意聚会的结果，每个人都觉得他们做了一件有意义的事。但谁也没有意识到，这短短几句话，成了近20年来最重要的软件文献，它推动了一场软件工程的革命。
我们一直在实践中探寻更好的软件开发方法，
身体力行的同时也帮助他人。由此我们建立了如下价值观：
个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划
也就是说，尽管右项有其价值，
我们更重视左项的价值。
下面是敏捷联盟认可的敏捷宣言的中文版。
正如一位宣言作者所言，这个宣言是一个战斗口号：它明确表达了我们支持什么及我们反对什么。这个宣言也清楚地指出什么是敏捷，什么不是敏捷。
敏捷宣言是一个价值宣言，它强调了在开发过程中我们要关注什么，正确的优先级应该是什么。
人、过程、工具和成功开发软件系统的关系是个老话题了。如果给你一个选择：谁更有可能开发出好的软件产品？是10个勤奋、能干的软件工程师，使用他们各自的工具，每天在一起协调配合工作，他们之间存在有效的沟通互动；还是10个能说不能做的牛人，他们共有一个明确的定义过程，可以用最好的工具，坐在最好的办公室。如果要开发的产品有一定的复杂性的话，我会选择前者。人和能保证他们在一起有效工作的机制是开发出好产品的最重要因素，没有这一点，工具和过程不会发挥它们的作用。这绝不是说工具和过程不重要，但软件开发是高智力活动，在开发复杂系统时，人更加重要。同时团队成员间及时沟通互动，比仅仅通过文档工具进行沟通更加重要。当然在一定程度上，工具和过程可以帮助建立维护保证人一起有效工作的机制。
问一下你的用户，他是更愿意看一个200页的文档描述你要开发的产品还是软件本身？我猜绝大多数用户都会选择软件本身。如果是这样的话，我们为什么不能通过快速开发出软件，让用户了解项目进展情况？大多数用户更容易通过观察软件演示来理解开发的产品，那些复杂的内部技术实现图、抽象的使用说明，恐怕会让用户望而却步。文档有其价值，它可以帮我们理解系统是如何被开发的及选择这种开发方法的原因（这对支持后期维护至关重要），文档也可以指导用户使用开发的系统。但文档不是软件开发的主要目的，否则我们就应该叫文档开发了。文档的目的，在某种程度上是为了帮助我们开发出工作的软件。
和客户打交道可能会是一件痛苦的事，因为他们通常没能力准确地描述出产品需求，他们从来不能一次把事情讲清楚，他们还经常改主意。但只有他们能告诉你他们需要的东西，只有开发出的软件得到他们的认可，你才能最终收到合同款项。这是每个软件企业必须面对的现实。通过合同明确各自的权利与义务，并且保护你的利益也很重要。但合同谈判不能替代和客户的沟通，成功的开发团队会把客户当成团队的一部分，通过迭代开发模式不断获取客户的反馈，在开发中逐步理解客户的真正需求，并和客户一起加深对产品价值的理解。
变化是软件开发过程中一个常态：客户对业务领域的理解加深会导致变更；商业环境的变化会导致变更；技术的变化也会导致变更；人员的变动也会带来变更。如果你的软件过程不能有效地处理变更，那么这些变更有可能把项目带到绝境。计划很重要，但计划必须有其伸缩能力，我们必须能及时抛弃过时计划元素，更新计划响应变化。项目的目的不是为了符合计划，而是用计划指导我们开发出对客户有价值的产品。
有意思的事是几乎所有人看到这4条都不会提出异议，第一反应很可能是“当然应该这么做”。可惜在传统开发模式下，在盲目强调过程符合的文化下，这些价值观都没有真正得到体现。
另外我们也要避免从一个极端走到另一个极端：完全忽略右项的价值，在敏捷的名义下，变得完全随意，没有过程，没有计划，这样的敏捷不会成功。
敏捷宣言讲的是方向性的东西，它是一个里程碑式的宣言。
在雪鸟城聚会后的几个月里，这些敏捷领袖通过邮件和wiki沟通，写出了12条原则，给出了实现宣言4个价值观的指导理念。这里我觉得很有必要对这12条原则逐一做个简单解释说明。为了让大家能准确理解每一条原则，我将英文附在里面。
（1）尽早、持续交付有价值的软件是我们满足客户的最优先考虑。（Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. ）
我们在第1章中讨论了先知后行（定义好一切再开始软件开发）的弊端，尽早、持续交付软件增加了开发团队和产品团队（客户）的沟通机会及质量。知行合一的增量开发也能让用户尽早开始使用开发出的有价值的系统功能特性。
在规划迭代时必须按照优先级安排，尽可能先为客户提供最有价值的功能。通过频繁迭代与客户形成持续的良好合作，通过及时反馈来提高产品可用性及质量。这个原则也告诉我们，团队应更加关注完成和交付具有用户价值的需求功能，而不是孤立的任务。
（2）即使到了开发的后期，也欢迎需求变更。敏捷过程利用变更为客户创造竞争优势。（Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.）
从来没有无缘无故的需求变更，变更的原因经常是开发中的需求功能已不能有效地满足用户的需要。我们要做的是，拥抱变更但要将变更成本降到最低。敏捷能让我们做到这一点，而瀑布模式则无法做到这一点。
（3）频繁交付可以工作的软件，交付间隔越短越好，可以从一两周到一两个月。（Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale.）
我们在第1章讨论了反馈的价值，频繁交付工作的软件给利益相关人提供一个很好的沟通反馈平台。这些反馈可以让开发团队和产品管理团队及时对产品的方向做出调整，也可以让开发团队及时总结、对使用的过程进行调整。和瀑布开发模式不同，敏捷开发模式对开发阶段没有什么重要的分割，不是接力的需求阶段，然后是分析阶段、架构设计阶段、编码测试阶段等。敏捷团队是一个跨职能的团队，在项目开始后，上述瀑布阶段的工作会同时开始。
（4）在整个项目开发期间，业务人员和开发人员必须可以天天随时沟通、一起解决问题。（Business people and developers must work together daily throughout the project.）
复杂软件项目不会完全依照项目前期制订的计划执行，各种不可预测的因素会产生实际和计划的差异。开发人员和产品团队（客户、市场人员、产品经理等）有效、频繁交互是及时发现并解决问题的最好手段。如果一些重要的利益相关人不在本地，那么我们需要建立沟通工具平台，支持异地人员能够随时和团队进行有效沟通。
（5）围绕一群有动力的个人进行项目开发。给他们提供所需要的环境和支持，并且相信他们会把事情做好。（Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.）
这些年来，我发现一些国内企业有这样的不切实际的想法：似乎通过引入符合CMMI、ISO等要求的过程，就能让一群能力不是很强的人良好地完成软件开发工作。似乎过程真的可以完全替代人，人完全变成可替换的东西。他们忽略了软件开发和制造业的差异，软件过程和流水线过程的差异。敏捷强调团队的重要性，敏捷团队是由一群自律、有团队精神的人组成的，他们乐于协调工作、互相学习。他们谦虚谨慎相互尊重，在敏捷理念里，人是软件开发成功的最重要因素。管理者的重要工作是激励每个人发挥出他的最大潜力，让个人的目标和团队的目标一致，以一群主动的个人为中心构建项目，同时为他们提供所需的环境、支持与信任。
（6）对一个开发团队来说，面对面沟通是最高效的传递信息的方法。（The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.）
行为研究显示，对一个小团队来讲（小于10人左右），面对面再加上一个白板就是最有效的沟通传递信息方式。这种方式比通过文档、邮件、电话沟通都更加有效。Scrum中的每日站立会议就是实现这个原则的一个实践。
（7）工作的软件是软件开发中首要进展度量指标。（Working software is the primary measure of progress.）
软件开发中完成了多少符合客户要求的功能应该是项目进展状况的重要度量指标，而衡量任务完成情况的所谓挣值其实很难代表项目真正的进展情况。我们比较容易度量大部分工作进展，如搬运1吨的煤，只要称一下已经搬运煤的重量就知道完成多少了。而对于软件来说，在软件没有完成编码、测试之前，我们不能因为代码编写了多少行，测试用例跑了多少个就去度量这个功能是否完成。度量这个功能是否完成的唯一标准应该是这个功能可以工作了，用户已经可以用它了。
（8）敏捷过程提倡可持续的开发。产品的赞助者、开发者和用户应该能够保持一个长期的、恒定的开发节奏。（Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.）
IT行业是一个很辛苦的行业，过劳死、亚健康往往和IT人士联系在一起。跑马拉松比赛，没人能够一直像跑百米一样地冲刺，否则你一定会倒在中途。让一个团队连续几个月天天加班，也很难开发出高质量的产品。软件开发主要是脑力活动，像我每天集中精力有效工作的时间也就6小时，过了这个界线，脑子就明显钝化了。
国内IT行业认为软件开发中加班是天经地义的，不加班反而不正常，敏捷也不会改变这种常态。可敏捷提倡的是可持续开发，开发速度不应该随着迭代的任务不同而不同。开发活动不应该是突击行为，因为你不可能指望突击完成一个项目后就轻松了，下一个项目会接踵而来，当然下一个项目依旧会让你再次突击。听起来长期加班也可以是所谓“持续开发”，但是这种状况是不可能持续恒定的，因为人会疲劳、厌倦，健康变坏，长期这样的话也会影响家庭幸福。软件开发的节奏意味着阶段、活动的可预测性：固定的迭代周期、固定回顾会、固定评审会等，都会帮助团队形成自己的开发节奏。
这也是我不喜欢将Sprint翻译成“冲刺”的原因，因为我们不可能用冲刺的方式来跑马拉松。在Scrum中，Sprint其实强调的是周期短，而不是跑得快。所以本书中，我将Sprint翻译成“迭代”。
（9）不断关注卓越技术及优秀设计能增强敏捷力。（Continuous attention to technical excellence and good design enhances agility.）
一个高质量的代码库比一个低质量的代码库更容易被理解、维护和完善。卓越技术应该是敏捷团队、敏捷人永远追求的东西。极限编程给我们提供了很多好的办法，如代码的重构、测试驱动开发、持续集成等。很多架构设计方法、数据库设计方法、技术评审方法也应该成为敏捷团队遵循的指南。这些好的技术实践可以加强产品敏捷能力，很多原则、模式和实践也可以增强敏捷开发能力，特别是解决敏捷的天敌—带病迭代的问题。
（10）简于形——是最大化地减少不必要工作的艺术——这是敏捷精髓。（Simplicity—the art of maximizing the amount of work not done—is essential.）
这一条是我最喜欢的敏捷原则，也是最难翻译的。敏捷是一种在可能限度范围内求全的艺术，但不是追求完美的艺术。如开发团队不可能预期后面需求会如何变化，所以不可能一开始就构建一个完美的架构来适应以后的所有变化。敏捷团队不会去构建明天的软件，而会把注意力放在如何用最简单的方法完成现在需要解决的问题。如果你已经预计到了肯定存在的需求扩展点，是否一开始就考虑呢？团队可以需要根据自己的最好理解去决定是否考虑，如果深信在明天发生了这个问题也可以很容易处理的话，那么就最好先不考虑。尽量只做正好够（just enough）的东西以及在恰当的时间（just in time）做决策是敏捷的核心实践之一。希望读完本书后，这条原则能够融入你的思维体系中。
（11）自我组织的开发团队能够逐步摸索出最适合的构架、需求和设计。（The best architectures, requirements, and designs emerge from self-organizing teams.）
这句话大概是最有争议的原则。在翻译“best”时我没有用“最好”而是用了“最适合”。自我组织管理团队是敏捷主要的实践之一，这个也是在国内实施敏捷的一个难点，很多企业都绕过了这一实践。后面章节中，我会对这个话题做深入的讨论。在自我组织管理团队中，管理者不再发号施令，而是让团队自己去寻找最佳的工作方式来完成工作。自我组织团队的第一个要素就是必须有一个团队，而不仅仅是一群人。一群人是一帮在一起工作的人，他们彼此之间并没有太多的沟通协调，他们也并不视彼此为一体。项目一开始，我们就会组建“团队”，但很多时候其仅仅是由构架师、需求人员、开发人员和测试人员组成的一群人而已，而不是一个团队。
团队的形成必须经历几个时期，只有在经历了足够的磨合后，成员才会开始对团队共同的工作理念与文化形成一个基本的认识和理解。团队内会逐渐形成规矩，而且这些规矩是不言而喻的。例如，每个人都知道上午9点来上班，都会主动询问别人是否需要帮助，也都会去主动和别人探讨问题。如果团队成员之间能够达成这样的默契，那么这个团队将成为一个真正高效的工作团队。在这样的团队中，成员之间相互理解，工作效率非常高。在自我组织团队中，团队成员不需要遵从别人的详细指令。他们需要更高层次的指导，这种指导更像是一个目标，一个致力于开发出更好软件的目标。总之，自我组织团队是一个自动自发、有着共同目标和工作文化的团队，这样的团队能够逐步将团队能力最大化，这样的团队才有可能一起摸索出最合适的技术解决方案。
（12）每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后对自己的做事方式进行必要调整。（At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.）
敏捷中的过程改进比传统环境下更及时、更有效。每个迭代结束后，团队会进行得与失的分析，固化好的做法，调整出问题的过程环节。针对性的改进可以很快在下个迭代中进行，不断提升团队的开发能力。本章后面章节我们会讨论敏捷过程的特征：它不是一个预定义的过程，而是一个基于经验的过程，团队通过不断的实践、反省、调整来改进所执行的敏捷过程。
希望你能再看一下宣言的4条内容，好好琢磨一下这12条原则。你觉得软件开发应该遵循这些原则吗？你认为这些表述是一些不现实的目标，还是简单的常识—本该如此？真正理解这些原则能够帮助你学会敏捷思维，而不仅是照葫芦画瓢地做敏捷。
敏捷12条原则
1．尽早、持续交付有价值的软件是我们满足客户的最优先考虑。
2．即使到了开发的后期，也欢迎需求变更。敏捷过程利用变更为客户创造竞争优势。
3．频繁交付可以工作的软件，交付间隔越短越好，可以从一两周到一两个月。
4．在整个项目开发期间，业务人员和开发人员必须可以天天随时沟通、一起解决问题。
5．围绕一群有动力的个人进行项目开发。给他们提供所需要的环境和支持，并且相信他们会把事情做好。
6．对一个开发团队来说，面对面沟通是最高效的传递信息的方法。
7．工作的软件是软件开发中首要进展度量指标。
8．敏捷过程提倡可持续的开发。产品的赞助者、开发者和用户应该能够保持一个长期的、恒定的开发节奏。
9．不断关注卓越技术及优秀设计能增强敏捷力。
10．简于形—是最大化的减少不必要工作的艺术—这是敏捷精髓。
11．自我组织的开发团队能够逐步摸索出最适合的构架、需求和设计。
12．每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后对自己的做事方式进行必要调整。
那么什么样的开发模式称得上是敏捷过程呢？敏捷的4条价值宣言及12条原则给出了明确标准。如果一个开发模式是在身体力行这些宣言及原则，那么它就是敏捷，否则就不能称之为敏捷。本章第一段落里提到的方法，是业界一些常见的敏捷开发模式。
当你读完这本书以后，可以回来再看一下敏捷宣言及原则。也许那时你的体会和理解会更深一些。
1986年2月，两位日本人Takeuchi和Nonaka（1986）在哈佛商业评论上发表一篇题为“一个新的新产品开发游戏”的文章，提出了一个类似于英式橄榄球（RUGBY）比赛的产品开发模式。他们没有想到，几年后这篇不起眼的文章给3位美国软件开发经理带来了他们需要的灵感。Jeff Sutherland、Ken Schwaber和Mike Beedle不约而同地将文章中的产品开发模式应用在他们管理的软件项目上。10年后他们在自己的经验基础上定义了Scrum的框架及实践（Schwaber，2004, 2007; Schwaber et al.，2002; Sutherland et al.，2011）。3位作为敏捷初期的探索者，也参加了2001年2月在雪鸟城的聚会。今天绝大多数应用的敏捷过程是Scrum或Scrum和其他方法（如极限编程、传统方法等）的结合。本书中描述的敏捷管理活动多以Scrum为核心，而工程活动则多以极限编程的方法为主。但我不局限于这两个方法，只要是经过验证的相关有效实践，我都会参考。
在介绍Scrum之前，我觉得很有必要介绍一下Jim Highsmith（另一位敏捷宣言的签名者）提出的敏捷开发架构（Highsmith，2011）（见图2-1）。这个架构体现了敏捷的核心理念，在这个架构下，我们可以更好地理解Scrum。
图2-1 敏捷开发架构图
如图2-1所示，敏捷开发应该包含以下5个不同阶段。
（1）产品愿景阶段：其主要工作是确定产品的愿景及大概范围，项目目标以及约束条件（做什么），同时明确团队相关成员（谁来做）及协同工作方式（如何做）。
（2）推测阶段：围绕需求特性建立产品发布计划，主要工作包括：收集分析初始需求，估计开发成本等信息，考虑风险缓解策略，建立一个迭代和需求特性基础上的开发计划。
（3）探索阶段：计划并在较短周期内成功提交一个产品功能特性子集，并不断寻求降低项目的不确定因素。这个阶段主要完成3个关键活动。
开发团队通过遵循有效的技术实践及有效任务管理，提交规划的需求特性子集。
建立并不断完善一个协作、自我组织的项目社区。
管理和客户、产品管理团队及其他重要利益相关人的沟通，加深对产品价值及约束条件的理解。
（4）调整阶段：开发团队和客户及其他重要利益相关人一起评审迭代完成的需求功能特性（工作的软件），对产品的需求做出调整。同时团队也会从迭代过程性能（如效率）及项目状态的角度回顾刚刚结束的迭代，根据情况调整迭代过程和发布计划。本阶段活动的结果会用来帮助更好地做好下个迭代的工作。
（5）关闭阶段：每个项目都有个结束点，结束点也是总结点—总结经验教训、优秀实践，获取新知识的总结传承。
注意图2-1中推测（speculate）、探索（explore）和调整（adjust）之间的闭环，这3个词较为准确地表达了敏捷核心理念，表达了知行合一的精髓。这3个词代替了瀑布模式中的计划（plan）、执行（do）和纠错（correct）。用推测而不是计划，更明确表示在这个阶段我们并不知道一切，当我们在迭代中获取更多信息后，调整是件自然的事。用探索而不是执行则体现我们在摸着石头过河，边开发边获取更多的信息。调整不是纠错更明确表示一开始我们并不知道什么是对的，也就是初始计划不见得是正确的。调整后我们会带着更深的理解及更多的信息进入下次探索（迭代）。这3个阶段不断地循环，直到将一版新的对用户有价值的软件产品提交给客户。在本书第4章中，我会更加详细地介绍这5个阶段的内容。
在传统瀑布开发模式下，“计划-执行-纠错”意味着早期项目一般不会偏离计划，但在项目后期往往会跳出计划的轨道。而“推测-探索-调整”则恰恰相反，我们预期项目不会按预测的进行，但后期则会越来越准。
但另一方面我们也应该意识到，敏捷架构也有一点传统方法的影子：推测有计划的影子，每一次探索的结束都有里程碑的影子。在实际操作中，敏捷过程往往会或多或少吸收一些传统方法的实践。这个平衡度的把握是由需求清晰度及技术稳定度来决定的。
为了让大家能够更深入地理解Scrum，还需要用些篇幅介绍产品开发的两类过程：定义的过程（defined process）和实验性过程（empirical process）。定义的过程往往描述一个可重复的生产过程，只要严格遵循过程中定义的每一步，我们就能生产出满足质量要求的产品，它是一个可预测的过程。在制造业，人们都会尽可能地使用第一的过程，这样才利于批量生产并能大大减少成本。但当开发复杂产品时，有时我们没有办法明确过程中的步骤，强制执行定义的过程反而会带来由于不定因素而造成的大量返工。这时，实验性过程就是一个好的选择。
实验性过程有3个关键支撑点。
（1）透明（transparency）：整个开发过程中所有活动透明，并且所有人对完成标准理解一致。例如，如果我们说某个需求项已经完成，那么所有人的理解都应该是一样的。不能是有些人理解为仅仅是代码已完成，而另一些人的理解是代码已完成，并通过了代码审查、单元测试、集成测试和验收测试。透明是实现另外两个关键支撑点的基础。
（2）审查（inspection）：在过程中，我们需要不断审查过程中的差异及问题，很明显，透明是审查的先决条件。检测的频率和过程活动的执行有密切关系，有效的审查也要求审查人员必须具备必要的产品、技术、管理和过程的相关技能。
（3）调整（adaptation）：在过程中，当审查出的问题会影响到过程目标时，我们需要及时调整相关过程或过程相关因子，将损失降到最低。
代码审查就是一个实验性过程的例子。当一位不是很有经验的程序员完成一个代码模块后，项目经理会要求对模块做一次代码审查。几位有经验的程序员会依据代码标准对其进行评审，当然他们对这些标准非常熟悉。评审中发现的问题及建议会用来完善该代码模块，也会用来完善评审过程、标准，它们也会帮助这位经验不足的程序员提升编程能力。
Scrum是为了在复杂场景（图1-4中的“困难”和“复杂”类项目）下开发出有价值的产品而建立的。复杂场景往往意味着不确定性、不可预测性，也就是说我们很难建立一个步骤明确的过程，指导我们开发出客户需要的软件。定义的过程对这类项目是非常不适用的。对于复杂项目来讲，实验性过程是个更好的选择。Scrum就是一个实验性过程，它给出了一个简单但有效的执行知行合一的架构，是多数敏捷组织的首选敏捷方法。
那么Scrum到底有多简单呢？我可以用7句话，用不到一分钟的时间把它概括一下。
（1）产品经理（product owner）负责建立并维护一个按优先级次序排列的、反映客户期望的产品需求列表（product backlog）。
（2）在迭代（sprint）计划时，团队从需求列表中优先级高的需求项中选取一小部分，放入迭代需求列表（sprint backlog）中，并决定如何开发这些需求功能。
（3）团队在固定的时间周期内完成一个迭代，通常是2～4周，团队每天会在一起评估项目进展情况（daily scrum）。
（4）在这个过程中，Scrum过程经理（Scrum master）会让团队关注迭代目标的实现并遵循Scrum实践。
（5）在每次迭代结束时，团队完成的代码是可以提交的：可以直接让客户使用，或者可以展示给客户或用户代表。
（6）迭代的最后两个活动是迭代评审（sprint review）和迭代回顾（retrospective），根据反馈，对产品及团队工作方式（过程）做优化调整。
（7）在下个迭代开始时，Scrum团队（Scrum team）又会从产品需求列表中选取一部分优先级高的需求项，开始新一轮的开发工作。
图2-2给出了Scrum一个大的管理框架。
如前所述，国内大部分人把Scrum中的Sprint直译成“冲刺”，我不是很喜欢这个翻译。因为冲刺这个词给人的感觉像是在跑短跑，而这是和第八条敏捷原则相违背的。这条重要的原则指出：“敏捷过程提倡可持续的开发。产品的赞助者、开发者和用户应该能够保持一个长期的、恒定的开发节奏。”软件开发是马拉松，按百米跑的冲刺速度来跑马拉松会让你很快累趴下。在本书里，我用迭代来表示Sprint，大家把它理解成一个短周期的开发就行了。在第5章，我会详细介绍Scrum中的实践。
有人把Scrum简单解释为3个角色、3个文档和5个会议。
图2-2 Scrum管理框架
在介绍Scrum角色之前，先讲一下著名的猪和鸡的故事。一只有经商头脑的鸡找到一头聪明的猪，提出合伙开一家火腿和煎蛋快餐店。猪想了一下说：“好像不太公平，我们介入的力度差别太大，我出的是身上的肉，你出的是每天下的蛋。”
Scrum的角色就是产品开发中的猪，他们是产品经理、Scrum过程经理和Scrum团队（Scrum team）。
顾名思义，产品经理最主要的责任是保证团队开发的功能特性对客户是有价值的，具体来讲，他需要做以下5件事。
（1）建立产品的愿景，也就是产品给客户带来的价值。
（2）建立维护产品的发布计划/版本计划（release plan）。
（3）及时收集用户反馈、优化产品需求。
（4）确定每条需求项（用户故事）的价值及优先级。
（5）明确每个需求项的验收通过标准。
Scrum过程经理比较特殊，在传统方法中是没有这个角色，所以这是个经常被误解的角色。一个称职的Scrum过程经理能在3个方面起到重要作用：让团队的关注点始终在实现客户价值上；让团队在每个迭代中不受干扰（大家都知道封闭式开发能够保证效率，Scrum的每一次迭代就是不需要团队成员住酒店的封闭式开发）；帮助产品经理和团队在Scrum的框架下做好各自的工作，并做到有效沟通。为了实现这3个目标，Scrum过程经理需要做好下面一些工作。
建立、改进适用于团队的Scrum过程。
推动敏捷实践及有效开发实践在开发中的有效应用。
推动团队问题障碍的解决。
帮助培育团队的自我管理形成良好的团队文化。
协调各方的沟通，包括猪与鸡的沟通。
注意，Scrum过程经理不是真正意义上的经理，不是传统的项目经理，他和团队成员之间不是管理和被管理的关系。Scrum过程经理更像是团队的过程教练，以及团队的“护羊犬”（如果把团队看作是“羊群”的话）。
开发团队是Scrum过程的核心，这是个规模小（5～9人）的跨职能团队。团队应具备软件开发所需要的所有技能：需求分析、设计、编码、测试、技术资料编写等。它的主要责任是通过迭代，不断开发提交对客户有价值的功能特性，同时持续改进提升团队能力，将其潜能最大化。团队的主要工作包括以下几项。
估计产品需求列表中用户故事的复杂度，考虑用户故事的优先级、依赖关系、实现难度等，选择下次迭代的范围，形成迭代需求列表。
遵循团队达成的工程实践共识，完成每个用户故事的需求澄清、设计、编码、评审、测试、资料编写等相关工作，不断提交对客户有价值的需求功能。
不断总结开发过程中的得与失，持续改进个人能力及团队能力。
在第4章讨论敏捷布局时，我还会进一步深入讨论Scrum中的各种角色的选择和要求。
在第5章中，我会深入讨论3个文档的使用，这里仅做一个简单介绍。
产品需求列表是Scrum中最重要的文档，它是一个动态的（产品经理可以随时对其进行调整）包含了客户期望的需求的列表清单。大部分敏捷团队使用“用户故事”的形式来表示每一个需求项，产品经理会对它们按价值排序，由高（上）到低（下）。用户故事的颗粒度会有很大差异，主要遵循“近细远粗”的原则：排在最上面的用户故事会被细化，以支持团队近期迭代的实施。而底层故事的颗粒度可以很大，因为前期花精力对其细化很不值得。这些需求后期很可能会变，也有可能根本不需要。因为没有完美的产品，所以产品需求列表永远不可能全。只要一个产品还在被使用，它的需求列表就应该存在。
迭代需求列表则是由团队负责管理，它定义了Scrum团队某次迭代承诺实现的用户故事或任务。在迭代中，它一般是不变的。团队会识别出完成每一个故事所需要完成的任务，通过完成这些任务，提交可提交的工作的软件。每次迭代应该有个主题或目标，Scrum的增量开发是通过不断迭代，完成迭代需求列表中的需求项来实现的。
燃尽图是Scrum中的第三个文档，它主要是用来监控版本及迭代开发进展情况。版本燃尽图显示本次版本未开发的需求项或剩余的工作，而迭代燃尽图则显示一次迭代中未完成的工作。图2-3和图2-4显示了两类燃尽图—版本燃尽图和迭代燃尽图。
图2-3 版本燃尽图
图2-4 迭代燃尽图
燃尽图可以简单清晰地展示迭代完成情况及版本实现情况。
在第5章中，我会描述如何开好Scrum中的5个会议，这里只简单介绍一下5个会议的目的。
（1）产品需求列表的细化会议：团队和产品经理会一起细化列在需求列表前面的需求项（用户故事），为近几次（如两次）迭代做好准备。
（2）迭代计划会议：团队从产品需求列表前面被细化的需求项中选择本次迭代要完成的用户故事或任务，形成迭代需求列表。
（3）每日站立会议：这个每日15分钟的例会可以让所有团队成员的工作得到同步，同时及时识别并解决任何影响实现迭代目标的障碍。这是审查（inspect）和调整（adopt）的最小颗粒度。
（4）迭代评审会议：通过演示本次迭代中团队成功完成的需求功能，让产品经理、客户及其他利益相关人加深对产品的理解，调整产品需求列表，逐步识别聚焦到真正对客户有价值的需求特性。这个会议实现了对产品的审查与调整。
（5）迭代回顾会议：这是每次迭代的最后一个活动，团队会在这个会议上对迭代中的问题及好的做法做简单的根因分析，如有必要，会调整团队的Scrum过程及实践。这个会议是对开发过程的审查与调整（改进）。
Scrum中的一个重要时间盒体现在固定的迭代周期（一般2～4周），固定时长的产品需求列表细化会议（2～4小时），固定时长的迭代计划会议（4～8小时），固定时长的每日站立会议（15分钟），固定时长的迭代评审会议（4～6小时）和固定时长的迭代回顾会议（3～6小时）。时间盒是使团队专注、发挥潜能，及早发现问题并做出解决决策的有效手段。
我们可以很容易在前面描述的敏捷框架下建立以Scrum为核心的开发过程。
愿景阶段可以解读为迭代前的准备，推测阶段可以看作是建立调整版本计划，而探索阶段则对应一次迭代，那么调整阶段就是迭代评审和回顾了。在这个过程中，团队不断优化产品需求列表，同时增量提交实现的功能。
大多数实施Scrum的团队会同时实施一些极限编程（极限编程）的实践，这是因为二者有极好的互补性。软件开发的工程实践是Scrum遗忘的角落，这不是疏忽而是刻意为之，它把如何做（工程实践）留给团队来决定。这个选择同时也带来了开发风险，因为团队有可能会过于追求速度，植入产品的维护及使用隐患。我们把这些隐患称为技术债务，而忽略它们则称之为带病迭代。
由于Scrum迭代周期很短，对开发出软件的充分测试往往是完成迭代目标的瓶颈。极限编程在这方面提出了有效的做法，大大降低了变更成本（这些变更包括需求、设计和编码）。在实施Scrum时，建立能支持持续集成等极限编程实践的环境及能力，是成功实施Scrum的重要保证。
在下一章我会详细介绍极限编程的原则及重要实践。
不难看出Scrum的实践（从20世纪90年代初开始）是敏捷宣言及原则的一个重要来源。真正合理使用Scrum，需要团队真正理解敏捷原则、实践、Scrum架构，同时用这些原则、实践、架构解决团队在开发软件中遇到的问题。Scrum是一个实现敏捷价值、体现敏捷原则的开发模式。
Scrum从传统的任务驱动管理转换为需求特性驱动管理，这个转换带来的最大好处之一是让团队关注的东西和客户关注东西高度一致。客户并不关心团队是如何实现需求功能的，一般也没有能力判断团队的开发及管理活动的合理性，他们关注的是团队实现的需求功能：哪些能实现，哪些不能实现，什么时间能提交，是否能调整需求（加、减、改）。
Scrum过程设置了一个专门的角色（产品经理）来和客户沟通，他同时又是客户和团队的沟通桥梁。这样客户有一个明确的渠道随时将他们的想法转达给团队，同时有一个既理解他们所需产品价值又了解开发团队能力的人帮助他们做产品规划。
由于每次迭代的周期都很短（一般不超过4周），哪怕是两年的项目，客户也可以不断看到团队实现的需求功能，给出需求优化的反馈。实现的需求真正变成了和客户沟通的载体，客户可以在整个开发过程中不断用自己熟悉的东西和团队进行沟通。
新的需求可以随时加到产品需求列表中，而迭代需求列表在迭代中一般是稳定不变的，这样需求变更造成的成本会比传统模式少很多。而短的迭代周期也降低了技术变更（如设计）造成的返工，以及需求不明确带来的返工。高频率的审查（每日例会、迭代评审和回顾会）也缩短了缺陷及问题植入和发现的距离，从而降低了质量成本。当然前提是团队真正掌握了Scrum管理实践，让改进变成团队常态化的活动。
每次迭代最重要的产出物是工作的软件，在迭代评审会上，我们只会演示达到“完成”（Done）标准的程序。其他工程管理文档都是用来支持团队开发出工作的软件。增量开发也就是代码库的不断扩张。
让我们看一下Scrum是如何体现敏捷的12条原则的。
（1）产品需求列表中的优先级及每次迭代后持续提交工作软件体现了第一敏捷原则。
（2）产品需求列表的随时更新保证了第二原则的实现。
（3）1～4周的迭代周期保证了第三原则的实现。
（4）Scrum的跨职能团队及每日15分钟的站立会议实现第四原则。
（5）Scrum中的自我管理原则也是敏捷的第五原则。
（6）5～9人的小团队，白板的使用以及面对面的沟通等Scrum实践保证第六原则的实现。
（7）Scrum对工作的软件的关注实现了敏捷第七原则。
（8）时间盒的概念、迭代速率（Velocity）的使用支持第八原则的实现。
（9）Scrum要求对产品需求列表中每一个用户故事都定义一个完成（Done）标准，这对第九原则的实现有很好的推动。Scrum对第九原则实现的保证不是很强，这也是很多Scrum团队同时引入一些极限编程实践的原因。
（10）Scrum为实施敏捷第十原则提供了一个很好的框架，不断地审查和调整，变更成本的降低，都为尽量只做正好够的东西（just enough）以及在恰当时间（just in time）做决策提供了有力的支持。
（11）Scrum将“如何做”完全放在团队的手中，这是对敏捷第十一原则的诠释。对团队自律的要求会逐步将一群人变成一个真正的团队。
（12）Scrum的回顾会议就是第十二原则的体现。
如果能在企业级为敏捷实施提供有效的支持，形成一个精益（Lean）文化，如果团队能够结合实际，建立一个合理的Scrum过程，并不断完善这个过程，那么这样的Scrum是新的项目管理铁三角的绝配。这样的Scrum也能让团队用小的代价实现高价值产品需求特性。
故事1：团队A的第一个故事
Team A是国内一家著名IT公司的一个开发团队，为了提高开发效率，Team A决定在下一个项目中引入Scrum。公司任命贾工担任团队的Scrum过程经理，同时也是项目经理。贾工是个很有经验的项目经理，公司派他参加过一些外部Scrum培训，他自己也上网了解了Scrum的很多实践。贾工对每日例会印象深刻，觉得很有道理，他认为每日例会是Scrum的核心活动。
新项目的客户要求团队18个月后提交产品，公司为了争取这个单子，在没有做必要可行性分析的情况下，做出了进度承诺。贾工十几年的管理经验都是在传统瀑布架构下积累的，他在做计划时还是摆脱不了瀑布思维。他把项目分成了下列几个阶段，阶段中间有些重叠。
需求分析阶段：目标是梳理清楚客户需求，并将功能及性能需求项记录在软件需求规格说明书中。
设计阶段：目标是完成概要及详细设计，并产生对应的设计文档。
编码阶段：目标是依据设计完成编码工作。
测试阶段：目标是对完成的代码进行测试，发现缺陷并修复回归。
发布阶段：目标是通过客户验收。
贾工依据Scrum的实践，引入了每日例会和任务管理白板。但这些例会，不同阶段有不同人员参加，如在需求阶段只有相关需求人员参加，设计阶段只有相关设计人员参加。贾工觉得很多其他Scrum实践在本项目里很难使用。例如他觉得有了需求规格说明书，就不需要再做一个产品需求列表了。很快到了年底，离发布只有6个月了，管理层和客户要求贾工对项目进展状况做个分析，并回答他们最关心的问题：团队是否能按时在6个月后提交满足客户要求的工作软件？
贾工报上来的结论让管理层十分失望，如果按目前进展情况估计，完成合同中所有需求功能，至少还需要18个月。也就是说，项目需要延期一年。
管理层不能接受这个答案，要求贾工必须按时提交满足客户要求的工作软件。和团队沟通后，贾工正式向公司提出了辞职，另谋出路了。
故事2：团队A的第二个故事
公司决定为团队A请一位业界口碑很好的敏捷教练郑博士做新的过程经理，希望他能够挽救这个项目。在给管理层一个新的计划之前，郑博士首先对项目做了诊断，识别出下列几个问题。
团队花了很大精力整理出了一份200多页的需求规格说明书，但不能起到产品需求列表的作用—优先级不清晰，变更成本很高。团队只能开发完需求规格说明书中的所有功能后才能提交产品。
团队内部缺乏信任，职责不明，承诺很随意。
团队成员会随意被管理层分派其他所谓更重要的任务。
测试及构建环境不能有效支持高效开发。
估算随意且无依据。
郑博士同时和团队一起也做了下列几件事。
建立产品需求列表。
定义了完成标准：可发布是完成标准的依据。同时把测试人员安排为Scrum团队成员。
依据当前的需求列表中的故事，估计用户故事点。需求列表中含尚未开始编码的故事及已完成编码但尚未测试的故事。前者的规模是180点，后者是70点，总计250点。
团队接下来按Scrum过程完成了两个周期为两周的迭代：第一次迭代，团队计划完成30故事点，但实际完成9个点。第二次迭代，团队在迭代需求列表放入了25个故事点，实际完成了10个故事点。
根据这些信息，郑博士向管理层提出了新的计划：产品需求列表一共有250故事点，按每次迭代完成10个故事点算（团队速率），团队还需要25次迭代。每次迭代的周期是2个星期，郑博士代表团队承诺一年后完成项目。这就意味着项目要延期6个月。
和客户沟通后，管理层否决了这个计划，还是坚持按期提交。郑博士代表团队同意按合同执行，但要求客户和管理层同意团队的两个要求。
缩小需求功能范围：将非必要及价值低的用户故事从产品需求列表中删去。
分两次发布：在合同要求的时间点，发布产品主要功能；3个月后发布剩余功能。
管理层和客户同意了团队的要求，并据此重新调整了合同。郑博士同时也向管理层提出一些期望。
相信团队会主动把事情做好，不要给团队施加不必要的压力，提出达不到的要求。
对测试及集成构建环境做必要的投入。
在迭代开发过程中，尽可能不要抽调团队成员做其他事情。
给团队更多的鼓励、支持。
郑博士在团队建设方面也做了很多工作，重点解决团队的自律、动力、相互配合等问题，使团队真正成为一个拳头而不是5个分开的指头。
经过6次迭代，团队的速率从10达到了近30。在项目启动后的第十八个月，提交的软件通过了客户验收。3个月后团队成功提交了剩余功能。
团队A的两个故事纳入了公司敏捷实施培训教材。
你读完第2章后会觉得Scrum描述了一个并不复杂的开发模式，但许多企业在导入Scrum时忽略了一个重要事实：这些实践是有关联性的。也就是说，随意选择部分实践而忽略其他关联活动不会将Scrum的价值潜力真正发挥出来。
近几年来，中国实施敏捷的IT企业越来越多，我也有机会和很多“敏捷”团队有所接触，得到了一个也许有些人不以为然的结论：大部分所谓敏捷团队及企业都没有真正理解敏捷的真谛，他们在做法上有一个共同点，即只引入一些相对比较容易的实践，对一些他们认为较难实施的Scrum实践则采取了视而不见的态度。另外一个大的问题是，敏捷只在团队层面实施，而整个公司的文化、理念和敏捷格格不入，“敏捷”团队无法得到组织层面的支持，使得一些重要的敏捷原则无法落地。
形似神不似只能让敏捷团队获得有限的提升，很难把团队打造成一个高效率的团队。Jeff Sutherland对Scrum的实施现状有下列的结论：
支离破碎实施Scrum的实践现状让人不可思议！哪怕是这样，大部分宣称和旧的过程比，还是看到了提高。我们还要做很多工作让大家回归到基本Scrum要求上面来。
他同时观察到，支离破碎的Scrum带来的效率提升在35%左右，而完整的Scrum有可能带来300%～400%的提升，可惜这样做的组织太少。
在Scrum的架构下，如何实施工程活动是所有团队面临的一个问题。Scrum中超短的迭代及部署上线周期给开发团队带来了极大的挑战，按部就班的传统开发方法不可能满足质量及进度的要求。增量开发下的架构设计、代码优化如何做变得格外重要，团队必须将代码库不断扩张带来的技术风险降到最低。我们需要引入能将技术变更、代码库增加的成本降下来的工程实践。极限编程是一个很好的选择，它能有效地支持Scrum的执行，让团队真正实现敏捷价值。在3.4节，我会探讨极限编程的价值观、原则及实践，并讨论如何将其和Scrum自然结合。在第6章，我会深入探讨一些能够有效支持Scrum架构的优秀工程实践，包括极限编程的一些有价值的实践。
形似神不似的Scrum有一个特点，那就是把在本组织难以实施的敏捷Scrum实践忽略不计，仅实施自己喜欢做、容易做的内容。如大部分国内企业在实施Scrum时，往往不做团队的自我管理实践，也不强求明确定义迭代完成（Done）标准。
另一个常见的问题是，在通过Scrum实施敏捷时，不考虑敏捷宣言及敏捷12原则。支离破碎的Scrum往往意味着放弃一些敏捷原则。知其然不知其所以然，没有理解敏捷带来的价值，为做敏捷而做敏捷，不可能达到形神兼具的境界。
当一个组织在“我特殊所以不适用”的借口下绕开一个Scrum实践时，很有可能这个实践触到了该组织的痛处：这个实践所指正是问题所在。变革需要勇气，正视自己的问题需要勇气，放弃习惯需要勇气。可惜勇气是很多组织缺乏的东西。
当管理者习惯地对一个Scrum团队说：“放下手中的工作，这边有更重要的任务需要你们去做。”这就是说Scrum过程经理没有办法保护团队在迭代中不受外界干扰，一条Scrum实践被放弃了。借口是“我们特殊，因为我们会常常碰到更紧急的任务需要团队处理”。
当一个管理者在无形中要求Scrum团队放弃这个实践时，他同时把危害团队效率的一个问题埋在了地毯下。同时做多件事，虽然貌似让团队成员一直在忙，但并不意味高效率。业界共识是同时做多件事是效率的杀手，从一个任务转到另一个任务需要转换成本，让专注变得困难。在放弃这个Scrum实践的同时，组织也失去了纠正这个问题的机会。
当一个团队以没必要为借口，拒绝对需求特性进行细化分解时，很有可能团队放弃了解决需求蔓延，用小的代价实现需求价值的机会。因为对需求分层细化，会给团队实现一个大特性更多选择机会，当你将一个大需求细分成5个小故事时，需求优先级才会起到作用。你可以判断一下核心的故事是什么，哪些故事是锦上添花的，哪些故事是其他故事不同的表现形式（也就是不需要的），哪些故事可以在以后确定了必要性后再实现。
当你以“团队成员会避开有难度的任务”为借口，放弃让成员自己认领任务的做法，而仍由项目负责人来分配任务时，你放弃了挖掘团队潜力的机会，放弃了营造一个能让团队成员有自豪感的工作环境的机会。一个人习惯了被动地接受任务，主动就是一个陌生词。当一个程序员3天完成了分配给他5天的工作，有多少程序员会主动去要求追加两天的工作？
当你以各种借口避开敏捷（Scrum）实践时，你同时放弃了解决组织内真正问题的机会。一个不易实现的实践往往是一个对组织价值大的实践，支离破碎的Scrum只能带来有限的改进也就不那么奇怪了。Scrum不能保证解决问题，但能保证暴露问题，而勇敢地面对问题，是解决问题必须跨出去的第一步。
当你尝试本书介绍的实践时，一定不要忘了和你组织的实际情况紧密结合。Scrum是一个来自美国的方法，它必然体现一些美国文化。在建立你的团队Scrum过程时，必须考虑本地特点，你的过程你做主，不要怕犯错误，因为不断完善过程是Scrum的要求。
用敏捷方法引入Scrum，已经被验证是一个有效的做法。我虽然建议敏捷组织尽可能全面实施敏捷实践，但这不是说你应该一下子将所有Scrum和极限编程的实践都同时引入。“增量实施、先易后难”是一个有用的八字箴言。引入Scrum的过程也是一个自己了解自己的过程，知己知彼，百战不殆，了解敏捷、了解Scrum、了解极限编程，同时了解自己，是成功实施敏捷的秘诀。
本地化意味着深入理解你的团队、你的客户、你的产品需求、你的技术平台、你的组织文化、你的工具、你的工作环境等重要因素。
举个简单的例子：在哪里开你的每日站立会议？如果只有一个敏捷团队，这可能不是问题。相信你总能找到一个会议室。但当整个组织都在实施敏捷，这就是个头疼的问题了。你需要因地制宜了，例如，重新布置办公空间，为每个Scrum团队建立自己的敏捷岛。
在你的组织架构下，谁来做Scrum的过程经理？谁来做产品经理？在你的产品环境下，如何设计产品需求列表？如何描述用户故事？这些都是你需要根据自己的情况来确定的。
不少正在实施敏捷的组织管理者无法明确回答一个简单的问题：“你希望通过引入敏捷解决什么问题？”也就是为什么引入敏捷。
这些聪明人无法明确回答这个问题的原因也很简单：他们没有真正理解敏捷，没有真正理解Scrum。不理解的后果是，他们可能会因为错误的原因引入敏捷。下面是我听到的一些引入敏捷的原因。
华为在用敏捷，所以我也要用。
敏捷可以解决CMMI的问题，团队不需要再浪费时间写文档了。
因为敏捷是目前最好的开发方法，引入敏捷就会解决效率问题。
在我做CMMI过程改进咨询、培训、评估时，听过许多公司老总谈他们对CMMI的认识和引入CMMI的原因。我的感受是道听途说、一知半解很害人。我不希望同样的问题在敏捷落地中国的过程中再现。
一个组织在引入敏捷以前，应该做3件事。
（1）搞清楚敏捷是什么、Scrum是什么、极限编程是什么，一定不要忽略其局限性。
（2）对自己的开发过程的瓶颈做个诊断：3～5个主要问题是什么？对这些问题做必要的根因分析，明确哪些问题可以通过引入敏捷解决、如何度量解决的效果。
（3）制订一个初步敏捷引入规划，列出范围、目的、步骤、策略、风险、时间表等。
俗话说：好的开始是成功的一半。知道为什么引入敏捷，明确要解决的问题是一个好的开始。
念好Scrum这本好经是一门艺术，它的难处在于我们需要放弃很多习惯的理念及做事方式，这些做事方法、理念已经深入人心，特别是你的领导的思维方式也被框在其中。在这一章节里，我重点讨论Scrum方法中没有直接描述，但是能决定Scrum成败的要点。
几乎所有软件开发面临的挑战都和人有关系：如何控制人的情绪，如何调动人的主动性，如何保障人与人之间的有效沟通。所有敏捷方法无一例外，把人及他们之间的沟通放在了比过程更重要的地位。Scrum实践最希望达到的目标是支持在一个团队中建立健康的工作关系：诚实、信任、开放、相互尊重、通力合作实现每一轮迭代目标。
我在国内一些企业看到的做法往往达到相反的效果，如测试人员完全依赖缺陷跟踪（Bug-tracking）系统和开发人员进行沟通，这种沟通模式往往会形成一个推诿责任的文化，损害了开发和测试之间的工作关系。为什么不能让他们一起紧密配合工作，确保用户不会发现任何缺陷呢？软件开发团队的跨职能小组之间不应该是PK的关系，应该是荣辱与共、同在一条船上的关系：产品缺陷给使用的用户带来了不便是整个团队的耻辱，发布前发现的每一个缺陷都是值得整个团队庆祝的事。
自我管理是敏捷在开发过程中提倡的人的管理方式。由于文化的原因，让中国的软件团队自己管理自己，确实不是一件容易的事。不考虑管理者的因素，工程人员一开始也很不习惯这种工作环境。从小到大，在中国教育体系下成长起来的软件工程师已经习惯了被动地接受：在家里家长告诉你应该怎么做；在学校老师告诉你应该怎么做；从你上班的第一天起，你的上司告诉你应该怎么做。在产品开发过程中，他们习惯了每周由经理告诉他们做什么，然后埋头去做，很少相互间沟通。如果能提前完成任务，就放慢节奏；如果不能按时完成，到时就找个借口，下周继续做。这样一个被动的团队，是很难将团队的潜力最大限度地发挥出来，也很难让开发人员有成就感，更没有动力去主动寻找更好的实现方法，真正形成一个紧密的团队。
实现自我管理要有两个大的调整：管理者管理方法的调整和工程人员工作方式的调整。这两个调整会是每一个实施敏捷企业都面临的问题。
用人不疑，让团队放手做好自己的事，是管理者常常挂在嘴边的话。但是没有几个领导能够真正做到这一点，一个原因是他们找不到一个让他们放心的放手管理的方法。Scrum给出让团队自我管理的架构，给软件研发团队指出了一个全新的工作方式。
首先，Scrum明确定义了产品开发中的“猪”和“鸡”，极其智慧地区分了产品开发的业务和技术的职责。在这个架构下，只有“猪”直接承担研发过程的责任，所以“猪”也是研发过程的决策者。Scrum的策略是让业务人员专注业务的问题，让技术人员专注技术实现的问题，项目的管理是由业务决策驱动，而业务决策必须是在技术方案的成本和风险基础上做出的。
Scrum的产品经理被赋予产品业务决策权，而团队则被赋予了相关技术决策全权，Scrum很好地平衡了业务和技术的关系，不给产品经理或团队过大的权力，不让一个强势的产品经理或技术高手完全控制整个过程。让产品经理控制产品需求列表，而让团队控制迭代需求列表，则是保证这种平衡的机制保证。从某种意义上来讲，Scrum的过程经理的主要责任之一也是维护好二者之间的平衡。
业务和技术职责的平衡是Scrum实现自我管理的基础，在这个大框架下，团队可以专注做好自己的事，同时必须不断完善其工程实践，完善使用的开发管理工具在短时间内能够交付可部署的软件。Scrum要求团队每次迭代的最后一个活动是回顾改进，从错误中学习，不断提升能力。正是有了这些保障，管理者可以放心放手让团队做好自己的事。
实现团队的自我管理，意味着每一个成员都清楚自己的责任及权利，团队会根据自己的能力确定每轮迭代完成的故事范围，每天让每个成员主动认领任务（在回答站立会议的第二个问题时），有问题及时沟通，充分利用团队内的资源寻找帮助，同时随时准备帮助其他成员，团队只有一个共识：想办法努力实现团队承诺的迭代目标。
何时认领任务是很有讲究的，我看到国内大部分Scrum团队在迭代规划会上就将任务分配完了，在我问为什么这样做时，最多的回答是怕没人认领比较难的任务，这又是一个绕过实施敏捷实践的例子。这种做法带来的最大问题是有些人认领的任务是他完不成的，而有些人认领的任务可以提前完成，等迭代快结束才发现某些任务无法按时完成时，很有可能团队已经没有时间实现迭代目标了。这样做的另一后果是，我们很难逐步把团队带成一个主动、互助、高效的团队。
Scrum鼓励当天的任务当天认领，这样有几方面的好处：避免了忙闲不一的情况；通过前面已完成的任务，成员会对后面的任务，各自的长处、短处更加清楚，这样任务和成员能力的匹配会更好。如果碰到了技术难点，可以集思广益、攻关解决。
虽然Scrum没有传统意义上的项目经理，但团队会自然形成一些技术领头人，以他们为核心，鼓励主动承担任务，不怕失败，及时从失败中学习，不断调整，正是Scrum的核心实践。Scrum通过自我管理机制的完善及相关实践的结合来解决复杂的问题。
让团队从被动到主动，不可能一步到位。管理者必须给团队创造一个安全的环境，让他们放手发挥自己的能动性，出了问题不要责难，而是要鼓励。中国的Scrum过程经理在这方面面临的挑战更大，他需要指导团队逐步学会使用自己的权力，去担当，去学习，逐步形成一个真正的团队。产品经理和团队也要学会互相尊重对方的权力，在同一目标下，双方协调实现Scrum的价值，实现产品的价值。
在Scrum模式下，管理者要从计划驱动思维方式转换为敏捷思维，其中一个重要的变化是不要把初始计划太当回事，要能够容忍计划的调整变化。从传统计划驱动到敏捷的另一个大转换是敏捷的管理者度量监控的是需求（如产品功能完成情况，产品是否可以发布），而不是任务。管理者关注的不是实现这些需求的任务执行情况，而是这些需求的实现情况。
管理者如果要了解某次迭代的情况，他可以列席团队的每日站立会议，但注意他只能听而不能干预团队。如果想了解整个项目的状况，管理者可以在项目的敏捷岛（更多的信息可以参见第5章）看到相关信息。迭代的评审会议、产品需求列表、燃尽图都是管理者了解项目进展的渠道。
也许Scrum团队需要为管理层提交其他的状态报告，但这些报告的制作必须有价值，同时不会占用团队很多精力。软件开发是马拉松，走的是一条艰难的路，管理者必须让团队轻装上路，不要在他们身上加任何不必要的包袱，因为背着沉重包袱是跑不快、跑不久的。管理者要尽量减少全员必须参加的、冗长的会议，不要求项目组定期收集一堆没人看的数据、提交冗长的项目状态报告，不在迭代过程中随意给团队追加新的任务。
管理者了解项目的状况不是为了监控团队，确定是否有人不尽力，而是为了帮助团队解决问题。在敏捷模式下，管理者从监控型变成了服务型，他们需要更加信任团队，能够有效地激励团队，为团队提供必要的物质和精神支持。
做好服务型的领导者要善于倾听，团队的声音让你知道团队能做多少以及成本代价、技术风险是什么，产品经理会告诉你客户要什么、什么最重要，Scrum的过程经理让你知道团队面临的困难是什么。并不是每个管理者都能成功地转型，有人统计在美国有20%的管理者在其企业推行敏捷后，由于无法适应新的管理模式而离职。
敏捷并不是不要管理，并不是反对项目管理。高效的敏捷团队会平衡好管理者和个人的关系，会平衡好自我管理和自我约束的关系，高效敏捷团队是灵活的，但不是无序的。
软件开发中的不确定因素要求Scrum团队不能是完美主义者，而应该是一群真正的软件工程师，因为工程师就是从复杂场景下找到解决办法的人。产品开发不确定性越大，越要求团队勇于实践，勇于探索，不怕犯错误，及时发现问题，及时调整。产品需求的不确定和技术的不确定意味着没有完美的解决方案，意味着团队需要在迭代中学习，不断完善。
为了实现迭代目标，团队需要在很短的时间内找出解决方案，并完成开发测试，在迭代结束时展示工作的软件。这就要求团队不要追求复杂的解决方案，而要尽量把复杂的问题简单化，简洁的解决方案是敏捷追求的目标。考虑一个简单的例子，某银行IT需要维护一个还要使用2年的软件产品，为实现某个功能我们需要判断当天是不是周末，因为如果是星期六或星期日，系统的处理方式和每周的其他5天不一样。你用什么样的算法来实现这个十分简单的判断呢？这个团队选择了万年历的算法，这个算法确实能解决问题，但它带来的设计、编程、测试的工作量相当大。既然这个产品只有2年寿命，为什么不用一个简单的实现方法呢？如把2年内的周末的日子做到一个表格里，一个简单的IF语句就能做这个判断。这个简单查询只实现了所需要的功能，而万年历则实现了许多现在不需要的功能。敏捷追求简洁，追求将复杂的事情简单化。越简单，开发成本、维护成本越低；越简单，沟通成本越低。
考虑两个今天需要做的决策选择：是用简单的方法实现功能、需要的话明天再修改，还是用复杂的、超前的方法来实现同样的功能，因为明天可能需要？敏捷的选择永远是前者，因为今天实现的额外复杂功能以后可能永远不会被使用。
不久前我为一家电信应用软件开发公司做了CMMI评估，其中一个评估项目的客户（甲方）是政府。我发现这个项目立项很早，但一直没有签合同，也就是说，公司承担着很大的商务风险。因为如果客户看到的东西不能让他们满意，那么客户就不会支付任何费用。我被告知公司有不少这种类型的项目。在评估中，我看到团队很认真地执行公司制定的过程，花了很大的精力做需求、设计、编码，做了各种技术评审、各种测试，而所有这些工作的目的就是为了能给客户（主要是几位政府官员）做些演示，得到他们认可，能够把合同签了，再立项开发出用户使用的系统。我在最后报告会上的建议让大家有些意外。我对这类项目的建议是：遵循“够了就好”（just enough）的原则，用最小的代价开发出可演示的功能，由于没有真正用户会使用开发出的软件，所以没必要做严格覆盖的测试，只要能清晰地向客户展示出系统特性即可，用最小的代价实现这类项目的目标。
我会在本章后面的章节中更多讨论敏捷实施中所需要的勇气，在这里我讲的是一个软件工程师在面对问题时应有的勇气。
哪怕是在迭代后期，如果发现设计架构有问题，也应该有勇气集中精力去修复它。
如果发现某段程序中存在很多问题，那么就扔掉它们，重新编写。
如果发现测试忽略了一个使用场景，那么就加上这个测试，修复可能发现的缺陷。
如果发现自己不能解决某一个问题，要有勇气不耻下问，寻求帮助。
由于敏捷的旅程充满不确定性，我们的方案可能有缺陷，这些勇气是敏捷团队必备的。如果你熟悉人工智能中的爬坡算法（hill-climbing）的话，那你就知道经典的局部最优（local optimum）问题。小的修改是解决不了这个问题的，要跳出这个问题的圈子，我们需要做大的改变，换一个思路，能做到这一点，这绝对需要工程师的勇气。
Scrum中的时间盒的实践在一定程度上也是鼓励团队追求简洁的解决方案，不要陷入没头没尾的所谓最佳方案的讨论。记得Nike广告里的一个口号吗？“Just do it!”在敏捷中我们再加4个字—“错了再改”。Scrum中的频繁反馈会让你很快就有纠错的机会。
在国内我常听到这样一种说法：敏捷是好，但我们开发人员能力不足，所以我们无法敏捷（这里的敏捷被当作动词用）。我不太赞成这个观点，因为敏捷并不是为技术精英设计的，如果你的团队在传统模式下能够开发出软件，那么他们就有能力敏捷。但我同意这样一种观点：没有自律，没有把团队能力提升作为敏捷迭代一个目标，我们无法打造一个高效敏捷团队，这也是自我管理的重要基础。
软件开发不是一件容易的事，按客户进度要求开发出高质量的软件更难。要做到这一点，开发人员必须严格使用团队制定的有效工程实践。比起传统的开发模式下的漫长周期和庞大团队，敏捷确实对人员素质、技能等方面要求更高。
Scrum团队必须是一个学习的团队，在工作中不断学习提升自己的能力是每一个团队成员的责任，用你的特长帮助你的伙伴也是你应尽的责任。只有你的团队真正开始实施Scrum后，你才能逐步真正理解它以及它的价值，在实践中学习（learning by doing）是掌握Scrum的唯一方法。当团队在一起攻克一个复杂问题，高效协作，学习调整时，你会慢慢体会到Scrum的妙处。
自律就是接受责任有担当，就是接受并遵循确定的开发架构，就是遵循团队定义的设计原则，就是遵循团队定义的编码规范，就是写出简洁的代码，就是不把质量作为一个牺牲品，就是遵循团队的行为规范，就是乐于让同伴检查自己的工作。这些不仅是贴在墙上的口号，而且是团队的日常实践。
自律也是让开发过程完全透明，每天都使自己的工作和团队其他成员的工作同步，让大家知道自己工作完成的情况：哪些已经完成，哪些还未完成，对代码做了哪些增加、哪些修改，这些增加和修改对其他代码的影响。团队成员工作之间的同步拉通不再是在项目后期才开始，而是每天需要坚持的实践，每天将新代码检入、构建、通过测试，保证每一天提交的代码都是干干净净的，一直保持到迭代结束。本章后面我会讨论极限编程实践和Scrum的结合及其对保证团队自律的作用。
有经验的敏捷实践者会意识到Scrum是一个能自我调整的系统，它不是一个具体的方法，不是一个过程或流程，而是一个能让一般团队自我管理、完善成为一个高效团队的框架。这个框架是由一些既独立又有关联的角色、活动和实践组成的，当然它也遵循敏捷价值及原则。
拿Scrum的3个角色为例，他们在每一个Scrum会议、Scrum文档的维护、Scrum实践中都会扮演独立的角色，但是每个角色又依赖其他两个角色才能更好地发挥作用。如果产品经理不能给出合理的产品需求列表中的优先级，那么团队每轮迭代做得再好，也很难为客户提供有价值的产品。如果团队不能给出可信的需求特性的成本估计，产品经理也很难平衡做好版本计划。如果Scrum过程经理不能有效协调产品经理和团队之间的沟通，那么我们很可能看到的是业务和开发的PK而不是紧密的合作。
Scrum的各类会议是为了确保团队内部必要的沟通，让大家关注同样的事，在工作中获得成就感。这些有效的会议使得产品需求列表的优先级、用户故事的细化、严格“完成”（Done）的标准、在清除障碍中持续的过程改进有了实实在在的意义。
图3-1展示了Scrum元素间的关联关系。
图3-1 Scrum元素间的关联关系
敏捷（Scrum）实践有极好的互补性，每一条都有自己的缺陷，敏捷的妙处是这些缺陷会被其他实践所弥补。正是这些相辅相成的实践，让我们能够实现敏捷带来的价值。
如果没有下列Scrum、极限编程等敏捷实践的支持，很难在一个短的周期（1～4周）开发出对客户有价值、可发布（满足质量要求）的软件。
有一个知道自己速率的、密切合作的跨职能团队。
通过每日例会实现同步开发并确保问题的及时解决，尽可能在识别出开发障碍后的24小时之内将其清除。
细化用户故事，让其颗粒度足够小，能够在一周内完成。
对迭代需求列表中的每一条需求都有明确严格的“完成”（Done）定义，让整个团队在迭代开始时就了解通过准则，并能长期控制带病迭代的问题。
让每日持续集成制度化，这样能够大大降低发布的工作量投入。
迭代中对团队工作的零干扰，让团队专注迭代目标的实现。
如果没有下列Scrum实践的支持，很难有一个真正做到自我管理的团队。
明确Scrum角色的职责，团队清楚自己应有的担当，并做出承诺。
迭代评审会对开发出的软件特性的反馈，使得团队能够及时调整产品方向，降低产品变更成本。
迭代回顾会议对开发过程的反馈，使得团队能够及时纠正问题及持续改进过程，降低所犯错误带来的成本。
每日例会让每个成员对团队负责，努力做好自己的工作，不拖整个团队的后腿。
由团队决定哪些需求任务放入迭代需求列表，由团队决定如何实现需求特性，相信他们会把工作做好，会在实践中提高能力。
如果没有下列Scrum实践的支持，很难让整个开发过程变得透明。
正确使用Scrum的3个文档（产品需求列表、迭代需求列表和燃尽图）可以让“猪”和“鸡”都能得到他们需要的重要信息。
设计管理好你的敏捷岛，用最简明的方式展示迭代、版本状态敏捷岛。
开好所有Scrum中的会议，让透明的过程服务于必要的审查和调整。
如果没有下列Scrum实践的支持，很难获取产品的反馈并做及时、合理的调整。
迭代结束时的评审会议是获取反馈的最好时机，对需求不明确的项目，这个会议可能是最重要的会议，不要仅仅走个过场。
产品需求列表的细化会议，是团队和产品经理形成默契、一起加深需求理解的重要活动，也是平衡产品需求价值和成本的好机会。
在整个开发过程中，团队可以随时和产品经理沟通，随时确认实现的需求特性。
如果没有下列Scrum实践的支持，很难获取对所用敏捷过程的反馈并做出及时调整。
迭代结束时的回顾会是获取反馈的好时机，对问题错误做根因分析，在下次迭代中改进调整。同时对本次迭代的优秀实践进行总结，固化可复用的实践。
在解决开发问题障碍的过程中，识别改进机会。让每一个严重问题都可能成为改进机会。
敏捷创造了让你的工程师从“I”型变成“T”型的平台，“T”型人才可以更好发挥过程的作用。
如果没有下列敏捷Scrum、极限编程等敏捷实践的支持，很难通过“完成”（Done）的标准把好出口关。
Scrum对技术卓越的追求是在增量开发中把好质量关的保障。
Scrum和极限编程的自然结合是解决带病迭代问题的良药。
敏捷和CMMI结合的探索也许可以是解决软件开发问题之匙。
如果没有下列Scrum实践的支持，很难保证可持续的开发节奏。
Scrum中时间盒的实践（固定的迭代周期，固定的会议时间等）创造了一个可预测的工作步调。
团队速率在计划中扮演着重要角色，也是形成团队开发节奏的重要保障。
Scrum中固定的例会、固定的工作环境、共同遵守的工程实践，都有助于开发节奏的形成。
Scrum对技术债务的管理要求，能防止团队只追求速度的错误倾向，有助于节奏的把控。
如果没有下列Scrum实践支持，很难通过最小代价实现最大的需求价值。
需求驱动开发，让团队和客户的沟通变得容易，双方的对话会关注需求价值及成本。
在整个开发周期，产品经理随时和团队沟通，随时根据最新的信息调整产品列表中的需求优先级，让团队优先实现价值最高的需求故事。
持续不断短周期的增量开发模式，通过不断演示需求特性，让利益相关人加深对产品需求的理解，识别真正能实现用户价值的功能。
持续不断迭代，让团队对产品不同需求的开发成本有更清晰的估算，使得需求特性的性价比变得更清楚。
如果没有下列Scrum实践的支持，很难维护好版本计划。
每次迭代后计算团队速率，让产品经理知道开发团队的能力—每次迭代能实现多少功能，这是让版本计划变得有意义的基础。
根据团队能力，调整版本计划，是保证计划准确的主要手段。
产品经理根据最新信息对产品需求列表进行维护，是确保在进度压力大的情况下，首先发布对用户最有价值的功能的保障。
坚持远粗近细的原则，让产品经理和团队高效完成版本计划工作。
如果没有下列Scrum实践的支持，很难让团队比较准确地计划每一次迭代。
赋予团队权力，让团队可以决定每次迭代完成哪些用户故事。
团队速率可以让团队根据自己的能力选择每次迭代完成多少用户故事。
产品需求列表的次序能够让团队选择完成优先级最高的用户故事。
需求细化会议让在极短的迭代周期中完成可发布的软件功能变得可行，这也是团队做迭代计划的基础。
如果没有下列Scrum、极限编程等敏捷实践的支持，就不可能有效地控制带病迭代。
敏捷对卓越技术的追求及明确的“完成”标准是控制带病迭代的关键。
持续集成等有效的工程实践也是迭代质量的保证。
迭代回顾会议让团队及时发现带来隐患的做法，并及时在后面的迭代中加以纠正。
燃尽图能让团队及时发现隐患对团队效率的影响。
团队的自律及相互负责的文化使得走技术捷径不是一件被鼓励的事。
尽可能完整地引入Scrum是让其价值最大化的保证，令人遗憾的是敏捷实践者往往忽略这一点。
目前业界最常见的敏捷是Scrum和极限编程（eXtreme Programming，XP）（Beck ，1999）实践的结合，从1995年起，极限编程和Scrum一起不断完善，成为最重要的、主流的敏捷方法。敏捷宣言及敏捷原则很大程度上是在这两个主要敏捷方法的基础上形成的。和Scrum的主要创立者一样，极限编程的提出者Kent Beck也是敏捷宣言的签名者之一。
极限编程在工程方面的实践很好地弥补了Scrum在这方面的空缺，共同的敏捷理念（小团队、短周期、强调反馈的价值等）又让Scrum框架可以很自然地支持XP的实践。
也许有些读者对为什么叫“极限”（extreme）感兴趣，原因很简单，其取意是如果某个实践好，那就将其做到极限。
如果做代码评审好，那就总做代码评审（结对编程）。
如果做测试好，那就让每开发人员都做（单元测试），也让客户做（功能测试）。
如果做设计好，那就让开发人员天天做（重构）。
如果简单的就是好，那我们就尽可能地选择简单的方法实现系统功能。
如果架构重要，那就让每个人时刻都了解完善架构（metaphor）。
如果集成测试重要，那我们每天都做几次测试和集成（持续集成）。
如果短的迭代好，那我们就让迭代变得极短：以秒、分钟、小时计，而不是以周、月、年（计划游戏）计。
在本章节里，我会介绍极限编程的核心价值理念、原则及实践，并探讨和Scrum的结合。
Scrum把如何实现软件的技术相关的事情留给团队自己来决定，它允许团队根据自身的项目特点或环境选择合适的技术实践。这样做也会带来一些风险：一些Scrum团队为了追求效率，会过多地选择技术捷径，只顾快速完成编码，能在迭代结束时将实现的功能演示出来变成了唯一“完成”（Done）的标准。这些团队会忽略一些必要的、经过验证的、见效周期较长的实践，而这些工程实践往往是系统级质量的保障。
片面追求技术捷径带来的恶果在前几个迭代中表现得不会十分明显，因为开发前期代码库还不是很大，新的功能还比较容易加进来。但随着迭代的累积，团队追求短期效率所借的技术债务会拖垮团队，借债长期不还会让你破产。“技术债务”可以看作是设计、开发不足的累积总和，技术债务的管理是决定敏捷成败的一个重要因素，带病迭代是敏捷的第一杀手。
如何能在短时间内开发出可发布的软件？如何能让代码库健康成长？如何降低已开发系统的变更（功能的追加、修改和删减）成本？极限编程给出了一套经过验证的实践，已成为敏捷实践中不可缺少的一部分，在很大程度上弥补了Scrum遗忘的技术角落。
在本书后面的章节中，我会从多方面讨论解决技术债务（带病迭代）的问题。
极限编程提出了4个核心价值，即沟通、简洁、反馈和勇气。
你的团队出现过下列问题吗？
一个程序员忘了告知团队其他成员他改动了一个关键设计。
开发人员没能问客户正确的问题。
管理人员没能问开发团队正确的问题。
谁报告坏消息，谁就要被处罚，结果是没人愿意报告坏消息了。
这些问题的后果想来大家都很清楚，好的沟通是不会让这些问题发生的，极限编程将沟通作为核心价值也是抓住了软件开发的一个关键问题。
这一点是很难做到的，因为人总喜欢容易把简单的事情复杂化，但很难把复杂的问题简单化。极限编程追求简单，宁肯今天用最简单的方法实现功能，也不自作聪明预测将来，用复杂的方法实现大而全的功能。它的选择是：如需要，将来再修改，坚决避免开发出没人使用的功能的情况。
简洁的价值是降低了变更成本，因为越简单，沟通成本越低；越简单，开发成本越低；越简单，维护成本越低。
我在前面多次讲了反馈的价值，极限编程将其发挥到了极致。
以分钟为单位的反馈：单元测试会实时对程序员所编程序给出反馈，这样他可以及时发现错误，找出原因，避免以后出同样的问题。
以天为单位的反馈：对客户提出的新的用户故事加以描述，开发团队给出自己的估算反馈，让客户了解自己需求描述的质量。每日例会的机制，团队对每个成员前一天的工作给出反馈，做到及时调整。
以周为单位的反馈：迭代后的系统功能测试能够对团队一次迭代的工作提供有价值的反馈，对所发现的缺陷进行植入分析，能帮助团队避免再犯同样的错误；同样，评审和迭代内测试的失效分析，能帮助团队提高评审及测试能力。每次迭代后，产品经理可以通过团队的速率的数据，来判断是否需要调整版本计划。
以月为单位的反馈：系统的部分功能上线后，用户使用带来的反馈可以让你完善后期需求，开发出对客户真正有价值的产品。在传统开发模式下，有一个常见的错误认识：系统一旦上线投入使用，你就无法做大的修改。极限编程让对上线后的系统进行修改变得容易。
勇气在敏捷中格外重要，当你放弃熟悉的东西，引入新的东西时，都需要勇气。敏捷的特点是摸着石头过河，当发现错了时，你必须具备进行纠正的勇气。如前面举的一些例子：在迭代后期，如果你发现架构的缺陷不足，你会怎么办？你必须敢于先放弃新功能的实现，集中精力修复架构的问题。当你发现一个程序模块存在大量问题时，你必须有勇气把它扔掉、重新编写。
有了其他3个价值的落地，极限编程中的勇气变得容易了许多，因为它们让变更成本变得可以接受。
从4个核心价值，Kent Beck（1999）提出了极限编程中5个基本原则及10个一般原则。4个核心价值定义了成功标准，15个原则让这些较为模糊的价值变得有血有肉，对照敏捷12原则会发现很多类似的追求。当然敏捷12原则的描述更加严谨，文字更加优美，而极限编程对原则的描述是简单而直截了当的。
我们先看一下极限编程的5个基本原则。
快速反馈（rapid feedback）：人在学习中，及时反馈会起到关键作用，如果我们的过程能为软件工程师的设计、开发、测试工作及时给出反馈，而不是拖到数周数月后，学习效果会有天地之别。
简洁第一（assume simplicity）：简洁就是简单干净，能简绝不繁是极限编程及敏捷一个重要原则，总是假设每一个问题都有一个简单的解决方案，不要为明天去设计、去开发，努力解决好今天的问题，相信自己明天有能力实现必要的复杂方案（如果需要的话）。这个原则是符合软件经济学的。
微量变更（incremental change）：也许你会将其翻译为“增量变更”，但我觉得微量比增量更能反映这个原则的核心理念，因为“小”是最想表达的意思。如果开发一个系统需要引入4个新技术，XP会建议你不要一下子全部引入，最好是分4次引入。微量变更体现在多个方面：设计一次变一点，计划一次变一点，团队一次变一点，Scrum和极限编程的导入也要一步一步地实施。
拥抱变更（embracing change）：在恰当的时间（just in time）能让团队集中精力解决手头最紧迫的问题，也能避免浪费。到需要时才决定，也会让团队有最多的信息，这时做的选择风险最小。敏捷不把变更当成负担，而把它看作是机会，整个极限编程的思路就是将变更成本降到最低。
质量至上（quality work）：Kent Beck认为项目开发的4个变量（需求范围、成本、进度和质量）中质量的自由度最小，具体来讲，质量只有两个可选值：卓越或超级卓越。极限编程的工程实践也充分体现了这一原则。
除了上述5个基本原则外，极限编程也提出了10条一般原则。
鼓励授人以渔（Teach learning）。
控制前期投入（Small initial investment）。
坚信战则能胜（Play to win）。
决策试验验证（Concrete experiments）。
坦诚沟通文化（Open, honest communication）。
做事尊重人性（Work with people’s instincts, not against them）。
敢于担当责任（Accepted responsibility）。
结合本地特点（Local adaptation）。
团队轻装上阵（Travel light）。
真实客观度量（Honest measurement）。
编码、测试、倾听、设计是极限编程提出的4个核心活动，之所以称其为核心活动是因为它们是软件开发不可缺少的活动：没有代码，我们什么都没有；没有测试，我们就不知道是否可以结束；没有倾听，我们就不知道如何编码、如何测试；而设计让我们能持续编码、持续测试和持续倾听。
关于编码：编码是任何一个软件系统的最真实的表示，代码是所有工程文档中唯一不会有假的东西，而其他文档如需求、设计等都有可能和当前的系统不一致。理论上讲，编码是软件工程中唯一必须做的核心活动。
关于测试：一个重要的测试秘诀是找到你能容忍的缺陷级别，例如，用户一个月抱怨一次是你可以接受的。找到这个标准后，依此建立你的测试体系，并且不断完善，直到测试过程能达到要求，然后把这个过程变成标准过程。从不同角度来看，测试分成两类：开发角度的测试和客户角度的测试。
关于倾听：项目开始时程序员很可能对要开发的内容一无所知，所以他们就要去问、去听，听了以后必须有反馈，而这些反馈是让业务人员或客户知道哪些难、哪些容易，也让他们更加理解相关的业务。
关于设计：设计是建立一个能将系统中的逻辑组织在一起的架构。好的设计有下列几个特征。
局部变化不会导致其他部分变动；
每个逻辑在系统里只在一个地方存在；
每个逻辑和它所操作的数据距离很近；
容许系统只在一个地方扩展。
坏的设计的特征则正好相反：
一处改则处处改；
逻辑在系统中被复制；
设计变更成本非常高；
新的功能的追加会打乱已有的功能。
团队需要有机制支持下面3件事。
做好的设计。
修复坏的设计。
让所有用到设计的人了解当前的设计。
我在国内企业做开发过程咨询时，常常碰到的一个问题是：如何建立所谓紧急项目流程？这类项目往往有刚性的需求范围和不合理的刚性的进度要求，如果按正常开发流程，团队根本无法按时提交。这类项目成了不少实施CMMI企业的头痛之处，在本章结尾的“两个团队的故事”部分，我会讲一个如何用极限编程核心活动建立紧急项目流程的故事。
极限编程的12条实践是Kent Beck根据自己及业界的开发经验总结出来的，这些实践，特别是其中的工程实践能够有效支持Scrum的实施。这里我们先简单介绍一下Kent Beck（1999）给的12条实践的定义。
计划活动（planning game）：快速依据业务价值及开发成本估算确定下次发布需求范围，随着迭代的滚动，计划会不断被调整，所以没有必要花很大精力制订初始计划。
小版本（small releases）：只要开发出对用户有价值的功能（哪怕是很简单的功能），就尽快上线让用户使用，然后不断频繁（1～4周）升级。
隐喻（metaphor）：用一个简单、公用的描述系统功能的故事指导所有开发工作。
简单设计（simple design）：用最简单的方法实现系统，一旦发现不需要的设计，立即将其清除。
测试（testing）：测试驱动开发。开发人员不断编写单元测试，只有通过了这些测试，开发才会继续进行。按客户要求编写展示系统特性的测试。
重构（refactoring）：在不改变系统功能前提下，开发人员不断地优化代码结构：清除重复代码，改善程序的可读性，简化程序的复杂度，让代码变得更灵活。
结对编程（pair programming）：所有程序都是由两个程序员在一台机器上编写出来的。
代码共享（collective ownership）：任何人都可以随时、随地修改系统中的代码。
持续集成（continuous integration）：每当完成一个新的任务时，就进行集成和构建，有可能每天要做多次集成构建。
不加班（40-hour week）：每周工作时间不超过40小时应该是正常的规则，不能允许团队连续加班两周。关于不加班，我这里想多讲几句。目前中国IT业的现状让这个实践变得很难落地，每天晚上7～8点钟时，华为办公楼还是灯火通明。为了赶进度，几乎所有软件工程师都有过持续加班的经历，这给个人及家庭生活带来不便。看过几期《非诚勿扰》，如果男嘉宾的职业是软件工程师，基本的结果都是最后遭遇全部灭灯。这个状况估计在相当长的时间里很难被改变，但我想从管理考核角度提一条建议：不要把加班多少作为主要的考核依据，考核决定行为，将其作为主要考核指标，会对提升工作效率有负面影响。同样的工作，一个人花6小时完成，另一个人花了12小时完成（加班4小时），作为管理者你觉得谁做得更好呢？
现场客户（on-site customer）：有一个真正的用户自始至终参与团队的开发，随时回答团队的问题。
编码标准（coding standard）：所有程序员都应遵循同样的编码规范要求完成所有开发。
和Scrum一样，极限编程的实践也是相辅相成的，它们所倡导的优秀实践，看似是一个个独立活动，实际上具有高度耦合度，不能独立执行，每一条实践的不足往往会被其他实践的强项所弥补。例如，如果没有编码标准，没有结对编程，那么代码共享的后果是不可预测的。没有重构作为重要保障，小版本的后果很可能是结构的混乱。在第6章里，我会更详细探讨4个核心极限编程实践在Scrum架构下的应用：简单设计、测试驱动开发、重构和持续集成。
Scrum实施中一个常见的问题是：在每轮所谓的开发迭代过程中，团队摆脱不了瀑布思维，还是遵循接力开发模式，即需求分析-设计-开发-测试-交付。当迭代周期只有一两周时，这种模式会导致没有足够时间完成必要的测试工作，不可能交付出可发布的软件。这种模式也会造成资源浪费，因为在每次迭代中，每一个角色不是一直都在忙，团队很难达到高效开发。
在这里我要明确一个观点：接力式的迭代（哪怕每次周期很短）不是敏捷，不是Scrum，还是传统开发模式。
而在敏捷（Scrum）的生命周期中，在某种程度上团队遵循“同时做所有工作”的模式，也就是说，开发人员同时在做需求开发、分析、设计、编码和测试。
在敏捷（Scrum）的生命周期中，在某种程度上团队遵循“同时做所有工作”的模式，也就是说，开发人员同时在做需求开发、分析、设计、编码和测试。如果你只有传统开发的经验，特别是如果你是传统开发模式下CMMI的忠实实践者，你会觉得这种想法很危险：如何保证需求、设计、编码和测试的一致性？如何保证质量？而另一方面，许多开发人员恐怕对这种模式不陌生，他们在巨大的进度压力下都这么做过，特别是一个开发人员同时负责设计开发工作时，他恐怕不愿意为自己单独做设计了。
如果没有过程支持，没有明确团队遵循的公共实践的支持，这种模式对开发人员能力要求会非常高。在这种模式下，要做到不以牺牲质量为代价的高效开发，团队需要有一个大家都理解的开发架构，这个架构能让团队成员清楚地了解到自己负责开发的模块和其他模块之间的关系；需要一个所有开发人员必须共同遵循的编码规范，这个规范要保证代码的持续优化；需要一个能随时验证代码变更正确性的持续集成环境，确保开发隐患的及时清除。
极限编程和Scrum的基本理念是相同的，并且高度互补。例如Scrum的迭代需要极限编程的持续集成、重构等的支持，才能保障维护产品的完整性及可靠性，是解决敏捷增量开发中带病迭代的有效方法。
Scrum的架构及实践也可以很自然地支持极限编程中的管理实践的落地，例如产品经理的角色在某种程度上可以替代现场客户代表，而产品经理在Scrum中的职责及产品需求列表的使用给出了客户代表发挥作用的方式。Scrum中的需求细化会议、迭代计划会议、迭代需求列表等活动及产出物可以有效地实现极限编程的计划活动，加上迭代评审会议及“完成”（Done）的要求，能有效支持极限编程的小版本实践也是自然的结果。Scrum倡导的团队自我管理及自律的要求能保证团队的代码共享及不加班文化。
正是由于极限编程和Scrum的高度互补，目前业界大部分的敏捷实践都是二者的结合，这也是我推荐的敏捷实施模式：Scrum+极限编程能够做到1+1>2。
引入敏捷意味着一场大的变革，其影响面经常会被低估，导致在做引入计划时考虑不周全，组织层面缺少必要的支持。当碰到大的问题时，管理者缺乏必要的勇气，往往会选择放弃部分或整个敏捷实践。
让我们首先从大的角度看看敏捷会带来哪些变化。
敏捷会改变我们定义度量业务目标的方式。
敏捷会改变我们的管理方式。
敏捷会改变我们的开发方式。
敏捷会改变我们的考核过程，考核项目团队、考核个人的方式。
敏捷会改变我们将变更风险最小化的方式。
敏捷会改变我们的思维方式。
丘吉尔讲过：“改进意味变革，追求完美就是不断变革。”但是变革需要勇气，任何时候让一个人放弃已经熟悉的做事方式，去尝试一个全新的方法都不是一件容易的事，那么改变一个组织的习惯则是难上加难。敏捷意味着随着大环境的变化不断调整变革，一个敏捷的企业意味着它必定勇于尝试，具备必要的勇气。
华为是一家令人敬佩的企业，通过和它十几年的接触，我认为它的成功不是偶然的。很多人羡慕的所谓华为的“狼文化”，在我看来它更是组织、团队、个人对新知识的渴望。华为是我看到的最有勇气的中国IT企业，它把变革当作学习的机会、超越竞争对手的机会、发展壮大的机会。以敏捷实施为例，华为是国内最早试点敏捷并将其纳入标准过程的企业。当年它成功导入了集成产品开发（intergrated product development，IPD）流程，但一直没有停止对其不断优化。业界新的优秀实践是华为改进的一个重要来源，敏捷的引入也不例外。一旦了解到敏捷可能带来的好处，华为毫不犹豫开始学习、试点并本地化。从2006年前后开始，华为开始了其敏捷之旅，他们请了许多敏捷领军人物来华为做过培训，经过几年的试点、尝试、总结，成功将敏捷融入其IPD流程中，并在2009年正式发布了“IPD+敏捷”新的产品开发流程。当华为开始纠正敏捷不足时，国内许多其他著名IT企业才刚刚开始了解敏捷，在小范围内做试点。
近年来，一些中国的IT企业也开始研究在丰田汽车公司生产方式基础上形成的精益生产模式，希望能将其应用于软件开发管理过程中。由于生产制造和软件开发的巨大差异，很少能看到成功实施案例。敏捷的逐步普及对中国IT企业实施精益方法带来了新的机会，企业层面精益思维能够有效支持项目级的Scrum实施。对精益生产管理感兴趣的读者，可以去看一些精益管理的书籍，找出其和敏捷相通的地方。
图3-2展示了精益组织和Scrum的关系，以及企业存在的目标、使命及价值是如何通过Scrum实现的。
图3-2 精益组织和Scrum的关系
引入敏捷对组织的管理者带来的冲击不比员工小，除了在本章节前面提到的从监控型到服务型的转变外，他们还肩负着更大的责任：领导组织的开发过程及管理实践从传统到敏捷的大转型，这个转型不仅是过程的变革，更重要的是人的转型。放弃熟悉并已使用多年的过程，引入新的过程一定有风险，领导者的勇气、智慧和决心是成功的关键因素之一。
成功引入敏捷需要领导者想清楚以下5件事。
为什么要做：引入敏捷的目的是什么？具体要解决什么问题？有了明确目标，你才能判定敏捷之旅是否成功。
必要的技能：分析完成这件工作所需技能，识别出技能的不足。面对这些不足，组织必须建立一个所需技能的获取计划，保证敏捷在组织内的顺利推动。需要提醒的是，技能不足的分析不仅仅需要在前期执行，而是应该在整个敏捷推动中持续关注，因为很多能力的不足只有在实施中才能更清楚地表现出来。
必要的动力：人的动力从哪里来？敏捷给出了清楚的答案：成就感、自我管理、清晰的目标。那么领导者如何能让执行者保持动力呢？如何和执行者的切身利益关联起来呢？华为有个说法：谁都喜欢雷锋、焦裕禄，机制上不能让他们吃亏。
必要的资源：引入敏捷需要什么样的投入？领导者在规划时就需要有个考虑。注意资源往往是个约束条件，它在很大程度上决定了引入敏捷的速率。
行动计划：哪些部门、团队、项目类型先试点？什么时候将敏捷在确定范围内制度化？在推动敏捷过程中，有哪些里程碑、检查点？我建议用敏捷的方式推广敏捷，但是建立维护组织级的敏捷推广计划是必不可少的，这个计划是监控的基础。
图3-3就是著名的成功变革管理的五要素及其某一要素缺失时的后果。
就敏捷变革而言，如果领导者没有充分沟通清楚变革的目的，那么不同角色的理解会发生混乱，有可能使力不往一处使。我的经验是，在全面引入敏捷之前，需要对职能部门、开发部门、所有的职能角色进行培训，让大家对新理念、影响等方面有一致的理解。
如果领导者不关注必要敏捷技能的获取，那么很可能引入的是形似神不似的敏捷。领导者的责任是提供必要的投入，保证相关人员获取实施推动敏捷所必备的技能。获取这些技能的方式很多，例如，引入松土培训，在试点、实施过程中引入敏捷教练，在内部建立沟通交流机制，让大家逐步掌握敏捷方法、实践和相关的工具。
如果领导者不把敏捷变革和利益相关人的切身利益结合在一起，那么这件事的优先级会很低，会减缓变革的步伐。如果敏捷让人人不安，会极大增加这个变革夭折的可能性。这一条是敏捷企业领导者最重要的管理工作之一。
图3-3 变革管理五要素
如果领导者不保证足够的投入，那么很难将敏捷带来的价值最大化。必要的投入包括办公环境的重新梳理，敏捷管理工具的引入，持续集成工具的引入，外部内部培训的投入等。由于前期的学习磨合成本，有可能一开始团队效率会有些下降，但随着时间推移，逐步会看到效果。图3-4是常见变革效果示意图，领导者需要智慧地看到整个画面，需要有勇气将敏捷变革坚持下去。
图3-4 有效变革效果图
如果领导者不要求建立维护一个清晰的敏捷推广计划，那么就无法监控推广过程，无法做问题影响分析，不知道还有多少事情要做，不清楚是否在按计划实施。用敏捷的计划方式来做这件事，是一个值得推荐的做法，因为敏捷之旅也一定充满了诸多不确定性，在某种程度上也需要摸着石头过河。
作为领导者，只有全面考虑了这5个环节时，才有可能领导一场有效的敏捷变革。
注意，敏捷环境下，管理者将不再会做下列工作：
替团队承诺什么时候完成多少工作；
说服团队这些承诺是可以做到的；
给团队指出具体开发思路、方向；
监控团队的进展情况，确保进度，确保没有大问题；
当团队碰到问题时，介入解决方案的制定及拍板；
每周听取团队进展状况报告，常常和成员做一对一的会议，发现问题并给团队提出具体指导；
用胡萝卜加大棒的方式，激励团队加班加点，完成工作；
给每个成员分配具体任务，并监督完成情况；
为团队在正确时间，用正确的方法，做正确的事负责任。
对工程人员来讲，在一个100人团队里面工作和在一个几个人的小团队里工作是完全不一样的。大的团队比小团队更容易混日子，因为人多时，经常会出现忙闲不一的情况，对个人来讲，压力会小很多。
而小团队里，每个人要做的事会更加透明，如果做得不好大家都会看到。想象一下，在每天的站立会议中，你总是不能完成自己的工作，总成为实现迭代目标的瓶颈，这个压力会是很大的。你需要极大的勇气，将压力变成动力，尽快提升自己的能力。就像滥竽充数的故事一样，独奏是要有真功夫的，独奏需要的勇气比合奏大得多。
在一家已实施CMMI或ISO 9000的企业推广敏捷时，你必须面对的一个问题是为EPG（组织过程改进委员会）重新定位。在敏捷环境下如何在组织层面推动过程改进活动？组织改进人员，组织质量保证人员的职责是什么？如何处理对自己工作定位的不确定性？这些都需要过程改进人员有面对新挑战的勇气。
敏捷更加强调的是自下而上的改进，更关注的是团队内部的改进，而不是组织层面的改进。这个敏捷的不足给过程改进人员带来了自己的机会，那就是如何在组织中借鉴共享团队中的优秀实践？如何让团队的迭代回顾会议在组织层面发挥作用？更重要的是如何在从瀑布模式到敏捷模式的转换中扮演重要的角色？
EPG必须是这场变革的组织推动者，在本书后面关于CMMI环境下的敏捷实施相关章节中，我会更加详细描述敏捷企业的过程改进活动的组织、管理。这里我列一些敏捷变革中，过程改进人员应该了解、关注、解决的问题。这些问题没有简单的解决办法，这些问题的解决需要EPG的智慧和勇气，过程改进人员需要有较高的情商，情商也许就是智慧和勇气的结合。
由于敏捷的引入会极大地改变人的做事方式，EPG必须意识到这个转变不可能是一朝一夕的事，需要给大家时间，同时需要在整个变革过程中给大家支持。人其实不反对变化，只要这些变化不需要他们自己去改变。过程改进人员需要让大家意识到敏捷带来的益处，这些益处有组织的、团队的、客户的，但千万不要忽略了其给个人带来的好处。
在整个变革过程中，EPG需要倾听大家的声音：
你们希望的变化是什么？
你们担心的是什么？
你们有什么好的建议让敏捷的变革成功？
这个沟通不是一次性的，必须是制度化的，让组织内部的敏捷实践者随时随地可以将他们的想法转达给EPG。
在沟通的过程中，大家对敏捷的愿景也要逐步形成一个清晰的共识，同时让大家了解为了达到最终目标，哪些东西必须变，哪些是实现目标必须走的步骤，每个人的工作会有哪些变化。EPG必须给出目标是否达到的明确度量，这些度量应该和企业的商业目标有直接或间接的关系。
在敏捷的变革中，EPG也必须将自己定位成服务型组织，也必须有勇气摒弃旧的工作模式，拥抱敏捷，用敏捷模式指导敏捷的引入。
根深蒂固的瀑布思维是敏捷化的最大天敌之一，在瀑布模式下很难想象在需求文档和设计文档还没有通过评审之前，开发团队就开始编码，更难想象允许在编码过程中追加或修改需求。同时瀑布模式的影响远远超出了开发团队，一个软件企业的组织架构，部门之间的沟通机制和客户及市场的沟通方式，人员招聘及员工的职业规划等都会不同程度上受瀑布模式的影响。从瀑布模式到敏捷模式的转变，不仅仅是开发过程的改变，在很大层面上更是企业文化及习惯的改变，后者的变更比前者更难。
在瀑布开发模式下，设计人员会向设计经理汇报，编程人员向开发经理汇报，测试人员向测试经理汇报，这种组织结构可以支持瀑布接力开发但对敏捷-Scrum的新模式会有负面影响。任何一个企业都不会轻易改变其组织架构，因为这些变化会冲击一些人的利益。但是将矩阵结构转换成产品线为主的跨职能结构很可能是你要做的一个转化。
在从瀑布模式到敏捷模式的转化中，近20%的员工（包括管理人员）可能会选择离职，因为不是每个人都可以接受敏捷的工作模式。
另一个主要组织变化是开发团队是其开发产品质量的责任人，而不是质量管理部。质量控制活动必须贯穿每一个迭代，质量部的人员结构及定位不可避免地会发生变化。
产品管理的职责定位会发生很大的变化，比以前要求更高。选择谁来做Scrum团队中的产品经理，将在很大程度上决定项目的成败。产品经理将会承担很多传统项目经理的责任，管理好风险，确保每个迭代都能开发出最大价值的软件功能是他要做的事情。高层管理人员会向他了解项目的状况。敏捷企业的PMO（项目管理办公室）需要重新定位或被取消。
从瀑布模式到敏捷模式会让其他一些工作消失，做这些工作的员工将被迫走上新的岗位，如项目经理很有可能变成Scrum过程经理，而一些职能经理的管理职能在敏捷环境下将不复存在，这些经理也将面临职业生涯发展的新挑战。他们也许会变成过程经理或产品经理。
敏捷的奖金机制也会发生变化，Scrum不鼓励个人英雄行为，而鼓励的是团队英雄行为。奖金的分发会更大程度上基于团队的表现，如果一个团队有优异表现，那就请奖励团队的每一个成员。一荣俱荣，一损俱损。
一个敏捷团队很难在一个没有敏捷文化的企业里成功，因为敏捷是一个端到端贯穿整个企业的行为。那么什么是敏捷文化？如何从瀑布习惯转换成敏捷文化？我认为下面是一些必要的文化变革。
建立价值文化：从进度、技术驱动决策转换成价值驱动。在做任何一个决策时，决策者一定要养成这样一个习惯：同时考虑成本及收益，而不是怎么方便怎么做。这就要求决策者扩大自己的视野，学会从全局看问题，学会平衡短、中、长期利益。敏捷宣言就是价值宣言，价值决策文化必须成为每个大小管理者的思维习惯。
真正建立的团队精神：从推崇个人英雄转换成推崇团队英雄，敏捷追求的核心目标之一是发挥出团队的潜力，在开发中提升团队的能力。“成也团队，败也团队”的文化应该渗透到每个成员的行动上。
“Just do it！”的精神：从追求完美的工程文化转换成关注问题的解决，从追求完满的产品转换为尽快提交为客户带来新价值的产品特性。Just do it!
全员质量文化：很多瀑布模式下的企业把质量仅仅当成测试部门的事，这种文化往往造成开发和测试变成PK的关系。敏捷转型意味着质量是所有人的责任，防止带病迭代是所有工程活动必须关注的事。质量不仅仅是通过测试，质量更是一种意识，一种在开发过程中减少隐患、维护使用的意识。
善始善终的文化：为了追求“效率”，不让员工有任何可能的闲置情况，很多企业会尽量启动很多项目，会让员工同时参与多个项目的工作，善始而不能善终是这种文化常见的后果。敏捷转型更会推崇善始善终的文化，启动一件事就专注地把它做好，尽量避免一个人同时做多件不相干事情的情况。
分而治之的文化：瀑布模式鼓励追求大而全的产品，由此带来追求全面完美的习惯，敏捷则鼓励分而治之，尽量将一个大的复杂工作项分成多个小的、简单的工作项，一个一个地完成。从追求完美转换到追求简单是敏捷带来的另一个变化。
勇于实践、创新的文化：瀑布模式带来高昂的变更成本，使得团队在开发过程中努力第一次把事情做好，不犯错误。而敏捷带来的快速反馈，让变更成本变得可以接受。鼓励团队勇于实践、勇于创新是敏捷转型中的另一变化。
开发过程的改变是瀑布模式到敏捷模式最显著的变化，是所有人都能看到的变化。从瀑布模式到敏捷模式，开发过程不是简单的简化，而是多层次、多方面的改变。
过程改进管理的变化：在敏捷模式下，“过程的执行者是过程改进的主人”，这句话变得更加实实在在了。过程改进的主要执行者是Scrum团队自己，每轮迭代最后一个活动就是对执行敏捷过程中的问题进行根因分析，找出改进实践，完善团队的Scrum过程实践。这些改进的落地是实时的，因为它们可以在紧接着的迭代中得到实施。这些新的变化大大完善了CMMI框架下的过程管理改进。
过程架构的变化：引入敏捷后，组织内的项目类型会更加丰富：可能有遵循传统开发模式的项目，有遵循敏捷方式的项目，有可能也有遵循二者结合的项目。所谓过程架构在某种意义就是项目开发流程的全景视图，当然站在不同角色的角度，这个视图会不一样。过程架构于心，我们才能清楚了解不同子过程、方法、实践、过程产出物等之间的关系。
方法实践的变化：敏捷的引入会改变很多管理、工程和支持活动的方法及实践。如项目估算方法会有很大的变化，技术评审方法、配置管理方法等都会有很大的变化。我们需要在组织层面形成敏捷模式下这些方法实践的新定义。注意这些变化很有可能对相关联的子过程及产出物也有影响，任何过程变更不能损害过程的一致性。
工具的变化：瀑布环境下的管理方式是任务驱动，而敏捷则是需求特性驱动，这个转换会要求团队替换旧的工具，引入敏捷管理工具。其他必要的工具引入也是敏捷转型中必要的投入，如持续集成工具等。
在从瀑布模式到敏捷模式的转换过程中，需要对原有的过程体系做一个全面的梳理，识别出需要追加的新内容，需要更改的内容，以及需要淘汰的内容。规划好过程的变更，不要妄图一口吃成个胖子，一步一步完成这个转换即可。导入Scrum最好的方式就是用类似Scrum的方法，通过持续迭代，不断收集反馈，逐步完善，完成从瀑布模式到敏捷模式的成功转换。
故事1：紧急项目的故事——让过程合理合法
几年前，我帮助一家国内国有IT企业做过程优化，虽然这家企业已经通过了CMMI四级评估，但公司领导认为开发过程还是不能有效支持组织的业务目标及客户的期望。在和项目经理访谈时，我问了一个问题：“如果给你一个绝对权力，允许你更改组织过程中的任何一块内容，你会改什么？”参加访谈的项目经理异口同声地提到了所谓紧急项目管理流程的问题：所谓紧急项目，是一些进度压力大的项目，这类项目往往带有一定的政治任务，有刚性的进度要求，如果按组织定义的标准过程来管理它们的话，一般是无法按时完成的。由于组织要求所有开发项目都必须遵循四级体系的要求，这就造成了这类项目的管理困境，如果完全按过程要求做，就不能满足进度目标，所以团队往往会在执行过程中走很多捷径。这也让PPQA（Product and Process Quality Assurance，过程与产品质量保证）人员很为难，因为他们知道，如果按过程检查单做稽核，识别出许多不符合项的话，由于进度压力，项目组也很难对这些不符合项进行整改，最后大家只好睁只眼闭只眼。我把这种现象称为“合理不合法”，合理说的是项目组被逼做出必要的裁剪（不一定是合适的），不合法讲的是实际的过程是不符合组织过程要求的。
紧急项目的问题显然是一个优先级高、必须尽快解决的问题，因为它直接影响了项目质量、效率，对项目开发团队认可过程改进、CMMI有很大的负面影响。我们决定将其列为当年的一个改进专题。首先我和开发部领导、项目经理以及分管需求及生产任务的职能部门领导一起，讨论确定界定紧急项目的标准：究竟什么样的项目可以认为是紧急项目？我们定义了下列4项界定标准。
（1）工期短：项目开发周期从项目组接收到开发指令至提交UAT（用户验收测试）版本的时间要求，原则上在两个自然月（含）以内。
（2）刚性的外部时间要求：在确保特定的质量要求下，系统能否在规定时间内按时上线对组织的声誉、市场、战略等有较大的影响。
（3）范围确定：需求范围是确定的，没有缩减的余地。
（4）任务量与工期不匹配：特定资源下工作量大，若按正常流程，很难在指定工期内完成任务。
在和组织的核心管理、工程人员讨论建立紧急项目实施指南时，我问了大家两个问题。
问题1：在你们的组织中，哪些工程活动是必不可少的活动？哪些是锦上添花的活动？哪些仅仅是为了符合CMMI、ISO 9000等过程标准的？
问题2：哪些是必不可少的管理活动？哪些是必不可少的文档？哪些是必不可少的度量项？哪些归档可以在结项后完成？
针对第一个问题，大家讨论后给出了下列不可少的核心工程活动及原因。
需求澄清评审：没有需求评审和澄清，开发人员无法真正理解要开发的系统，就不知道要做什么。
总体设计：好的总体设计可以给所有开发人员一个公共架构，减少沟通及潜在返工成本。
编码：没有代码就没有软件产品。
测试：测试让开发团队了解什么时候开发可以结束。
当我告诉大家，这4个活动也是业界敏捷领军人物识别出来的核心活动时，他们都非常开心。我接着问了一个新问题：我们如何做这4件事，才能做得好、做得快？这个问题也引出了热烈讨论，但是没有达成明显的共识。他们问我业界有没有一些可借鉴的东西，我花了半天时间给大家介绍了极限编程的价值、核心理念以及相关实践。我向他们推荐了Kent Beck的极限编程的书，建议他们结合实际认真看看其中的12条实践，研究一下其中的例子，一周后我们再讨论紧急项目的工程过程。
他们当天在网上买了这本书，后来很多人告诉我，他们一口气读完了这本书，并结合紧急项目特点边读边做笔记。除了结对编程及不加班，我们全部或部分引入了其他所有的极限编程实践，在此基础上形成了紧急项目工程及管理流程。
在讨论第二个问题时，我引导大家摒弃任务驱动的管理模式，采用需求驱动的管理模式，简化管理计划、跟踪活动，简化管理文档。在此基础上，我们很快形成了紧急项目管理指南初稿。经过6个项目的试点，这个指南变成了体系的一部分。让所有人高兴的是：这6个项目的生产效率大大高于组织级效率基线，同时
这6个项目的遗留缺陷率也都低于组织级的平均基线。
在年底总结时，公司领导问我：我们为什么不将这种做法推广到其他项目呢？
故事2：用Scrum的方式引入Scrum
这个故事描述了一家软件企业第一年的敏捷之旅。
KS是中国南方一家知名软件公司，它在6年前第一次通过CMMI三级评估，并在3年前通过复评。KS产品开发过程一致遵循瀑布模式，两年前管理层决定在公司内部引入Scrum为主的敏捷方法。KS的CEO李总在和一些美国IT企业合作过程中，看到了敏捷带来的好处，他在美国期间参加了Scrum过程经理及Scrum产品经理的培训，研究了许多敏捷书籍，特别是Scrum创始人写的一些关于导入Scrum的书。参考一些成功转型的敏捷企业，李总决定用Scrum的方式引入Scrum。
李总做的第一件事，是在公司层面成立了敏捷转型Scrum团队，他亲自做这个团队的产品经理，直接管理推广Scrum过程中的任务项，指导团队攻克下一个价值最高的任务。一位有经验并且有成功敏捷经历的敏捷教练被李总聘请为这个团队的Scrum过程经理，指导公司的敏捷之旅。几位公司副总、开发部门及职能部门（包括人力资源、财务、市场销售、行政等部门）的经理成了团队的其他成员。
敏捷转型需求列表对应的产品是一个敏捷化的组织，其产品开发过程由瀑布模式转换成敏捷模式。列表中的需求项来自转型团队及Scrum开发团队在实施Scrum中碰到的困难障碍及重要的任务。
敏捷转型团队将迭代周期定为4周，在迭代计划会上，需求列表中优先级高的任务项被选中，团队会选择建立执行团队来清除敏捷转型中遇到的障碍，完成任务项。在每天的例会中，转型Scrum团队为执行团队提供支持、指导。正在实施Scrum的开发团队的过程经理也会在会上提出团队碰到的、需要公司领导帮助解决的问题。
在迭代评审会议上，大家会展示各部门在上个月（本轮迭代）敏捷转型带来的变化，并调整需求列表中的任务项；而在迭代回顾会上，执行团队会分享好的实践及教训。
经过一段时间的准备，李总主持召开了由转型团队成员及其他高层管理人员参加的敏捷启动会议。参考Ken Schwaber（2004）建议，会议在3小时的时间内完成了下列议题。
就公司敏捷转型的目的形成清晰的文字表述，它们将成为转型所做决策的依据。
过程经理（敏捷教练）给大家介绍了敏捷团队将要遵循的Scrum过程，让大家对新的过程有个基本了解，并解释了一些大家后面会经常听到的新的敏捷术语。
审定敏捷实施团队成员及转型团队将要遵循的Scrum工作方法，以及如何识别敏捷推动中的问题。
讨论敏捷可能带来的各种变化及影响。
对下列具体事宜做出决定：
转型团队第一次迭代计划的日期；
正式确定敏捷教练为转型Scrum团队的过程经理；
正式确定李总为团队的产品经理；
正式确定团队成员。
确定了下列任务项作为产品需求列表中的初始内容：
所有转型团队成员完成Scrum联盟的ScrumMaster证书培训；
研究并建立跟踪组织内部变化的方法及机制；
确定敏捷试点范围：项目类型、试点项目项目团队；
确定试点Scrum团队角色；
确定试点范围完成准备要求的标准；
制订并执行组织的敏捷实施沟通计划，通过各种会议，面对面地让所有人了解敏捷转型可能带来的变化；
在公司内部网建立并维护“敏捷之角”，让所有人了解转型过程；
调整公司内部过程改进反馈处理机制，确保任何人在任何时间、任何地点都可以提出针对敏捷实施的反馈及建议；
制定组织转型需求列表追加机制，确保相关人员都可以将需要克服的困难加入列表中；
调整度量体系，建立跟踪Scrum项目的度量项和使用指南；
建立针对Scrum项目的汇报沟通机制。
启动会结束几天后，转型团队召开了第一次迭代计划会议，根据需求列表的内容及优先级，确定了下列迭代需求列表。
在全公司范围内宣贯敏捷转型的目的、推动计划以及对组织和个人的影响。
全员Scrum培训让大家了解引入敏捷的理由、Scrum过程及对个人的期望。
通过“敏捷之角”回答大家提出的任何问题。
确定下列实施Scrum的先决条件：建立一个全职跨职能团队；Scrum过程经理接受Scrum过程经理培训；产品经理接受产品经理培训；所有团队成员接受Scrum团队成员培训；建立一个能支持Scrum活动的办公环境。
建立敏捷项目汇报机制及渠道。
选择第一批敏捷试点项目。
选择这些项目的Scrum过程经理、产品经理和团队。
建立Scrum度量及其收集使用机制。
开始建立维护敏捷转型产品需求列表。
评估支持敏捷模式开发的考核办法。
敏捷实施执行团队具体执行迭代列表中所列任务，在实施过程中将识别出的困难障碍不断纳入需求列表中。这样第一轮迭代开始，也意味着敏捷转型在KS公司逐步推开。
从第二个月开始，更多的项目开始使用Scrum，转型团队面临的第一个问题是：是否一定要等一切都准备完美了，才能开始敏捷之旅？是否可以一边实施Scrum，一边解决这些问题？转型团队决定只要前提条件基本满足，项目就可以遵循Scrum开发模式。因为敏捷之旅本来就充满不确定性，用Scrum方法来指导Scrum实施是最好的保障。
新的任务项不断加到转型需求列表中，它们主要来自Scrum开发团队、转型团队和敏捷执行团队在实施中碰到的困难。产品经理李总将问题分成两类：一类是Scrum带来的问题，而另一类是原来就有现在被Scrum凸显的问题，识别出的大部分障碍都属于第二类。
前几个月中，主要问题集中在以下几个方面。
瀑布习惯是敏捷转型的普遍问题，这不光体现在开发团队本身需要基本摆脱文档沟通、接力开发模式，其他利益相关人也需要适应敏捷模式。以往客户的参与主要集中在一头一尾，而敏捷的增量开发需要他们自始至终地介入。特别是政府客户，往往不习惯这种模式。人力资源部在做岗位设置、为员工做职业规划时，也是按瀑布模式来做的。转型团队发现观念的改变十分困难。
执行团队缺乏必要的权力及技能推动敏捷转型。有些执行团队成员会将自己应该负责的工作布置给下属去做，没有尽到应尽的责任，在许多配合上不到位，难以达到Scrum的目的。
所有的Scrum项目都在实施不全的Scrum，它们在不同程度上绕过了一些有难度的Scrum实践，实施过程遇到困难时有停滞不前的情况。
CMMI和敏捷结合带来的问题，如EPG（过程改进委员会）在转型中的定位、QA（质量保证）人员的定位等。
Scrum本地化的问题。一个简单的例子是如何将Scrum术语本地化，大部分转型团队成员建议用大家熟悉的叫法替代Scrum术语。但敏捷教练（转型团队过程经理）则建议为了显示敏捷转型的决心，还是尽量用Scrum中的术语，而且这些术语量也是非常有限的。例如，如果还用项目经理替代Scrum过程经理的话，会给这个角色以他还拥有传统项目经理的责和权的错觉。
真正的透明需要有敢讲真话的环境，敏捷依赖于完全透明，在敏捷转型前期，很多项目团队还没有完全讲真话的安全感。
在同一时间段想变革的东西太多，急功近利，欲速则不达。有些管理人员希望能“立竿见影”，短期内就“大见成效”，导致没有找到好的切入点。以最容易做到、最明显的改善成果来让每一个人都感受到Scrum的好处，从此改变意识，建立信心。
在第一年里，敏捷转型团队在摸索中完善，边做边总结，一轮一轮地迭代，李总要求碰到问题时要集思广益，准备多个解决方案；打开心胸，吸取不同意见，不要解释不能做的理由，要想出做下去的办法；不要等到十全十美，有5成把握就可以动手，错了就及时调整。随着时间的推移，KS公司中越来越多的项目引入敏捷模式，其带来的价值也逐步体现。我问李总最大的感受是什么，他说：“企业文化、习惯比任何策略都更加重要，敏捷转型更多的是企业文化的转型。”
第4章 布好自己的局——确定Scrum中的角色、文档和活动
第5章 迭代管理亦有道——执行Scrum项目管理
第6章 把握好敏捷的度——敏捷工程及质量控制实践
