精益产品开发/principles, methods, and development/原则、方法与实施_何勉_9787302476559

全书分为两部分, 第1部分侧重于比较看板和Scrum, 帮助读者更好地理解它们, 而不是判断孰优孰劣。工具没有好坏之分, 只有不恰当的使用场合和使用方式。第2部分是案例分析, 讲述在使用Scrum的组织中, 为运维和支撑团队而实施看板的过程。本书与《硝烟中的Scrum和XP》的风格一致, 行文轻松诙谐, 同时辅之以案例实践和图示。

　　前言：新常态下的精益产品开发和创新

　　2008 年，我开始在自己的产品开发部门尝试敏捷实践，当时这样做是前卫的，有争议的。9 年后的今天，大部分组织争论的焦点不再是要不要变得更敏捷，而是“如何才能做到”，后者从来都是个难题。

　　10 年间，敏捷实践不断完善，但实施难度却变大了。不是我们的进步不够快，而是现实要求越来越高。移动互联网技术改变了我们的生活，对各个行业的冲击更加剧烈。新的商业模式和技术革新不断涌现，新入者随时有机会脱颖而出，传统的优势厂商则随时面临巨大的挑战。

　　美国军方曾经用四个特性来概括冷战后的世界：易变 (Volatility)；不确定 (Uncertainty)；复杂 (Complexity)；模糊 (Ambiguity)。它们的首字母合在一起是 VUCA，“VUCA World”在 20 世纪 90 年代是常用的军事术语，用以形容全球政治和军事格局。21 世纪以来， VUCA 被更多用于形容商业格局和企业所处的生态，成为我们当下移动互联时代和即将到来的机器智能时代的最佳注脚。

　　在 VUCA 的世界中，黑天鹅和跨界打劫司空见惯。胜出者的共同特点是拥有快速反应和把握机会的能力以及系统化的试错、创新和价值创造能力。拥有这些能力就有机会快速上位，反之则随时可能被淘汰出局。而随着信息技术向纵深的发展，再传统的行业也不可能置身事外，这是企业运营和产品开发面临的“新常态”。

　　面对新常态，人们不再怀疑敏捷的必要性，而且要求的更多。产品的持续创新事关生死，产品开发部门不应该再被看成组织内部的成本中心，而是要成为价值探索、发现、创造和验证的创新中心，是企业的核心竞争力所在。

　　今天我们讲敏捷与 10 多年前相比，对它的要求发生了根本改变。 2001 年《敏捷宣言》发布时，针对的是软件开发，所以它的全称是《敏捷软件开发宣言》， 17 位起草人也全部是软件开发专家，宣言的本质是寻求更好的软件开发方法，强调了软件开发中的有效沟通、迭代交付和灵活应变。上图是宣言的内容，它引领了软件开发方法学的思潮，直到今天仍旧在发挥重要的作用，但今天我们再讲敏捷，要求有了以下本质上的提高。

　　我们尊崇“个体和互动”，更要“连接和打通组织的各个职能，以确保协调一致的行动”。

　　我们尊崇“可工作的软件”，更要“聚焦端到端的价值流动，以快速、灵活和持续地交付真实的客户价值”。

　　我们尊崇“客户合作”，更要“与客户建立共同目标，以最大化业务成果”。

　　我们尊崇“响应变化”，更要“有计划和系统地主动试错，以支持有效地学习和创新”。

　　“一致行动，快速、灵活和持续地交付真实的客户价值，最大化业务成果，有效地学习和创新”，这是新常态对产品开发组织的敏捷性要求。与这一要求相对应， 10 年间我们看到了另一个显著的变化——精益思想和实践被广泛和深入地应用在产品开发当中，无处不在。

　　�6�1 精益成为几乎所有规模化敏捷框架（如 SAFe、LeSS 等）背后的重要方法学支撑。

　　�6�1 精益看板方法得到越来越广泛的应用，为敏捷变革和提升组织交付能力提供了新的路径。

　　�6�1 精益创业成为热点，精益创业理念和实践开始被广泛接受和实施。

　　�6�1 DevOps 实践开始普及，而精益价值流动的思想在 DevOps 实践体系中扮演了重要的角色。 2016 年下半年，我开始在自己的公众号“精益产品开发和设计”（微信号LeanAction）发文，总结精益设计和精益看板方法实践，受到了圈内圈外超出预期的关注，很多朋友从这些文章开始实施精益开发方法，我几乎每天都能收到不同形式的反馈。有

　　的甚至成立学习小组，每周学习一篇文章，坚持了数月。这让我决定更系统地总结精益产品开发实践，最终形成今天您手上的这本书。

