错误修复是任何开发中乏味但必不可少的部分，并非所有人都愿意这样做。 如何将错误修正变成令人兴奋的东西？ 安排比赛！ 在这篇文章中，我们将详细讨论我们24小时的“错误修正马拉松”-从初步准备到授予获奖者后进行最后的提交。
被想法感染
在过去的一年中，我们的Sberbank Online应用程序的开发规模已大大增加。 随之而来的是，小错误开始积累，这些错误在关键指标上没有得到任何体现。 但是我们知道这是一枚定时炸弹，需要做一些事情。
我们的
Avito同事如何解决此类问题给我们
带来了灵感，我们决定针对Bagaton格式的错误组织一次大规模的攻击-考虑到我们的开发结构，文化和流程的细节。
有必要安排一切，以便家伙们自己想参加一场比赛，并证明自己的冷静无上司指示。 为此，比赛应具有凉爽的氛围。 我们决定提出一种特殊的样式，这种样式可以识别错误。 错误就是错误。 谁消灭平凡生活中的虫子？ 灭虫者穿着黄色化学防护服。 近年来，它们在哪里点亮？ 在一个有关化学老师的热门系列中。 有一个基础，我们以活动结束。 他们组织了一场视频游戏锦标赛，有奖竞猜，很酷的个人提名……当然还有很多美味的食物。 但是，不管怎么说，最主要的是消除错误的竞争。 这使人想起了带有Web界面的仪表盘，该仪表盘显示了团队的进度，他们的当前位置，分数等。 我们与团队负责人讨论了所有事情-他们批准了我们的计划。
Android vs iOS-如此不诚实
首先，我们希望推动Sberbank Online Android开发人员与他们的iOS同事一起在平台的竞争中发挥作用。 但是在此过程中，组织意识到这不是最佳解决方案，因为从技术上讲，平台在不平等的条件下工作。 碰巧的是，在iOS上，构建速度更快并且运行了自动测试。
然后，我们更改了格式，并组成了混合小组：分别由五个Android和iOS开发人员组成。 以前，从积极的开发人员中选择队长来帮助组建团队。 原来有九支球队。 尽管我们从公平竞争的角度解决了铁的问题，但我们仍然必须确保其他限制不会妨碍我们的漏洞修复专家。
下一个任务是选择巴格顿日期。 每个平台的发布日期都不同-选择它们的目的是使每个人都感到舒服。 我们试图使日期尽可能接近分配候选发布者的日期。
此外，bagaton会给平台基础架构带来沉重负担。 当有比赛时，谁可以更快地修复错误，请求请求的数量就会激增。 Bagaton前一个半月，我们的设备可能无法应对预计的峰值。 但是在那一刻，我们正期待着新的熨斗，而且它很快就到了。 我们成功地连接，配置和增强了两个平台的带宽基础架构。
管道-如何不将所有东西降低到管道中
一切都按以下步骤进行：在开发工作开始进行之前，我们进入了团队必须在其中工作的分支。 在Bagaton期间，大量带有固定bug的拉取请求被注入其中。 在每个工具上都进行了自动测试，开发人员检查了拉取请求，测试人员检查了新版本以修复该错误。 比赛的所有24小时都是如此。
也有必要分配测试人员的工作量。 我们按小时图表绘制了24小时交易间隔中预计的拉取请求数-取决于参与者的数量，服务器负载，第三方活动等。 与测试人员的平均表现以及每个伴随的Bagaton的有效小时数进行比较。 我们分配了“职责”，以便到星期六早上为止，排队人数尽可能少。 总的来说，他们感到困惑。
同时，我们考虑到在进行完Bagaton之后，有必要立即开始进行回归测试，以便尽快评估分支的质量并决定将其注入dev分支。 这是测试人员的额外负担。
功能回顾
对于我们而言，不仅要修复错误，而且要定性地做到这一点非常重要。 可以通过三个过程来验证开发人员在请求请求中发送的代码。 为了使代码对齐，它们必须成功通过：
- 三位经验丰富的开发人员审查并批准了该代码。
- 代码通常崩溃并且没有通过自动测试；
- 在构建和注入之后，在上述条件下的程序集中的错误不会继续。
我们担心在竞争模式下不会有人互相审查。 在团队内部，您无法发表评论。 因此，他们决定不发明任何东西并按照标准流程采取行动，就像在工作模式中一样：任意的交叉审核-谁有空，他都会自己承担这个过程。
还必须进行跟踪，以使评论不会进入队列。 为了安全起见，我们吸引了签名者（包括那些没有参加过比赛的签名者）参加评论，并积极提醒参与者有关质量的信息。 一位高级iOS开发人员在为团队修复错误的同时，每天收到80个请求请求-他阅读并理解。 这真的很多！
我们选择并评估错误
我们采用了低优先级的错误，并通过标签和日期消除了明显的垃圾。 总共发现了490个错误-大多数是中小型的，由于更重要的任务而无法实现。 这些都是理智的琐事和未成年人：
- 版本之间反复发生的错误
- 根据用户要求整理的错误
- 最新鲜的崩溃
- 回归错误
- 影响UX的错误
根据关闭优先级，将所有错误分为三波：
- 第一波-大约230个错误
- 第二波-大约150个错误
- 第三波（保留）-大约110个错误
缺陷的评估不是根据复杂性，而是对业务的重要性。 最关键的是“人为地”，并暂时置于优先级“阻止者”和“关键”中。 错误的优先级越高，为此获得的积分就越高。 没有考虑复杂性-碰巧错误阻止程序在20分钟内关闭，而琐碎-在4小时内关闭。 对于一个错误，您可以获得1到7分。
我们根据封闭规则中的错误值来保持每个团队的得分。 如果团队有时间，他们就可以弥补以下缺陷。 通过价值激励可以首先关闭更严重的错误。
如何关闭错误
我们将第一波错误分成11组（有边距），它们的分数相同，并且Android和iOS的比例相等。 第一波是“昂贵的”漏洞，优先级的漏洞会增加成本。 为了方便在Jira中进行搜索，我们为他们分配了适当的标签。 每个小组发布了大约20个错误。
在比赛开始时，我们召集了队长并演奏了唱片。 此外，队长在其过滤器中指定了所需标签，并在团队中分配了相应的错误。 因此，我们设法消除了混乱的错误修正程序，这些错误修正程序使这些人只会采取他们更容易理解的方式。
在最初的四个小时内，仅针对那些带有落在他们身上以设定特定节奏的标签的错误，团队才获得积分。 时间到了，仍然开放的虫子进入了第二波，增加了其他有意义的虫子，可以将它们关闭在Bagaton中。
到19:00为止，所有未公开的bug都进入了第三次浪潮-除了已经计划好的那些bug。 结果，到了晚上，我们遇到了“快速”的错误，这些错误会按照常规流程关闭：缓存和当前的错误，实际上是在Bagaton的前一天卸载的，以及优先级最低的错误。 这三波浪都去上班了。 结果，在493个选定的错误中，有286个被关闭以进行Bagaton。
Bagaton团结
Bagaton总部位于我们的会议室，还进行测验和视频游戏比赛。 团队不受限制，分散在方便的地方。 结果，整个银行都发现了有关巴顿的信息。 四楼的一位产品发布者说：“我要在14楼见面，寻找合适的会议室。 突然我明白，我刚刚看到熟悉的面孔，我又回来了-我的开发人员正坐在雕像上，威武与主力，对我的关注度为零。 哈-我认为-他们不会对产品所有者隐瞒，并且超过10层楼，好吧，已经坐好了，错误修正是对的。”
有一个团队，其中只有一个Android入选，同时有六个强大的iOS开发者。 我们非常出色地用iOS错误将这个团队淘汰了。
此外，来自该地区的七名开发商来到了巴格顿。 一些人是第一次与他们的团队见面，而以前他们是通过视频会议才见过的。 看着这些家伙如何积极参与这个过程真是太酷了。
如何评估结果？
对于将近一百名开发人员而言，我们只有15个测试人员。 晚上一共有四个。 所有这些还不够，因此第二天继续进行测试。 是测试人员向团队授予积分，因此我们从团队中删除了积分，以消除偏见。 在正常的工作流程中，测试人员可以致电开发人员并发现：“听着，伙计，有这样的问题……”。 在Bagaton上非常严格：测试人员应该包装所有未通过的东西。
因此，我们能够看到一些开发人员没有按照公认的流程进行工作。 Hackathon已成为所有偏差的催化剂。 那些流程清晰的人在第一波测试中就通过了测试并获得了分数。 并非真正往来的每个人都进入了队列，他们在巴格顿过后就已经倾斜了。 它有60个错误。
突发事件
总的来说，一切都照常进行，事件是典型的，并按工作顺序解决。 当发生故障时，一些签署者立即从错误修复切换到消除事件。
有一个有趣的事件。 在准备仪表板时，我们描述了可能的风险：访问Jira，滚动更新等。 他们通知所有管理员，在执行任务之时，有必要暂停所有维护工作，Jira的更新和服务器。 创建了备份帐户以访问Jira。 突然在18:00左右，我们意识到仪表板已停止收集数据。 假设是不同的。 也许他们没有考虑某种安全协议？ 原因是出乎意料的。 我们的组织非常庞大，并非总是能够获得有关所有计划流程的完整信息。 我们的仪表板已部署在其中一台辅助服务器上的虚拟机上。 事实证明，是在这一天（星期五晚上），根据未知计划，该服务器已从插座上断开物理连接，装入汽车中并发送到我们新数据中心的永久居住地。 结果，到周六早上，我们不得不收集所有数据并以手动模式计算积分。
合并分支和其他结果
在正常操作模式下，整个分支由800多个测试用例手动驱动。 完整的测试人员团队将在两周内完成我们的全职回归测试。 我们不能长期保持不变。 为了减少测试时间，我们选择了应用程序运行状况的主要测试案例-大约107个。直到星期一结束，他们开车使用了80％的iOS，50％的Android，并且没有发现一个严重的错误。 我们决定分支可以合并。
在Bagaton上关闭的286个bug中，有182个已修复。 其余的是由于各种原因（错误（设计或功能已更改的地方））不相关的二十一点。 这些错误并不重要，但现在不再需要分散注意力，您可以从容地专注于重要任务。
同样，根据bagaton的结果，许多人提出了一个问题：我们制造了多少个错误？ iOS上只有8个错误，Android上只有7个错误。
对于我们而言，重要的是，开发人员应与其他团队成员平等地对产品代码负责。 这在任何开发中都很重要，但是在分布式开发中，它成为成功工作的先决条件。 在我们看来，我们设法提高了相同所有权和团队合作精神的水平。 结果产生了一个故事，并带来了很多好处：在短时间内，我们修复了许多错误，未完成的积压工作，丰富的团队技能并赢得了很多拥护者。
Sberbank数字商务平台团队准备的材料