软件开发被认为是无法衡量的过程，并且似乎为了有效地管理它，您需要特殊的才能。 而且，如果对情绪智力的直觉不是很发达，那么不可避免地这些术语会发生变化，产品的质量会下降，交付速度也会下降。
谢尔盖·塞梅诺夫（Sergei Semenov）认为，发生这种情况主要有两个原因。
- 没有用于评估程序员工作的工具和标准。 管理者必须诉诸主观评估，这反过来会导致错误。
- 没有使用自动控制团队中流程的方法。 如果没有适当的控制，开发团队中的流程就会停止履行其职能，因为它们开始被部分执行或被简单地忽略。
它提供了一种基于客观数据的过程评估和控制方法。
以下是Sergey报告的视频和文本版本，根据观众的投票结果，该报告在
Saint TeamLead Conf上排名第二。
关于演讲者： Sergey Semenov（ sss0791 ） 从事IT工作已有9年，曾是开发人员，团队负责人，产品经理，现在是GitLean的首席执行官。 GitLean是针对经理，技术总监和团队负责人的分析产品，旨在制定客观的管理决策。 这个故事中的大多数示例不仅基于个人经验，而且还基于拥有6至200人开发人员的客户公司的经验。我们已经与我的同事Alexander Kiselev在2月的上届TeamLead Conf上谈论了
对开发人员的
评估 。 我不会对此进行详细介绍，而是会参考有关某些指标的文章。 今天，我们将讨论流程以及如何控制和衡量它们。
资料来源
如果我们在谈论度量，那么了解从何处获取数据将是一件很高兴的事情。 首先，我们有：
- 用代码信息Git ;
- 吉拉（Jira）或任何其他具有任务信息的任务跟踪器；
- GitHub ，Bitbucket，Gitlab，提供代码审查信息。
此外，还有一个很酷的机制，例如收集各种主观评估。 我会保留一点，如果我们要依赖此数据，必须系统地使用它。
当然，污垢和痛苦在数据中等待着您-您对此无能为力，但这并不那么可怕。 最不愉快的是，在这些来源中可能根本没有有关流程工作的数据。 这可能是因为构建了流程以便它们不会在数据中留下任何伪像。
我们建议在设计和构建流程时遵循
的第一条规则是进行流程处理，以使它们在数据中保留工件。 您不仅需要构建敏捷，还需要构建可衡量的
敏捷 。
我将告诉您一个令人恐怖的故事，我们遇到了一位要求改善产品质量的客户。 为了使您了解规模，每周大约有30-40个从生产中产生的错误飞到15个开发人员的团队中。 他们开始了解原因，并发现30％的任务未处于“测试”状态。 最初，我们认为这只是数据错误，或者测试人员没有更新任务的状态。 但是事实证明，实际上只有30％的任务没有经过测试。 一旦基础架构出现问题，由于该问题，迭代中的1-2个任务就不会进入测试。 然后所有人都忘记了这个问题，测试人员停止谈论它，并且随着时间的流逝，它增长到了30％。 结果，这导致了更多的全球性问题。
因此，任何过程的第一个重要指标是它留下数据。 请务必遵循。
有时，出于可测量性考虑，您必须牺牲敏捷原则的一部分，例如，在某些地方，人们更喜欢书面交流而不是口头交流。
为了提高可预测性，我们在多个团队中实施的到期日实践被证明是非常好的。 其本质如下：当开发人员接管任务并将其拖到“进行中”时，他必须设置任务发布或准备发布的截止日期。 这种实践教会开发人员成为自己的任务的有条件的微型项目经理，也就是说，要考虑到外部依赖性，并理解只有在客户可以使用其结果时任务才准备就绪。
为了进行培训，在到期日之后，开发人员需要前往Jira并设置一个新的到期日，并以特别给定的形式留下评论，这是为什么发生的。 看来为什么需要这样的官僚机构。 但实际上，经过两周的练习，我们用一个简单的脚本卸载了Jira的所有此类评论，并以此纹理进行了回顾。 事实证明，对于截止日期为何被打破的很多见解。 它非常酷，我建议使用它。
问题方法
在过程的度量中，我们采用以下方法：我们需要从问题出发。 我们想象一些理想的做法和过程，然后我们以它们可能无法发挥作用的方式发挥创造力。
有必要监视流程的违反情况 ，而不是我们如何遵循某些实践。 流程通常不起作用，不是因为人们恶意地违反了流程，而是因为开发人员和管理人员没有足够的控制权和内存来跟踪所有流程。 跟踪违规行为，我们可以自动提醒人们需要做什么，并且我们可以自动控制。
要了解您需要实施哪些流程和实践，您需要了解为什么要在开发团队中执行此操作，以及业务从开发中需要什么。 每个人都知道并不需要那么多：
- 产品交付期足够长；
- 产品质量适当，不一定完美；
- 这样就足够快了。
也就是说，
可预测性，质量和速度很重要。 因此，我们将仔细考虑所有问题和指标，同时考虑它们如何影响可预测性和质量。 我们几乎不会讨论速度，因为我们以一种或另一种方式工作的近50个团队，只有两个可以以速度进行工作。 为了提高速度，您需要能够对其进行测量，并且至少要有一点可预测性，这就是可预测性和质量。
除了可预测性和质量外，我们还引入了
纪律指导 。 我们将把确保流程的基本功能和数据收集的一切称为纪律，在此基础上进行具有可预测性和质量的问题的分析。
理想情况下，我们要构建以下工作方案：这样我们就可以自动收集数据； 根据这些数据，我们可以建立指标； 使用指标来发现问题 直接向开发人员，团队负责人或团队报告问题。 这样，每个人都将能够及时回应他们，并解决发现的问题。 我必须马上说，并非总是能够理解信号。 有时，指标将仍然只是必须进行分析，查看值，趋势等的指标。 即使使用数据，有时也会出现问题，有时无法自动收集它们，您必须手动进行（我将分别说明这种情况）。
接下来，我们考虑功能生命的四个阶段：
我们将分析在每个阶段中可能存在哪些纪律，可预测性和质量问题。
规划阶段的纪律问题
有很多信息，但是我要注意最基本的要点。 他们似乎很简单，但是他们面对着很多团队。
在计划期间经常出现的第一个问题是陈旧的
组织问题 -并非所有应该参加的人都在计划会议上。
示例：一个团队抱怨测试人员正在测试错误的东西。 事实证明，该团队中的测试人员根本不会去计划。 或者，团队没有坐下来做任何事情，而是疯狂地寻找一个坐下的地方，因为他们忘记了预定会议室。
度量和信号不需要配置，只需确保您没有这些问题。 会议被标记在日历上，所有人都被邀请参加会议，会议地点被选定。 无论听起来多么有趣，这都是在不同的团队中遇到的。
现在，我们将讨论需要信号和度量的情况。 在计划阶段，我将谈论的大多数信号应在计划会议结束后约一个小时发送给团队，以免分散过程中的注意力，但仍保持专注。
第一个学科问题是
任务没有描述，或者描述不清。 这是基本控制的。 任务应采用一种对应的格式-我们检查是否正确。 例如，我们遵循已设置的接受标准，或者对于前端任务，有一个指向布局的链接。 您还需要跟踪放置的组件，因为描述格式通常与组件绑定。 对于后端任务，一个描述是相关的；对于前端任务，另一个描述。
下一个常见的问题是
优先级是口头或根本不说，并且没有反映在数据中 。 结果，到迭代结束时，事实证明最重要的任务尚未完成。 有必要确保团队使用优先级并充分利用它们。 如果团队在迭代中有90％的任务具有高优先级，那么这与根本没有优先级一样。
我们尝试进行这样的分配：20％的高优先级任务（您不禁要卸载）； 60％-中等优先级； 20％-优先级低（如果我们不发布它，这并不可怕）。 我们把信号挂在这一切上。
该学科的最后一个问题发生在计划阶段-
没有足够的数据 ，包括后续指标。 基本的：任务没有评级（应发出信号）或任务类型不足。 也就是说，错误是作为任务而启动的，根本无法追究技术债务的任务。 不幸的是，不可能自动控制第二种类型的问题。 我们每隔几个月建议一次，尤其是如果您是CTO并且您有几个团队，请仔细阅读未完成的工作，并确保人们启动错误（例如bug），故事（例如故事）和技术债务（例如技术债务）任务。
规划阶段的可预测性问题
我们转向可预测性问题。
基本的问题是
我们不在截止日期和估计数之内； 不幸的是，不可能找到某种魔术信号或度量标准来解决这个问题。 唯一的方法是鼓励团队更好地学习，使用示例通过一项或多项评估来分析错误的原因。 并且该学习过程可以通过自动方式来促进。
可以做的第一件事是以很高的估计执行时间来处理明显有问题的任务。 我们挂起SLA并控制所有任务都已充分分解。 我们建议一开始最多执行两天，然后您可以继续进行一天。
下一段可以促进工件的收集，在该工件上可以进行培训并与团队一起分析为什么评估发生错误。 我们建议为此使用到期日练习。 她在这里证明自己很酷。
另一种方法是作为任务一部分的称为Churn代码的度量标准。 其实质是我们查看在任务框架中编写了多少百分比的代码，但没有达到发布要求（在上
一份报告中有更多介绍 ）。 该指标显示了经过深思熟虑的任务。 因此，最好注意并了解Churn跳跃的问题，我们没有考虑的因素以及为什么在评估中犯了错误。
下面的故事是标准的：团队计划了一些事情，冲刺完成了，但是最后
根本没有计划的 。 您可以配置用于填充，更改优先级的信号，但是对于我们与之合作的大多数团队而言，它们是无关紧要的。 通常，这些都是产品经理的合法操作，它们会将某些东西放入sprint，更改优先级，因此会出现许多误报。
在这里可以做什么？ 计算相当标准的基本指标：初始sprint侦查的关闭，对sprint的抛出次数，自身抛出的关闭，优先级更改，请参阅抛出的结构。 之后，评估您通常在迭代中投入多少任务和错误。 此外，使用信号控制您
正在计划阶段分配
此配额 。
规划阶段的质量问题
第一个问题：
团队没有考虑已发布功能的功能 。 我将在一般意义上谈论质量-质量问题是客户是否认为质量存在。 可能是杂货店的某种缺陷，也可能是技术问题。
关于食品缺陷，诸如
三周流失的指标
效果很好 ，表明流失任务发布后三周高于正常水平。 本质上很简单：任务未发布，然后在三周内删除了足够高比例的代码。 显然，这项任务没有很好地执行。 我们与团队一起捕获并分析了此类情况。
对于存在错误，崩溃和质量问题的团队来说，第二个指标是必需的。 我们建议建立一个
错误和崩溃之间的平衡图：现在有多少错误，昨天有多少错误，昨天有多少错误。 您可以在团队前面悬挂这样的
实时监视器 ，以便她每天都能看到它。 这极大地使团队专注于质量问题。 我和两个团队都这样做了，他们真的开始更好地思考任务。
下一个非常标准的问题是
团队没有时间承担技术债务 。 如果按照类型进行工作，则可以轻松监视此故事，也就是说，在Jira中评估技术债务任务并将其作为技术债务任务启动。 我们可以计算出在该季度中分配给技术债务团队的时间分配配额。 如果我们同意该业务比例为20％，而仅花费10％，则可以考虑这一点，并在下一季度将更多时间用于技术债务。
发展中的学科问题
现在让我们进入开发阶段。 纪律有什么问题？
不幸的是，碰巧
开发人员什么也不做，否则我们无法理解他们是否在做任何事情。 通过两个平庸的迹象可以很容易地跟踪到此：
- 提交频率-每天至少一次；
- 在吉拉（Jira）至少完成一项任务。
如果不是这样，那么就不需要击败开发人员，而是需要了解它。
即使是最有能力的人，甚至是一个非常酷的开发人员的大脑，都会遇到的第二个问题是
持续处理 。 如果您作为团队负责人，知道一个人在处理：几个小时后编写代码或进行代码审查，那将是很好的。
各种Git规则也可能被违反 。 我们敦促所有命令遵循的第一件事是在提交消息中从跟踪器指定任务前缀，因为只有在这种情况下，我们才能将任务及其代码链接到该任务。 在这里甚至最好不要构建信号，而是直接配置git hook。 例如，对于您拥有的任何其他git规则，您无法在master中提交，我们还配置了git hooks。
商定的惯例也是如此。 在开发阶段，开发人员必须遵循许多实践。 例如，在截止日期的情况下，将有三个信号：
- 未设置截止日期的任务；
- 截止日期已过期的任务；
- 截止日期已更改但没有评论的任务。
所有这些信号均已调谐。 也可以为任何其他实践设置类似的内容。
开发阶段的可预测性问题
在开发阶段的预测中，很多事情都会出错。
一项任务可能会长期挂在开发中。 我们已经在计划阶段尝试解决此问题-很好地分解任务。 不幸的是，这并不总是有帮助的，并且
有些任务会冻结 。 对于初学者，我们建议您将SLA设置为“进行中”，以便有信号表明该SLA被违反。 这将不允许您立即开始更快地发布任务，但是它将再次使您可以收集发票，对此做出响应并与团队讨论发生了什么，为什么任务长时间挂起。
如果
一个开发人员上有太多任务，则可预测性会受到影响。 建议通过代码（而不是Jira）检查开发人员执行的并行任务的数量，因为Jira并不总是反映相关信息。 我们都是人类，如果我们执行许多并行任务，那么某些地方发生问题的风险就会增加。
开发人员可能会遇到一些他没有谈论的问题，但是很容易根据数据进行识别。 例如，昨天开发人员几乎没有代码活动。 这并不一定意味着存在问题，但是作为团队负责人，您可以站出来并找到答案。 他可能会被困住并需要帮助，但是他很尴尬地问她。
相反，另一个例子是开发人员承担着某种大任务，它的代码在不断增长。 这也可以被检测到并可能被分解，从而最终在代码检查或测试阶段不会出现问题。
, . , , . .
. , , .
.
«» : , ; «»; «»; , bug fix. , , , , , — « ».
, , , , . , - , .
, , ,
, «» . , . ,
Legacy Refactoring , , , .
, —
SLA high-priority- . , . , , : high-priority critical .
, —
. -, . -, , . , .
-
Code review. ? , , — pull requests. -, pull request, . , , «in review», , Jira. , . , 2-3 , .
, , , pull request, . — , pull request ticket Jira .
, , , . pull requests, . , , : «, , - ». , . pull requests , , Jira.
pull request, , — , , - , - , , . .
, , — , , , , . : , « , ». , .
, , linter. , , - linter, - - , .
-
, SLA , , . , , .
SLA , "
- " — . , -. pull request .
,
- , . , CTO , , , . -. - , 6 50% - . , , 50%, CTO . , CTO - , 100%.
, — , - . :
, -.
-
, -. , .
100 . - 10 , - 1-2 . , .
— , , . , , , .
, , , , .
—
, - , . — churn -, .. pull request , .
,
- , , , . , commit, , -.
, - ( pull request ), - . , commit, . , .
. , — Jira. Jira. , «testing». task-tracker. , , - .
SLA . SLA , .
-, , , — . . , , ,
.
pipeline test- — , , , . build' , , — , . , 1-2 , , . , .
— . , . , , «» , , , , , .
, , ,
. . , , , , . , , , . : , , , .
, «» , , . , , , .
, —
- . , , . , , .
我们讨论了指标，现在的问题是-如何处理所有这些？ 我只讲了最基本的事情，甚至很多。 如何处理所有这些以及如何使用它？
我们建议您最大程度地自动化此过程，并通过即时通讯程序中的机器人将所有信号传递给团队。 我们尝试了不同的沟通渠道：电子邮件和仪表板-效果不佳。 该机器人已经证明自己是最好的。 您可以自己编写一个机器人，可以从某人那里获得OpenSource，也可以从我们这里购买。
这里的意思很简单：团队对机器人发出的信号的反应比对指示问题的经理的反应要平静得多。 如果可能的话，如果开发人员在1-2天内没有响应，则将大多数信号首先直接发送给开发人员，然后再发送给团队。
无需尝试一次构建所有信号。 由于纪律方面的琐碎问题，它们中的大多数根本无法使用，因为您将没有数据。 因此，我们首先要建立纪律并为纪律实践树立信号。 根据与我们交谈过的团队的经验，花了一年半的时间在没有自动化的情况下简单地在开发团队中建立了纪律。 借助自动化，并在不断发出信号的帮助下，团队在几个月后开始以纪律严明的方式正常工作，这要快得多。
您公开或直接发送给开发人员的任何信号在任何情况下都不能直接打开。 首先，您需要与开发人员协调，与他和团队进行交谈。 建议以书面形式在团队协议中输入所有阈值，执行此操作的原因，下一步将要执行的操作等。
应该记住，所有过程都有例外，并在设计阶段将其考虑在内。
我们不会为开发人员建立集中营，在开发人员集中区，不可能向右走，向左走。 所有进程都有一个例外，我们只想了解它们。 如果机器人不断宣誓某些任务确实无法分解，并且需要5天才能完成，则您需要打上“ no-tracking”标记，以便机器人将其考虑在内。 作为管理员，您可以单独监视此类“无跟踪”任务的数量，从而了解这些流程和所构建的信号的良好程度。 如果标记为“无跟踪”的任务数量稳步增长，那么不幸的是，这意味着您所发明的信号和流程对团队来说很困难，无法跟踪，并且更容易解决。
手动控制仍然存在 。 打开自动程序并离开巴厘岛的某个地方将不起作用-您仍然必须处理各种情况。 您收到某种信号，此人没有回应-您将在一两天内找出原因，说出问题并制定解决方案。
为了优化此过程，我们建议引入诸如
过程助理之类的实践。 这是一个了解机器人程序发出的问题的人员（每周一次）的过渡职位。 您作为团队负责人，可以帮助服务员解决这些问题，即对他进行监督。 因此，开发人员增加了使用该产品的动力。 他了解它的好处，因为他知道如何解决这些问题以及如何应对。 因此，您可以减少团队的独特性，并
在团队变得自治的时刻拉近距离 ，并且仍然可以去巴厘岛。
结论收集数据。 构建过程，以便您收集数据。 即使您现在不想建立指标和信号，如果现在就开始收集它们，也可以在将来进行出色的回顾性分析。
自动控制过程。 在设计流程时，请始终考虑如何对它们进行黑客攻击，以及如何从数据中识别此类黑客攻击。
当几个星期的信号很少时-做得好！ 我们面对这样一个事实，当团队发现信号较少时，并且情况似乎正在改善，它开始疯狂地提出其他一些实践，开始实施某些措施以便再次看到这些信号包。 这并不总是必要的，也许是如果信号较少-一切都很好，您的团队从一开始就按照您想要的方式工作，然后您就完成了:)
快来在TeamLead Conf上分享您的Timlid发现。 二月份的会议将在莫斯科举行， 征文活动 已经开始 。
您想体验别人的经历吗？ 注册我们的管理时事通讯，以接收有关该计划的新闻，而不会错过讨价还价的时间。