没有控制的快速开发可能是技术研发的劲敌。你应该放慢速度的三个主要领域是人员、流程和产品。在深入讨论细节之前，让我先讲一个故事。

大概是在2011年，我加入了一个团队，负责建立一个在线营销平台。我的主要职责是尽快为系统添加新功能。很快我就发现由于前期的技术债务和设计挑战，我们不可能快速完成。几乎每次尝试加快速度，我们都适得其反地增加了复杂性并破坏了质量。在我看来，唯一的方法就是重新编写整个系统。

我记得，我打电话给产品经理说我们需要重写整个系统。电话沉寂了30秒后，项目经理说：“你说你的团队写的产品质量太差，以至于同一团队不得不再次重写相同的产品，但这次更好。对吧？对不起，伙计，这是不可接受的。你应该写得更好。”

盲目求"快"产生“僵尸软件”

根据Standish Group的Chaos报告，94%的项目都是多次从零开始重新开发的。94%！不忍直视啊！当我查看过去开发的产品时，我发现几乎所有的产品都是用新技术、架构和设计从零开始重写的。重写是如此普遍，以至于企业常常将其视为项目管理和创新的唯一选择。我们写啊，写啊，写啊，写啊，写啊。

什么是技术研发中最大的敌人？在研发世界中，速度是至关重要的。不仅对于在市场上处于领先地位很重要，而且通过添加新功能和快速消除bug来响应客户的需求也能保持客户的高满意度。但我们都有“速度”的问题。我们认为，更快、更聪明、更高效地完成任务与设定目标的截止日期有关。我们认为花更多的时间工作，或者与更多的人一起工作，就可以“更快”。因此，我们要么增加新员工，要么加班加点提高生产效率。

然而，匆忙既不会让我们更快，也不会让我们更多产。匆忙只会增加压力，分散注意力，破坏效率。相反，我们需要创造力、效率和专注。

技术研发是非常困难和复杂的。我们无法摆脱复杂性，只能接受它。对速度的追求创造了一个不稳定、不可持续的环境，使我们压力更大、注意力更不集中、效率更低。

团队能力、总体规划、估算、固定工作时间、截止日期和速度概念都是虚构的；无能是现实。

交付时间直接依赖于人员的技能、流程的效率和产出的质量。大多数情况下，开发人员给自己设置了隐藏的截止日期，而没有任何实际需要。

最终，我们得到了遗留产品。最后期限的压力加上无能导致了遗留产品，即死胡同。我给遗留产品起了个更合适的名字：僵尸软件——因为这类产品实际上已经死了，但似乎还在生产中。它在生产中起作用，人们从中获利，但是它需要开发人员的血液、生命和精力来以某种方式继续工作。开发人员不敢碰它，只要它能工作，没有人想要改变它。

Robert C. Martin在twitter上对僵尸软件的症状有一句完美的描述：“如果你的产品越来越难开发，那你就做错了。”“在匆忙中，我们破坏了质量，以至于我们每向前走一步，整个过程就会变得更慢。”我相信，慢下来，直到我们达到一个可持续的状态是唯一的加快速度的方法。

在软件开发中，匆忙是罪恶的

正如Robert C. Martin在谈到CleanCoders的主要价值时提到的，“系统能够容忍和促进这种持续变化的能力是产品的主要价值”。在软件开发中，匆忙是罪恶的。任何匆忙的尝试都会在生产力、注意力、人的效率、适应能力和对产品的容忍度方面造成破坏。

例如，我们总是有时间来修复bug，但是没有时间来编写测试。我们没有重构和编写测试，因为我们没有足够的时间。但我们有时间调试和修复bug。

我们过于关注过程，以至于经常忘记技术研发中的主要资产：人员。流程帮助人们改进他们构建产品的方式，增加动力，培养健康的环境。流程的效率也很重要，但人员是关键。

我们必须承认，没有人和事是完美的。客户、老板、经理、团队成员、友商，甚至你自己，都远非完美。需求、文档、工具、代码、构建的系统和设计，也永远不会是完美的。因此，我们必须停止不受控制的匆忙和加速。要想以可持续的速度更快发展，唯一的方法就是放慢速度，这主要体现在三个方面：

