🍦 😆 🔍 不适如何帮助我们改善开发过程。 ✋🏾 😝 🏇🏻

我是团队负责人，我的任务是确保团队的高效工作。这并不容易，因为没有现成的成功秘诀。当然，有公认的方法：敏捷，精益，价值流图。他们给出了通用的准则和价值观，这已经很好了，但这仅仅是准则。对于特定的解决方案，请善待自己。这就是您和团队负责人的原因。

在本文中，我将介绍我和团队如何逐步组成，现在定期完善有效工作的方法。关键是所选工具已为整个团队所接受，并已扎根于工作中。这给该方法带来了希望。

一点背景

在True Engineering，我们从事企业发展。我们制作了一个庞大的多年产品，许多团队参与其中。具体来说，我们的团队由七人组成：四名开发人员，一名团队技术负责人（编写大量代码），一名质量检查人员和一名下午人员。团队正在研究的产品已有两年历史了。在整个团队的共同努力下，技术条件几乎堪称典范。

不适作为诊断工具

为了发现和识别团队中的问题，我们使用了一个非常简单的工具-参与者的不适感。

当然，这与一个人装有空调而另一个人很热的情况无关。我说的是正常工作流程中的失败。

例如，发布版本是歪曲的，尽管每个人都做得很好。或稳定已经持续了两周，而团队却在流泪，尽管我们自己进行了估算，但没人能打扰我们做得好。或企业没有达到预期。

如何在类似情况下采取行动：

停止恐慌，意识到为什么我们现在不舒服。
找出根本原因。例如，使用“ 五个为什么”技术或只是常识。
决定如何处理该问题。本文结尾将讨论选择正确解决方案的指南。在这里，我指出了一个根本性的重要点：我们使用不适感来诊断问题，但这并不意味着选择解决方案的准则就是获得舒适感。请记住，您作为团队存在的主要原因是商业价值。没有人需要一个不会带来成果的快乐团队。
一段时间后，进行回顾。如果该决定没有帮助，我们将以新的理解返回第1款。如果有帮助，我们会为将来的初学者自动化或添加到原则列表中。不再需要任何控制，如果真的很好，参与者自己将采用这种方法。

所描述的算法很简单，但是细节还不够。接下来，我将描述我们使用这种方法得出的原理。为了使本文不会成为回忆录，我将仅描述获得的结果，而不是描述从了解痛苦到消除痛苦的整个故事。

我们建立流程的原则

1.我们不断创建和缩短反馈循环

人类与外界的所有互动都是建立在反馈的基础上的，如果没有反馈，就不可能验证所执行动作的正确性。想象一下，如果我们不感到从四米高的地方跳下来或抓着炽热的茶壶时会感到怎样的生活。

在开发中，代码完成可以作为一个良好的，简短的反馈循环的示例-它告诉我们有关在代码输入时正确执行操作的信息。

现在是一个没有反馈循环的例子：我们知道用户的问题，但是我们无法重现它，我们没有日志，无法快速推出此修复程序，甚至不知道该产品当前是哪个版本。你不会希望敌人。

开发过程中的每个动作都可以并且应该提供反馈：构建，完成，通过自检，进行测试，与企业进行测试会话，成功部署，监视产品-所有这些都是检测错误并调整其进一步操作的方法。

还值得注意的是，随着前进，错误的代价会增加。如果我们在生产中发布了会破坏数据的生产错误，那么任务不仅是要修复它，而且还要还原数据（如果可能的话）。尽早消除此类错误的成本非常高，更不用说对企业造成的后果了。

因此，重要的是要有大量的快速而有用的反馈回路。

以下是我们有意识地支持并尽可能缩短的循环。我想你们大多数人都知道。但是您真的有他们并且可以工作吗？

在本地运行和运行项目的能力。
设计用于快速失败。
快速，内容丰富的CI构建。
不断检查代码并通过请求请求处理代码。
自动测试的可用性。测试是快速，稳定，信息丰富的错误消息。
自动部署，因为手动执行的频率较低。
频繁发布而不是在完成任务后一周内累积和发布版本。
信息丰富的日志，监视，诊断工具。从整个团队访问他们。
日志过滤和图形可视化的能力。
作为日常工作的一部分，持续监控系统的技术和功能指标。
系统的实证研究-Google Analytics（分析），分析系统中累积的数据。
存储数据更改历史记录，而不是存储最终状态（如果适用）。
开发人员，运营人员，质量检查人员，业务部门紧密合作，而不是将上一阶段的结果“推翻”。
在团队内部以及与企业进行定期回顾。
来自企业的定期反馈。最终用户的反馈甚至更好。
能够“在现场”观察用户的工作。
观察第一次看到您系统的用户的能力。

通常，反馈本身必须引人注目。例如，损坏的构建。

值得注意的是，有时很小的变化就足以进行根本的改进。

例如，您将日志写入ELK 。它们经过结构化，分析，公开可用-一切都很好。但是开发人员在调试过程中会多久去一次呢？很有可能不会。

