《敏捷思维：移动互联网和大数据时代IT企业转型、升级与再造之道.html.pdf》由会员分享，可在线阅读，更多相关《敏捷思维：移动互联网和大数据时代IT企业转型、升级与再造之道.html.pdf（194页珍藏版）》请在三一文库上搜索。
1、序言一 我作为最早加入摩托罗拉中国公司研发中心的人员之一，在IT通信行业工作了超过20年。和明志的经历相似，我早期主要从 事测试方面的工作，而后又参与了开发、系统集成等工作，亲身经历了开发中心从最初的十几个人发展到上千名工程师的辉煌。 我在10年前离开摩托罗拉加入NEC后，又开始侧重于市场、销售方面的工作，直至负责公司的全面运营管理。我看到一般大型 企业尤其是外企的产品研发和市场运营都采用按部就班的模式，虽然有其严谨的一面，但有时不免效率不高，很可能由于一个环 节的拖延造成整个项目的延迟。 明志书中的敏捷研发和敏捷管理恰恰另辟蹊径，开拓了另一片天空。在摩托罗拉等外企衰落的同时，华为等一批国内企
2、业快 速成长，成为市场上的领军企业。众所周知，华为聘请IBM为咨询顾问，任正非总裁曾经说IBM是最好的老师，明志也参与了其 中的项目。华为把IBM的敏捷研发和敏捷管理灵活应用于软件研发、项目管理甚至客户服务流程中，取得了巨大的成功。 在书中，作者不仅对敏捷方法进行了系统和详尽的描述，还论述了如何在大型企业和创业型企业中应用敏捷，如何避免容易 出现的问题和误区，结合大量的案例和切身经历深入浅出地讲解，以便读者理解和掌握。此外，书中也融入了许多关于管理和人 才的讨论，例如人才培养和潜力发掘的相关内容，使方法、工具与人得以有机结合。 随着微信的普及和碎片化时间的利用，很多人放弃了系统的读书习惯。20
3、12年，几位资深创业人秋游西山，有感于当前知 识信息碎片化、社会功利浮躁、精神交流匮乏以及人际信任缺失，组织了学习互助型群体，现已形成以创业家为主体，同时包含 金融投资家、企业高管、资深媒体人、专家学者在内超过一千人的西山读书会。明志和我皆是西山读书会的成员之一，每天读书 也已成为习惯。本书的出版面世，从管理学的角度带来了新的思考，希望书中的内容能够给广大读者以启迪。 丁伟 NEC通信（中国）有限公司常务副总裁 序言二 武林至尊，宝刀屠龙，号令天下，莫敢不从，倚天不出，谁与争锋！21世纪初的科技界，一如武侠场，英才辈出，新式武 功不断显现江湖，而在一场场移动互联网新技术的激烈逐鹿中，也诞生了一
4、些名满江湖的高手，他们的传奇经历，一如倚天屠龙 传记，不禁让人拍案叫绝。 2009年的一天，偶然在网络上搜索“敏捷测试”，排名第一的敏捷测试的最佳实践赫然映入眼帘，作者正是IBM资深 敏捷专家谢明志。虽然素昧平生，但明志热情地接受了我们的咨询，并无私地利用个人时间多次接待了我们的登门造访和求教。 明志身上IBM国际化的专业经验打动了我，我在中兴通讯所肩负的民族企业使命感和创新学习精神也打动了明志，这就是缘分。 由于我个人在工作上向来讨厌官僚、追求高效，明志甚至帮我们在IBM与中兴通讯两个大公司复杂漫长的流程中找到捷径，灵活 而“敏捷”地为我们打造了一次量身定制的敏捷测试咨询服务，让我们得以快速
5、揭开敏捷的神秘面纱，见到倚天剑、屠龙刀的真 容，这让我感动至今。 与明志认识的那一年，也正是中兴通讯手机测试团队试水敏捷的元年，经过与IBM的合作，我们收获了很多有价值的思想和 方法，不仅有效促进了当时我们与北美顶级客户Verizon的一个项目进程，而且经过多年的学习、思考、交流与沉淀，中兴形成 了一套独特的敏捷思路和方法，这对于后来整个中兴手机测试中心的组织转型和专业化发展都有非常大的帮助。但其实我更希望 强调的是，一种思维、一种方法，无论以何种方式被应用，其结果如何都并不重要，重要的是领悟和知己。高手过招，有时求的 也许不是胜负，金庸用“华山论剑”而不是“华山决战”、“华山比武”来形容南宋
6、那一场武林“峰会”，高手自能领会其中真 意。 得客户者得天下。敏捷是软件行业从传统模式走出来的一次伟大变革，除了传统软件业之外，敏捷天然地与互联网行业结 合，造就了这个伟大的时代。敏捷模式的快速迭代和拥抱变化让产品、交付及其演进过程焕然一新，最好地契合了各类客户需 求，在这个模式下工程师们的观念和思维开始不断进化，成为软件业具备互联网思维的先行者。我认为这是敏捷超越行业的一个 重要贡献和意义，它让人们思考如何更好地融入这个时代，迎接变化，顺势而为。 开放思维、乐于分享、重视朋友，通过近年来明志领队的多次IBM workshop和交流，我的团队不仅收获了先进、专业、地 道的敏捷咨询服务，造就了中
7、兴通讯终端测试技术在业界的领先地位，更从明志身上看到了从为人到做事的诸多闪光点，并以为 同业挚友相交多年。明志是有真才实学又乐于分享的人，其思想最能够不断成熟、完善，其实践最能够带来启发，也更接地气， 相信此书能够为读者提供一份精美的敏捷大餐！ 谢伟 中兴通讯终端事业部副总裁 中兴通讯终端事业部产品测试中心主任 序言三 本书作者谢明志以敏捷开发正规军的角度与我们分享他在敏捷开发管理中的实战经验。虽然讲述敏捷开发理论与案例的书籍 绝对不缺，但是本书从更多维度来剖析敏捷开发的真谛。 我多年前刚回国的时候，就听说敏捷开发在国内已经流行了不短的时间，大部分IT企业也都说自己的研发流程是敏捷的。可 惜当
8、我有机会深入了解后却发现，大家除了能说出“快速迭代”、“响应变化”、“小步快跑”等关键词，绝大部分的研发团队 其实并没有真正理解敏捷开发的核心思想，结果敏捷开发成为开发不写文档、需求无序进入开发环节、架构不断被推倒重来等恶 果的最有力借口，用户也就不可能真正享受到敏捷开发所应该带来的用户体验不断递增的快感。其实，我们还能从实践误区中更 好地理解为什么很多敏捷开发团队的产出并没有达到预期的高度。从Rational产品的发展历程中，我们也能体会到敏捷开发并非 初创团队才能使用的专利，像IBM这样的大型企业也能完成从瀑布式到敏捷式的华丽转身，让敏捷开发成为基石，以应对万变的 市场需求。 本书还用大量
9、篇幅讲述了敏捷型人才的培养方法，详细地把优秀人员的素质罗列在我们的眼前，在我看来，这才是敏捷开发 成败之间最大的分水岭。敏捷开发的确需要大量的前置培训来统一关键人员的思想，而这些培训并非单单提供理论上、流程上与 技术上的知识，更重要的是提高大家的自我管理、自律与协作能力。更理想的状态是，团队不仅仅理解规划需求，而且对目标用 户和市场有业务上的理解，使得呈现出来的产品能真正触动用户的内需，从而让用户真心实意地成为铁杆粉丝。 以前市场存在着各种经济红利，IT企业并不需要精益求精就能活下来，而且还能活得不错。可是温水煮青蛙还是终有煮熟的 一天，本书不仅仅对国内的开发环境提出了有力的批判，同时也提供了
10、可借鉴的转型之路。但愿我们能与作者共勉，为更多企业 踏上康庄的敏捷开发之路做出贡献。 余康柱 资深IT/互联网企业管理人 前易宝支付运营副总裁 序言四 当明志请我为他的新书写序时，我毫不犹豫地答应了。因为这本书将为中国的IT行业带来非常正面的影响。 2006年，IBM软件部面临了很多市场和经济方面的挑战，那个时候的IBM软件部已经是独当一面的部门，每年的收益是200 多亿美元，而每年并购进来的大小公司有几十家，在全球89个地区有27000多名开发人员，但也是由于这个原因，软件部内部产 生了协作和创新的问题。要解决这些问题，并且实现收益的持续高速增长，IBM软件部肯定要转型。 IBM软件部确定将
11、当时行业中非常流行且得到认可的敏捷方案作为转型的模式。当然，IBM Rational亦是这个领域的专 家，它在软件和系统工程市场上累积了超过30年的经验，转型将建立在Rational Unified Process（RUP）的坚实基础上，与之 相辅相成。 20062013年期间，IBM软件部在敏捷开发模式下创造了有目共睹的成果。我们的Release Cycle从2006年的一年一次大大 缩短至一季度一次，功能上的提交一点都没有减少，而且质量继续维持在一贯高的水平。 过去几年，IBM Rational致力于推动敏捷开发的方法论和管理，希望把我们的经验分享给客户和社区。很多大中型的企业 对敏捷开发
12、都非常感兴趣，特别是怎样将敏捷开发从理论上落地到大企业和大团队的开发实践中。过去几年，IT行业的不断变化 和新技术的不断涌现，如云计算、移动互联网、大数据，都迫使我们的很多传统客户变得更敏捷。 但每次我们探讨敏捷话题的时候，结论都是：今天企业需要的不单是开发的敏捷，更是企业的敏捷。这就带出了另外一个课 题DevOps。 就如敏捷开发一样，DevOps过去几年也是IT行业里备受关注的方法论。DevOps本身当然是针对Development和 Operations之间的协作矛盾。但是，如果引入敏捷开发，矛盾将会进一步加深，因为敏捷的一个重点是持续交付，即多版本多 交付，这势必会减少大版本带来的风险
13、和不灵活性。 Development和Operations中间是一个关卡，要达到企业敏捷，我们要过的关卡还有很多。所谓企业，是端到端的，由企 业愿景开始，变成业务计划和需求，变成IT项目和需求，经过分析、设计、编码和不同环境的测试，如单元测试、性能测试、 SIT、UAT，再交给Operations团队进行最后的生产环境上线测试，等等。每一个关卡都会影响整个流程的进度，当然，最终会 影响我们满足业务的需求。所以，IBM Rational认为DevOps的定义应该是涵盖整个端到端的企业流程，只有端到端的DevOps 才能做到企业敏捷。 本书通过深入浅出的讲解，把敏捷开发从传统的小规模敏捷伸展到跨地
14、域、跨时空的DAD方法，是读者了解敏捷的必备参 考书。 谢毓明 IBM大中华区Rational CTO 序言五 自从1946年第一台计算机诞生以来，人类一直在寻找开发软件的最佳方法，以提高软件质量，减少项目成本，并更好地控 制项目进度。最早的软件开发模型是1970年W.Royce提出的瀑布模型（Waterfall Model），这种方法在20世纪80年代成为软 件开发的主流。瀑布模型的概念是按照需求、设计、开发、测试的顺序，线性地开发出软件产品。在前一个阶段完成之前，不能 进入下一个阶段。这种方法对需求明确、设计方法成熟且开发人员对编程工具非常熟悉的软件项目十分适用，但是对已经完成的 工作进行
15、修改却很麻烦。 为克服瀑布模型“死板”的缺点，在20世纪90年代出现了迭代和增量开发模型（Iterative and Incremental Development Model），其核心思想是每一次“需求设计开发测试”的迭代只开发整个软件的一部分，这样做的目的是尽早发现并解决项 目中存在的重大问题。在迭代和增量开发模型的基础上，也出现了一些更加“短小精悍”和更加“以人为本”的开发模型，比如 RUP（1994）、Scrum（1995）、Extreme编程（1996）等。这些方法更加注重持续回顾和增量开发，并通过逐步完善的方法 来开发和交付软件产品。 2001年2月17日，17位“草根”程序员在美
16、国犹他州发布了敏捷宣言（Agile Manifesto），其中最重要的4项原则 是：“个人和交流重于过程和工具，能运行的软件重于详尽的文档，与客户合作重于合同谈判，响应变化重于执行计划”。敏捷 宣言的发布，在软件开发方法领域开启了一场轰轰烈烈的敏捷运动。所谓敏捷方法，其实只是一个概念，它是所有带有敏捷特征 的软件开发方法的统称。上面提到的Scrum和Extreme编程都属于敏捷方法。 在过去的十几年里，随着网络的普及，以及近年来越来越多移动应用的出现，信息的传播速度越来越快，软件开发的周期也 越来越短。很多项目启动时需求并不是很明确，传统的瀑布模型不再适用，敏捷方法的优点得以发挥。因此，敏捷方
17、法越来越流 行，特别是针对小型项目。在敏捷方法里，使用最多的是Scrum方法。据敏捷联盟（Agile Alliance）统计，在全球使用敏捷方 法的企业里，66%使用过Scrum方法或Scrum方法的变种。 提到软件开发，我们不能不提到CMMI模型。有人认为CMMI和敏捷方法是相冲突的，二者不能共存，其实这是一种误解。 CMMI规定了必须做什么，但是没有规定怎么做。在选择项目的生命周期模型时，CMMI项目可以选择瀑布模型，也可以选择敏 捷模型。敏捷方法的出现，实际上是丰富了软件开发模型的可选项，是对CMMI的补充。敏捷方法合理地借鉴了CMMI的400多 条最佳实践，可以最大限度地保证敏捷项目的
18、成功。所以CMMI和敏捷方法是相辅相成的关系，不是对立的关系。写这篇序的时 候，我正在美国华盛顿参加CMMI研究所举办的北美SEPG年会，今年年会的一个特点就是出现了大量CMMI与敏捷结合的论文 和报告。可以预见，在未来的几年，CMMI与敏捷方法的结合将会是一个重要的趋势。 在敏捷方法不断发展的过程中，IBM扮演了一个非常关键的角色。从最早的RUP方法到DAD，再到最新的DevOps方 法，IBM都走在时代的最前沿。本书作者非常幸运地亲身参与到这场轰轰烈烈的敏捷运动中，更为可贵的是，作者把自己在IBM 十年的亲身体验写下来，与广大读者分享，为大家更好地理解敏捷方法，避免已经走过的弯路，提供了第
19、一手的资料，非常有意 义。 最后祝愿敏捷方法如作者所期望的那样，能在中国的企业里开花结果！也祝愿中国的软件产业能早一天走向世界！ 高山 CMMI评估师，CSM 前言 这是一部讲述管理思维变革的书，一部用失败教训、成功体验和行业前沿的系统管理思维打造的创新之书。它将管理学与心 理学融为一体，告诉你如何将敏捷思维用于商业、工作和生活，破译初创团队成长为千人企业的平稳转型密码。 什么是敏捷方法？作为IBM敏捷官方发言人，无数人问过我这个问题。敏捷方法是一种让企业最大程度降低成本、增加利润 的方法，一种通过增量互动对客户的需求和反馈保持开放的产品或服务。它不是出于恐惧项目超期、成本超支、团队离散而制定
20、 出的一些监测和控制项目的方法，而是赋予团队信任和自治、全力支持团队以满足客户需要、最大化交付价值的方法。迄今为 止，我已经以敏捷方法为主题做了近8年的讲座，工作成绩得以飞速提升的学员不计其数。他们不仅跨越了知识和经验的门槛， 运用“新式武器”打击顽固的症结，而且窥破了敏捷方法的奥秘，在工作中变得“放下”和轻松许多，仿佛不知不觉中，封存起 来的内在力量冲破禁锢释放出来。他们能够全神贯注于自己感兴趣的工作，将精力和时间用在对人生和企业有价值的事情上。他 们明白在职场中要做到不复制、不模仿，在团队中要证明自己的差异价值，通过真实的自己来影响和带动团队，成为团队中独具 一格的领袖。这就是敏捷思维的有
21、趣之处。敏捷思维是一种非颠覆性的创新，以“实现最小代价换取最大回报”为价值度量， 在“简化工作流程+合理运用工具+智慧管理人心”的平台上实现降低产品交付成本且全心成就客户。 从2006年开始接触敏捷方法至今，我目睹了很多实践者追求和学习敏捷方法的热情不断熄灭在荒废的半成品中，也不断听 说某些敏捷讲师将客户敏捷部署不落地的原因归结于企业领导的不理性、不支持或团队人员的素质低下。于是，我决心写一本书 来为敏捷思维正名。事实上，我的敏捷实践也历经了长达8年的探索，尽管我有着得天独厚的成长环境和开明的企业平台，但我 所走过的路，包括部署敏捷方法、推行新工具、培养敏捷团队、改良和变革企业流程和模式，每一
22、步都布满荆棘。不过，坚持到 今天，相信很多有过相似经历的人一定像我一样，正在品尝努力付出所结出的硕果。但是，至今也没有一部深度探索敏捷思维变 革和企业级敏捷转型的书籍出版，于是，2013年春节，我开始了本书的写作。 第1章引出“何为敏捷”的问题，从Scrum方法出发，展示敏捷的价值，介绍敏捷方法的基本构成。同时，该章还将以IBM 公司为案例，解析IBM作为一家有先进管理理念的大型企业，在面临外来挑战和内部革新的内驱力时，为何选择敏捷作为自身变 革的策略，展示企业敏捷转型中可能面临的挑战和光明前景。 第2章通过一些典型案例，分析敏捷转型困境，总结敏捷实践误区，指出Scrum等核心敏捷方法的局限性
23、，特别是与国内企 业相结合时所暴露出来的水土不服问题。这一章还介绍了项目经理的重要作用，对比了传统项目管理模式和敏捷项目管理模式， 向敏捷项目管理转型的企业提出了忠告和建议，并在最后总结了13条“敏捷实施法则”。 但是，仅仅照搬别人的成功方法还不能保证改革的成功，必须活血化瘀，疏通承载方法的实体，即“人”与“工具”的任督 二脉，使得敏捷转型平滑、系统地进行。根据“人”的职业养成阶段、“工具和技术”的成熟度、“政治、架构、企业文化”的 环境差异，“流程”也需要适当裁剪。必须让团队、团队负责人、产品负责人看到，风险可预期、转变非颠覆、目标可实现，他 们才能有信心并自发地配合企业由下而上的变化。 第
24、3章介绍了敏捷扩展模型（ASM）和规范性敏捷交付（DAD）方法。DAD是Scrum、Lean、Kanban等方法的复合体， 本章主要讲解该方法的特色，例如重要角色及其不同于传统敏捷的典型实践。为了清楚地分析DAD方法，与第2章Scrum房地产 公司的小故事呼应，本章讲述了一家DAD房地产公司如何通过自身的优势规避来自政府规划的重大风险，建造楼盘并取得项目 成功。本章以IBM Rational中国的转型为例，分享了以“工具+流程+人”为框架的敏捷转型实践。此外，还讲述了传统服装行 业中DAD方法的应用，并在最后以“敏捷开发者的一天”的故事来完整描述一个大型组织中敏捷方法的成功落地。 第4章介绍了
25、以敏捷思维开发商业模式的方法，并通过ASM因子的调整得到了适合10人以下初创团队的敏捷方法，同时指出 初创团队成功的关键在于建设敏捷团队，以及团队领袖、带头人作为灵魂人物在敏捷转型中的重要性。此外，本章还讨论了敏捷 团队建设的四个阶段和防止人才流失的方法，以及人格测评对招聘甄选和岗位匹配的影响。 第5章讲述人才培养中如何使团队自发地做到“自我管理、自我认知、自我控制”，特别是在团队建设、团队协作方面，通 过几个小故事模拟“三自”培养方法，手把手地教你如何通过心理学方法精细地打造一个“轻管理”的敏捷团队，分享“沟通和 倾听”的方法与技巧，降低团队建设中的“信任”成本。 第6章的主题是“非凡的测试
26、”，这是因为敏捷测试实属不易，有太多经验需要分享。同时，这一章也讲述测试生涯规划， 作为DAD敏捷方法的推崇者，详细讲述“独立测试”的必要性，测试的“决策影响力”、“投入产出效益”，“自动化测 试”的策略和规划方法，以及“自动化工具”的选择。通过“敏捷测试工程师的一天”的故事分享，帮助测试者在工作中学习如 何实现更高的自我价值。 目前，对于研发工作，我已经渐行渐远，而开始深入市场和客户需求、客户关系的梳理工作。但每当与客户们谈及其需求、 趋势，我们都会延伸到流程、管理，以及关于持续改进理念的探讨。通过这些交流，我不仅收获了客户的信任，也听到了更多有 价值的观点，遂在附录中分享了有关敏捷思维和敏
27、捷转型的常见问题和回答，并大胆推断了第二代敏捷“DevOps”持续交 付软件驱动的创新。此外，还介绍了一个以完整的IBM敏捷方案和敏捷实施体验帮助团队深入了解IBM规范性敏捷方法的敏捷大 赛活动，通过在线评分系统展示了一套简单的敏捷成熟度度量体系。 谢明志 2014年9月 第1章 敏捷思潮 1.1 变革悄然而至 1.2 最简单的敏捷交付 1.3 百家争鸣 1.4 Scrum 1.5 敏捷旅行 1.6 敏捷实施报告 1.7 案例分析：IBM的敏捷转型之路 1.1 变革悄然而至 新工业时代已经到来，为了迎接这场静悄悄的工业革命，产品交付团队中，从工程师到项目经理都在极力做出自我调整。医 药、软件、
28、汽车、集成电路等行业客户对新产品的不断需求以及行业研发成本的不断攀升，标志着从计划性开发方式到自适应式 开发方式的重大转变，这个转变使得那些仍然坚守预见性的旧思维和旧规则的工程师、项目经理陷入了大混乱，因为旧思维方式 正在迅速退出历史舞台。 2002年中期，加拿大多伦多市的Alias System公司开始开发Sketchbook Pro，这是一个与微软的Tablet PC操作系统几乎 同时发布的软件包。起初，它的管理和开发团队并不确定开发计划需要包括哪些细节，但团队成员有一个明确的产品构想和商业 计划，对于产品需要具备哪些功能有大体的想法。他们没有积极地参与市场营销，但有一个总体设计架构，并且
29、每两周提交一次 新测试完成的功能，然后根据产品测试的实际情况调整未完成的工作计划。最终，在微软发布日期（11月），该产品同步上 市，并因其高质量标准在市场上取得了空前成功。 在汽车业，日本丰田公司的副总裁大野耐一综合了单件生产和批量生产的特点，创造了一种在多品种小批量混合生产条件下 高质量、低消耗的生产方式准时生产（Just In Time，JIT）。JIT生产方式的基本思想是“只在需要的时候，按需要的量， 生产所需的产品”，也就是追求一种无库存或库存最小的生产系统。丰田公司始终要求以用户的需求为生产起点，强调物流平 衡，追求零库存。生产节拍由人工干预、控制，重在保证生产中的物流平衡，每一道工
30、序均要保证对后道工序供应的准时化。 上述产品开发方法指出了一个非常关键的问题，当研发成本减少到一定程度时，产品开发的整个经济学就会发生变化 以计划性、合规性为基础的开发流程转变为以适应性为基础的流程（构想、探索、适应）。这种演变是一种进化过程，就像生物 进化一样，但是它要比自然界的进化迅速得多。生物进化的流程是试验（突变和再结合）、探索（适者生存）和改进（产生更多 的生存者），而产品开发流程越来越类似这个流程。 开发过程的不确定性增加、进度不断被期望压缩，研发任务将不仅仅局限于工作室内部完成。新的营销理念需要我们从客户 参与管理和研发开始，还要以高质量为目标，对于服务精度和速度的要求也不断提高
31、。因此需要创新，需要适应新环境的新研发 过程，以更有效地增加产品价值并保持竞争优势。 事实上，大型公司对变革和创新的诉求比小型公司更加强烈，因为大型公司往往在新产品和交付新产品之间存在着更大的差 距。新投放的产品失败率高达59%，这个数字从20世纪90年代早期以来几乎没有变化。而且，半途而废或者（在市场上）失败 的产品消耗了46%的产品开发资源。虽然少数侥幸的公司还可以挽回败局，但真正成功的公司则越来越多地在实施敏捷交付方 法。 2006年的IBM全球报告（见图1-1）指出，鉴于市场和竞争压力，面对多元化的变革，如果不能快速适应，那么企业赖以生 存之基本，或者当下各种项目的最终价值可能会受到影
32、响，甚至可能失去商业价值。因此，CEO们认为需要具备在项目进行的 过程当中根据需要做出变革的能力。如果项目团队不能够在项目进行过程当中积极地对刺激进行反馈和变革，问题可能会接踵而 来。 图1-1 2006年3月IBM全球CEO调查报告 CEO们皆希望对项目进行有效的变革管理。这个过程应该包括对变化的识别和判断，对变化的商业价值的判断，对变化会 给项目带来的冲击和影响的判断，并将相应的信息提交项目投资人进行评估，最终由项目投资人决定是否将变化引入到项目当 中。如果变化被引入，项目投资人还应该考虑变化对项目的影响程度，并且为之配备相应的额外资源，如延长时间和追加资金预 算等。2006年，IBM决定
33、在公司推动模块化设计以提升整合能力的设计思路，并且采用简单、迭代的敏捷开发过程作为项目组 织和实施的重要决策。 敏捷绝不再局限于研发阶段，而是贯穿软件的生命周期，从产品的抽象概念，到客户渐渐体会到产品的真正使用价值，再到 解决方案在组织内获得成功，敏捷的价值无不凸显其中。若用一言以蔽之，敏捷的核心价值是充分地将人的时间、精力、金钱始 终集中在最有业务价值的部分，并以风险最小的方式将可用的产品推向市场。 1.2 最简单的敏捷交付 如果用敏捷方法生产钢笔，敏捷规划了四个重要功能组成部分，即笔芯、笔杆、笔帽和雕花，相应功能若投入市场可以获得 的价值分别为50、30、15和5。倘若每项功能开发所需的成
34、本一致，时间都是1个月，那么敏捷开发就是要将每个月的开放力量 投入到最有价值的部分，并依次类推。那么在没有生产规划的情况下，最开始的迭代应该将资源投入在钢笔笔芯部分，因为这个 部分可以带来最高的价值。而第一个迭代完成时，客户体验到了用钢笔书写的刚劲有力、笔锋回转、酣畅淋漓，因此决定了第二 次投资，即为钢笔打造第二项重要的功能笔杆，一个可以方便把握的笔杆，一个可以保护笔芯、防止墨水侧漏的笔杆。当 我们在第2个月全力完成此功能后，客户便拥有了第二个发布的功能。现在重新排列未完成的工作，此时客户给出重要的指示， 决定放弃在笔帽上的雕花功能而选择一个既可以将钢笔别在衬衣口袋又能够保护鼻尖的笔帽作为第三
35、项最重要的功能。因此，最 终我们仅仅用3个月就开发出来价值为50+30+15=95的新产品钢笔。节省下的一个月时间将投入到第二代钢笔的研发中， 很快，我们设计出第四项新功能节省墨水50%。因为每个月都能够从市场上获得产品推出的反响，所以我们将新功能的价 值评估为50。也就是说，我们用了4个月的时间，使用敏捷方法生产了145的价值，而且一共发布了4次产品，产品投产30天 后，我们就收获了价值为50的回报。 1.3 百家争鸣 如果用传统开发方式，也就是瀑布式模型来开发钢笔，将产品的架构划分为数据层、逻辑层、应用层和接口层，团队也划分 为相应的4个平行开发团队。每一层的架构和设计都需在代码构造前完美
36、地完成，因而为了实现产品的按期发布，四个团队都不 能独立将自己的产出在4个月内的任何时间向外发布，也就无法评估笔杆上的雕花是否比新加入的“节约墨水”功能更吸引用 户。所以，最后产出的产品虽然有50+30+15+5=100的评估价值，但在这个过程中投资者只得一次性投入4个月的资金，直至4 个月后才等到第一次面向市场的机会；而此时同类产品的竞争优势更加可观，产品实际带来的利润价值并没有预期的大。 图1-2给出传统开发过程与敏捷开发过程的对比。 图1-2 传统开发过程与敏捷开发过程对比 在此不过多列举敏捷方法，但值得一提的是核心的敏捷方法Scrum，以及可以与Scrum媲美的敏捷方法论。XP（eXt
37、reme Programming）更加适合35人的小型项目团队，DSDM（Dynamic Systems Development Methodology）与Scrum一样 更加适合大型团队的项目开发，还有Lean等方法。这些方法其实都可以在IBM的某些项目中窥见一斑，后文将具体讨论。 1.3.1 极限编程 极限编程（XP）是由KentBeck在1996年提出的。XP是一种注重协作、快速和早期软件创建的有技巧的开发实践方法，适 合10人以下的团队。XP是一个轻量级的、灵巧的软件开发方法，同时也是一个非常严谨和周密的方法。它的基础和价值观是交 流、朴素、反馈和勇气，即任何一个软件项目都可以从四个方
38、面入手进行改善：加强交流，从简单做起，寻求反馈，勇于实事求 是。XP是一种近螺旋式的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期，通过积极的交流、反馈以及其 他一系列的方法，开发人员和客户可以非常清楚开发进度、变化、待解决的问题和潜在的困难等，并根据实际情况及时地调整开 发过程。 极限编程的基本原则： 通过客户、开发团队、项目经理三方共同参加的会议来确定开发计划。 小版本发布：尽快发布，尽早发布。 通过系统隐喻（metaphor）让每个人了解整个系统。 简单设计：为明确的功能进行最优的设计，不考虑未来可能需要的功能。 重构（refactoring）：不断优化系统设计，使之保持简
39、单。 单元测试：先写测试，后写代码。 结对编程（pair programming）：系统的每一行代码都是两个人用一个键盘完成的。 代码集体拥有：开发队伍中任何人可以修改任何其他人的代码，代码不属于某个个人。 持续集成：至少每天将整个系统集成一次，保持一个能运转的系统。 40小时工作制：保证休息，保持体力。 现场客户：客户自己也是软件开发队伍的重要一份子。 编码标准：必须有统一的编码规范，确保代码的可读性。 关键词 测试驱动，结对编程，持续集成，重构，小版本发布，沟通。 1.3.2 水晶方法 水晶（Crystal）方法论由Alistair Cockburn在20世纪90年代末提出。他把开发看做是
40、一系列的协作游戏，而写文档的目标 是帮助团队在下一个游戏中取得胜利。水晶方法的工作产品包括用例、风险列表、迭代计划、核心领域模型，以及记录了一些选 择结果的设计注释。水晶方法也为这些产品定义了相应的角色。然而，值得注意的是，这些文档没有模板，描述也可不拘小节， 但目标一定要清晰，即满足下次游戏开始的条件。 对于水晶方法论，根据方法论的轻重可以分为透明水晶和橙色水晶等。透明水晶一般适用于轻量级的团队。不管是哪种水 晶，都会对团队的角色、团队的工作项和产出、核心实践、支持过程等进行定义。 关键词 协作，角色，文档，迭代，风险管理。 1.3.3 动态系统开发方法 动态系统开发方法（DSDM）倡导以业
41、务为核心，快速而有效地进行系统开发。可以把DSDM看成一种控制框架，其重点 在于快速交付并补充如何应用这些控制的指导原则。 DSDM是一整套的方法论，不仅仅包括软件开发内容和实践，也包括了组织结构、项目管理、估算、工具环境、测试、配 置管理、风险管理、重用等各个方面的内容。 DSDM的基本观点是，任何事情都不可能一次性圆满完成，应该用20%的时间完成80%的有用功能，以适合商业目的为 准。实施的思路是，在时间进度和可用资源预先固定的情况下，力争最大化地满足业务需求（传统方法一般是需求固定，时间和 资源可变），交付所需要的系统。对于交付的系统，必须达到足够的稳定程度以在实际环境中运行；对于业务方
42、面的某些紧急需 求，也必须能够在短时间内得到满足，并在后续迭代阶段中对功能进行完善。 DSDM的基本原则： 活动用户必须参与。 必须授权DSDM团队进行决策。 注重频繁交付产品。 判断产品是否可接受的一个基本标准是符合业务目的。 对准确的业务解决方案需要采用循环和增量开发。 开发期间的所有更改都是可逆的。 基本要求是高层次的并区分优先级（以在低优先级的项目上获得一定的灵活性）。 在整个生命周期集成测试。 在所有参与者之间采用协作和合作方法。 关键词 以业务为中心，用户参与，迭代，快速交付，团队协作和沟通。 1.3.4 精益生产 精益（Lean）管理的思想起源于丰田公司，旨在创造价值的目标下，通
43、过改良流程不断地消除浪费。这种方法现已被广泛 用于生产制造管理，对于IT系统建设，精益开发的常用工具模型是价值流模型，如图1-3所示。 图1-3 精益方法的价值流模型（括号内代表浪费的时间） 精益开发的基本原则： 杜绝浪费：将所有的时间花在能够增加客户价值的事情上。 推迟决策：根据实际情况保持可选方案的开放性，但时间不能过长。 加强学习：使用科学的学习方法。 快速交付：当客户索取价值时应立即交付价值。 打造精品：使用恰当的方法确保质量。 授权团队：让创造增值的员工充分发挥自己的潜力。 优化整体：防止以损害整体为代价而优化部分的倾向。 上述方法都是流行的敏捷方法。图1-4是VersionOne在
44、2013年发布的敏捷方法的使用情况。最主流的敏捷方法仍然是 Scrum，下面来看看Scrum是什么。 图1-4 敏捷方法的使用情况 1.4 Scrum 1986年1月的Harward Business Review期刊登载了一篇题为The New New Product Development Game的文 章，其要义说的是：“原有的接力跑式的产品开发模式一定程度上违背了以人为本、最大化生产力、灵活生产方式的原则。 相反，另一种独特的团队，采用橄榄球式的团队合作方式整个团队合作无间，灵活机动地接球、传球，并作为一个整 体迅速突破防线这可能更加适应今天更具挑战的市场需求。” 这就是Scrum源起
45、的故事，从产品研发的角度来理解这个恰到好处的比喻，可以更好地理解Scrum的精髓： Scrum使我们能够专注于如何在最短的时间内实现最有价值的部分。 Scrum使我们能够快速、经常地监督实际产品的发展状况（每两周或一个月）。 按照商业价值的高低先完成高优先级的产品功能，采用自主管理模式，凝结团队智慧创造出最好的方法，因而效率提高。 每隔一两周或者一个月，就可以看到实实在在的可以上线的产品。此时，可以进一步决定是继续完善功能实现更多需求或 者直接发布。 Ken Schwaber在他的书中指出，Scrum不是一种构建更好产品的方法，也不是快速构建高质量软件的方法。Scrum是一种 工具，一种可以帮
46、助我们找到用来快速构建高质量软件的要素的工具。 1.4.1 发源与发展 Scrum之父Jeff Sutherland于1993年在Easel Corp提出了Scrum的方法，而大师Ken Schwaber创作并出版了三本有关 Scrum的书：Agile Project Management with Scrum、Agile Software Development with Scrum、Enterprise Scrum，Scrum自此开始坚实地扎根于软件行业。 2002年，Ken Schwaber和Mike Corn联合创办了Scrum Alliance（Scrum联盟）。在发布后的10年内，
47、Scrum相继被微 软、雅虎、谷歌、飞利浦、西门子、IBM、第一美国不动产经纪公司等知名企业采纳，所涉及的领域已经超出了软件研发的范 畴，涵盖嵌入式系统、游戏、网站、手机、网络交换设备等众多领域。 1.4.2 自我管理 Scrum方法并没有特定的工程实践惯例，但是定义了几个角色，例如，团队（Team）、团队负责人（Scrum Master）、 产品负责人（Product Owner），以及角色相应的职责。团队这个角色被注入了“自我管理”的使命，团队成员会主动朝着产 品研发的进展方向规划自己的迭代计划、日计划，并主动完成工作。产品围绕着产品清单（Backlog）展开，这个清单作为一个 容器容纳所
48、有待完成和已完成的工作项，而每个工作项都可以继续拆分和重新排列优先级，当Scrum开发开始时，团队将从中选 择重要且能够完成的产品清单，在24周内完成这些产品清单的发布。产品正是通过一次次的迭代（Sprint），由增量构建的产 品清单所组成的。 Scrum同XP、水晶等方法一样均属于敏捷方法范畴，敏捷宣言强调，在项目实施过程中： 1.拥抱变化（embrace the change） 无论多么明智、多么正确的决定，也有可能在日后发生改变。因此，团队要充分理解利益关系人（Stakeholder）和客户代 表为什么经常提出新的需求，一句话，“唯一不变的是变化”。团队要相信利益关系人做出的每次决定和需
49、求调整都是将产品开 发推向更正确的发展方向，新变化将进一步降低风险，实现团队最大化利益，这是适应市场变化的必然行为。 而在接受变化的同时，我们应该积极地向利益关系人和客户代表反映开发过程中暴露出来的可能的设计缺陷和错误。在实际 工作中，团队成员应该用优先级制度来划分事情和目标的先后顺序，在迭代周期内，对于还没有最终决定的设计方案，可以置后 实现、测试，不用急于投入资源展开全面的开发、测试活动。这样一来，开发、测试团队也将更加适应，真正拥抱变化。 2.客户的参与（with customer representative on site） 首先，谁是客户（Customer），谁又是客户代表（Customer Representative）？利益关系人可以理解为客户、产品的最 终使用者（End User）、内部使用者（Insider User）和商业伙伴（Business Partner）。利益关系人作为团队中最了解业务的 人，将帮助开发团队快速达到目标和做出适时决策。开发团队拥有很好的技术，但在业务方面需要利益关系人的帮助。通常在敏 捷的开发项目中，当团队中的任何一个人需要帮助时，只要简单地邀请大家参加一个15分钟会议，或一封邮件、一个电话便可