🤸🏿 🚎 📹 为什么开发人员这么慢：常见问题及其解决方案 🤚🏻 💪🏼 💗

哈Ha！我向您介绍了Eric Elliot 撰写的文章“ 为什么开发团队如此缓慢：常见的软件困境和解决方案”的译文。

如果您喜欢听的不仅仅是阅读，那么您可以在音频格式的Yandex.Music和Apple Podcasts上获得翻译，

让我们看一下是什么原因导致了软件开发过程的中断，以及您作为经理可以做什么。可能有很多原因，因此，当然，我们的清单远非详尽无遗。相反，我们将重点关注一些最常见的问题：

不切实际的期望
公开票太多
任务范围不受控制
累积码审查
准备不足
倦怠的开发人员
虫子
员工流动

发展缓慢不是问题的根源。这是列出的其他问题的症状。在100％的情况下，如果开发团队工作太慢，那是领导者的错。但是好消息是您可以修复它。让我们更详细地查看每个项目，以了解我们可以对它们进行处理。

不切实际的期望

开发人员生产力方面的大多数问题通常不会影响开发本身。这实际上是我们将发展过程视为管理者和利益相关者的问题。

经理工作中最困难的部分是了解编写代码所花费的时间与所花的时间一样多，而试图加快此过程只会减慢它的速度并增加错误的数量。耐心是我们的一切。

通常，工作速度的问题不是团队效率不足，而是面临很高的期望。这完全是您的责任。如果压力来自上级领导，则您尚未形成对形势的正确认识。如果压力来自您，请继续阅读。

我们经常忘记，我们创建的软件从根本上来说是新的。如果您已经具有相同的软件，请购买，使用，导入模块等。无需从头开始重写它。新软件是独一无二的。他做新的事情或做不同的事情。然后就是我们创建它。而且由于我们还没有这样做，我们如何知道需要多长时间？

建筑商以相同的速度建造预制墙，因此可以根据观察结果或多或少地提供准确的估计。软件开发人员没有可靠的数据可依靠。由于不同开发人员的速度不同，此问题更加严重，并且可能会变化一个数量级。

正如《完美密码》的作者史蒂夫·麦康奈尔（Steve McConnell）写道：“不同程序员的生产力之间存在显着差异的结论已由专业开发人员进行的许多研究证实（Curtis 1981，Mills 1983，DeMarco和Lister 1985，Curtis等1986，Card 1987）。，Boehm和Papaccio，1988，Valett和McGarry，1989，Boehm等，2000）。我们没有足够的数据来预测完成我们的项目需要多长时间。我们将发现规模和复杂性已经开始发挥作用，并且此过程通常充满许多惊喜。 “无论我们多么努力地预见一切，发展不仅是计划，而且是研究。”

« 90 10 , . 10 90 »
— , Bell Labs

经理可以控制的期望有很多原因。根本原因之一是衡量错误的事情。
您可能熟悉彼得·德鲁克（Peter Drucker）的一句名言：“测量的是受控的。”

当然，这是个很好的建议。当然我们必须测量！但是，我们错过了此报价的本质，而且，我们将其含义颠倒了。

整个想法是： “衡量的东西是受控的，即使它被衡量，并且试图控制是完全无用的，即使它损害了组织的目标。”

不值得衡量的两个例子：

预测性燃尽图显示了基于最近对工作速度的测量来预测项目结束日期的未完成票数的图表；
开发者关闭的凭单数量，显示单个开发者完成了多少任务。

衡量这两件事使无数公司因生产力，员工和其他成本的损失而蒙受了巨大的损失。

任务进度图

许多软件工具试图根据当前的任务规模和工作速度来预测项目的完成日期。问题在于，其中没有一个考虑到未开发的任务量。而且，这是不可能的，因为完成一项任务所需的时间可能因不同任务而变化一个数量级，这可能会大大扭曲已为已关闭的工单计算出的平均值。