️◉ 任用提高专业水平和工艺的人才

◉ 提高适应和效率的流程

◉ 应用提高自动化和质量的产品

当涉及到人的时候，要放慢速度

流程和工具不会生成产品，生产产品的是人。我们必须承认，“人才招聘”是一个组织最重要的功能。它直接影响到公司的未来和产品本身。

为你的组织雇佣最优秀的人才。我所说的“最好的”并不是指最聪明、最有经验的人，而是寻找至少具备激︎情、纪律和动力三要素的人才。如果一个人具备这三种特质，那么其他技能的增长对他来说将不是问题。

招聘是一个双赢的过程，双方都应该从中受益。所以你应该放慢你的招聘进程，并投资改善它。人们会加入他们相信的公司。所以，请为你想要看到的行为建模，通过你的公司文化、你的愿景和你的员工，让人才相信你。

自我会慢慢地杀死你的组织。永远不要让自负进入你的组织。从可爱的傻瓜到天才蠢货，永远不要让极端的人加入你的团队。永远不要雇佣自负的人。和这些人在一起，你永远无法建立让人钦佩的公司文化。

停止独自工作，开始一起工作。永远不要让筒仓（一个人的深井）发生，因为筒仓或英雄开发者是组织功能失调的症状。让团队紧密地坐在一起，两人一组，多人一组，一起定义团队标准，一起工作，一起切磋。让团队共同承担责任。

一起练习是提高技能最有效的方法。在合作中，我们不仅相互激励也互相学习。让知识在人与人之间流动。

从2010年开始，我每周都在自己的团队中组织Brown Bag / Lunch & Learn课程。我多次听到我的同事说，“每周三参加会议能让我提高自己，这对我很有激励作用。”这反映了公司内部定期会议的影响力。

收集并提供反馈。为了收集集体反馈，你可以像我多年来所做的那样，组织Grand Retrospectives（大型“复盘”会）。顺便说一下，Grand Retrospectives是一种新型的挖掘问题的复盘会议，每次有20多人参加。

教学和分享是掌握一个主题的最佳方式。做一名演讲者并回馈社区。

开发人员似乎讨厌文档，但实际上恰恰相反。人们阅读的任何输出都是一个简单朴素的文档;从生产代码本身到测试代码，从提交消息到提交图表，从日志消息到错误消息，开发人员无意中记录了很多文档。所以，无论你记录什么，因为人们读它是为了理解，所以请尽可能把它做得更好。

你不是孩子。公司不是你的父母。我们必须拥有自己的事业并投资自己。如果投资意味着花费时间和金钱，那就自己动手吧。

如何通过减慢速度来优化流程?

每一天，我们都面临着新的挑战。这些挑战不应仅仅是市场需求或新要求。技术挑战对我们的进步也有很大影响。

计划什么都不是，但计划就是一切。计划常改常新。特别是在创业的早期阶段，团队需要非常敏捷。通过每日Scrum或每日站会，每天一次校准计划是不够的。你们必须紧密合作，每天不止一次地校准计划，保持迭代的长度较短，最短为一周。通过组织定期的评审和演示会议来创建多个反馈循环通道。

定义短期目标和长期目标。短期目标为团队创造了焦点，长期目标可以防止注意力分散。

如果你想了解哪里出了问题，可以从可视化流程开始，包括技术上的和业务上的。想象失败和糟糕的事情来促进你从过去的经验中学习。

永远不要凭直觉做决定。始终收集数据，并根据数据分析做出决策。允许每个开发人员访问产品和代码指标也很重要。这增加了产品开发的集体所有权和常识。

浪费是你生产的任何没有商业价值的东西。检测并消除办公室、代码和流程中的浪费。童子军们把露营地弄得比他们来之前还要干净。同样的理念在技术研发中也适用。遵循童子军规则，让你的代码更简洁。当你打开一个文件来添加新功能并注意到其中的一个问题时，请在无需提示、无需许可的情况下自觉修复它。在修复问题之前，不要忘记编写测试。这能使你对自己写的代码感到自信和舒适。