　　本书的目的是为组织的精益和敏捷实施和提升提供原则、方法和实施步骤的有效指引，帮助企业打造移动互联网时代的产品交付和创新能力。它的适用范围涵盖几个人的创业团队到华为与招行这样的大型组织。

　　写作本书时，我对自己有三个要求：其一，所有实践都必须有真实案例支持；其二，所有案例都必须来自本人的实践；其三，只选取那些被证明有效且易于实施的实践。

　　本书案例全部来自华为、招商银行、平安科技、上海爱数软件以及几家创业公司，作者与这些公司都有两年以上持续而深入的合作。

　　本书适合的读者

　　本书适合以下读者：

　　�6�1 希望开始实施精益或敏捷开发的组织或项目管理人员

　　�6�1 已经实施敏捷和精益开发，但遇到困难和阻力的组织或项目管理人员

　　�6�1 已经实施敏捷和精益开发，希望进一步深化和拓展的组织或项目管理人员

　　�6�1 希望了解精益和敏捷产品开发方法和实践的产品开发从业人员

　　�6�1 希望提高产品开发交付和创新能力的各类角色

　　如何阅读本书

　　本书分成三部分，分别介绍精益产品开发的原则、方法和实施。

　　第 I 部分“精益产品开发的原则”介绍敏捷和精益开发的目标、思想和原则，并由这些原则出发，构建完整的精益产品开发实践体系。

　　第 II 部分“精益产品开发的方法”介绍看板方法实践体系，用看板方法来承载组织的交付流程和价值交付能力的持续改进。

　　第 III 部分“精益产品开发的实施”将从破解资源效率和流动效率的悖论出发，介绍精益产品开发的实施步骤，并详细介绍需求管理、质量改进、团队管理等方面的实践和实施。在这一部分，我还请到了两位大咖分享他们的的洞见和实践。其中，吕毅分享了关于 Scrum 的洞见，并比较了 Scrum 和看板方法，王津银分享了 DevOps 的实施原则。他们两位在各自的领域都是国内最顶级的实践者和专家。

　　本书三个部分具备一定的连贯性，同时也可以独立存在。大家可以根据自己的需要和兴趣有重点地阅读或作为备查。但是，我个人认为从头阅读收获会更大。

　　第1 章从传统向敏捷软件开发的演进

　　在产品开发中，“敏捷”和“精益”这一对热词如影随形。精益产品开发离不开对敏捷软件开发的深入理解，所以我们的精益之旅也将从敏捷软件开发开始。本章讲述软件开发从传统进化到敏捷背后的业务动因以及敏捷软件开发实践体系。

　　传统软件开发方式面临的挑战

　　传统软件开发方法是与软件工程的概念一同诞生的（图1-1）。1968 年，北约（NATO）召开全球第一届以“软件工程”命名的会议，这次会议通常被视为软件工程诞生的标志。会议上提出了“软件危机”的概念。随着软件复杂度的不断提高，软件项目普遍出现预算超支、质量低、性能差、不符合实际需求和延期等问题，造成所谓的“软件危机”。

　　图1-1　传统开发方法的产生历程

　　当时，业界普遍认为，软件行业应该借鉴工程领域的经验，“系统地应用工程管理方法”，以此来应对软件危机。这是软件工程诞生的背景，在这一思路下产生的软件开发方法就是传统软件开发方法。它们共同的特点是强调计划、管控和结构化的工程方法，并遵循严格的生命周期概念，把软件开发分割为顺序阶段构成的过程，瀑布式开发方法是其中的代表之一。

　　相比作坊式的开发，传统方法开发方法进步明显。它让产品开发有矩可循，让项目和产品的成功可以重复，让组织的能力可以被评估，这些当然是好的。图1-1 是传统开发方法的大致发展历程，到了上世纪90 年代初，CMMI 和PMI 项目管理知识体系[1] 成为传统产品开发管理方法的典型代表。

　　然而，传统方法并没有从根本上解决软件危机，软件项目的失败率依然居高不下，甚至越来越糟糕。在这方面被引用得最多的是Standish Group 定期发布的IT 项目报告[2]，该报告在1994 年第一次发布时的数据显示，项目成功比例只有16%，有31% 在发布前就被“砍掉”，剩下的53% 平均超出了预算189%。

　　人们认识到，遵循严格生命周期的概念，把开发分割为顺序阶段构成的过程，实施起来不现实，造成了以下直接的危害。

