我们的团队为法人实体开发信贷和担保产品。方向很年轻，第一期始于2018年。我们签到并研究了市场，进行了透支，增加营业额的贷款和银行担保。该计划是针对合同，抵押贷款和其他产品推出贷款。
病征
我们从迅速开始做杂货技工的过程一直在堆积拐杖。我们忍受了这些，并且，您可能已经猜到，一旦注意到流程的任务开始开发的时间过长。这反映在发行版的不断转移中，任务没有按时完成。错误堆积如山，影响到一小部分特定的客户群。
在某些情况下，已经下达两个月的下一个任务的发布又被无限期地推迟了。同时，透支功能的发布破坏了银行的担保。产品理解不同步。开发人员认为重要的事情是业务团队根本没有注意的。另一方面，产品的主要功能仍然未知。
为了摆脱危机局面，成立了一个工作小组，其工作任务是从“坏与长”中取得“快与好”。对于我们自己，我们设定了提高性能和减少错误数量的目标。
问题
在深入研究团队流程之后，我们发现了无法单独解决的纠结问题，它们需要一种集成的方法：
- 旧技术栈；
- 漫长而扭曲的看板流程；
- 商业进入发展的内政；
- 开发团队对该项目失去了兴趣；
- 一般毒性。
我将更详细地告诉您这是如何表达的。
旧技术堆栈。我们的流程是用IBM ODM编写的-该系统具有妨碍团队工作的许多功能。我们的建筑师Denis对它们进行了详细描述 科茨金对于相邻的项目（尽管有IBM BPM，但总的来说一切都是公平的）。另外，我注意到市场上没有使用此系统的专家。
交货过程漫长。正式地，我们将自己定位为看板团队，但过程看起来像瀑布和Scrum之间的交叉。瀑布式开发的遗留之处在于，业务，开发和测试只能在Jira卡中进行通信。每个人都有一个清晰的想法：“我已经完成了我的工作，我的小屋就在边缘。”
我们没有立即来看板。从一开始，我们就将Scrum与sprint一起使用，这在年轻项目中表现得更好。然后，他们意识到团队在道德上难以从sprint转移到sprint，并转而使用看板。然后很明显，没有人知道如何使用输入流，开发周期开始出现。它体现在以下事实上：每周收到一次来自企业的任务，然后团队对其进行评估，很明显，什么都不知道，任务被发送到下周。同时，换句话说，我们做了看板，寻找瓶颈。
我了解看板和Scrum的思想并不矛盾，并且在一些例子中，方法论的结合显示出良好的效果。但是，我想强调的是，纯粹的看板立场十分激进。从测试到开发的大量回报也大大减慢了速度，这表明早期阶段任务的质量很低。
违反榜样。业务分析人员从事体系结构工作-他们提出了解决该问题的技术方案。这导致了这样一个事实，即他们经常拒绝进行深入的发现以支持解决方案的详细说明和规范，并且这种hack加上脆弱的体系结构一再减慢了开发速度。
团队对项目失去兴趣。一个有才华，雄心勃勃的年轻团队。纯粹的启动。发射和缩放后，成长的烦恼开始了。来自业务的持续压力，由于缺乏重构而导致的开发复杂性，内部问题的累积，未来数月的积压导致普遍的疲劳和倦怠。
由于上述所有原因，团队中的气氛变坏了。问题是固定在复古上的，但没有解决，并且一周又一周地徘徊。一般的毒性超出了范围，任何关于工作的对话都变成了相互指责。
我们做了什么
坦白说，一开始我们只了解我们需要从头开始重写流程，以消除of脚，并与经验丰富的开发人员加强团队。六个月后，我可以列举另外两个对我们有帮助的事情：
- 重建看板流程。感谢Tinkoff Biznes交付中心，该中心及时研究了我们的问题并帮助适应了Jira。
- 业务和IT同步。在这里，我们的信念是，团队应该对产品有充分的了解，而不仅仅是执行将带来产品的任务。
最后，重写流程解决了技术堆栈问题，并帮助摆脱了拐杖。对看板流程的重新思考有助于重建角色模型并减少退货数量，即提高了向产品交付任务的速度。大量同步活动和对当前格式的重新思考使总体气氛更加明朗。
第1部分。重写过程
因此，我们开始将流程从IBM ODM重写为Camunda。Nikolay的文章介绍了选择Camunda的原因 恩恰亚科夫...
在申请流程中，我们使用阶段这一术语-流程中逻辑上封闭的部分，对客户有明确的含义，例如“收集文档”或“签署贷款协议”。我们的首要任务是发起合同贷款。我们意识到，这三个阶段的逻辑是特定于它的，其余的与循环贷款的类似阶段没有什么不同。实际上，我们在Camunda上写了一个新产品的三个阶段。将来，当业务任务因其重大变化而出现时，整个阶段都被重写。
一个自然的问题出现了：我们如何与企业进行谈判？显然，重写一个已经起作用的功能比在旧引擎上修改它需要更长的时间。一切都变得非常简单：同事们准备投资新流程，因为他们看到了该流程在相邻项目中的运行效果如何（再次，丹尼斯，您好！科茨金）。同时，自从我们开始轮换以来，新引擎的开发时间就不多了：精疲力尽的人搬到了其他项目，聘请了具有开发和设计业务流程经验的员工来替代他们。
第2部分。更改执行任务的顺序
在更改开发过程时，我们依赖以下准则：
- 不应存在未反映在板上的步骤。
- 应向团队提供技术专长。
- 团队必须了解任务如何影响业务。
通过更改看板流程，我们已经确定了以前隐含地经历了开发阶段的新阶段：这是架构和三个好友的会议。自然地，架构并不是在很小的改动下进行的，但是我们尝试召开一次由三个朋友组成的会议来完成任何任务。Nastya有一篇有关“三友”方法的文章特拉维索...我要特别感谢Nastya：她在敏捷测试方面的培训启发了我们在团队中做出许多改变。
团队以用户故事的形式接收有关产品价值的数据，并评估任务对产品的影响。很难发现精明的商业客户的虚张声势。例如，“此规则很重要，将对所有应用程序进行检查”等级的信息远少于“我们进行了分析，该规则将每周拒绝10个其他应用程序”的信息。因此，在提交开发任务之前，我作为共享开发人员价值的业务团队的代表来验证书面价值的质量。
我们还放弃了对我们无效的做法。例如，现在我们很少再进行复古讨论，仅在必要时才进行讨论。这大约每月一次。我们必须解决追溯中指出的问题，因为每个团队成员都必须在困扰他的问题上看到积极的变化，这一点很重要。
我们不再使用故事点和对任务的团队评估-我们按照从企业收到的截止日期进行工作，并根据它们来管理输入流程。在几个月内完成的大型任务上，我们进行分解：这使得可以建立一种检查点并提高到期的准确性。为了监控进度，我们定期开会并讨论是否准时。如果发现不是，请调整输入流并执行较少的小任务。至于到最后期限的准确性，我只能说，对于我们目前的主要任务，我们是适当的。
关于角色的重新分配，我们通过架构师和第二位系统分析师加强了团队。业务团队试图清楚地说明任务中需要什么，执行任务所带来的价值，而不是建议或参与开发的内部工作。我也照顾业务团队。
第3部分。IT和业务团队的同步
我们使用多种格式来同步业务和开发人员。
按任务演示。这是所有感兴趣的人的会议-投资组合分析师，风险部门，市场营销人员和IT专家-讨论了价值，问题性问题和技术解决方案。
一个重要的会议，在这里您可以找到在发现阶段遗漏的错误，并有时间进行纠正。同样，领导任务的经理不确定是否会影响发布的公司流程。通过我们的宣传，我们可以防止流程更改中断的情况，例如分析报告。
复古的任务。在这次会议上，我们讨论了开发人员和客户在问题发展过程中遇到的问题。我们在发布后的分析之后进行操作-当激情消退并且每个人都准备好进行建设性对话时。在找出原因之后，我们形成了增长点和想法云，我们将在将来尝试这些想法。
我们以教育计划的形式进行产品讲座，并随后进行讨论。他们的目标是使IT人员融入业务环境。对于以最普遍的措辞“今天的演讲率”进行的调查形式收集的反馈，平均评分为8.5，满分为10。
结果
六个月后，我们重写了80％以上的流程，并使用全新的引擎对合同进行了贷款。团队气氛有所改善，我们变得更有效率。为了验证这一点，我们对团队进行了调查，并从吉拉（Jira）获得了统计数据。
该调查询问了团队中的气氛，规范的质量，开发和架构，与企业的沟通质量。根据调查结果，参与该项目半年以上的人员的平均得分从10分中的6分提高到8分。不幸的是，该调查并不完全诚实，因为它是在更改之后进行的。显示的数字是年初和七月初的数字。因此，可以公平地说团队中的情况有所改善，但还不能说多少。
在这段时间内，性能（每天的任务数量）增加了一倍。自然地，不以分解为代价：我们事先同意了我们遵守的某些标准。
从测试到开发的回报数量略有减少。也就是说，随着为生产显示的任务数量成倍增加，退货数量没有增加。这表明在发现和架构阶段，任务开发的质量有所提高。在生产环境中发现的错误数量没有改变。
我们学到了什么
现在，我将提出一些想法，这些想法是我和团队从我们的经验中学到的。如果您的团队中有类似的问题，希望他们也能为您提供帮助。
- , . — . , — , . — .
- , , , , , . , .
- — , , . , , discovery .
- . one-one-, , . Shoom3301, .
- : — , IT — . , .