如果警告级别和更高级别的消息直接显示在IDE中，则有可能引起注意，例如查询执行时间下降。即使它与当前任务无关。有机会更早发现问题，并且修复该问题的成本会降低。

2.任何活动都会留下公共物品

人工制品应完全公开。而且有用。

由于这个原理，我们将总线因素降到了最低，对情况，工作（和fakapim）有一个统一的了解，有意识地不断做出结论。

一些实践是显而易见的，并且被普遍接受：提交的信息丰富，提交与任务的联系，如何测试的描述，完成的定义。

不太明显的几点：

您不能“仅仅将其拧紧”，必须实现故障。如果分析显示出考虑周全的需求，那么精心设计将成为所有人的产物。如果问题出在系统的体系结构中，那么工件将是所描述的技术职责，并且带有明确的术语可以投入工作。
邮件，即时通讯程序，邮件头中的知识量应该最少。所有改进都反映在知识库或任务跟踪器中。因此，当测试人员接受任务时，对其进行更改的要求将不是新闻。当企业接受结果时，每个人都知道应该得到什么。这种状态将作品变成连续的流。提供它（查找详细信息，更新知识库和任务描述）-过程中每个参与者的任务。
测试结果不仅是“我检查了，一切都OK”，而且是通过的测试用例的公开列表，该列表是在测试之前而不是在测试期间或之后进行编译和讨论的。该列表可以由过程中的每个参与者进行研究和补充。

3.我们尊重彼此集中工作的权利

我认为，工作流程中的重要性和中断的后果已经众所周知。因此，我不会详细讨论这个问题，而是立即转向我们的实践。

仅鼓励使用耳机。
工作通讯是异步的。不要让您的同事有一个小问题，请在任务跟踪器中问他（请参阅有关公开可用工件的部分）。
有时会发生一些事情，打乱正常的操作模式：产品事故，对于已经执行的任务的需求难以理解。信号可能是办公室中嘈杂的讨论，三个或更多人参加。如果这种情况在几分钟内仍无法解决，我将任命一名人员来澄清细节。其余的将恢复正常运行，直到负责人提供信息以进行进一步分析。

4.我们避免多任务

因为多任务不起作用。她只精疲力尽，全神贯注并推迟接受结果。

什么做法有帮助：

工作进度限制。
关注价值流，而不是资源。例如，第一个开发人员可以在一天内完成任务，第二个开发人员可以在一天内完成任务。但是第一版将在一周后发布。因此，第二个任务要完成。我们将在实施上花费更多的时间，但是我们将更快地交付结果（三天而不是一周零一天），然后继续执行下一个任务。同时，我们不会试图将“不可推挤”推给第一位开发人员，也不会因为期望“悬而未决”的工作而分心。
如果一个任务涉及几个人，并且工作完成了90％，那么团队的首要目标就是尽一切努力完成最后10％。之后，我们继续前进。

5.我们尽早做出架构决策

这不是我们的专业知识，而是精益生产的基本原理之一。

做出并执行的决定限制了进一步更改的可能性。而且，如果决策是在信息不完整的情况下做出的（这几乎总是这种情况），那么做出错误决策的机会就会大大增加。

如果未能做出决定不会阻碍工作并且不会导致技术债务呈指数级增长，则应该推迟它，使系统在将来有更多信息时可以为将来的任何决定做好准备。

这是开发的基础-在项目开始之前，我们不会构建“大型”架构。相反，我们使重构过程安全（请参阅有关反馈循环的部分），并将其转变为过程的自然部分。

同样，我们也不会试图猜测系统的未来需求或构建通用解决方案。安全重构的能力更为通用，因为它使得将来进行任何更改成为可能。

6.该代码在任何给定时间均可操作。

当然，这种状态是绝对无法达到的，系统会在做出更改后定期崩溃。但这并不意味着不应寻求该特性。

如果故障是一种异常情况，而不是一种生活规范，那么其原因很容易找到。通常这是最后一次提交。因此，负责人是可以理解的，消除的步骤是可以理解的，当我们回到稳定状态时就很清楚了。

由此产生的对系统操作的信心为随时释放提供了宝贵的机会。

第二个价值是我们对承诺可用性更有信心。如果我们将工作分为“发展”和“稳定”两个阶段，那么就很难做出具体的承诺，因为“稳定”是针对我们尚不了解的问题开展的工作。因此，我们无法准确评估它们。

如果稳定与发展密不可分，并且有所有必要的工具来实现，那么这种情况就更可预测了。

我们如何保持持续表现：

显而易见：代码审查，自动测试，功能标志。
任何更改都将立即部署到测试环境。如果损坏，则以后将无法修复-质量检查已被阻止。
任务完成后立即进行连续测试，而开发人员可以记住任务和代码并迅速进行更正。
我们不做部分工作。如果需要两个人来实施，那么他们将成对工作，在一个分支中，将代码完全准备好并包含在测试中后，将代码上传到main分支。
无需手动“完成”交付自动化和固定交付工件。
每个团队成员都知道诊断工具，知道如何使用它们，并知道如何发布。

7.我们是一个团队，而不是一个发展团队。

“团队”是什么意思：

