来自翻译者：
从年初开始，是仔细评估过去一年的好时机。 全面了解正在发生的事情，并了解如何使2019年成为更好，更平静和更高产的一年。 在这种情况下，我们发现Lemi Orhan Ergin撰写的文章《 如何以比以往更快的速度放慢速度》 非常有用 。 并且我们在下面发布她的翻译。
重点：
- 急促不能使我们更快或更高效。 它增加了压力，使无法集中注意力。 您无需急忙，而需要创新的方法，效率和重点。
- 雇用最有才华的专家，一起工作，一起练习和学习。 这将提高专业水平，并在公司中营造卓越的文化。
- 通过制定计划并定期检查计划，提高团队的灵活性和流程效率。 查找，分析和消除浪费时间的任何来源。
- 没有高质量的代码基础，您就不会灵活。 消除缺陷，更频繁地发布版本，在编写主要代码之前编写测试，进行重构，着重于简单的设计。
- 运行软件并不意味着设计良好。 只有真正的专业人员才能构建高质量的软件，使您能够尽快开发。
如果您无法控制地从事开发，那么最快地执行任务就可能成为您的敌人。 需要放慢三个重要领域：人员，流程和产品。 在深入探讨细节之前，让我先讲一个故事。
据我记得，那是2011年。 我加入了创建在线营销平台的团队。 我的主要任务是尽快添加新功能。 我是一名高级开发人员。 当开发人员的开发速度快于其他开发人员时，我们称其为“高级”，对吧？ 但是，当我开始工作时，我们注意到由于技术负担和系统设计中的缺陷，几乎不可能快速工作。 我们还注意到，每次加速尝试都会增加复杂性并破坏质量。 我得出的结论是，加快速度的唯一方法是从头开始重写系统。
我记得在与产品经理进行电话交谈时，我说过我们需要重写整个系统。 沉默30秒后，经理问：“您说您的团队开发的产品质量很差，以至于现在这支相同的团队应该再次重写相同的产品，但这一次最好这样做。 对不对 对不起，但这是不可接受的。 您应该马上写得更好。”
Zombie软件需要反复重写
根据
Standish Group的《混沌报告》 ，94％的项目从头开始进行了多次重做。 这是一个巨大的数字。 记住我所做的项目，我知道几乎所有项目都是使用新技术，新架构和新设计从头开始重写的。 从头开始复制在我们行业中是如此典型，公司通常将其视为开发和管理项目的唯一方法。 首先我们写，然后我们一次又一次地重写。
我们需要认识我们的主要敌人。 速度是软件开发中至关重要的品质。 重要的是，不仅要首先进入市场，而且要快速响应客户的评论，添加功能并修复错误，以使用户对产品感到满意。
但是我们都对“速度”的概念有疑问。 我们认为，快进，合理和有效的行动在某种程度上与期限的确定有关。 我们认为，如果您更加努力工作或吸引更多的人，将会更快地达到结果。 结果，我们要么添加新人员到项目中，要么加班工作以加快工作速度。 急促并不能使我们更快或更高效。 急于营造压力氛围，使我们失去了专注于工作的机会并破坏了生产力。 需要的是创造力，效率和专注力。
软件开发是一件非常复杂的事情。 我们不能摆脱这种复杂性。 因此，我们需要和她一起生活。 快速工作的要求造成了不稳定，动荡的气氛，使我们陷入压力，无法进行富有成效和专心的工作。 这种方法是行不通的。
团队生产力（能力），总体规划，人工成本估算，固定工作时间，截止日期和团队速度（团队速度）-所有这些都是虚幻的。 无能是真实的。 交付的速度直接取决于人员的专业水平，流程的效率和执行的工作质量。 开发人员通常会为自己设置内部截止日期，即使没有必要。
结果，我们得到了一个遗留系统。 截止日期带来的压力加上无能为力导致了遗留代码-系统进一步开发的死胡同。 我曾经在遗留系统中使用另一个名称-僵尸软件。 此定义的效果更好，因为旧版实际上是已失效的软件，但是看起来可以在生产环境中使用。 它可以工作甚至带来金钱，但是它需要开发人员的血液，生命和精力才能以某种方式进行工作。 开发人员害怕触摸有效的代码，没有人愿意开发它。
罗伯特·C·马丁（Robert C. Martin）在Twitter上对遗留系统的评价很好 ：“如果您的软件越来越难开发，那么您在做错事了。” 急着工作，我们正在降低质量，以至于每走一步，工作就会越来越慢。 我确信，更快发展的唯一方法是减慢该过程，直到我们实现稳定。
匆忙开发软件是邪恶的
罗伯特·C·马丁（Robert C. Martin）在CleanCoders系列文章中说 ：“软件的主要价值在于系统适应未来变化并简化其实现的能力。” 在软件开发中，匆忙是邪恶的。 任何匆忙的尝试都会导致生产力，专注力，人员效率，对变更的适应性以及软件灵活性的严重下降。
例如，我们总是有时间修复错误，但是没有时间编写测试。 我们没有时间重构，因此不重构或编写测试。 但是我们总是有时间调试，拐杖和修复错误。
我们如此专注于流程，以至于我们经常忘记对软件开发最有价值的人员。 流程可帮助人们制作更好的产品，增加动力并营造健康的工作环境。 最终，过程效率很重要，但没有什么比人更有价值。
您必须明白，没有人是完美的。 客户，高管，经理，团队成员，业务代表甚至您都不是完美的。 需求，文档，工具，代码，开发的系统及其设计也将永远不是理想的。 因此，我们必须急着停下来，漫不经心地加快发展。 保持稳定步伐的唯一方法是朝三个重要方向减速：
- 员工-越来越专业和技能，
- 该过程正在提高灵活性和效率，
- 产品-质量改进和自动化。
当涉及到人时放慢脚步
流程和工具不会创建产品。 人们做到了。 值得认识的是，“聘用人才”是公司最重要的任务，它直接影响着整个公司的未来，特别是对正在生产的产品的影响。
雇用您组织中最有才能的人。 说“最”，并不是说最聪明，最有经验的人。 我正在寻找至少热情，纪律严明和有上进心的人。 如果一个人具有这三种素质，他将很容易地发展自己的才能。
招聘对双方都应有利。 因此，请放慢招聘过程，并花点时间进行改进。 人们加入他们所信奉的公司。 模拟您希望在团队中看到什么样的人。 让有才华的人相信您，审视您的文化，对未来的想法以及您的员工。
自我是慢慢杀死组织的毒药。 永远不要让它渗透到您的组织中。 从善于交流的傻瓜开始，到以白痴为结尾-不要让极端变成您团队的一部分。 不要雇用自我go肿的人。 与他们在一起，您将永远不会创造出一种会取悦他人的企业文化。
停止一个人工作，一起工作。 不允许团队分裂。 孤独者和英雄开发者是组织功能失调的标志。 坐在附近。 与整个团队制定标准。 成对或成组工作； 一起审查。 允许过程中的所有参与者对结果负责。
一起练习是提升技能的最有效方法。 通过互动，我们不仅可以激励他人，而且可以彼此学习。
与您的整个团队定期
运行 代码撤退 ，
编码dojo和
randori 。 每天练习30分钟。
让知识在人与人之间传播。 一起学习。 自2010年以来，我与我工作过的所有团队一起举办了“
Brown Bag /午餐与学习”会议。 我两次听到同事说：“参加星期三的会议让我兴奋不已，这极大地激励了我。” 这清楚地反映了定期进行内部mitap的好处。
收集反馈并将其提供给其他人。 要收集集体反馈，请安排一次大型回顾展。 我已经做了一年多了。 顺便说一句，这是一个让20个人或更多人参与解决问题的好方法。
教别人和分享知识是达到精通的最佳方法。 公开演讲并为社区做出贡献。
通常，开发人员讨厌编写文档。 但是现实却相反。 他人阅读的任何结果都是文档。 从系统代码开始，以测试代码结束，从消息到提交再到存储库中的提交图，从日志消息到错误消息，开发人员创建了大量文档，而没有意识到。 而且，无论您要记录什么文件，如果人们都阅读了它，请尽可能地做到最好。
你不是孩子 组织不是你的父母。 每个人都应独立管理自己的职业并进行自我投资。 如果您的贡献涉及浪费时间或金钱，请自己动手做。
如何减慢并改善流程
我们每天都面临着新的挑战。 这些不仅仅是市场需求和新产品需求。 技术挑战也会影响我们的进步。
计划什么都不是，但是计划就是一切。 制定计划并不断进行审查。 特别是在项目的早期阶段，需要最大的灵活性。 每天与计划（例如每天混乱或每天站起来）进行核对是不够的。 有必要在团队内部进行更紧密的互动，成对工作并更加频繁地咨询计划。 将最小迭代长度保持长达一周。 通过定期的审核和演示会议来组织多个反馈渠道。
定义短期和长期目标。 短期目标是团队的重点，长期目标可以防止团队的流失。
如果您想了解为什么出现问题，请从技术和组织的角度可视化工作流程。 可视化错误和失败，以最大化第一手学习。
切勿根据感情做出决定。 始终收集数据，分析数据并据此做出决策。 让每个开发人员访问产品和技术指标也很重要。 这增加了对正在开发的产品的参与和理解。
浪费只是您花费的时间，但这对企业没有价值。 在办公室，代码和业务流程中查找并消除浪费。
童子军离开停车场时比到达时更干净。 同样的原理也适用于软件开发。 遵循侦查规则，并在每次更改后保持代码清洁。 如果要添加新功能并发现文件中可以修复的缺陷，请在未征得许可的情况下进行操作。 请记住首先编写测试。 这将使您有信心进行更改。
您可以在系统开发周期的任何时候发现浪费。 遵循明确的准备标准（完成定义），并本着“ 90％完成，剩余90％”的精神淘汰任务。
不允许出现长寿命的分支-它们被认为是邪恶的。 不要手动检查您的代码。 通过手动测试，您可能会验证成功的执行脚本。 所有其他脚本只能使用代码进行验证。 因此，请认真对待此问题。
减速如何改善产品质量
可以肯定的一件事-对不起，如果没有高质量的代码库，您将无法灵活应对。 首先要做的是消除技术负担并修复错误。 如有必要，请暂停开发新功能，并专注于修复错误。
“我会先解决，然后再解决”的方法在当前现实中不起作用，因为它风险太大。 在消除错误时，需要一种更严格的方法。 首先，编写一个重现该问题的测试。 之后，请修复错误并确保测试现在通过。 现在，您可以安全地将补丁发送到生产环境中。
我在团队中工作，几乎所有的时间都花在修复错误和维护项目上。 他们受苦的原因是生产工作不稳定。 要继续开发新功能，同时更正错误，您必须将团队分成虚拟团队。 例如，在每次迭代中，我们选择两个人来支持和修复错误。 我们称它们为蝙蝠侠和罗宾。 无论您急忙完成什么功能，都可以在不中断主要开发的情况下修复错误。
开发人员经常使用减速方法之一来进一步加速拉取请求。 他们停止正在进行的开发，执行检查并进行代码审查以提高代码质量。 未经验证的代码永远不会影响生产。
我们的最终目标应该是过渡到持续交付和频繁发布。 从使用git分支开始，以部署策略结束，从提供反馈的方法到自动化测试实践，所有这些都需要一种特殊的方法。
您在软件开发周期的不同阶段使用的实践表明了您的开发速度。 使用分支机构时，请使用“提早提交，经常提交，稍后完善，发布一次”的方法。 如果没有分支，请使用功能切换。 这将消除时间的浪费。
我已经使用TDD多年了。 人们经常向我抱怨，TDD会对开发速度产生负面影响。
Joe Rainsberger在Twitter上分享了他对TDD的看法 ：“
您担心 TDD会减慢您的程序员的速度吗？ 不用了 他们可能需要放慢脚步。”
TDD比测试更具重构性。 比编码更思考； 比优雅更简单。 这就是TDD带来更高质量的原因。 使用TDD时，您将只有最少的测试数量和简单的设计。
您是否曾经通过测试达到100％的代码覆盖率？ 我在一个为期三个月的项目中完成了该项目，涵盖了生产代码的每行测试。 那一刻，我感觉自己像是一个拥有超能力的英雄。 但是，当我们将系统部署到试生产进行验收测试时，我们注意到这四个功能不起作用。 我编写了集成和功能测试来查找和修复错误。 那时，我意识到单元测试不能保证良好的设计和功能。 停止将代码覆盖率的百分比计为测试。 该指标没有显示任何内容。
如果需要30分钟或更短的时间，请立即纠正错误。 此外，请使用20％的时间消除技术债务。
通常，我们编写代码时无意在将来进行更改。 在设计系统时，我们类似地选择技术和工具，并计划在将来不对其进行更改。 但是我们错了。 在项目的任何阶段都应该可以进行重构。 正如肯特·贝克（Kent Beck）所说，我们需要进行简单的更改，以便轻松进行进一步的更改。 为了实现这一点，我们将所有微服务的代码存储在一个单一存储库中。 这使得重构变得容易，而且确实是必要的。
如果设计决策早于必要，则将是错误的。 您应该等待最后可接受的时刻才能做出决定。 我们使用“端口和适配器”体系结构在整个系统的设计级别上实现低耦合和高内聚。 因此，我们得到了设计完美的整体。
整体不是邪恶的，邪恶是不好的设计。 我们始终从整体开发开始，由于“端口和适配器”架构，我们将部分功能提取到微服务中。 正如Martin Fowler
在他的Monolith First文章中所说：“立即开始使用微服务架构是有风险的，最好从Monolith开始。 仅在必要时才划分为微服务。”
减速以加速生活
安德烈亚斯·莫勒（AndreasMöller）
在推文上分享了他对软件开发的看法 ：“我不想编写行之有效的代码。 我想编写干净，可维护，易于理解且经过良好测试的代码。”
为此，我们必须关注三个领域：人员，流程和产品。 放慢人们的工作，我们努力提高专业水平和技能。 通过放慢进度，我们努力提高灵活性和效率。 通过减慢产品的工作速度，我们努力提高自动化水平和质量水平。 当我们专注于这三个领域时，我们开始培养一种使快速发展成为可能的文化。
我们必须记住以下几点：
- 一个工作系统不一定写得好
- 只有真正的专业人员才能创建精心设计的系统
- 只有精心设计的系统才能让您尽快发布新功能
关于作者
Lemi Orhan Ergin是
一位软件开发向导 ，他致力于提高自己行业的卓越水平并与社区分享他的经验。
Craftbase的共同创始人和
土耳其软件工艺社区的创始人。 自2001年以来一直从事软件开发。 他在Scrum，极限编程，开发方法论和Web技术等领域积极实践和指导。