敏捷之旅：Braze 如何重新构想其软件项目管理流程

制定计划

经过一番思考，我们决定为工程团队采用一种久经考验的方法——我们决定要变得更加敏捷。

为了应对这一新挑战，我们希望组建一个小组，代表并利用我们整个产品和工程组织的知识——因此我们创建了一个委员会，由八名成员组成，代表产品管理、设计和工程。 我们包括经理和个人贡献者，以及具有不同敏捷背景、资历和经验的人。

这个敏捷委员会，正如我们所称的那样，在处理这种情况时牢牢记住了一些关键原则：

• 我们希望尽可能跨方法和软件使用经过验证的解决方案。 成为独一无二需要付出很多努力，而我们只希望在必要和战略性的领域独一无二。 我们还希望人们能够在 Google 上搜索有关管理工作的最佳实践——或者更好的是，让加入 Braze 的人已经知道如何去做。
• 我们希望 Braze 的产品工程团队在他们的运作方式上基本保持一致，因为能够说同一种语言是很有价值的。
• 我们不想教条地做任何事情，或者不经过深思熟虑。 仅仅选择一种方法然后照本宣科是不够的； 对我们来说，重要的是常识和深思熟虑的迭代统治了这一天。

有了这些指导方针，我们决定使用 Scrum，这是一个敏捷框架，已被证明对许多组织有效。 它广为人知，具有可扩展性，当您希望实施敏捷流程时，它是安全的默认选择。

接下来，我们面临两个主要决定：（1）我们应该使用哪些工具来支持我们的新流程，以及（2）我们应该如何对我们的流程进行更改。 我们讨论、评估和演示了几个软件，最终证明 Atlassian 的 Jira 是我们的正确选择。 这是一个经过充分验证的解决方案，我们团队中的几个人已经有使用它的经验，Braze 中的其他团队已经在使用它，这为更好的跨团队协作提供了机会，因为我们都在一个系统中工作。

在选择敏捷推出计划时，我们需要做出一些关键决定。 首先，我们如何训练/赋能团队？ 我们可以聘请敏捷教练，让团队中有经验的人来培训其他人，或者让顾问帮忙。 其次，我们是否应该让在敏捷方面有一定经验的工程团队在实施之前等待培训？

最后，我们决定让熟悉 Jira 和 Scrum 的团队在他们认为有能力的范围内开始工作，并聘请了一名顾问来帮助完成整个组织的过渡。 我们对让团队中的人或独立玩家主要负责在过渡期间指导团队成员不感兴趣，因为：

• 我们不希望任何单独的团队拥有我们如何做敏捷，我们认为培训会更好地接受，如果他们来自第三方的建议会更具包容性
• 我们认为咨询业务会比单独的敏捷教练更稳定、更可靠
• 我们希望对整个工程组织进行基础培训，并在开始时不对组织成员对敏捷的知识做任何假设
• 最后，我们想让教练在某个时间点离开，以明确我们组织中的每个人都有责任维持前进的过程

执行计划

经过几个月的计划，我们有了一份详细的文件，详细说明了我们打算做的所有事情——我们与整个组织分享了它以获取反馈。 然后，在评估了几家供应商之后，我们选择了 Eliassen 与我们一起踏上敏捷之旅。 这段旅程始于 Eliassen 进行的为期两天的敏捷培训，随后是 Eliassen 与我们联系的专家为期三个月的敏捷指导。

从一开始，我们就对迁移到 Jira 和 Scrum 相当谨慎。 互联网和我们团队的个人经历都充满了关于过度教条方法的危险、Jira 如何成为“反模式”以及 Scrum 在组织中可能出错的所有方式的警示故事。 我们咨询过的人都非常警告我们，这些变化可能需要时间，而且在我们看到敏捷带来的真正好处之前，很可能会经历成长的痛苦。

值得庆幸的是，我们立即发现了新流程的价值。 这种过渡的好处之一是，我们从未感到盲目地遵循 Scrum 的任何特定方面的压力。 为了让事情变得更好，我们会每两周回顾一下事情的进展情况，然后修改需要修改的内容。 在三个月的辅导中，我们在整个工程组织中实施了彻底的变革：

• 每个人都学会了如何编写、修饰、指出、分解和挑选用户故事
• 在完成手头的工作时，站立会重新获得关注
• 产品、设计和工程都学会说相同的语言，界面设计得越来越好

结果

现在我们已经完成了这大约六个月的努力，这些变化是显而易见的——而且是戏剧性的。 我们已经看到导致这项工作的问题显着减少。 借助敏捷，我们现在拥有清晰且易于理解的签核、协作、积压工作创建和梳理机制，并且我们会定期对需要改进的地方进行回顾。

我们还为设计工件提供了更加一致的位置，以及对给定项目真正“完成”的期望更加一致。 查看其他团队正在做什么变得很容易，而且人们比以往任何时候都更容易理解如何很好地合作。

在这个过渡的尾声，我注意到，在任何特定时间，组织中打开的拉取请求的总数都在下降，即使我们正在做更多的事情并扩大我们的团队规模。 通过以较小的增量工作并专注于完成工作，飞行中的项目数量显着减少。

我们在组织中取得的成功也启发了其他人。 我们开始看到 Braze 其他部门的团队开始他们自己的敏捷转型，因此很快会有更多人使用相同的语言并拥有定义和改进协作所需的工具。

外卖

我们努力的两个主要因素确保了它的成功。

首先，它由一个代表委员会推动这一事实对于从工程组织周围和从各种不同的角度获得输入至关重要。 在公司范围内，人们在可能影响他们日常工作的问题上感到被倾听和代表。 随后创建了一份详尽的文档，其中列出了可以与团队共享的敏捷过渡的动机和计划，这也非常有用。 我们相信展示决策是如何制定的并引入清晰的反馈路径——因为它提供了上下文并建立了一个提供反馈的工件。

其次，让第三方帮助指导我们团队的决定至关重要。 拥有一个客观、经验丰富的合作伙伴使我们能够快速对我们的流程进行大量改进。 我们的教练知道什么是好的，并且能够毫无偏见地提出建议，我们可以多次问：“团队通常会如何做 X？” 并立即获得可行的解决方案。 另一方面，如果我们使用内部资源，我们就会冒这样的风险，即我们收到的反馈来自有偏见的一方，并增加了与现有职责的资源争用。

还要别的吗？

如果您想了解更多关于我们如何看待我们的产品以及制作它的工作，请查看 Building Braze。 有兴趣加入我们的团队吗？ 查看我们当前的职位发布。