如果您根据图表中的日期设置了最后期限，则认为您尚未达到最后期限。唯一可以节省您的事情是将来将尽可能多的任务扔出范围。

当您基于不完整的信息来评分时，您和您的团队肯定会为此付出代价。不切实际的估计会产生不切实际的期望。如果您还与营销团队，客户和媒体共享这些评级，那将是一场真正的灾难。

并非所有图表都是邪恶的。那些不尝试预测未来的人可能会有用。当您看到门票数量增加而不是减少或上下移动时，他们可以警告我们项目的传播和组合爆炸。有用的任务图演示了已经现实完成的任务，而不是试图预测未来。

一个好的指标是具有起伏的曲线，但是总体上它是向下移动的，这表明到项目结束时，未完成任务的数量减少了。

减少门票数量的项目时间表

范围过大的项目将由向上弯曲的曲线表示。

淹没在新任务中的项目时间表

请记住，观察此曲线的目的不是尝试更改它，而是识别并解决潜在的问题。我们不希望程序员简单地停止打开新票。

目标是流程的透明性，而不是优美的下降曲线。

提防Goodhart原则：“如果一个维度成为目标，那么它就不再有用。”

没有任何预测是有害的。当您的工作期限很紧时（例如，您试图在黑色星期五之前发布游戏），您可以根据平均工作速度来系统地控制范围，因此您知道何时开始调整范围。如果预报告诉您您将不迟于12月完成，请相信它。现在是确定优先级和减少优先级的时候了。

这种预测的经验法则是：
“如果预测表明您可以在给定的日期做某事，请不要相信它，如果预测表明您不能做某事，请相信它。

一名程序员关闭了门票

重新计算一个程序员执行的所有任务，然后将此数字与平均值进行比较的想法很诱人。但我敦促您抵制这种诱惑。有很多更好的方法来收集开发人员生产力数据。

计算封闭任务有两个基本缺陷。首先，任务在复杂性和重要性上并不完全相同，实际上，工作的价值取决于权力定律。一小部分任务比“平均”任务具有更高的重要性。就像摩天大楼的地基和最后钉子被钉之间的区别。因此，仅通过计算已关闭票的数量，就不可能确切地知道员工的价值。

许多年前，我为全球零售业领导者设计了一个购物篮。一旦我停止编写代码并关闭Jira的凭单，并添加了另一张凭单：“可用性研究”。

我已经进行了超过一年的重新设计购物篮的工作，发布日期正在迅速接近。在此之前，用户尚未进行新订购过程的可用性测试，因此花费了一周的时间。我们尽早接触了数千名最忠实的支持者，并对他们进行了采访以收集反馈。

我分析了结果，发现民意测验和日志显示出令人震惊的趋势：在购物篮阶段离开站点的用户的频率过高，用两位数表示。一场真正的灾难来了！因此，我开始工作并计划以个人身份记录新的可用性测试。我坐在新篮子后面的新手，给他们一些任务，让他们一个人呆在现场。我什么也没说，只是看着他们使用新界面。

我注意到在下订单的过程中，人们在表格错误方面遇到困难。有了这些数据，我在github上稍微纠正了我们的开源项目（在Gira中没有任何注意）。一段时间后，我们进行了另一项测试。用户离开购物篮的可能性越来越小：公司的收入差额为每月100万美元。

在此期间，我的同事们分别关闭了10到15张门票。您可能会说我可以得到更多的可用性测试票证来反映现实。但是，那时我将不得不再制造一千张票，这只会产生噪音并且需要很多时间。

计数封闭票效率低下的另一个原因是，最有效的团队成员也是每个人都在寻求帮助的人。他们最了解代码库，或者他们是优秀的开发人员，或者他们具有出色的沟通能力。他们可以帮助您解决请求请求的待办事项，查看其他程序员的代码，培训和指导您的队友。他们是团队中效率最高的，因为它们可以帮助团队的其他成员将工作速度提高一倍。他们关闭的门票也许是框架或库的创建，这些框架或库可以提高整个团队的生产力。他们完成大部分工作，而其余的则得到认可。

