描述
开 本: 16开纸 张: 纯质纸包 装: 平装-胶订是否套装: 否国际标准书号ISBN: 9787302537342
《深入核心的敏捷开发：ThoughtWorks五大关键实践》的特色如下：
萃取自ThoughtWorks十年敏捷实践
有效、有用、深入核心的敏捷开发
系统梳理切实可行的敏捷落地框架
《深入核心的敏捷开发：ThoughtWorks五大关键实践》的主题如下：
核心原则，核心实践，管理体系，敏捷转型，真实案例
来自项目实际演练过程中的深度思考与适应性行动参考
敏捷，精益，Scrum，Kanban，究竟应该怎样有效落地
涉及行业广、具有深度启发性的敏捷实施落地调研结果
《深入核心的敏捷开发：ThoughtWorks五大关键实践》介绍了ThoughtWorks是如何实践敏捷开发的，主题包括测试驱动开发、持续集成、持续交付、全功能团队、需求分析和敏捷转型等。ThoughtWorks经过十多年的实践和沉淀，总结得出一套独特的、切实可行的敏捷软件开发核心原则、核心实践、管理体系和敏捷转型过程。全书共5部分18章，介绍了什么是合理正确的需求分析方法，如何采纳先进和理性的技术，自适应的团队组织形式是怎样的，如何建立客户价值优先的思维，如何持续改善软件交付方法。与此同时，作者也提到了一些可能遭遇的坑，引导读者参与思考什么是敏捷的实质。
《深入核心的敏捷开发：ThoughtWorks五大关键实践》面向开发者、敏捷咨询顾问、CIO和CTO，可以帮助他们顺利导入和实施敏捷。
推荐序1 “大象起舞”，别有一番风景
—— 价值驱动的精益研发转型实录
2019年7月30日早上8:30，深圳南山科技园招行研发大楼，步履匆匆的上班族；8:45，每一层的员工围向各自工作区域的看板，开始每日站会，面对面沟通当天工作。已使用电子看板的开发室组，深圳、杭州、成都三地同事在同一个看板上进行远程即时沟通。9点左右，站会结束，紧张充实的一天开始了——这是招行信息技术部深、杭、蓉三地6500多员工（含外包）每天工作的开始。
从2015年看板和敏捷SCRUM的引入，到2019年7月全面规模化精益研发转型，招行经历了四年多的时间。事实上，规模化精益研发转型并没有相对成熟的可参考的案例，尤其对于监管严格的大型银行科技部门，一路走来，可以说一直摸索着前进。值得欣慰的是，招行有一群致力于工程管理、过程改进，有责任心和使命感的SPI（Software Process Improvement）人，始终紧紧围绕科技的目标及痛点，瞄准“价值”“质量”“效能”，持续开展前瞻性研究、试点，立足当下，着眼未来，脚踏实地，敢于创新，摸索出一条适合招行的精益研发转型之路，这个过程可谓环环相扣、步步为营，推动招行科技在支持全行业务发展的新时期未雨绸缪、占领先机。这个过程中，招行与ThoughtWorks咨询事业部精诚合作，共同探索，为转型输入了先进的理念和方法。
与大多数银行科技组织一样，招行的软件工程管理大体分为三个阶段，如下图所示。
让我们看下几个重要的时间点。
* 2009年和2013年，招行科技分别通过了CMMI2级和3级的认证，建立了软件过程管理体系，项目开发的过程能力和质量相对稳定，积累了软件工程管理、过程改进等方面经验，尤其培养了招行IT人的规范化工程管理素质。
* 2015年，面对互联网金融的冲击和市场竞争，如何提高需求响应速度和交付速度，如何把有限的IT资源投入到更有价值的需求开发中，是摆在科技面前首要解决的痛点。当年，招行与ThoughtWorks合作，开始在个别相对独立的软件产品上试点敏捷SCRUM开发；同年，引入了“看板”在基层开发组织落地，并着手研究和规划DevOps流水线建设，积累了一些迭代开发的经验。
* 2016年下半年，一个问题自然摆在面前，面对业务不断增长的需求及快速交付的呼声，90%的传统开发项目该何去何从？11月，总结敏捷试点经验，秉承循序渐进的改进原则，确定了双模的“精益研发转型”目标和方向。
* 2017年初，招行确定了Fintech战略，首次提出了“科技敏捷带动业务敏捷”的要求。6月，敏捷产品模式从几个业务片区做起，逐步形成套路，开始推广到其他片区。着手培养招行内部的精益教练队伍。
* 2018年9月，总结提炼三年多的经验，确定精益研发管理与工程实践集，明确双模的定义及使用场景，创新提出“过程制定选择”机制，正式发布了 “价值驱动、质量为先”的“精益研发管理体系V1.0”，软件工程管理翻开了新的一页。
* 2019年3月，招行科技启动规模化精益研发转型，截至7月底，近60%科技队伍转入精益研发模式，可以预见在不久的将来，招行科技将全面完成精益研发转型。
值得一提的是：招行不但没有放弃、而是继承了原有软件过程管理体系(CMMI)的框架，保留了原有体系中经过多年验证有效的过程及活动，在此基础上总结、吸收了这几年试点的精益、敏捷的理念及核心实践，重构工程与管理实践集，建立新的价值驱动的端到端的软件生命周期，改变原来串行的来料加工式的开发模式，真正形成从产生想法到上线运营数据分析的闭环。研发模式上，明确“精益项目”和“敏捷产品”两种模式，及相对弹性的定制选择机制。这些是招行精益研发管理体系的核心。
思想上统一认识，行动上才有一致的可能，我们总结提炼了“精益研发”的愿景、目标及四项原则：
* 愿景：打造招行端到端的精益研发管理体系，价值驱动、质量为先，以行业领先的科技能力驱动创新与变革。
* 目标：更高的产品质量，更快的交付速度，更好的客户满意度，更高的研发效能，建立生机型文化氛围。
* 原则：价值驱动，质量为先；快速响应，高效执行；尊重信任，紧密协作；持续改进，追求卓越。
精益原则已纳入招行科技组织级的价值观中。其核心是“价值驱动”，这也借鉴了ThoughtWorks“价值驱动的业务创新管理框架”的理念。这四个字不仅仅是指业务价值，也包含IT自身的价值衡量，比如如何优化IT内部流程，尽可能减少浪费，如何在关键的技术环节强化决策等等。同样，“紧密协作”不仅仅是深化IT与业务的融合，IT内部的开发、测试、运维等等，也需换位思考，紧密协作。
招行始终坚持走演进式而非颠覆性的持续改进之路，注重“体系化、结构化、规范化”，时刻聚焦转型的“愿景和目标”。2017年，招行Fintech战略的落地，也推动了业务部门的思想转变，使IT与业务融合走向深入，为精益研发转型提供了有利的条件。
规模化转型落地方面，继续发挥EPG（Engineering Process Group）工作组牵头作用，从愿景和目标分解出几大专项工作，强化组织级的推进，逐年扎实落地，
* 重构软件过程管理体系及资产库。战略上，“愿景-目标-原则”，层层分解、保持统一；战术上，“领域-实践-定制选择”，针对每一个跨职能交付团队的痛点和目标，定制选择合适的开发模式和实践（含管理实践和工程实践）。
从业务（产品）片区入手、相对弹性的定制选择（而非全盘强制执行）、变“要你做”为“我要做”，是招行精益研发管理体系的一项创新。定制重点考虑的因素有：业务战略重点、需求的连续性及特点、软件交付期望、业务架构与系统架构状况、CICD成熟度、业务方的能力与参与度、资源情况等等，针对性地选择相匹配的研发模式及实践，形成各自特色的实施方案，重点强化业务IT紧密协作，真正解决研发过程中的痛点与难点。
同时，根据产品发展的状态及市场绩效的变化，定期对方案进行适应性检视，并提供研发模式之间的转换及多模的协同机制。
* 全面推行精益看板。看板是招行早引入的精益实践，招行一开始就把看板定位于基层开发室组（<=12人）的跨组织管理与工程管理的工具（而不仅仅局限于迭代管理），建立了招行看板应用的成熟度模型，全面推广，逐年提升应用能力。推广的前期侧重于组织管理，后期随着精益研发的深入，与新的软件生命周期紧密结合，侧重于工程管理及效果，聚焦资源效率和流动效率，与精益转型形成1 1>2的态势。看板的全面推广，在工作透明化、限制在制品、加快工作流动、高效沟通、建立自组织文化氛围、提高基层小组织的活力等方面发挥了重要作用。
2017年，招行开始着手电子看板的自主开发，截至2019年7月，已有2/3的物理看板迁移到电子看板，在功能上与项目管理、DevOps流水线、度量分析平台等实现无缝链接，可以说开辟了大规模IT组织研发过程数字化的崭新道路，未来也必将是招行精益转型取得更大成效的重要利器之一。
* 建立持续交付的DevOps流水线。工具平台对研发管理来说可谓如虎添翼。DevOps在招行精益研发体系中占据重要位置，也是规模化精益转型的核心支撑。早在2015-2016引入敏捷SCRUM的同时，招行即着手研究“DevOps”理论与实践，2017年形成招行的DevOps实施框架和路线图，并提出目标：建立适应招行特点的端到端的持续交付“高速轨道”，更快地交付高质量的软件产品，全面支持精益研发转型。几年来，招行大力投入资源推进工具平台建设，优化整合原有的工具资产，并将精益管理实践和工程实践有机结合，形成工具生态链，为规模化转型提供了强有力的支撑。
* “精益需求分析”，转型的核心实践，没有之一。要达成“价值驱动、快速迭代交付”的目标，必然要求在需求侧做好两件事：一是结构化分解业务目标，做好价值分析与决策；二是分解及细化需求，形成MVP，建立和维护需求动态优先级列表，做好版本规划。这两点是精益需求分析的根本目的，也是研发转型的前提。传统项目开发始终困扰的需求不清晰、需求分解问题（结构化、条目化）、无法排出优先级、需求价值无法衡量和验证等诸多问题，在精益需求分析实践中一一考虑解决。这是个艰巨的任务，但又是PO或BA必须掌握的能力，唯有迎难而上。
* 内部赋能，能力自建。2015—2016年招行与ThoughtWorks合作引入敏捷Scrum期间，当时的教练主要以外部为主，2017年起，招行开始建立内部教练的培养机制，加大内部精益教练（包括管理方向、技术方向）的培养力度，因为我们认识到，面对几千人的规模化精益转型，仅靠外部资源远远不够，培养内部教练队伍，加强能力自建，才能更好做到及时响应、务实有效，也才能走得长远。两年多时间，招行培养了近100位的精益教练，开展各项社区、开放日活动，营造精益敏捷文化氛围。不但QA队伍全面转型精益教练，各开发团队也逐步培养自己的教练队伍，一方面在转型中辅导内训、反馈问题，发挥布道者作用，另一方面这支队伍在适当时候转身QA角色，开展背靠背的审计活动，监督执行过程，自我发现问题，自我持续改进。
* 建立精益研发度量体系。数据让我们知道现在的能力与目标的差距，了解自己的现状，为管理决策提供依据。度量分析是招行从CMMI2级就开始建立的组织级重要能力，多年来招行坚持用数据说话，所谓“来自一线、服务一线”。精益研发转型，也同样从愿景和目标分解出可度量的指标，同时优化度量分析平台，与电子看板等数字化管理工具结合，为项目、团队、组织级提供及时的指标数据，助力转型效果的自我量化分析。
“不忘初心，方得始终”，每年底，EPG工作组对标精益转型的愿景与目标，组织专题研讨，提出下一年度的目标和具体行动计划，采取“方案-试点-验证-形成规范-发布推广”策略，协同作战，稳步推进。研发模式与实践的定制选择、自我能力建设、自我度量分析、自我回顾改进等，逐步形成良性循环，自驱式的生机文化在招行科技队伍中慢慢生根发芽，也即将蔚然成风。
当前，招行科技又提出“从精益研发到精益组织”的目标，可预见的未来必然是：“大象起舞”别有一番风景——转型，我们仍在路上。
欧红
招商银行总行信息技术部 项目办&EPG负责人
过程改进与管理变革资深专家
2019年8月19日，深圳
推荐序2
ThoughtWork敏捷开发的四大经济价值
15年前，ThoughtWorks开始在中国技术社区推广敏捷开发理念和实践，由一开始被认为是一小撮离经叛道者的游戏，逐渐生根发芽，被越来越多的实践者所接受。特别是近几年，商业环境的变化节奏不断加快。科技，特别是软件，正是在这种变化的驱动下开始在业务当中扮演核心角色。这些变化倒逼着企业寻求突破，采用高响应力的软件开发模式，其影响也延伸到了商业的组织模式。
ThoughtWorks不是一家互联网公司，却是一家数字原生的组织。我们一直吸引追求卓越的专业人士，打造学习型的组织，寻求更好的方法应用科技来解决复杂商业问题。更重要的是，我们与一群难能可贵的客户合作。这些客户有的是以互联网模式运营的数字化公司，也有正处于积极转型当中的百年企业。他们的业务和组织差异巨大，但都有个共同点，就是拥有锐意进取、勇于变革的领导团队。ThoughtWorks和这些组织一起，探索适合业务发展的技术和方法，共创科技驱动的数字化组织。在这个过程中，一线团队并不死守教科书式的各大敏捷流派，而是在明确核心原则的基础上，在一线生产的热土中，反省和提炼经验，总结核心实践。本书就是这些实践的生动呈现，并且深入分析了这些实践所处的组织和管理生态，后以企业实际所经历各个发展阶段的演进案例，以及采样丰富的行业分析，描述了这个领域从微观到宏观的动态。
近，Forrester在对大量ThoughtWorks客户调研之后，撰写了关于总体经济影响（Total Economic Impact）的研究。报告以量化的度量，总结了ThoughtWorks方法为各种商业组织所带来四个方面的经济价值：
* 通过更快将产品和服务投入市场提升营收
* 通过缩短新客户导流的周期加速营收的产生
* 减少维护遗留系统的成本
* 减少新开发系统的维护成本
但是，要让实践持续发挥上述商业价值，除了需要软件开发团队不断学习，刻意练习，以至于能够娴熟地运用书中的核心实践以外，还需要团队所在公司文化和结构上的配合，也就是要把敏捷理念和方法融入运营的流程、预算和政策，我们称其业务敏捷。
来自一线开发团队的总结让本书的实操性区别于世面上的其它书籍。希望本书能为打算采纳敏捷方法的团队提供有价值的参考，帮助已经起步、正在持续改进的团队提供努力的目标。
张松
ThoughtWorks中国区总经理
第1章 敏捷宣言到底有几句
“嗨，A同学，敏捷宣言有几句？”
“4句呀，分别是个体和互动……”
如果你的答案和A同学一样，也认为是4句，那么请你继续往下读，相信会对你有所帮助。
如果你的答案和A同学不一样，认为不是4句或者不知道，那么可以选择性阅读，它不一定对你有所帮助。：)
为什么写此文
当我还是一名敏捷实践的试行者，接触到的个信息就是敏捷宣言(非4句)，虽然不能完全领悟，但当时的教练让我把它熟记于心，说这个就是敏捷。我想：我终于知道敏捷了。
当我还是敏捷教练时，向大家介绍敏捷，问都有谁知道敏捷宣言的时候，有部分同学举手，他们的答案和A同学一样。我想这下可有的喷了。
现在我是敏捷咨询师，接触到一些企业内部的敏捷实践者，问他们同样的问题，他们的答案也和A同学一样。我想：“这下你该请我们做咨询了。”
就在前不久，我听了一些敏捷培训，讲师提到敏捷宣言的时候，竟然也都介绍4句敏捷宣言，之后我饶有兴趣地百度了“敏捷宣言”的关键字，也询问了周围的敏捷实践者，得到的答复是敏捷宣言就是4句呀，大家都知道的……我忽然意识到此事的严重性，我是时候分享给大家了！
敏捷宣言到底有几句
让我们来看一下原版的敏捷宣言。以下是官方的翻译：
数一数有几句？6句。这里并不想纠结于数字，你也许会说敏捷宣言中有4句价值观，这似乎也没错，但问题是你了解其余2句吗？敏捷宣言流传至今，我们心中似乎只记住了那4句，其余的2句被我们天然屏蔽了，甚至我们还一直在做“敏捷宣言只有4句”这样的知识传递！难道那两句不重要吗？答案肯定是否定的(不重要为什么要写在宣言里……)，两句的偏差带给我们的是敏捷转型方向上的错误。让我们来看一下这两句告诉我们了一些什么。
我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观。
通过这句我们了解到敏捷宣言是通过不断实践总结出的价值观。价值观不是具体详细的目标及实践，它是在我们心里的一种根深蒂固的思维取向，它会影响我们做出的每一件事情。所以有团队会说，我们现在已经敏捷了，因为我们做了迭代开发，这种单纯的实践=敏捷是不成立的，我们需要多维度了解团队的价值观是否符合敏捷的价值观。
虽然右项也具有价值，但我们认为左项具有更大的价值。
这句是敏捷宣言里重要的一句话。如果你丢了句，说宣言有5句，这个还可以原谅。但如果你丢了这一句，那是个错误！在做敏捷转型的过程中常遇到这样的现象：“敏捷说了不需要文档，太好了，我们以后就不用写文档了！”“敏捷说了不需要计划，我为什么要给你计划？！”这样实施的后果可想而知，这样的案例比比皆是，这就是敏捷转型方向上的错误。
为什么会有这样的错误呢？原因就是忽视了宣言中的后一句话。宣言的价值观中英文用了over中文翻译是“高于”，A高于B，多数人的理解就是A比B好，那么为了敏捷转型我们就只用A舍弃B，这似乎是字面上的正常的理解，但这不是宣言中要表达的意思。想必当初17位大牛早已预见了这样问题，他们用后这句强调，给大家正确的引导。告诉大家宣言中的价值观不能理解为取A舍B这样的二分。敏捷的价值观是承认右项是有价值的，不过我们要更重视左项的价值，这不是二分！当初软件开发在不断发展的过程中，大家越来越重视右项的价值，这时敏捷站了出来，提出在这个过程中我们要更加重视左项的价值，它并不是让我们要放弃右项实施左项。
在我们实际做敏捷转型的过程中，左右两项通常情况下也是共存的，不过我们更重视左项。例如你在帮一个团队在做敏捷转型，你发现产品把需求都录入系统中，告诉大家他的任务已经完成，之后研发按照系统中录入的需求进行研发，期间他们无任何沟通。这时你应该做的是加强他们之间的互动，例如让产品给研发对着系统的需求讲一遍，研发在过程中发现问题立刻和产品沟通，不过度依赖于系统中的描述等，你不能认为宣言里说了互动比工具更重要，就让他们停止使用系统只靠互动，这样团队会“手忙脚乱”，就算团队勉强坚持下来了(且不说效果好坏)，后你会发现数据统计的工作如果没有工具，对团队来说就是一场噩梦。这样的例子还有很多。
评论
还没有评论。