　　�6�1 希望通过对各个阶段设置关卡，严格控制，以期更早地发现问题，却滞后了集成和测试，让错误的发现延迟到最后，这是很多项目失败的根源。

　　�6�1 希望一开始就能设定完整和正确的需求，这对软件产品越来越不可能，因为用户也不知道或说不清楚自己想要什么。事实上，对需求的挖掘和理解，应该是一个持续的过程，需要不断的反馈。

　　�6�1 把成功定义为“遵循最初的计划和范围”。为了确保项目的“成功”而避免或拒绝进行合理的变更，却忽略了“达成商业目标才是真正的成功”。这已经成为业务成功的一个严重障碍。

　　另一方面，传统产品开发方法强调控制，所以一旦流程出现问题，自然的应对就是进一步加强管控，流程本身有自我复杂化的趋势，反而会压制关键软件开发人员的主观能动性。

　　面对以上问题，对传统软件开发方法的反思，几乎与其本身一样悠久。比如，瀑布模型的提出者Wiston Royce 1970 年在他的论文[3] 中，只是把瀑布模型作为一个理论模型提出，并警告人们它绝对不适合用来进行大型软件开发。在论文的后半部分，Royce 提出了一个包含原型和各阶段之间反馈的修正模型。遗憾的是，业界当时渴望的是一种建构式工程方法，瀑布模型迎合了这一要求，导致反对瀑布模型的Royce 反倒被业界称为“瀑布模型之父”。至于Royce 的忠告，也只有等到30 年后敏捷运动兴起时才又被人们重新提起。

　　从传统到敏捷

　　面对传统软件工程方法的现实问题，一批轻量级的软件开发方法陆续涌现（图1-2），它们共同的特点是遵循演进和迭代的模型。其中，上世纪90 年代出现的Scrum 和极限编程在实践上最为成功，它们都是迭代和增量的软件开发框架。两者的区别是，Scrum只包含管理实践，而极限编程同时涵盖工程和管理实践。

　　图1-2　敏捷产生和发展的历程

　　上世纪90 年代，另一个主要变化是PC 软件流行和第四代编程语言的出现，面向对象和设计模式运动的兴起，使小型开发项目蓬勃发展，同时互联网应用和开源社区也在此时兴起，有别于传统的开发模式不断涌现，优秀个人在程序开发中的作用越来越明显。

　　这些因素都让非传统开发方法有了实验的土壤。其结果是，一方面质量问题层出不穷，促使源自全面质量管理体系的CMM/CMMI 在这一时间迅速繁荣和推广；另一方面也产生了许多不同于传统方法的有效实践，让业界看到新的可能。敏捷运动这时呼之欲出，它既是对传统的反叛，也是对野蛮生长的规范。

　　2001 年2 月，17 位轻量级软件工程方法的代表人物齐聚美国犹他州的雪鸟滑雪胜地，在两天的会议之后，发布了对后来产生巨大影响的《敏捷软件开发宣言》[4]，如图1-3所示，敏捷宣言陈述了他们共同认可的软件开发方法理念，同样重要的是，他们找到“敏捷”这个词来总领这些理念。

　　敏捷概念在2001 年出现，可谓适逢其时。当时一方面，传统方法变得越来越臃肿笨重，却没有解决软件危机；另一方面，人类正在进入互联网时代，软件业对响应变化和创新的要求迅速升级，这是更根本的原因，毕竟需求才是行业发展最好的助推剂。很快，敏捷成为一场运动，被迅速推广和应用。

　　图1-3　《敏捷软件开发宣言》

　　理解敏捷必须回归业务视角

　　《敏捷宣言》属于价值观层面的宣导，对敏捷的推广和公众的认知起到了很大的作用。但对于敏捷是什么，却从来没有统一的定义。2010 年，软件工程大师Ivar Jacobson 在一篇博文中这样说：“过去你问我支不支持敏捷，我会说哪些支持，哪些不支持，并给出我的理由。但现在你再问，我就只能回答支持。因为，如今敏捷的意思已经演变成“软件开发中一切好的东西（Everything good about software development）。”Ivar 一语道破了真相。如图1-4 所示，敏捷成了一个集合性的概念，一切好的，都归入敏捷，而一切失败，都归于不敏捷。这在商业上或许不错，却不利于概念的明晰和有效实施。

　　毕竟，要真正理解敏捷，还是要回归业务目标。产品开发的最终目标是业务成功，这是没有异议的。接下来我们将从目标出发，理解敏捷的意义所在，并以此来指导我们具体落实敏捷实践。

　　图1-4　雾里看花，敏捷是一个集合性名词

你还可能感兴趣

我要评论