如果不小心，然后查看最有生产力的开发人员的贡献。找出程序员在做什么的最好方法就是问他们。向团队询问他们认为最有帮助的同事。

通常，此反馈中反映的信息与仅通过计算票数即可获得的数据有很大不同。

收集绩效数据，但不要一味地对待每个开发人员。发展是一项团队运动，过程中的每个参与者都在其中发挥作用。没有任何一种神奇的方法无一例外地适合评估所有对象。

打开的任务太多

这看起来很简单-在跟踪器中打开票证并继续前进。但是跟踪器中的每个任务都需要一个完整的处理周期。

在开发人员可以开始实施它们之前，需要对它们进行排序，确定优先级并分配艺术家。每次开发人员关闭一项任务并选择下一项任务时，都会重复进行这项工作。如果您有项目经理或Scrum管理员，则他们会在每次重新确定任务列表的优先级时执行此操作（通常在sprint的开始或每两周一次）。

然后，开发人员需要深入研究任务的上下文，了解问题的本质，将复杂的任务分解为子任务，然后才可以最终开始执行。

创建和阅读票证需要大量工作，但这就像是虚假的工作。这是一个元任务。需要她开始真正的任务。它们本身具有零值。程序员每次选择下一个任务都需要花费时间。一次在跟踪器中的票数越少越好。积压的低优先级任务越少，开发人员选择高优先级任务的机会就越高。

如果只有一个用户提到过一个错误，那么它对我们有多重要？他感动了一个人，但是我们是否有更多人注意到的错误？有什么新功能比修复此错误有用吗？
大概是。

消除积压的噪音。删除您近期不打算做的事情。
如果这真的很重要，请在有时间的时候再添加。

任务大小不受控制

我想请团队中的开发人员将工作分解为可以在一天之内完成的任务。这比看起来要复杂得多，因为它要求能够将复杂的任务划分为较小的任务，这些任务也可以与应用程序的其余部分分开进行测试。

示例：您正在网站上执行新的结帐过程。您不需要将UI组件，状态管理以及与服务器的通信混合到一个涉及13个文件的大型提交中，这些文件都与当前代码库密切相关，因为结果将是巨大的请求请求，难以检查和合并。

取而代之的是，从一个经过独立测试的客户端篮子状态模块开始，并对此进行拉取请求。然后构建服务器API并为其单独创建PR。然后编写一个UI组件，该组件将从模块中导入状态并与服务器API通信。这些任务中的每一个都可以划分为单独的任务，尽管这本质上是一个很大的功能。另外，任务可以分散在几个程序员之间，并可以利用团队的规模来加快开发速度。

功能切换器将使此过程更容易，更安全，使您可以关闭已开发的功能，直到准备好将其包含在生产中为止。

注意：如果没有很好地覆盖烟雾测试，请勿尝试这样做。通过部署半成品功能，您应该能够确保没有破坏任何东西。一定要检查它是如何工作的。

通过代码查看来积累任务

当开发人员的努力超出了他们的承受能力时，结果就是巨大的请求请求，需要等待审查和验证。

这是“连续集成”（CI）中的集成阶段。问题是PR保持打开状态的时间越长，花费的时间就越多。开发人员将打开它，看他们是否可以帮助遏制它。他们将留下反馈，请求更改，并且请求将返回给作者以进行更改并进一步批准这些更改。同时，所有发生的拉取请求都将远离主服务器。
当几个开发人员习惯进行非常大的提交时，请求请求的数量开始像滚雪球一样增长，并且集成变得越来越复杂。

