匆忙既不会让我们更快，也不会让我们更有效率；它会增加压力，分散注意力。我们需要创造力、效率和专注力。
聘用更优秀的人才，一起工作，一起实践，一起学习，以提高专业水平，在您的组织中培养技能。
通过制定计划并经常修订、收集、分析和消除浪费，提高团队的适应性和流程的效率。
如果没有一个高质量的代码库，你就不可能是敏捷的。降低缺陷，频繁地发布，先测试，然后重构并专注于简单的设计。
可工作的软件不必是精心制作的。只有优秀的专业人员才能构建精良的软件，而且只有精良的软件才能让您比以往更快地构建。
缺少控制的快速发展可能是软件开发的最大敌人。您应该放慢速度的三个主要领域是人员、流程和产品。在深入讨论细节之前，让我先讲一个故事。
我猜那是2011年。我加入了一个团队，负责建立一个在线营销平台。我的主要职责是尽可能快地为系统添加新功能。嘿，我是高级开发人员。当开发人员能够比其他人更快地开发时，我们就称他们为“高级开发人员”。然而，当我加入时，我们注意到，由于技术债务和设计挑战，几乎不可能走得很快。在每一次尝试加快速度时，我们都注意到我们增加了复杂性并破坏了质量。在我看来，加快速度的唯一方法是从头重写整个系统。
我记得，我打电话给产品经理，说我们需要重写整个系统。在电话中沉默了30秒后，项目经理回答说:“你是在说你的团队写的产品质量太差，以至于同一个团队不得不重写同样的产品，但这次做得更好。对吧？对不起，这是不能接受的。你应该写得更好些。”
僵尸软件需要一次又一次的重写
根据Standish Group的Chaos Report， 94%的软件项目都是多次从零开始重新开发的。类似地，当我查看过去开发的产品时，我发现几乎所有的产品都是用新技术、体系结构和设计从零开始重写的。重写在这个领域非常普遍，企业常常将其视为项目管理和创新的唯一选择。我们写，重写，再重写，一次又一次。
我们必须了解软件开发中我们最大的敌人。在软件世界中，速度是至关重要的。不仅对于成为市场上的第一是重要的，而且通过添加新特性和快速消除bug来响应客户，保持客户满意度高。但我们都有“速度”的问题。我们认为，更快、更聪明、更有效地行动与设定目标的最后期限有关。我们认为更努力的工作或与更多的人一起工作，我们会走得更快。因此，我们要么增加新员工，要么加班加点提高产量。匆忙既不会让我们更快，也不会让我们更有效率。匆忙会增加压力，分散注意力，破坏效率。我们需要的是创造力、效率和专注力。
软件开发是非常困难和复杂的。我们无法摆脱这种复杂性。因此，我们必须接受它。对速度的过分要求创造了一个不稳定、不可持续的环境，使我们压力大、注意力不集中、效率低下。但速度仍然很难被提高。交付时间直接取决于人员的技能、流程的效率和输出的质量。
最终，我们留下了很多工程债。最后期限的压力和无能导致了这些债，即工作的死胡同。我称呼它们为僵尸软件。因为这类软件实际上是死的，但似乎在生产中仍然存在。它在生产中起作用，人们从中赚钱，但是它需要软件开发人员的血液、生命和精力来继续工作。开发人员不敢碰它，因此如果它能工作，没有人想要改变它。
Robert C. Martin有一句关于twitter上遗留软件症状的完美名言:“如果你的软件变得越来越难开发，那说明你做错了。“在匆忙的时候，我们破坏了太多的质量，以至于我们每向前走一步都会让整个过程比以前更慢。”我相信，慢下来，直到我们达到一个可持续发展的项目，才是我们能快起来的唯一途径。
在软件开发中，匆忙是大忌
正如Robert C. Martin在CleanCoders中提到的软件的主要价值，“软件系统能够容忍和促进不断变化的能力是软件的主要价值”。在软件开发中，匆忙是罪恶的。任何匆忙的尝试都会对生产力、注意力、人们的效率、适应能力和对软件的容忍度造成极大的损害。
例如，我们总是有时间来修复bug，但是没有时间来编写测试。我们没有重构和编写测试，因为我们没有足够的时间。但我们有时间进行调试、破解代码和修复bug。
我们过于关注过程，以至于经常忘记软件开发中的主要资产:人。流程帮助人们改进他们制造产品的方式，增加主动性和培养一个健康的环境。最后，流程的效率是重要的，但是人是关键的。
我们必须承认，没有人和事是完美的。客户、老板、经理、团队成员、商业人士，甚至你自己，都远非完美。需求、文档、工具、代码、构建的系统和设计，也永远不可能是完美的。因此，我们必须停止没有控制的匆忙和加速。要想以可持续的速度前进，唯一的方法就是放慢速度，这主要体现在三个方面:
人才：有专业技能和工匠精神的专业人才
流程：提高适应和工作效率
工具产品：用于提高自动化和产出质量
关于人，需要慢下来的地方
流程和工具不会生成产品，但是人可以。我们必须承认，“人才招聘”是一个组织最重要的功能。它直接影响着公司的未来和产品本身。
为你的组织雇佣最优秀的人才。我所说的“最好的”并不是指最聪明、最有经验的人。我至少会寻找激情、自律和动力。如果这三种技能都存在于一个人才身上，那么其他技能就可以轻松地得到发展。招聘是一个双赢的过程，所以双方都应该从中受益。所以你应该放慢你的招聘过程，投资改善它。人们加入他们相信的公司。所以，为你想看到的行为建模。通过你的公司文化，你的愿景和人，让人才相信你。
停止独自工作，开始一起工作。永远不要让独行侠出现，因为他们是功能失调组织的症状。坐在一起紧密工作。一起定义团队标准。彼此做评审，一起复盘。让团队共同承担责任。
一起练习是提高技能最有效的方法。在合作的过程中，我们不仅能激励他人，还能互相学习。在你的团队中定期组织静修和技术交流。每个工作日花30分钟来练习。
让知识在人群中流动。一起学习。从2010年开始，我每周都在自己所在的团队中组织课程。我从我的同事那里听到了两次，在不同的时间，“每周三参加会议可以让我提高自己，这对我很有激励作用。”这反映了公司定期内部会议的力量和影响。
收集并提供反馈。为了收集集体反馈，你可以组织大型的复盘，就像我多年来所做的那样。
教学和分享是掌握一个话题的最好方法。做一个演讲者，回馈社会。
开发人员似乎讨厌文档，但实际上恰恰相反。人们阅读的任何输出都只是一个文档：从生产代码本身到测试代码，从提交消息到提交图，从日志消息到错误消息，开发人员无意中记录了大量内容。所以无论你记录什么，因为人们读它是为了理解，所以要做得更好。
你们不是孩子。公司不是你的父母。我们必须拥有你的事业，为你自己投资。如果投资意味着花费时间和金钱，那就为自己投资吧。
我们如何通过减慢速度来优化过程?
每一天，我们都面临着新的挑战。这些挑战不应该仅仅是市场需求或新要求。技术挑战对我们的进步也有很大的影响。
计划什么都不是，但计划也是一切。所以要经常做计划和修改。特别是在创业的早期阶段，你需要极度的敏捷。每天一次对齐，比如通过daily Scrum或daily standups，是不够的。你必须紧密合作，两人一组工作，并且每天要有多次合作。保持迭代的长度较短，最短为一周。通过组织定期的回顾和演示来创建多个反馈循环渠道。
定义短期目标和长期目标。短期目标为你的团队创造了焦点，而长期目标则防止了焦点的分散。
如果您想了解哪里出了问题，可以从可视化流程开始，包括技术上的和业务上的。想象失败和糟糕的事情，从过去的经验中学习。
永远不要凭直觉做决定。始终收集数据，分析和作出决定的基础上的数据。允许每个开发人员访问产品和代码指标也很重要。这增加了产品开发的集体所有权和常识。
浪费是指你生产的东西没有商业价值。检测并消除办公室、代码和流程中的浪费。让你的代码更简洁。当您打开一个文件以添加新功能并注意到其中的一个问题时，请在没有获得任何许可的情况下修复它。在修复问题之前，不要忘记编写测试。这使您对自己的代码感到自信和舒适。
您可以在软件开发生命周期的每个点上检测到浪费。遵守你对已完成任务的定义，消除“90%已完成”的任务。不要让分支存在时间太长。这样的分支是非常有害的。不要通过手工测试来验证您的代码。手动测试主要验证用户体验。所有其他场景只能通过测试代码进行验证。所以请认真对待。
放慢速度怎样才能提高产品质量?
有一件事是清楚的。如果没有一个高质量的代码库，你就不可能是敏捷的，抱歉。您需要做的第一件事是消除技术债务和解决bug。如有必要，请在一段时间内停止构建特性，并专注于消除bug。
“修复bug，然后部署到服务器”在今天已经不是一个合适的过程。它包含着风险和危险。我们需要一种更好、更自律的方式来做这件事。当您想要修复一个bug时，首先编写一个测试并以编程方式重现问题。然后修复错误，并查看测试是否通过。部署到生产后是安全的。
我所在的团队几乎把所有时间都花在修复和维护代码库上。这些团队长期忍受着不稳定。为了在修复bug的同时继续开发新特性，您需要将您的团队分成虚拟团队。例如，我们在每个迭代中选择两个队友来交付直接的技术支持，并继续修复bug。我们叫他们蝙蝠侠和罗宾。无论您正在处理的是哪种特性，都必须不间断地修复bug。
今天，开发人员通常使用一种方法来减慢进度，以加快速度。即使用拉请求。他们停止生产线，进行验证和代码评审以提高代码质量。他们从不将未经审查的代码部署到生产环境中。
我们的最终目标应该是实现持续的交付和频繁的发布。从git的分支机制到部署策略，从反馈机制到自动化测试实践，都需要不同的思维方式。
您在软件生命周期中使用的实践表明了您的开发速度。对于git分支机制，“尽早提交，经常提交，稍后完善，发布一次”的哲学，和基于主干的开发，通过特性切换可以消除浪费。
我已经使用TDD很多年了。许多人向我抱怨TDD对编程速度的影响。Joe Rainsberger在twitter上分享了他对TDD的想法:“担心TDD会减慢你的程序员？这可能正说明了他们可能需要慢下来。”
TDD有更多的重构而不是测试，更多的思考而不是编码，更多的简单而不是优雅。这就是为什么它能带来更好的质量。通过TDD开发，有足够的测试和简单的设计。
您曾经达到过100%的代码覆盖率吗?我在一个为期三个月的项目中做到了这一点。我为生产代码的每一行都编写了单元测试。那时，我觉得自己像一个拥有超能力的英雄。但是，当我们为UAT部署到预生产环境时，我们注意到有四个特性无法工作。我必须编写集成和功能测试来检测bug并解决它们。然后我意识到单元测试并不能保证良好的设计和工作功能。停止计算代码覆盖率。代码覆盖率不过是愚蠢的信息辐射器。
对于 bug，如果你需要30分钟或更少来修复他们。另外，用20%的时间来消除技术债务。
我们通常都想将来不要再去改变它的想法而编写代码。因此，当我们设计软件时，同样地，我们选择技术和工具是为了在将来不改变它们。但我们错了。在开发过程的每个阶段都应该进行重构。正如Kent Beck所说，我们必须做简单的改变来让改变变得简单。
先慢后快作为指导方针
[Andreas Moller在一条推文中提到了他对软件开发的看法] “我不想写可以正常工作的代码:我想写干净的、可维护的、容易理解的、经过良好测试的代码。”
为此，我们需要关注三个方面:人员、过程和产品。通过减少人员，我们的目标是提高专业水平和工艺水平。通过放慢进程，我们的目标是提高适应能力和效率。通过放慢生产速度，我们的目标是提高自动化和质量。当我们关注这些领域时，我们开始培养一种能够快速进行软件开发的开发文化。
我们不应该忘记以下几点：可以工作的软件不必是精心设计的。只有优秀的专业人员才能构建良好的软件。只有精心设计的软件才能让你比以往更快地构建功能。
公众号：AIG-AU
创新 | 成长 | 分享
长按识别二维码关注我们
