大家好！ 今天，我想谈谈开发过程。 随着公司的发展，不仅业务本身会发展，而且内部尤其是在开发过程中也会累积问题。 他们通常试图通过引入一些实践和新颖的方法来解决这些问题。 las，根据书籍和培训的这种流程的强制重组，通常会带来更大的问题-人们嘲笑。
我最近在
Saint TeamLead Conf 2019大会上发表讲话，谈到了我如何能够发现工作流程中的许多问题，然后逐步克服这些问题。 在这里，我将尝试描述最有价值的实践，这些实践不仅帮助我建立了工作流程，而且还使我不再嘲笑开发人员。 员工改变了他们对公司整体以及工作流程的态度。
开发过程中的挑战
因此，当现成的方法没有产生结果，而我们几乎绝望时，我开始分析过程，并开始对所有事物进行分析。 结果是一系列问题：
- 董事会任务繁重 -那里真的很混乱。 纵观董事会，几乎不可能了解流程。
- 没有正常的评估 -我们不知道如何根据交货时间正确评估任务，因此，截止日期一直在不断，企业领导者忙于发展。
- 我们一直在确定最后期限 -我们无法确切说明该功能何时才能投入生产，通常是由于外部因素，我们将其推出时间比计划的要晚得多，例如，企业诉诸行动并要求迅速做出一些紧急功能。
- 尚不了解如何加快开发速度 -100％聘请新人和聘请工程师并不总是使过程更快。
- 计划和紧急任务 -如果使用当前任务可以以某种方式制定计划并指出大概的日期，那么通常从企业起飞的紧急任务就会破坏所有计划。
- 会议非常耗时 ，这是我们最常见的错误：无法解决问题，或者我们需要确定任务的优先级，让我们聚在一起讨论。 还是例行会议，开发人员坐在那里一两个小时，却听不懂他们在做什么。
- 团队的积极性和团队参与的问题 -通常，一些创新只是在没有征询开发团队意见的情况下，由上级主管部门简单地提出来的，这并未掩盖团队的气氛。
实际上，无论是TL还是CTO，任何领导者的任务都是使他成为业务与发展之间的纽带。
为了摆脱这种情况，我们转向了看板方法。 他告诉我们什么？ 让我们改进已经存在的内容。 好吧，我们去改善了我们的开发过程。
下订单
我们开始争论：如果支持者完成了任务并将其移交给前端，他们会立即开始吗？ 纵观董事会，这是不可理解的。 根据看板原则，我们将每个开发方向（后端，前端，DevOps，QA和设计共5个）分为两列：Do和Done。 问题立即变得很明显：我们的带宽使我们无法完成他们想要的任务。
看板还说：让我们介绍一个
WIP限制并限制任务数。 我们如何设置限制？ 根据经验。 当然，他们错过了几次，但是后来他们选择了它，这样我们就不必在最狭窄的地方积累任务。 WIP-limit的另一个好处是可以触发，这表示一旦我们取消任务，我们就可以采取以下行动。 这是一种拉动系统。
这导致了什么？ 工程师开始更加专注于任务，因为当他们不能解决问题时，就会使用阻塞器。 由于存在WIP限制，因此无法执行更多任务，因此工程师必须等待他们来解决问题。 有机会留下没有任务的机会。
当我们开始详细分析返回任务的问题时，结果发现每个人的执行方式都不同，例如，有人编写测试，而有人编写测试。 在这方面有规则，但被当局放任的规则。 他们没有解决开发人员问题。 我们引入了新规则（
“完成”的定义 ），这些规则已集成到董事会中。 它们既可以作用于某些列，也可以作用于卡的类型。 例如，对于API，您需要后端来记录所有方法和内容。 每个人都可以访问这些规则，并且这些规则在董事会上可见，最重要的是，这些规则来自工程师自己并解决了他们的问题。 如果未完成某项操作，则工程师会看到并去做。
成绩任务
我们不知道如何按截止日期评估任务，看板告诉我们：“没有估计值”。 怎么办 我们积累了统计数据并建立了这样的时间表。 这是一张频谱图，说明任务数量与时间的关系。
我们开始研究它，在图表上看到3个与三种类型的工作相对应的峰。 基于这些类型，为此类工作制定了分类和标准。 我们在任务板上介绍了这些类型，然后在流程中为每种类型添加了附加规则。 我们得到以下内容：
我们与客户（即企业）就服务质量协议（SLA）达成了一致。 一位经理来找我们，问：“您将使用此功能多少钱？” 我们不能确定要做什么，但是可以说在整批此类任务上要花费多少时间。 无需Scrum扑克，我们不再因计时问题而折磨人们。 我们只是查看了统计信息，并称为营业日期。
当然，这种方法也有缺点。 例如，这不适用于我们没有统计信息的新型任务。 他们假装过时了，但是后来他们积累了足够的数据，这个问题就解决了。
然后我们面对这样一个事实，即有些任务开始属于其他类型的工作。 我们进行了一些研究，发现某些任务的执行速度要快得多，因为该业务向合作伙伴承诺了一些事情，并要求开发人员紧急执行。 相反，有些任务并不那么重要，因此被推迟了。 因此，我们获得了优先级，即关于服务等级（CoS）的协议，我们将其置于董事会中。 为了使企业不会滥用它，也不会为所有任务设置更高的紧迫性，因此引入了水平在制品限制。
如何加快发展
再次转向任务跟踪器统计。 我们发现，许多任务挂在板上，需要改进，检查或添加其他数据，也就是说，他们意识到可以加快开发速度。 他们开始查看正在累计多少任务，多少空闲任务，并发现某些功能的开发少于预期的接受程度。 我们决定为接受功能设置一天，并减少了发布任务的时间。 然后，我们固定了CD（连续交付）并开始发送通知。
显然，我们需要一种工具来评估我们的改进。 我们决定使用累积流程图。 简而言之，它是如何构建的：我们为每个工作中心分配一种颜色（板上的列），对一单位时间内单位时间内有多少个元素（任务）进行统计，然后将它们绘制在图形上，将它们一个放在另一个下面。 在图表上，X轴是时间，Y轴是任务数。
我们从这里得到了什么？ 在这里可以很容易地看到交货时间（生产时间）-水平线（沿X轴的流的宽度）以问题陈述开始，并到达准备阶段。 因此，在这里您可以看到任务如何经历开发的所有阶段-线条与所有颜色相交，每种颜色都对应于其阶段。 还有板子的总在制品极限-沿Y轴的流动高度如何提高显影速度？ 您可以降低WIP限制（即，使图形上的流变窄），或者可以使从原点指向图形右上角的流倾向于进一步增大（即，将流向进一步增大，减小其相对于Y轴的角度）。 为了向上引导流程，您可以引入一些新的实践，例如，实现Docker或建立方便的知识库。 这不必是技术创新；新的管理方法也可以产生这种效果。
因此，我们得到了一个工具，可以清楚地显示哪些改进有效，哪些无效。
业务计划，紧急和无用的任务
业务发展计划是最大的难题。 我们做了什么？ 从业务部门接收到任务后，分析师和开发人员举行了一次会议，对它们进行了分解，然后开发人员提出了解决方案。 结果，我们了解了任务需要多少资源。 然后只有在没有我们参与的情况下，企业才制定计划并考虑可以发布多少功能。 在看板中，这称为
补货节奏 。
相对而言，我们根据WIP限制分配一定大小的插槽，您可以在其中放置任务。 每个插槽仅容纳有限数量的任务。 换句话说，该方法称为“杯计划”。
我们制作了一个简单的业务工具（Excel中的表格），可以在其中直观地进行计划。 经理们相互斗争，争论谁的任务更重要，然后他们来到我们这里，将任务交给了开发人员。
由于我们已经有局限性，因此业务更专注于任务的选择，选择了最重要的任务，并且不会因出现问题而使我们不知所措。 还有一个更大的好处：他们在没有我们参与的情况下自行选择了任务，而没有分散开发人员的注意力，他们安静地工作并且没有花时间在会议上。
我们还把注意力转向了紧急任务问题。 他们开始分析有关它们的统计数据，并意识到这些任务并不是那么紧急。 例如，我们需要提倡驾驶员季节性更换车轮。 我们知道，这种情况每年都会发生2次。 重复执行后，让我们提前在板上预留用于此类任务的插槽。 不必紧迫-我们将从队列中承担另一项任务，我们将不做任何工作。 结果，我们发现60％的紧急任务实际上并不紧急。
还有另一个问题。 我们经常看到功能，这些功能最终导致业务下滑，因为从业务角度来看，这些功能无用。 我们建议企业使用MVP功能所需的时间比传统开发少几倍。 反馈开始被更快地消除了，工程师开始意识到这是实验。 以前，当他们把数周的工作扔进垃圾桶时，他们担心，这会毒死他们的生命。
我们以这种方式开始测试85％的功能，最终释放了大量的时间，然后我们将这些时间花在了实际测试的假设上。 他们已经为公司带来了钱。 此外，如果在此过程中出现问题，则业务的客户可以在早期阶段进行校正，而不是在整个开发周期内进行校正。
结果，发现并非所有想法都能奏效的事实。 而且由于它们不起作用，所以也不要这样做。 从那时起，开发人员就不再从事猴子劳动，而正是公司带来的收益。
会议会议
那时我们引入的改进已经杀死了许多无用的会议。 关于优先级的讨论不再存在，因为我们将其交给了企业，所以我们也计划没有工程师。 我们还放弃了对经理的五分钟突袭，并要求“迅速提供帮助”。 只有真正必要的会议。 我们还引入了规则，即现在将会议安排在一个特定的时间，以便每个人都可以计划他们的时间表。
结果，所有关于螺栓学的会议都转换为以下类型的会议：
- 当分析人员想要与工程师讨论特定问题时，例如，寻找最佳解决方案或分解方法；
- 当有东西粘在板上时。 在这些情况下，我们聚集在一起，从右向左走动，询问工程师发生了什么事，谁可以提供帮助。 重要的是我们要从任务中走出来，不要试图计算人们在做什么。
- 当他们计划冲刺任务时（补给节奏）；
- 他们何时使用功能；
- 例如，在讨论API格式或确定要发送的事件时，开发团队之间的会议。
重点：我们只邀请那些直接参与讨论主题并且没有像以前那样召集被提名听众的人参加会议。 工程师在不喜欢会议之前已经从根本上改变了对会议的态度，但是现在反过来了，它们似乎对他们来说是必要和有用的。
团队动力和参与
我们执行的所有操作：WIP限制，基于统计的任务评估，拒绝上述无用的任务等，这些都为工程师节省了时间。 他们现在将做什么？ 最大的误解是没有人会做任何事情。 我本人曾多次听到这些家伙的话：“我会重构这段代码，否则魔鬼的腿会折断”。 是的，起初工程师真的有足够的睡眠，可以休息2-3周，然后呢？ 他坐在没有任务的地方，开始向他的同事求助，帮助完成任务，然后两人都已经没有任务了。 “让我们发送错误修复程序”-包含错误的列为空。 “发送我们将重构的代码”-代码变得更快地编写，可以增加WIP限制。 然后他们开始实施CD / CI，编写知识库。 发生什么事了 工程师开始做很多有用的事情，而这是他们的双手无法企及的。 这是企业想要的速度，但是由于某种原因，它无法从任何人那里得到它。 以前，工程师很生气，他希望每个人都在他身后，现在人的范式已变成：“现在我能为您提供什么帮助？” 倡议的数量在增加，它们全都来自下面，而不是来自上面。 最终，它变得更加有用。
结果汇总
- 我们能够找到系统中的瓶颈，并了解我们不能做更多的事情。
- 他们不再给开发人员带来不必要的工作，而是腾出时间来处理更多有用的任务。
- 当工程师无所事事时，他们便开始更好地评估任务，解决错误，开始使流程自动化并出现了知识库。
- 工程师不再感到压力，变得更加友善。
- 通过改进，优化工作（由于自动化和改进而增加了WIP限制），我们能够以4倍的速度加快新功能的发布。
- 我们获得了业务统计数据，并对开发的过程和过程有了清晰的了解。
- 我们学会了节省时间（拒绝不必要的任务，开始提前考虑任务以避免其他因素，等等）。
- 会议和会议在真正需要时举行（变得更加灵活）。
- 每个人都开始思考，倡议的数量增加了。 团队中产生的主动性总是比自上而下的主动性更好。 这个过程不断进行，每个人都参与其中。
结论
在本文和报告中，我不仅要引起人们对我所应用的工具和方法的关注，而且要引起人们对最重要的方面的关注，而这一点通常并没有引起人们的注意，但是在我看来，它也同样重要。 我们开始了整个改革，因为我们遇到了痛苦，我们希望摆脱它们。
您可以通过阅读智能书籍或听取有关灵活方法的报告来“在额头上实现”某些东西，从而甚至有可能加快开发速度或使产品更好地运行。 但是，我们常常忘记人们制造这些产品，而我们生活的越好，他们制造的产品就越好。 例如，我去找人问：“那你的痛苦是什么？ 有什么问题吗？”，开始执行某些操作之前。 而且仅由于这种方法，我才得以完成业务所需的工作-开发的速度和质量。
PS：有人告诉我在欧洲有一家公司，当您来到欧洲的办公室时，似乎完全处于混乱状态：开发商像黄油中的奶酪，游戏机一样，没人工作。 但这只是乍一看，这里有一种特别为人们创造的氛围，使人们可以创造和改善。 在娱乐任务之间的间隔中，一个膝盖写了一个解决方案，该解决方案随后得以实施，并开始为公司带来利润。 我希望我们的俄罗斯管理层将在不久的将来朝这个方向发展。 如果由于某种原因您出了点问题，请考虑您在做什么。 好吧，或者把这篇文章扔给老板，但是如果有帮助的话:)