详情
本书以一家金融公司的IT部门的敏捷转型为背景，详细介绍了转型前IT部门目前面临的问题、转型过程中碰到的各种问题以及为解决问题试过的多种方法和每种方法的优缺点。本书共有14章，以小说的形式讲解了盛远金融公司的敏捷转型行动以及将敏捷应用于某个大型项目的实施过程。本书的内容主要包括敏捷开发（Scrum、极限编程）、精益方法（看板方法）、CI/CD流水线、基于Trunk的开发微服务等。
书名：猎豹行动：硝烟中的敏捷转型之旅
ISBN：978-7-115-49154-1
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
著 刘 华
责任编辑 武晓燕
人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
读者服务热线：(010)81055410
反盗版热线：(010)81055315
本书以小说体的方式引导读者经历一场虚拟的体验式学习。本书以一家金融公司——盛远金融公司的IT部门的敏捷转型为背景，详细介绍了转型前IT部门面临的问题、转型过程中遇到的各种障碍，以及为解决问题而尝试过的多种方法和每种方法的优缺点。
本书共有14章，每章的结束部分会列出本章的主要知识点。本书的内容主要包括敏捷开发（Scrum、极限编程）、精益方法（看板方法）、CI/CD流水线、基于Trunk的开发、微服务等。
本书风格独特，轻松易读，非常适合对敏捷模式感兴趣但尚未实践的读者阅读学习，也适合已经有一定经验的实践者作为参考。
Kenneth（刘华）和我相识于一家跨国银行的敏捷与DevOps组织转型之旅，这个转型的过程就是我们常说的“让大象跳舞”，当然此中的酸甜苦辣只有亲身经历者才能体会。随着敏捷开发的普及，越来越多的组织开始出来分享自己的转型经验。Kenneth从一个转型过程中的行动派，到本书故事的讲述者，为我们演绎了一个复杂组织鲜活的转型历程。
正如Kenneth在序中所写到的，《目标》和《凤凰项目》这样脱胎于现实的故事更能给读者代入式的体验，让我们能够突破文字表达的局限，场景化地去体会企业面临的市场挑战和转型过程中的矛盾冲突。在这个数字化时代，企业的敏捷与DevOps转型毫无疑问也有着类似的过程。有幸这种讲故事的方法被Kenneth所采用，带给我们更加场景化的阅读体验，帮助正在转型过程中挣扎的读者找到共鸣和激励，也让准备启动转型的读者寻到经验和信心。
本书的结构由此也不同于很多的理论和实践书籍，更像是敏捷圈子里的一部经典“剧本”，按照时序一幕幕展开，读起来让人饶有兴趣，时而因为找到共同点而会心一笑，时而又为组织壁垒的阻隔唉声一叹。如果你是一位转型推动者，你会在故事中看到自己的影子；如果你是一位敏捷和DevOps的实践者，你会从故事中体会到更宏观的组织视角。
故事是生动的，但敏捷和DevOps的实践需要在转型过程中刻意练习，持续学习必不可少。Kenneth在故事中穿插了相关知识点的提炼和总结，从敏捷需求管理到团队迭代运作，再到CI/CD技术实践、微服务改造等。这样的描述方式为很多学习敏捷和DevOps实践的读者提供了实战案例，让读者从实际问题出发来理解敏捷经典实践（如Scrum、Kanban）的一些正确运用。
大型企业的敏捷转型都会遇到方法、框架的挑战。由于敏捷和DevOps本质是抽象和提炼出的现代软件开发指导原则，在落地到具体行业和具体企业的时候，就需要进行适应性的实践框架的打造。这里没有捷径可循，也不应该有一个所谓敏捷开发统一框架，因为软件本身的价值在于使能业务、激活创新，而每家企业的业务都有差异性，每个组织的文化都是不同的。从这点出发，我们更希望看到类似本书中有血有肉的企业转型故事，让读者能够从故事中得到启发。
最后希望大家能够和我一样在轻松的心境下愉快地阅读这本“故事书”，不妨也拿起笔在Kenneth的故事中标注出自己的相似经历和体会，看看书中针对各阶段问题和挑战的分析及应对是否跟自己的思考相仿。在这样的碰撞中，我相信大家会和我一样学到不少新的知识点！
肖然
ThoughtWorks咨询总监，敏捷精益专家
2018年7月16日
前几日，本书的作者Kenneth找到我说他写了一本书，希望我能给这本书作序。说实话，写这段文字的时候我和作者还没有见过面。我们是通过一段有关“粒度”的话题而认识的；相信读完本书的读者应该会明白我们所指的“粒度”是什么。读完整本书我只用了不到2天的时间，又一次创下了我读书的记录，上一本是《凤凰项目》，我用了5天时间。
作为一名软件工程顾问，在过去的十多年中我接触到各个不同行业、不同类型的软件研发团队不下百个。对于团队转型中的各种成功与失败、坚持与妥协、理想和失望感触颇深。在这本书中，我找到了这些似曾相识的场景，看到了一个个熟悉的身影。如果你也是软件行业的一位从业者，我相信你也可以在这本书中找到你的那些领导、客户、同行、同事，甚至你自己。
敏捷转型和DevOps实施从来都不是一帆风顺的，特别在大型组织中，这就如同一场没有硝烟的战争，看似风平浪静，实则风起云涌。每个部门和个体都有自己的利益，要打破已经稳固的利益链条，就必然引起各方面的矛盾和冲突，这就是变革的本质所在，也是大多数组织无法推进变革的原因。这就如同一个长久不进行体育锻炼的人突然间开始跑步，每天10km下来肌肉酸痛是不可避免的；而这种“痛”恰恰代表你的机体正在改变。如果锻炼结束后没有任何“痛”的感觉，那只能说明强度不够，没有触及该触及的那部分。在一个大型组织中，敏捷就如同大脑中产生的“我要健康”的意念，而Scrum、Kanban、极限编程、持续集成、自动化测试等就是你每天的10km。如果把DevOps看作企业效能的驱动力，那它就是你的肌肉。组织变革困难就和体育锻炼无法被坚持是一个道理，第一是因为必须触发“痛点”，组织的痛点都是和利益相关的，和利益相关的痛都是真的痛；第二是因为枯燥而难以坚持，不能持续10天以上的跑步不可能有任何的改进，Scrum的迭代不坚持5个以上也不可能有任何的成效。这个过程枯燥而无味，它就是一遍一遍地重复同样的动作，但最终却可以锻炼出组织的那份肌肉记忆……这就是本书中所提到的“迈向常态”。
本书与《凤凰项目》颇有几分神似，同时也具备自己的味道。如果你正在寻求敏捷转型和DevOps实施的最佳路径，本书将为你提供非常具有实用价值的信息。本书对于敏捷和DevOps的很多基础实践进行了非常明确的说明，同时也对落地这些实践过程中可能遇到各种障碍进行了故事化的描写。我觉得这些描写虽然可能经过了作者的艺术化处理，但却非常有参考价值。我在所参与的每一次会议和交流上都会讲述很多自己帮助过的客户的过往经验，听者也都会觉得非常过瘾，但最后也都发现这些他们求知若渴的经验都是别人家的。而随着这些年讲述了越来越多的案例，我从更多地讲述成功开始转为更多地讲述失败，因为我发现那些失败的例子更有参考价值，我们真正要学习的是怎样少走人家的弯路，而不是与别人到达同一个顶峰。
希望大家都能和我一样在本书中找到共鸣。我们不必纠结故事本身的真实与否，因为即便是真实案例，那也不是“你家的孩子”。经验对于没有经验的人来说毫无价值！
宝剑已经交予你，而江湖本来就是你的。
徐磊
LEANSOFT 首席架构师
2018年7月7日于北京
当出版社的编辑问我是否有兴趣写一本敏捷方面的书时，我既兴奋又忐忑。兴奋的是能出版一本书，当然是人生中功成名就的一件大事；忐忑的是这将是一项浩大的工程，对于像我这样的上班族来说，时间是一个挑战。幸好过去有写短篇小说的经历，书的架构还是很快就出来了。把提纲和样章交给了编辑，本书获得了立项。
本书受《目标》1《凤凰项目》2的启发，以小说体的形式，讲述了一家公司的IT部门的敏捷与DevOps转型过程，同时涵盖了敏捷与DevOps的大部分知识点，适合对敏捷没有了解，有一定了解但没有实战经验，以及有一定实战经验的各类读者阅读。本书采用小说体的形式是为了提升阅读体验，这是我在阅读《目标》和《凤凰项目》时得到的启发，也希望这种形式能使内容更贴近现实，避免干涩。
1 作者：Eliyahu Goldratt、Jeff Cox，译者：齐若兰，出版社：电子工业出版社。
2 作者：Gene Kim、Kevin Behr、George Spafford，译者：成小留，出版社：人民邮电出版社。
在软件开发行业中，虽然敏捷、精益和DevOps已经不是什么新鲜词汇，但是转型依然困难重重。在《精益企业》3的译者序中有以下这段“控诉”：
3 作者：Jez Humble、Joanne Molesky、Barry，译者：姚安峰，出版社：人民邮电出版社。
“在这个行业做开发、管理和咨询这么多年，有一种深深的失望。软件本可以是优美的，做软件的过程本可以是充满创造性、充满乐趣的，然而目之所及，大多数管理者深受建筑行业、制造行业生产过程的传统管理模式（即泰勒主义4管理模式）影响，生生将软件开发变成了一个艰苦而无趣的工作。殊不知（或知道，但视而不见）现代软件开发与传统的建筑、制造行业的生产过程有着本质区别。”
4 英文为TAYLORISM，又称为泰罗制、泰罗主义或泰勒制。Taylor认为企业管理的根本目的在于提高劳动生产率，他在Principles of Scientific Management一书中说过：“科学管理如同节省劳动的机器一样，其目的在于提高每一单位劳动的产量。”而提高劳动生产率的目的是增加企业的利润或实现利润最大化的目标。在工业时代它曾发挥过重要作用。
我非常认同这段话，这也是我想出版本书的理由之一。
敏捷转型就像一场艰苦卓绝的革命，需要一代又一代人前仆后继，让这个行业回归它应有的模样。我愿意一直投身其中。
我的工作涉及软件交付和维护、团队建设和管理、敏捷落地与组织转型等方面。多年前，一次偶然的机会，我接触到了敏捷开发，其理念和价值对我的影响远远超出了软件开发的范畴，可以说是刷新了我以往的工作理念，也深深影响着我的管理思路。近年来逐渐流行的“敏捷企业”“精益企业”的概念，也证明了敏捷思想影响之深远。我们正处在一个快速变化的时代，如何适应这种快速变化和高度的不确定性，是值得每一个人思考的问题。敏捷正是在这个大的时代背景下应运而生，相信在不久的将来，它将成为一种常态。因此，敏捷思想可以说是今后每一个人的基本技能。
本书的内容涵盖了以下知识点，知识点的内容以楷体印刷：
敏捷开发——Scrum、极限编程；
精益方法——看板方法；
DevOps——特性团队、CI/CD流水线、基于主干的开发；
微服务；
关键链。
从故事内容上，您可能也会发现，并非所有知识点都适合故事中的盛远金融公司的情况，这也是笔者有意而为之。现实中，没有一个方法是可以放之四海而皆准的，每一个方法都有其适用范围。但这也并不妨碍我们继续介绍和推广这些方法。同样的道理，不适合盛远的并不代表不适合您的组织。
随着家里二宝的出生，我也可以利用陪产假的时间完成本书的大部分内容。在此感谢我的家人的支持和奉献。感谢人民邮电出版社的武晓燕编辑的邀约和耐心指导。也感谢GitChat5，正是GitChat，让我结识了武晓燕女士，开启了此次的出书之旅。感谢LEANSOFT的徐磊、ThoughtWorks的肖然为本书写序和书评。感谢香港Imbibe Cosmos Solutions的陈铁儿（Taylor Chan）博士、汇丰的周纪海对本书的评价。
5 GitChat 是一个新兴的、活跃的知识分享平台。
刘华（Kenneth）
2017年12月31日于广州
本书由异步社区出品，社区（https://www.epubit.com/）为您提供相关资源和后续服务。
本书提供如下资源：
要获得以上配套资源，请在异步社区本书页面中点击
，跳转到下载界面，按提示进行操作即可。注意：为保证购书读者的权益，该操作会给出相关提示，要求输入提取码进行验证。
作者和编辑尽最大努力来确保书中内容的准确性，但难免会存在疏漏。欢迎您将发现的问题反馈给我们，帮助我们提升图书的质量。
当您发现错误时，请登录异步社区，按书名搜索，进入本书页面，点击“提交勘误”，输入勘误信息，单击“提交”按钮即可。本书的作者和编辑会对您提交的勘误进行审核，确认并接受后，您将获赠异步社区的100积分。积分可用于在异步社区兑换优惠券、样书或奖品。
我们的联系邮箱是contact@epubit.com.cn。
如果您对本书有任何疑问或建议，请您发邮件给我们，并请在邮件标题中注明本书书名，以便我们更高效地做出反馈。
如果您有兴趣出版图书、录制教学视频，或者参与图书翻译、技术审校等工作，可以发邮件给我们；有意出版图书的作者也可以到异步社区在线提交投稿（直接访问www.epubit.com/selfpublish/submission即可）。
如果您是学校、培训机构或企业，想批量购买本书或异步社区出版的其他图书，也可以发邮件给我们。
如果您在网上发现有针对异步社区出品图书的各种形式的盗版行为，包括对图书全部或部分内容的非授权传播，请您将怀疑有侵权行为的链接发邮件给我们。您的这一举动是对作者权益的保护，也是我们持续为您提供有价值的内容的动力之源。
“异步社区”是人民邮电出版社旗下IT专业图书社区，致力于出版精品IT技术图书和相关学习产品，为作译者提供优质出版服务。异步社区创办于2015年8月，提供大量精品IT技术图书和电子书，以及高品质技术文章和视频课程。更多详情请访问异步社区官网https://www.epubit.com。
“异步图书”是由异步社区编辑团队策划出版的精品IT专业图书的品牌，依托于人民邮电出版社近30年的计算机图书出版积累和专业编辑团队，相关图书在封面上印有异步图书的LOGO。异步图书的出版领域包括软件开发、大数据、AI、测试、前端、网络技术等。
异步社区
微信服务号
“我强烈要求大家回去看《凤凰项目》1，一个月内在我们的内部博客上写读后感！”思文在管理层例会上说道。
1 《凤凰项目》是一本小说体的DevOps图书，可以说是DevOps的启蒙书，它与精益图书《目标》的小说体风格相似，生动地讲述了图书DevOps转型的过程。《凤凰项目》的故事思路围绕着DevOps三步工作法进行。DevOps可以算是敏捷开发的延伸，实现了最终的持续交付。本书后面将详细解释敏捷开发与DevOps的关系。
思文是盛远金融公司的CIO。盛远公司主要提供证券服务等金融服务，它拥有100多人的IT部门，为公司业务提供软件交付与维护服务，CIO就是IT部门的总负责人。
“我真的被这本书打动了！”思文接着说，“我觉得我就好像书中的比尔，而比尔曾遇到的种种困境就是我们每天的写照，比尔通过与团队一起探讨了一些具体方法扭转了局势，对我有很大的启发。业务部门对我们最大的不满是IT交付得太慢且太昂贵了，我们必须做出改变。”
“半年前，我开始和大家聊敏捷开发，我们要变得更加敏捷，像猎豹一样，更快地响应业务部门的请求，更好地交付业务价值。我们有些团队已经开始行动了，效果不错。我宣布，从今天开始，我将启动 ‘猎豹行动’，落实我们的敏捷转型。”
思文转向王章，向大家介绍道：“我来介绍一下，这位是王章，我们外聘的敏捷顾问，来自思域咨询公司，他将带领我们落实猎豹行动，大家一定要好好配合王章，有任何问题都可以向他请教。另外，我已经向公司申请了一笔专款投入到相关的培训和工具支持上，这也是很多同事多年来的诉求，大家要好好珍惜这次难得的机会，我希望一年后我们能有一个崭新的面貌！”
思文让王章做了简单的自我介绍后，接着说：“另外，之前提过的‘热带雨林’项目也正式提上日程了，我已经委任张丽为这个项目的总监，她会直接向我汇报。下面请张丽给大家正式介绍一下这个项目。”
大家把目光转向张丽。
张丽问大家：“大伙还记得‘热带雨林’项目因何得名吗？”
除了王章和刚来公司不久的李俊外，其他人都纷纷点头。
张丽接着说：“看来大家的记性不错，王章和李俊刚刚加入不了解情况，我也借这个机会和大家温故而知新。大家知道，基金2外包业务是我们公司最重要的业务，‘热带雨林’就是竞争对手把他们的基金外包业务的后台服务转包给我们，由于对方的业务量是我们的两倍，我们接下这项业务后，在基金外包服务这个领域将成为领头羊，这项业务也会为我们带来丰厚的收入。另外，对方的具体业务其实跟我们的并不完全一样，有大量的开发工作需要进行，因此这个项目的收入和投入都非常庞大，用热带雨林来形容完全不为过，它是我们未来两年最重要的项目。”
2 从广义上说，基金（Fund）是指为了某种目的而设立的具有一定数量的资金。主要包括信托投资基金、公积金、保险基金和退休基金及各种基金会的基金。这里提到的基金主要是指证券投资基金，投资于股票、债券或货币市场。
李俊有点不解地问：“不好意思，可能我对公司业务还不是很熟悉，没太听懂，基金外包业务的后台服务转包，好绕啊，能再解释一下吗？”
张丽回应道：“没关系，我来打个比方吧。比如对方是一家餐厅，他们把厨房，也就是做菜这个服务外包给了我们，但餐厅的招牌和客户服务还是属于对方的。”
李俊和王章连连点头表示理解。
张丽接着说：“这个项目有明确的期限，两年内必须完成，超过时限我们会被对方罚款。最新的消息是双方的合同已经签署，两边的项目已经正式立项。大家要随时迎接‘热带雨林’的挑战。”张丽把时间交还给思文。
思文小结道：“好，我总结一下，大家目前要完成以下几项内容。第一，回去记得看《凤凰项目》；第二，猎豹行动正式启动，大家要全力配合王章并利用好这次机会；第三，‘热带雨林’很快就会进入实施阶段，大家也要全力配合张丽，特别是李俊，基金外包IT团队是项目的重头戏。好，散会。”
李俊在会中能感受到思文的兴奋，特别是在讲《凤凰项目》和猎豹行动时，在座的一些同事也被打动。思文是个性情中人，喜怒形于色，兴奋的时候会手舞足蹈，虽然是IT部门的一把手，却一点架子也没有，平易近人，也爱说话，拉上个人就能海聊一顿。
李俊是一个比较沉稳、冷静的人。他跳槽到盛远三周，是一位有着十多年经验、训练有素的资深项目经理，有PMP认证。虽然“热带雨林”看似比他以前做过的所有项目都大，但他对自己的项目计划和把控能力很有信心。
在之前的公司中，李俊在客户和业务部门的口碑非常好，他一诺千金，总能做到按时交付。但他也清楚这背后的代价。为了兑现承诺，他总是把团队逼得很紧，导致团队经常加班，尽管他会不时地自掏腰包请大伙吃饭来补偿，但团队士气并不高，流动性也比其他团队要大，大伙私下里都叫他“周扒皮”。项目交付后团队也会被各种质量问题缠身。
他的所有项目管理知识和经验都建立在瀑布模型上。他也曾经看过一些关于敏捷开发的文章，但是没有经过系统的培训。敏捷倡导的东西在他看来是取巧，是为不做计划和不写文档找借口。他更相信一个项目的成功靠的是强大和严密的计划能力、跟进能力和沟通能力，承诺是客户最需要的。
他也经历过一些自顶向下的变革运动，要么雷声大雨点小无疾而终，要么完全不考虑具体情况一刀切，并没有带来什么实质的好处。所以他对“猎豹行动”是有点抵触的。变革一定会带来额外的开销，团队为了交付已经疲于奔命，不能让他们受到太多干扰。尽管他了解到团队里有几个小伙伴对敏捷开发也很热衷，跃跃欲试。
王章是“老敏捷”，他深深地感受到思文对敏捷的热忱，他觉得来到这里是“广阔天地，大有作为”。
通常敏捷开发更受基层工程师的欢迎，因为它倡导信任、自治以及通过技术手段如自动化测试来取代繁文缛节的文档。管理层通常更喜欢管控与流程，因此很多人认为敏捷转型应该是一个自底向上的过程，因为每个团队的实际情况都不一样，自顶向下容易一刀切，形而上学。经过多年的实践，王章强烈地认为管理层的支持和推动也非常重要，自底向上的实验只能在极有限的局部发生作用，很快就会遇到阻力和瓶颈，变革需要整个公司文化和价值观上的改变与配合以及人力、工具的投入，唯有管理层的支持才能使变革遍地开花。管理层要在具体方法上避免一刀切，由基层团队按照自己的具体情况来选择具体方法和实践。
因此他觉得盛远有思文这样的领导在敏捷转型上一定会大有前途。
他很快构想了猎豹行动的具体启动方案：
1．全面扫盲——他发现盛远IT部门的大部分同事对敏捷开发都是只知其名，他要组织全覆盖的敏捷扫盲班，让所有IT同事对敏捷开发有基本的了解；
2．体察民情——跟每个团队进行交谈，了解团队痛点，探讨具体改进方案；
3．教育客户——没有业务部门的配合，敏捷也玩不溜，他也要组织针对业务部门的敏捷基础培训。
思文对王章这么快就能拿出具体方案感到满意。
王章计划安排3场敏捷扫盲班，面向全体IT同事，目标是让所有同事对敏捷开发有基本的了解，以帮助他们有能力审视当前的交付模式并找出改进点。
思文也给每个团队主管下了死命令，必须保证所有团队的成员都参加。
对于敏捷的基础培训，王章可谓是驾轻就熟。他的培训大纲分成4个部分，计划用时一个半小时。
1．传统模式的问题——剖析瀑布模型的适应局限以及给业务部门和IT部门带来的痛点。
2．转向敏捷——什么是敏捷开发？它和瀑布模型最大的区别在哪里？具体方法和价值观是怎样的？
3．实施敏捷的好处——包括对业务部门和IT部门的好处。
4．如何开始——具体的启动行动。
第一场培训的参与人数最多，培训室50个座位座无虚席，大部分的团队主管也纷纷到场。
跟以前一样，王章在培训开始时都会抛出一个问题：“大家听说过敏捷开发吗？听说过的请举手。”
现场有十多个同事举了手。
王章向其中一位举手的同事问：“好，请问你能说说你理解的敏捷开发是怎样的吗？”
那位同事腼腆地回答道：“其实我也只是听说，应该是一种迭代开发的方法，把一个项目拆成一个个迭代来交付。”
王章鼓励道：“不错，有没有同事有其他补充？”
有同事说：“我听说可以不写那么多文档。”
这个回答引来了一些笑声。
王章也笑着问：“大家是不是特讨厌写文档？”
有同事回应说：“是的，据说可以写一些自动化测试来取代文档，我觉得这才是一个程序员该干的。”
王章说：“好，那我们带着这些问题来看看敏捷开发是不是和大家想象的一样。在座的各位应该做过不少项目，大家能说说做项目最大的痛苦是什么吗？”
“加班！”大家异口同声地说。
王章被逗笑了，接着问：“好好好，‘IT狗’的共同心声。还有其他吗？”
“业务人员经常改需求，特别是在快要上线时才改。”一个同事控诉道，现场有不少同事点头呼应。
“好了，其实大家面对的问题都是业内的共同问题，而这些问题其实不光是IT部门的痛点，业务部门也有痛点，我们来看看。”王章顺势开始他的培训内容，他先回顾了瀑布模型的开发过程，并总结了在当前模型下，业务部门的痛点有：
1．逾期交付；
2．超支；
3．看到成品时项目已接近尾声；
4．缺乏透明度，不知道具体进度；
5．很难变更需求；
6．最终发现开发出来的产品不是他们想要的；
7．贻误战机，丢失市场机会。
IT部门的痛点有：
1．过度承诺；
2．难以一次性消化所有需求；
3．惧怕需求变更；
4．不断重做；
5．后期压力巨大；
6．加班！加班！加班！
王章随即分析造成这些痛点的原因。一个项目开始时，业务部门会给IT部门需求概要和期望交付日期。IT部门需要做估算和计划。而在项目开始的时候，只有预算和目标交付时间是确定的，下面的所有因素都存在不确定性：
1．范围与具体需求；
2．可能的需求变更；
3．人员（中途有人会放假甚至离职等）；
4．估算的准确性；
5．对现有系统的影响；
6．服务器环境的搭建（需要什么配置、何时能到位）。
瀑布模型的过程是需求分析、设计、编程、测试和发布等几个阶段。在这里有以下问题。
1．瀑布过程中每个阶段一环扣一环，设计、编程、测试都依赖于完整且稳定的需求，因此需求分析非常重要。我们期望能在这里花更多时间来挖掘所有的需求细节，然而在目标交付日期确定的情况下，在需求上花的时间多，后面的开发时间就会被压缩，从而形成矛盾。
2．也因为每个阶段的环环相扣，需求变化会牵一发而动全身，变更成本高，因此IT部门惧怕需求变化。
3．在整个过程中，业务部门要在测试的后半部分，也就是用户验收测试阶段才能看到成品，这个时候已经临近目标交付日期，此刻用户才发现产品并非他们想要的已经太迟了，覆水难收。
简单来说，瀑布模型适合确定性非常高的项目，而这样的项目凤毛麟角。软件开发过程充满不确定性，我们要管理和适应的正是这种不确定性。
“有没有一种方法能解决以上问题呢？我们来看看敏捷开发。”王章过渡道，他又抛出问题：“大家觉得软件开发过程中，到底什么最重要？”
同事们答道：
“质量。”
“准时交货。”
“满足用户需要。”
……
王章回应道：“大家讲的都对，但在我看来，软件开发最重要的是搞清楚用户到底想要什么！下面这张图大家应该都见过，用户最开始想要的东西和他们最终想要的东西可以完全不一样！
“我们要正确地做事（Do It Right），比如确保质量，但前提是我们做了正确的事（Do the Right Thing），交付用户真正想要的东西。用户在看到成品前，可能都无法确定自己真正想要的是什么，因此需求变化是不可避免的，我们必须适应。如何更快地交付也是我们必须思考的问题，因为业务部门需要面对市场的快速变化。我们来看看敏捷开发如何满足这些需要。”
接着，王章的PPT翻到了下面这组蒙娜丽莎图。他首先问在座的同事：“大家觉得瀑布模型是上面一组图的过程，还是下面一组图的过程？”
有人投上面一组，有人投下面一组。
王章接着说：“我认为是下面一组，我们来分析一下这个过程有什么特点。这3个阶段都是画的整个范围，只是完成的程度不一样，这就很像瀑布的过程。假设一个问题，如果原来估算完成这幅画需要3个月，而客户突然要我们两个月就交货，我们只完成到第二幅画的阶段，这样的作品可以交付吗？”
大家纷纷摇头。
“是的，很显然不行。来看上面这组图，整幅画被切分成若干个部分，而每个部分都按照最终交付标准来完成。同样的假设，这组图中第二幅画可以交付吗？”
大家有点纠结，有人点头有人摇头。
“大家也不确定吧，其实在这个过程中，我们始终问客户，这幅画中哪些部分最重要，如果客户说蒙拉丽莎的头最重要，那么第二幅画是可以交付的。这个过程就是迭代开发或增量开发的过程，这就是敏捷开发最重要的特点，也是瀑布和敏捷最大的不同。”
不少同事点头表示理解。
“好了，说了这么多，我们来看看敏捷开发有些什么具体方法。敏捷开发有很多方法论，其中比较流行的有Scrum、极限编程、看板方法等，今天我将重点讲解最流行的Scrum。
“首先，Scrum是个专有名词，它不是缩写，也没有中文翻译，大家只需要记住这个单词就可以了。然后，Scrum引入了若干个新的概念。
Product Owner（PO）——用户/客户/业务的代言人，就是可以做出业务决策的人，所谓业务决策包括需求与优先级。
Scrum Master——熟悉Scrum流程的人，指导和确保团队以Scrum的方式进行交付。
Sprint——Scrum中对迭代的说法。一个项目/产品的交付就是由一个又一个的Sprint构成的。
User Story——用户故事。具有业务价值的交付单位，一个项目/产品是由很多用户故事构成的。
Product Backlog——可以理解为项目的代办列表，由用户故事构成。
Sprint Backlog——一个Sprint的代办列表，确定Sprint里有哪些用户故事，框定Sprint的开发范围。
“下面这张图阐述了Scrum的整个过程：
“每个项目或产品的交付由若干个Sprint构成。Sprint的周期是固定的，以保持节奏。通常是2～4个星期，不建议超过4个星期。
“在每个Sprint开始的时候，Product Owner（下面称PO）和IT团队一起开Sprint计划会议，PO会对Product Backlog中的用户故事进行排序，选出最重要的用户故事。IT团队会对这些用户故事进行估算。由于Sprint的周期已经确定，团队成员数量也是确定的，这两个因子确定了团队的大概交付能力。经过PO与IT团队的协商，确定哪些用户故事会放在这个Sprint的Backlog里，作为Sprint的开发范围。
“接下来IT团队围绕Sprint Backlog中的用户故事进行开发。IT团队每天会组织一次站会，所有成员聚在一起，每个成员说一下‘昨天做了什么，今天会做什么，昨天遇到了什么问题。’这是为了让整个团队了解进度，也是为了尽早地暴露问题并及时解决。一个问题，越早解决成本越低。由于站会每天都要发生，因此这个会议宜短不宜长，要控制在15～20分钟，让大家站着开会也是因为站的时间长了会累，从而逼着大家控制时间。这对团队规模也有要求，建议团队人数控制在7个人以内。如果项目比较大型，应该考虑把大型团队拆分成若干个小团队。小团队的沟通效率也远远比大型团队高。
“在Sprint结束的时候，PO和IT团队又聚在一起开Sprint评审会议，IT团队向PO展示这个Sprint的交付，PO有任何反馈，甚至需求变更都可以定义成新的用户故事放到Product Backlog里重新排队，这也是敏捷应对需求变化的方法。为什么我们提倡短迭代呢？因为它大大缩短了反馈周期，即使整个迭代的交付最终都不是PO想要的，损失也有限，可以帮助双方及时调整产品的方向，确保最终交付的正确性。
“团队也可趁这个时候举行回顾会议，审视一下这个Sprint里哪些地方做得好，哪些地方可以做得更好，如果每个Sprint都坚持进行有效的回顾会议，便可形成持续改善的机制。”
王章在这里稍作停顿，因为这是本次培训最重要的内容，需要大家消化。在回答了现场几个问题后，王章强调了在Scrum中，PO的角色非常重要，一个成功的敏捷项目背后一定有一个好PO。
接下来，王章开始介绍敏捷开发的一些核心价值观，首先是敏捷宣言：
个体与交互胜于过程与工具；
可工作的软件胜于面面俱到的文档；
与客户的协作胜于基于合同的谈判；
响应变化胜于遵循计划。
敏捷所有的改变，就是为了一件事情——快速反馈：
短迭代开发——让PO更快、更早地看到成品，给予反馈；
每日站会——每天都能看到进度和阻碍；
回顾会议——每个迭代都反思改进点，形成持续改善的机制。
“今后我还将给大家介绍极限编程1，它提出的以下实践也是为了快速反馈：
1 极限编程（Extreme Programming，XP）是由Kent Beck提出的另一种敏捷开发方法论，它有12个具体实践，涵盖了Scrum未包括的有关设计、编程、测试、集成等的工程实践，Scrum和XP经常组合在一起。本书后面的章节会对极限编程作详细的介绍。
测试驱动编程——围绕一个需求先写自动化测试代码，再编程，自动化测试能立即给予程序是否正确的反馈；
持续集成——每天甚至每次提交代码的时候都把所有代码集成一次，运行所有自动化测试，立即反馈集成结果；
结对编程——一般的事后评审的有效性存疑，也会带来返工消耗。结对编程就是两个人边编程边评审，及时反馈，一次性确保代码质量。”
王章总结了敏捷开发给业务部门和IT部门带来的好处。
对业务部门而言：
1．不再需要一次性解释所有的需求；
2．可随时提出需求变更；
3．进度透明；
4．确保最重要的需求能在目标交付日期获得；
5．确保得到正确的产品。
对IT部门而言：
1．不再需要承诺一个未必能实现的计划；
2．更早地开工和交付；
3．为当前迭代进行更精确的计划；
4．适应需求变化；
5．适应不确定性；
6．开发正确的产品；
7．与业务人员的争执更少。
最后，王章给出敏捷启动的建议：
1．围绕已知的范围和需求定义用户故事和建立Product Backlog；
2．为用户故事排优先级；
3．商定Sprint的长度；
4．商定Spring计划会议和评审会议的日程；
5．商定发布计划；
6．准备相应的辅助工具。
王章结束了培训的内容，到了问答时间。
有同事问：“除了敏捷，业界现在也经常提DevOps，请问两者有什么关联吗？”
王章回应道：“问得好。”
他随即翻出了下面这张PPT，继续说：“我们来看这张图，敏捷打通了业务、开发、测试之间的‘墙’2，通过更紧密的沟通与交互实现更频繁的交付。然而，开发团队与运维团队之间还有一堵‘墙’，开发团队希望持续交付，运维团队希望稳定，DevOps就是要打破这最后一堵‘墙’，实现开发与运维一体化和端到端的持续交付，它融合了敏捷与精益3的精神，涉及自动化、精益思想、量度和分享。建议大家去看看《凤凰项目》，它可以说是DevOps的启蒙图书，而且是小说体，故事性强，可读性高，我第一次看的时候一个周末就看完了，思文也强烈推荐，大家一定能从中收益。今后有机会我也会和大家作进一步分享。”
2 关于敏捷如何打通开发与测试之“墙”，将在后面介绍极限编程时提及。
3 精益是从丰田生产系统移植到软件开发的方法，看板方法就是其中一种精益方法。本书后面的章节会对精益和看板方法作详细的介绍。
李俊问了另一个问题：“我明白敏捷通过迭代不断交付部分需求和寻求客户的反馈，并且不断调整开发方向以满足最终需求。但在项目开始的时候，客户一定要我们承诺什么时候能交付他们的需求，而敏捷好像并不做长期计划，这个问题怎么解决？”
王章回答道：“是的，客户需要我们的承诺，我们也需要在一开始进行估算。但是正如我们开始所说的，在项目开始之前，我们拥有的信息只有需求概要和目标日期，相应的估算确定的其实只是预算，我们通过迭代就是想帮助客户花好这笔预算，交付他们想要的产品。打个比方，客户一开始要的是冰箱，我们估算制造这台冰箱要5000元，在迭代过程中，客户发现他想要的其实是洗衣机，于是我们通过及时调整做出了洗衣机。也许客户最想要的是全自动洗衣机，但是在5000元预算内，我们只能做出半自动洗衣机，客户可以选择追加投资继续开发。关键是这个过程中，客户全程参与，这个结果是客户与IT部门一起缔造出来的。但如果是瀑布，我们只会开发出他最终并不想要的冰箱，造成浪费。
“当然，敏捷也有自己的一套估算和计划方法，今后有机会再跟大家详细介绍，今天的内容比较多，大家还是先消化消化。”
在回答了所有问题后，培训结束了。
李俊通过这次培训受到了很大的启发，他发现自己过去对敏捷的理解太片面了，这次是很好的刷新知识的机会。他甚至在培训中通过自己的理解帮王章解答了一些现场的问题，王章也对他的解答表示认同。不过他相信在真实的项目中落地以及让业务部门买账时，肯定会遇到很多实际的问题。
接下来的两场培训也顺利完成。随后王章向所有学员发出了调查问卷，得到的反馈都不错。
敏捷开发与瀑布模型的最大区别——迭代开发/增量开发；
Scrum——Product Owner（PO）、Sprint、Sprint计划与评审会议、每日站会；
DevOps——打破开发与运维的“墙”，实现端到端的持续交付。