所有代码均至少由一个人审阅。如果发现严重问题，则鼓励他们坐在一起做配对编程。要共享一本书，一篇文章，详细的解释，而不是传播个人意见，是无价的。
在必要时，我们成对紧密地工作，而不是将结果进行后续艰苦的整合。
我们不会将审阅者变成检查错别字的工具，我们会向审阅者发送干净，小巧的请求。
我们不会“无所适从”地执行任务，而是要认真交出质量检查的工作，亲自检查幸福的道路。我们帮助质量检查人员了解要测试的内容和方法，并帮助我们通过边界情景（例如，人为破坏系统）。
QA反过来研究系统的内部结构，知道如何收集所有必要的详细信息（日志，数据状态）并获得非常有用的错误。

8.我们砍尾巴

为了最大程度地提高当前工作的效率和集中度，我们消除了与已经完成的工作相关的“债务”：

尽快将任务推向销售。只有在那之后，我们才认为它们完成了。
我们不断消除技术债务，以免技术债务增加到高昂的修复成本（一周），并且不会阻碍工作，从而破坏了交付业务功能的计划。
我们不会启动将在“某天”执行的任务，但是会删除长期存在的任务。当（如果）确实有时间来做时，企业肯定会来完成任务的。并且以防万一，在任务跟踪器中，您可以还原已删除的任务。但是此功能对我们从未有用。
长期存在的分支，注释掉的代码，To-do-shki-所有这些都是无效的代码，其位置在篮子里。
不稳定的测试将立即修复或删除，并用较低的测试代替。
我们跟踪“爬行”任务。

最后一点值得单独解释。

我的意思是最初以较低的人工成本进行“爬行”任务，但是却在进行中数天或数周。

为什么会这样：

该任务最初设计得很差，已经需要大量改进，说明是矛盾的或不完整的。因此，我们停止浪费时间，停止执行任务并返回到声明。
任务处于等待某人结果的状态。例如，来自另一个团队的服务或来自企业的改进。我们将这类任务放在铅笔上，不要让它们自己完成。

这一点很难遵守。首先，必须实现“蠕变”。然后，您需要做出坚定的决定，并退一步回到细节上。由于已经花费了时间，因此开发人员很难做到这一点。当然，这样的决定会遇到企业的阻力。但是实践表明，这减少了产生团队，业务，用户都不满意的结果的机会。

循环时间图有助于搜索此类任务。它显示了从上班到完成的时间。如果任务是“不在人群中”，那么这是进行仔细检查的候选人。

如何选择有用的解决方案

不幸的是，我没有现成的食谱。团队效率是一项启发式任务，这意味着它没有确定的解决方案。

但是仍然有一些清单。这是：

我在文章的开头就写过这一点，并在此重复：我们使用不适感来诊断问题这一事实并不意味着我们在做出决定时就力求舒适。记住主要目标-增加业务价值。
分析问题时，请记住所有参与者都有良好的意愿。如果您的想法是基于偏执狂的信念，即有人故意伤害您，那么做出正确的决定将非常困难。
不要尝试破坏所有内容并进行重建。逐步移动，逐步进行更改。等到所做的更改带来结果，然后再引入新的结果。
如果没有明确的解决方案，请循序渐进，不断评估结果并尝试各种选择。清晰的反馈回路和不断的反思对您和团队而言都是取之不尽用之不竭的开发工具。
趁热锻铁。不要将分析推迟到追溯之前-团队将已经忘记正在发生的事情。最好是对已经认识到的问题和现成的解决方案进行回顾，以供团队权衡并选择最佳方案。
该决定必须由整个团队做出。从上种下任何植物都行不通，试图控制只是一种幻想。
不要教人日常工作中非典型的任务。您会遇到一千个合理的解释，为什么没有兑现诺言，但您不会得到结果。
决定的效果必须是切实的。您很难成功地决定SMART的特征，但是必须存在一些有意识的评估结果的方法。至少基于“现在这种情况不再那么频繁”了。
尝试定期记录最痛苦的时刻。如果半年后您笑着重新读了录音，以为“有罐子”，那么您就走上了正确的轨道。

结论

总之，让我们讨论该方法的缺点。

首先，此方法可用于搜索局部优化；因此无法为产品和整个公司制定开发策略。当然，对问题的意识比在工作中不自觉地胡扯和烧伤要好，但这只是第一步。

我还请您不要使用现成的原则列表，而要使用创建它的工具。原因如下：

我们的清单不完整。它仅包含我们在日常工作中已经实现的内容。
团队没有采取根本的原则，而由于缺乏原则，她没有意识到自己的重要性。您会得到一个柏忌，每个人都会在办公室待一段时间，然后把灰尘扔在角落里，而不是付诸实践。

我们的清单是特定的。例如，如果该项目的技术债务已经被忽略了五年，并且可以与美国的公共债务相提并论，那么将很难从不断消除技术债务的原则中受益。公平地承认：如此规模的债务将永远无法偿还。并专注于真正有助于改善情况的解决方案。
您如何改善流程？您在工作中已经采用了哪些原则？

不适如何帮助我们改善开发过程。