采用 Agile 文化

如果要说从过去十年的“敏捷转换”中吸取了一个教训，那便是：采用或实现敏捷方法没有一个一刀切的解决方案。 每个组织都有不同的需求、约束和需求。 盲目墨守成规不会带来成功。

敏捷运动关乎不断寻找改进软件构建实践的各种方法。 而不是关乎完美的日常站会或回顾。 相反，它关乎创造一种文化，其中正确的事情往往出现得更为频繁。 站会和回顾等活动的历史地位不可撼动，但它们无法改变组织的文化。

本文详细介绍每个组织都需创造敏捷思维模式和文化的相关基础要素。 但，不应盲目遵循这些建议。 每个组织都应在具体环境下采用对其有意义的内容。

计划和节奏

没有完美的冲刺长度。 对于长度从一周到四周不等的冲刺时长，团队都曾取得过成功。 其中最重要的是一致性。

选择适合组织文化、产品和希望提供更新的冲刺长度。 例如，Microsoft 开发人员工具部门（约 6,000 人）采用为期三周的冲刺。 领导团队并未选择此冲刺长度，它其实来自工程团队的直接反馈。 整个部门在为期三周的冲刺计划中开展工作。 自那以后，冲刺便成为组织的心跳。 现在，每个团队的节奏都会趋同。

选择冲刺长度并坚持不懈十分重要。 如果有多个敏捷团队，他们均应采用相同的冲刺长度。 如果有反馈能推动变化，则应予以接受。 当正确的术语出现时，它就会变得清晰起来。

交付文化

Microsoft 首席集团计划经理 Peter Provost表示：“你没法欺骗交付”。该声明的简明和真理正是敏捷文化的基石。 Peter 的意思是：交付你的软件会教会你只有真正开始交付软件时才能理解的事情。

推迟或懒惰是人的天性，除非到了绝对必要时。 在软件开发方面，这更是无比真实。 团队将 bug 推到周期结束时来解决，在强制安装或升级之前不会考虑安装或升级，并且通常会尽可能避免开发本地化功能和辅助功能等内容。 出现此模式时，团队会形成技术债务，而后续则需为这些债务付出代价。 交付时要求所有债务都得到清偿。 你没法欺骗交付。 若要建立敏捷文化，请先尝试在每个冲刺结束时交付产品。 起初这并非易事，但当团队努力尝试时，他们很快就会发现本应发生但却没发生的一切。

健康的团队

打造完美的敏捷团队没有一定之规。 但是，某些关键特征会让成功更容易实现。

尽可能让团队聚集在一起

团队能否通过跨不同地理位置的人员来取得成功？ 可以，但这更困难。 当人们并坐在同一个房间时，往往才能出现正确的对话。 尽管如此，仍有可能通过遍布全球和不同时区的团队来取得成功。 但是，没有所有这些障碍的同一团队就缺少优势吗？

在合理的时段内保持团队的完整无损

允许团队掌握一起构建软件的艺术。 当团队争先恐后时，他们建立起来的化学反应都会中断。 有时需重新组织，但当团队有机会学习如何协同工作时，团队通常更有效率。 作为指导建议，尽量使团队保持至少 12 个月不变。

均衡地分配工作，而不是人员

有时团队会出现落后，且需要帮助。 解决此问题的常见策略是将一个人从一个团队出借给另一个团队。 但是，这也可能适得其反。 更好的解决方案是将工作均衡地分配给其他团队，而不是在各团队之间对人员进行均衡分配。 从一个团队拉一个人来帮助另一个团队会扰乱这两个团队，同时还可能会使出借的人感到挫败，即便是临时出借也是如此。 所有这一切都会影响团队的工作效率，而且更可能对恢复正常计划的能力产生负面影响。

通过均衡地分配工作而不是人员可让某一现有团队介入其中并提供帮助。它会变成关乎优先级的对话，而不是关乎人员。

让团队负责特定功能领域，而不是体系结构的各个层级

努力构建负责各自功能领域的垂直团队。 这些团队负责将功能添加到其所在领域所需的各项工作中，其范围涵盖从数据库到用户界面更改。 该团队有权提供并负责端到端的体验。

当水平团队负责体系结构的各个层级时，没有一个团队会负责端到端的体验。 添加功能需要多个团队进行协调，并且需要更高水平的依赖关系管理。 解决 bug 需要多个团队调查他们是否负责修复 bug 所需的相关代码。 当团队确定它不是他们负责的 bug 并将其分配给另一团队时，bug 就会四处碰壁。

功能团队则没有这些问题。 所有权和问责均十分明确。 对于某些基于体系结构的团队，或许还可应对此问题。 但是，聚焦垂直领域的团队更有成效。

后续步骤

随着团队启动自己的敏捷转型，请记住这些基本原则。 请记住，对于每个组织来说，没有绝对有效的一定之规。 敏捷转换是一个旅程。 做出改变并从中学习。 随着时间的推移，组织将培养出所需的敏捷文化。

Microsoft 是全球最大的敏捷公司之一。 详细了解 Microsoft 如何采用敏捷文化进行 DevOps 规划。

了解 Azure DevOps 如何让团队采用和调整敏捷文化。