我是
UniSender邮件
服务的 PM。 6年前，我是一名程序员，现在负责产品团队之间的互动。 以前，我们的开发由一个分布式团队组成，并且遇到了2个麻烦。 但不是傻瓜和马路，而是冲刺和无聊的站立动作延迟了半个小时。
我会告诉您我们如何解决它们。
就像我说的，我们遇到了两个麻烦：
- 由于一项任务的失误，Sprint可能会持续存在 。 质量检查和开发人员在同一个冲刺中工作，任务范围在工作开始时就已确定，整个团队都英勇地急于实施它。 有时，紧急漏洞到了“主”修补程序。 冲刺任务可能非常繁琐。 当一些任务准备发布时，其他任务仍在开发中。 结果，团队可能会由于一项任务而延迟冲刺。
- 站起来既费时又有用 。 团队不断壮大，在Skype上进行了站立训练，一开始没有任何麻烦。 当站立姿势开始伸展20-30分钟时，我们开始怀疑出了点问题。 在场的人们并不总是了解其他团队成员在做什么。
有一段时间，我们生活在这些问题中，然后努力抗争。
- 他们通过引入有关人类的法规来减少脱口秀。
- 他们减少了在场人员的数量-只有团队负责人可以站起来。
- 尝试了每周冲刺。
- 减少了sprint中的任务数。
这些尝试没有得到预期的结果。 已经有了一种认识，那就是根本的变化是不能放弃的。
在这里有必要对产品说几句话。
我们是24/7全天候可用的SaaS解决方案。 除了对用户可见的部分（GUI）之外，我们还具有广泛的系统逻辑层，无论一天中的时间或该国的政治局势如何，都可以正常工作。 即，服务的开发和更新正在进行中，而不会停止。
去看板
第一次大规模革命发生在我们意识到：“混乱不适合我们”时。
我们决定改用看板。 当然，我们不是丰田，也没有开始实施全部实施。 因此，“我们的看板”将不同于“您的看板”。
短跑和团队合作
简而言之，我们的版本：
- 我们将sprint（一项完整的功能）视为工作单元。
- 根据工作量和必要的技能，收集了一个任务小组。 一个团队通常最多拥有3个开发人员和1个质量检查人员。 没有常设队。
- 同时冲刺的数量已超过一个。
- 没有看板的物理板和其他属性，通过添加Jira来执行任务。
在这种情况下，团队必须从头到尾进行冲刺。 这也适用于测试阶段：冲刺工作的同一个人纠正了错误。
结果。- 随着大型任务的延迟，其他任务没有受到影响，其开发已完成。
- 部署过程中的问题数量有所减少-在一次冲刺中，杂色任务减少了。
站立
站立式比赛发生了变化-来自每个团队的代表在一个单独的冲刺中访问了它们。
结果。- 站起来就像站起来一样，我们再次开始适应标准的10-15分钟。
因此，我们能够解决关键问题。
但是……整个冰山开始从岛后出现！
改用看板后，我们有一个专门的前端团队，后端和产品团队中有更多员工。 部门之间的交互变得更加复杂-多个团队可以从事一个项目。
我们解决了一些问题，但新问题浮出水面：
- 并非每个人都参加站立比赛-团队通常不得不重述信息。
- 一个质量检查人员可以与不同的团队进行2-3次平行冲刺。 我不得不切换：记住sprint的功能，并不断在测试环境中重新部署代码。
- 质量检查未完全参与冲刺工作。 通常，任务在冲刺结束时就到达了他们，并且在完成开发之后研究了需求。
- 团队聚集在一起参加该项目，其组成经常发生变化。 一个由两个开发人员组成的团队可以同时处理3个Sprint：测试中2个Sprint和1个当前Sprint。
- 很难估计开发时间。 目前尚不清楚之前未完成的冲刺将吃多长时间。
一段时间以来，我们一直遵循新规则，并面临新挑战。 我们尝试了不同的方法，并填补了许多难题。
最后，我们再次开始怀疑问题出在哪里。 一场新的革命。
分成小组，进行新的站立训练，引入Fireteam
我们分析了从构思开始到在产品中部署完成的过程。 我们研究了敏捷方法在其他公司中的工作方式。 我们意识到我们对开发过程的态度还不错。
无需中断工作系统，您只需解决造成痛苦的时刻。
这就是我们在开发过程中所做的更改。
冲刺
我们仍然采用“冲刺”的概念。 Sprint是团队的“近两周”工作范围。
有什么好处。 该代码不会“变质”，并且可以在没有明显延迟的情况下进入产品。 如果团队要在2周内进行冲刺-您需要尝试将其收紧至一个月。
有什么可以改进的。 通常我们会错过标记，并且冲刺会有所延迟。 最初难以评估处理某些sprint的时间（例如，大量重构）。 我们必须解决这个问题。
分成团队
我们将一个大团队分成几个小团队。 他们每个人都包括2-3个开发人员和一个专门的质量检查人员。 现在，团队稳定了，并且不会因项目而异。 有时，人们在团队之间切换以优化花名册或向团队添加所需的专业知识。 BA参加了该团队，但同时可以领导2-3个项目。
尽管其余的仍然是一支球队）同时，整个团队从开始到完成一个项目。 一个项目可以包含多个冲刺。
有什么好处。- 团队在同一房间。 在此之前，每个人都坐在部门中。
- 该团队从头到尾都参与了该项目的工作，这减少了总线系数。
- 团队成员出席所有活动：复古，站立，宣誓。 所有员工都紧跟最新任务。
- 该团队不再处理其他人的冲刺。 现在，一切都是本地的。
有什么可以改进的。 我想在团队中全面介绍BA。 这是有问题的，因为VA通常比团队的其他成员更早开始工作。
团队合作
一个工作团队最多只能有两个冲刺：“一个仍在测试中的冲刺”和“我们将看到的新冲刺”。 通常，在开发结束后，每个人（一旦被释放）都将开始新的冲刺。
有什么好处。 团队工作变得更加可预测，每个人都熟悉代码并可以在测试期间支持sprint。 参与者在任务之间切换的可能性较小，并且切换过程现在更快。
有什么可以改进的。 理想情况下，团队中只有一个冲刺。 但是就目前而言，理想的世界还不是我们的世界。
消防队
每个团队选举一个星期。 此命令响应所有外部刺激因素：来自其他部门的呼叫，服务的异常行为，修补程序。 我们称这个团队为“ Fireteam”。
有什么好处。 Fireteam周在冲刺时间内不计入球队。 在消防之间，员工可以专注于他们的任务：
- 重构。
- 完成冲刺任务。
- 编写文档。
- 与其他团队进行知识转移。
缺点。 在消防队周中，团队的生活非常重要。 所有部门都很喜欢并认识这些人，尤其是技术支持。 您必须不断在不同任务之间切换：借方，阅读日志，锯切紧急任务并扑灭所有火灾。 所有这些必须同时完成。
站立
我们介绍了两种站立式：
- 团队 他们参与了一个从事该项目的团队。
- 一般 他们每周举行一次，每个团队的领导参加。
有什么好处。- 该团队将了解sprint的状态。
- 员工知道其他团队在做什么。
- 站起来不会变成“无聊的活动，从纸上读取一些数字。” 所有在场的人都知道危在旦夕。 检测工作中的问题区域变得更加容易。
- 站起来需要5到10分钟。
缺点。 团队仍将信息传达给团队。
总结
因此，逐步改变流程，我们解决了大多数紧迫的问题：
- 我们组建了由2-3个开发人员和质量检查人员组成的稳定团队。 每个团队现在不超过2个冲刺，参与者不参与其他人的项目。
- 有一个团队处理来自其他部门的消息，以响应服务和修补程序的异常行为。 其他团队不会因这些任务而分心。
- 现在公司有两种类型的站立：团队和普通。 所有员工都将获悉有关冲刺状态的信息，站起来通常需要5到10分钟。
好吧，我们正在努力。