你可以在技术研发生命周期的每个点上检测浪费。遵守你对已完成任务的定义，消除“90%完成，90+剩余”的任务。不要留着那些长得太长的“树枝”，它们是邪恶的。不要通过手动测试来验证代码，手工测试只会验证快乐路径。所有其他场景只能通过测试代码进行验证，所以要认真对待。

放慢速度如何提高产品质量?

有一点很清楚，没有高质量的代码库，就做不到敏捷。你需要做的第一件事是消除技术债务并解决bug。或许你需要停止构建功能一段时间，专注于消除bug。

“修复bug并在之后部署到服务器”这样的流程包含着风险和危机。我们需要换一种更好、更有效的方式。当你想要修复一个bug时，首先编写测试并以编程方式重现问题，然后修复bug并检查测试是否通过，之后部署到生产环节中去才是安全的。

我所在的团队几乎把所有的时间都花在修复bug和维护代码库上。这会影响效率。为了在修复bug的同时继续开发新特性，你需要将你的团队划分为虚拟团队。例如，我们在每个迭代中选择两个队友来提供直接的技术支持，并继续修复bug。我们叫他们蝙蝠侠和罗宾。无论你正在处理哪种特性，都必须不间断地修复bug。

如今，开发人员通常使用一种方法来减缓进度，以便加快速度——使用拉取请求（pull requests）。他们停止生产线，进行验证和代码审查，以提高代码质量。他们从不将未经审核的代码部署到生产环境中。

我们的最终目标应该是实现持续交付，并经常发布。从git分支机制到部署策略，从反馈机制到自动化测试实践，都需要不同的思路。

你在SDLC中使用的实践表明了你的开发速度。对于git分支机制，“尽早提交、经常提交、稍后完善、发布一次”的理念和基于主干的开发，以及功能切换，可以最大程度地消除浪费。

我已经使用TDD很多年了。许多人向我抱怨TDD对编程速度的影响。Joe Rainsberger在twitter分享了他对TDD的看法：“担心TDD会减慢程序员的速度？他们可能正需要慢下来。”

TDD的重构多于测试，思考多于编码，简单多于优雅。这就是为什么它能带来更好的质量。通过TDD开发，有足够的测试和简单的设计。

你是否曾经达到100%的代码覆盖率?我在一个为期三个月的项目中做到了这一点。我为每一行生产代码编写了单元测试。那时，我觉得自己像一个拥有超能力的英雄。但是当我们部署到UAT的预生产环境时，我发现有四个功能无法工作。我不得不编写集成和功能测试来检测bug并解决它们。然后我意识到单元测试并不能保证良好的设计和工作功能。停止计算代码覆盖率，那玩艺儿毛用没有。

如果你需要30分钟或更短时间来修复bug，别犹豫，直接干！此外，用20％的时间消除技术债务。

通常我们编写代码避免将来要修改它。同样，当我们设计产品时，我们选择适当的技术和工具，以便将来不需要修改它。但我们错了。重构应该出现在开发过程的每个阶段。正如Kent Beck所说，我们必须做一些简单的改变来让改变变得简单。为了实现这一点，我们在一个mono存储库中管理所有的微服务。Mono repository用于简化重构，正是我们所需要的。

把放慢速度当作一种哲学

AndreasMöller在一条推文中提到了他对技术研发的看法：“我不想写那些只能工作的代码：我想写干净、可维护、易于理解和经过充分测试的代码。”

为了实现这一目标，我们需要关注三个领域：人员、流程和产品。

◉ 减少人员，我们的目标是提高专业水平和工艺水准。

◉ 放慢进程，我们的目标是提高适应能力和效率。

◉ 放慢生产速度，我们的目标是提高自动化和质量。

当我们专注于这些领域时，我们开始培养一种能够快速研发的开发文化。

我们不应该忘记以下几点：

◉ 可工作的产品不一定制作精良。

◉ 只有优秀的专业人士才能制作精良的产品。

◉ 只有制作精良的产品才能让你比以往更快地构建功能。