示例：Bob更改了Jane也管理但尚未抵押的文件。首先是Bob的拉取请求，PR Jane成为了距离主控更远的一次提交。现在，她必须解决所有与Bob的代码冲突的问题，才能保留分支机构。将这种情况乘以在您的项目中使用相同代码的程序员数量。这种“交通拥堵”会导致行动过多。

我们计算标准方案中此类操作的数量：

Bob和Jane在同一个分支中开始工作（0个动作）
鲍勃进行更改并提交到他的分支。简做同样的事情（2个动作）
鲍勃的代码掌握了。简下载鲍勃的更改并发现冲突。她将其更正并将结果提交给线程。（3个动作）
简打开请求请求。鲍勃（Bob）指出，她在代码中所做的更改将破坏她没有考虑的某些内容。Jane根据Bob的评论进行更改，然后再次提交代码（4个操作）
PR Jane终于合并了。只有4个动作。

现在考虑一种情况，其中提交会更少，而拉取请求会更快地闪烁：

鲍勃做了一个小小的改动，他的代码落入了主代码（1个动作）
Jane下载了新版本的向导，并考虑了Bob的更改编写了代码。（2个动作）
由于简的犯案也很小，因此他很快就被关在了大师手中。总共只有两个动作。

当创建小的PR时，我们大大减少了重做代码的需要，重做代码是由冲突和代码复杂性引起的。

准备不足

在培训和支持方面，IT行业非常糟糕。大学深入地教授标准库中已经内置的算法，只有很少的程序员从头开始编写它们。

尽管开发的基本原理（例如抽象，连通性和参与性，模块化与整体式设计原则），使用模块，功能组成，对象组成，框架设计和应用程序体系结构却被忽略了。由于该行业的爆炸性增长，大约一半的开发人员拥有不到5年的经验，而88％的专家认为培训不会伤害他们。

团队工作缓慢是因为他们对自己的工作了解得很少，而且没人愿意教他们。

作为经理，我们的任务是聘请经验丰富的专家来指导我们的团队，并为此分配时间。

可以做什么：

代码审查：开发人员通过学习彼此的代码学到很多东西
创建高级工程师和初级工程师的对：不必创建永久对，一次解决特定问题的工会可以很好地工作。
专门用于指导的时间：聘请经验丰富的专业人员，他们乐于学习和交流，并给他们时间与初级开发人员分享经验，这将有助于后者了解他们如何发展自己的技能。

燃尽

对于领导者而言，使团队精疲力尽是比未能按时完成任务的一大挫折。

倦怠是一个严重的问题，可能导致开发人员流失，人员流失，巨额成本，低音系数增加（总线系数-衡量单个项目成员之间信息集中程度的度量;该系数表示项目参与者的数量，损失之后，其余参与者无法完成项目）。

但是，更重要的是，倦怠会导致健康问题。倦怠的后果可能导致身体不稳定，甚至因心脏病发作或中风而死亡。在日本，这种现象非常普遍，以至于他们甚至有一个特殊的词：“ karoshi”。

领导者可能会耗尽整个团队，从而完全丧失生产力。耗尽整个团队的问题在计算机游戏开发行业中尤其常见，因为黑色星期五几乎总是一个艰难的截止日期。

不幸的是，尽管组织者很少意识到采用这种方法的危险性，但“死去做就可以了”是组织这些团队工作的共同原则。

经理们不应强迫开发人员开展更多工作，而应认识到，按时完成任务的100％责任在于管理人员，而不是开发人员。

如果使用以下技术，截止日期会更容易：

更好地确定任务的优先级并缩小范围
简化流程
识别并重构代码混乱

员工流动

Linkedin在2018年收集的数据显示，IT员工的流动性优于任何其他业务。这很不好，因为它会引起低音因素的风险，即您将失去项目关键专家的风险。

许多公司不重视保留专家。让我们仔细研究一下人员流动成本。

职位空缺的费用为15-30 000美元。工程师的时间平均每小时花费90美元。将其乘以约50次面试以及许多很多小时才能回答新手的问题，并帮助他习惯团队。因此，我们已经花费了5万美元，但这还不是全部。

