成为一支健康的工程团队的一部分就是成为一支自我组织的团队！这是一个角色和职责明确的团队，致力于通过深思熟虑的计划来交付项目。
去年，我们创建了一个名为 Micros Scale 的新团队，专注于创建 Atlassian 的内部 平台即服务 (PaaS)，即我们的开发人员体验平台。由于我们的工作范围固定，时间线明确，因此我们更加致力于完成更多工作，更加集中，以目标为导向，并做到积极主动。
但是，之前我们的团队接到了大量临时的操作工作，这使我们无法正确计划冲刺。至少 55% 的团队能力被分配给保持运转 (KTLO) 轮换。这使看板成为当时最适合我们的方法。
值得注意的是，根据 Tuckman 模型，Micros Scale 团队处于组建阶段，有一些需要改进的领域，包括能力规划、冲刺规划、目标设定、团队反思、梳理和故事阐述、估计、项目分解等。
哪种敏捷方法适合我们？
Micros Scale 有两个高度复杂的重大项目，截止日期是向我们的客户公开宣布的。这意味着更快的交付至关重要。我们需要对我们的交付方法充满信心，并希望像敏捷专业人士一样进行规划。我们希望我们的团队能够自我组织，实现共同的目标，并以经验为基础。
我们根据以下问题重新评估了我们的敏捷方法：
- 是否有可能为每次迭代设定目标，以实现具有独特主题的目标？
- 我们能否承诺一两周的交付时间？
- 我们能否详细说明并锁定我们需要解决的要求？
- 临时请求变更任务优先级的频率是否较低，我们发生重大变更的可能性是否较小？
- 我们的团队是新的，在敏捷流程方面还不那么成熟吗？
由于这些问题的答案是肯定的，我们意识到 Scrum 是我们团队最好的敏捷方法。以下是我们用来为决策提供依据的其他详细信息：
| | | | |
|---|---|---|---|
| 敏捷方法 | 这是关于什么的？ | 它对我们有帮助吗？ | 为什么？ |
| Scrum | Scrum 是关于清晰的路线图和按优先顺序排列的工作块，而看板是关于可视化您的工作，这是针对团队临时提出的。 | 是 | 我们有清晰的预定义待办事项列表，需要完善和优先排序。我们的工作是可预测的，这与之前的团队不同，之前的团队充满了惊喜和高优先级请求。 |
| 故事不应该在冲刺中途变更。 | 是 | 我们可以采取更灵活的方法，在本例中为 scrumban（Scrum 和看板的混合体）。 | |
| 对于仍在学习功能领先的敏捷团队来说，Scrum 更容易采用。Scrum 的规范性更强，并且有常规程序和时间范围提供保障。 | 是 | 我们有一支由新成员组成的新团队，仍处于组建和头脑风暴阶段，因此 Scrum 可以帮助我们变得更加成熟。阅读 Tuckman 模型。 | |
| 看板 | 限制正在进行的工作，并专注于缩短项目周期时间。用例是您的团队没有工作时间限制和既定时间线。该请求会尽快提交给团队并得到解决（例如服务台团队的 SLA）。 | 无 | 其他团队依赖我们，因此我们需要预估的时间线来帮助其他人做出相应的计划。我们向 Atlassian 客户公开做出了一些承诺，因此我们需要谨慎行事并为之做好计划。我们没有很多像服务台这样的短时请求。 |
| 非常适合有大量传入运营请求的团队，请求的优先级和大小各不相同。 | 是 | 我们没有沉重的 KTLO 负载，工作流由团队成员轮换管理。如果我们愿意，我们可以把那个被打扰的角色当成看板。 |
我们选择了 Scrum
我完全意识到，工程经理的主要特征之一就是像指挥家一样行事，同时他也是联系人、指南针和教练。所以我同样需要锻炼指挥家能力。以下是我实现这个目标的方式：
了解更多敏捷信息
Atlassian 的内部学习资源帮助我提高了敏捷实践方面的技能。我参加了大量的敏捷课程，并咨询了敏捷教练。我还采访了几位工程经理，学习其他组织和团队的经验。
使用 DACI
DACI 决策框架——代表“推动者、审批者、贡献者、知情者”——用于做出有效和高效的小组决策。我向我的团队介绍了 DACI 变更提案，以确保获得他们的意见、同意和支持。
使用冲刺模板
我想出了一个管理我们冲刺的流程，并为每个冲刺建立了一个模板，以帮助进行更合理的规划。冲刺计划模板包括：
- 如何回顾之前的冲刺，确保我们清楚自己取得的成就并进行庆祝。
- 如何回顾之前的冲刺，并将我们的学习应用到下一个冲刺中。
- 什么是冲刺节奏、名称、目标和目的？
- 我们承诺交付多少故事？冲刺范围是什么？
- 如何根据人们的可用性进行能力规划。
- 我们需要在冲刺中期进行哪些活动才能为下一次冲刺做好充分准备？
- 如何写故事、阐述要求以及解决问题的解决方案。
- 如何跟踪我们承诺的故事状态以及如何处理未完成的故事。
转向 Scrum 是值得的
以下是我们转向 scrum 所做的改进：
速度改进
在敏捷中，衡量团队生产力的因素之一是速度，也就是说 Scrum 团队在冲刺期间完成的平均工作量。我们使用速度图来了解我们的团队的承诺和交付的内容。在下方速度图中，灰色列显示了团队根据能力承诺的故事点数。我们将其与蓝列进行比较，蓝列是他们实际交付了多少故事点。然后，团队可以用它来调整对未来冲刺的预测。
及早发现风险
能够及早发现风险并提出拟议的解决方案是项目成功的关键。
通过定义目标和冲刺主题，我们选择了有凝聚力的故事来实现目标。在冲刺中期会话，我们的团队整理、完善和详细阐述了故事。在详细阐述过程中，我们提出了以下问题：
- 需要做些什么?
- 我们为什么要做这项工作？
- 它会增加什么业务价值？
这有助于我们的工程师识别依赖关系，并对影响较大的请求单进行优先排序，以消除障碍。它还促使我们改变了工作方式，使每个项目都更加专注于团队。
庆祝！我们成功交付
能力规划和目标设定为我们带来了有意义的动力，也为我们带来了保持承诺透明的挑战。我们成功交付了 Atlassian PaaS 账户分片的一个关键阶段。我们还即将交付数据驻留项目的第一阶段，以覆盖更多 AWS 区域，以实现可靠性、灵活性和合规性。
从“组建”过渡到“规范”
正如我上面提到的，Micros Scale 团队相对较新，根据 Tuckman 模型，往往处于组建阶段。
为团队定义统一的目标能够推动每个人团结一致和相互支持，以实现团队目标并提高团队动力。我们失败、反思、吸取教训，然后变得更好。三个半月后，我们又为 Micros Scale 扩招了 50％ 的员工，并且我仍然很自豪地将该团队视为一支规范团队。
沟通改进
制定计划并在每次冲刺期间全神贯注，这提高了我们计划为整个团队做的事情的可见度，也使我们能够保持同步。对于工程经理和利益相关者来说，跟踪项目障碍和进展要容易得多。
如何选择敏捷方法
- 如果发现问题，请立即查看您的流程。以敏捷的方式思考：人员、流程和工具。
- 评估您的团队项目和职责，找到最适合您团队的敏捷方法。请查看我们的看板与 scrum 页面，了解有关这些方法的更多信息。
- 如果您决定转向 Scrum，我建议使用 Jira Scrum 板或者在 Confluence 或您最喜欢的工具上创建一个模板。
对于每个冲刺，创建一个冲刺计划页面，以回顾和反思上一次冲刺，并根据团队的能力和冲刺目标为下一次冲刺做计划。这是我的个人 Confluence 模板：
这是我的能力规划模板，包含在我的整个 Scrum 模板中：
还有我的冲刺目标和范围模板：
在冲刺中期，最好再用一页来跟踪团队在过去一周的表现，根据当前的冲刺进度决定需要将哪些故事延续到下一个冲刺中（整理），并详细说明您整理的故事（故事优化）。这是我的冲刺中期待办事项整理和优化模板：
每个团队都不一样，对我们有用的东西可能对其他团队不起作用。Scrum、看板或两者兼而有之，比如 scrumban 和 kanplan，可能就是更好的方法。评估团队的特定需求并了解哪种方法对他们有用，这一点至关重要。