新员工可能需要长达一年的时间才能达到他所替代的开发人员的水平，而这将是他第一次犯下很多错误并花费大量时间来解决这些错误。

因此，雇用和培训新的开发人员，机会成本以及必须培训初学者一段时间并同时完成部分工作的团队的生产力损失几乎是离职开发人员薪水的90％。寻找替代品可能需要几个月的时间，然后初学者才能花更多时间才能完全发挥作用。

这都是非常耗时的，而且大型团队一直在不断遭受营业额的困扰，因为根据Stack Overflow在2019年进行的一项调查，过去两年中有60％的开发人员更换了工作。

当开发人员最终开始以最高效率工作时，您将失去它。

如何避免流动性？以下是来自各种来源的一些提示：

诚实地付款
定期提高薪水
让人们放长假
提供远程工作
保持现实的期望
提供开发人员感兴趣的任务
不要让技术栈变得过时
提供培训和职业机会
提供健康益处
不要强迫开发人员每周工作40小时以上
为员工提供现代化的设备

虫子

如果您认为没有时间实施高质量的开发流程，那么您真的不能没有它。

根据评估软件工程技术（David N. Card，Frank E. Mc Garry，Gerald T. Page，1978），经过充分优化的流程可以减少错误，而不会增加成本。主要原因是根据另一本书“软件评估，基准和最佳实践”（Casper Jones，2000年），缺陷检测和纠正是开发中最耗时，最昂贵的任务之一。

由于臭虫导致需要进行代码处理而臭名昭著，并且发现臭虫越晚，修复臭虫的成本就越高。当指示开发人员修复生产中已经发现的错误时，这通常会使他感到震惊。在《任务切换和中断的日记研究》（玛丽·切尔温斯基，埃里克·霍维茨，苏珊·威尔希特）一书中，他说，一个让我们分心的任务可能要花费两倍的时间，并且包含两倍的错误，这表明高优先级漏洞在某种程度上具有感染力：修复一个漏洞，我们很可能会产生新的漏洞。

生产中的错误还要求我们更加关注支持，并且用户非常烦人和累人，这最终会花费您金钱。您将不得不投资修复旧功能，而不是创建新功能。

在开发阶段发现的错误可以在几分钟内修复，而在生产环境中发现的错误将经历许多其他阶段：报告错误，检查，确定优先级，任命艺术家并最终进行开发。

但这还不是全部。该错误将具有其自己的提交，其拉取请求，审阅代码，集成，甚至可能具有其自己的部署。在任何阶段，某些测试都可能会失败，整个CI / CD周期将不得不重新开始。

如前所述，生产中的错误要比开发期间发现的错误花费更多。

以下提示将有助于提高过程质量。

放慢速度以加快速度。慢表示不间断，不间断表示快速。
进行设计审查。代码验证和要求的结合使您可以捕获多达70％的错误。
邮政编码审查。经过良好测试的代码易于维护90％。一小时的审核可为您节省33个小时的支持。进行代码审查的程序员的生产率提高了20％。
使用TDD方法。它减少了30％到40％的错误。
CI/CD. , , . , . CI/CD .
增加测试范围。您的CI / CD进程应运行测试，并在其中至少有一个崩溃时停止测试。这将有助于避免在生产环境中部署错误，并节省大量金钱和时间。您的目标是至少达到70％的覆盖率，但尽量保持接近80％。当您接近100％时，您会注意到功能测试对重要用户流程的覆盖范围将为您带来更多的单元测试。

结论

影响团队绩效的方法有很多，包括：

设定现实的期望
跟踪和控制未完成任务的数量
控制任务大小
不允许通过代码审查来积累任务
培训开发人员
在工作与休闲之间取得良好的平衡
实施有效的开发流程
注意员工保留

为什么开发人员这么慢：常见问题及其解决方案