如果从过去十年的“敏捷转换”中吸取了一个教训，那么采用或实现 敏捷 方法就没有一个一刀切的解决方案。 每个组织都有不同的需求、约束和要求。 盲目遵循处方不会导致成功。
敏捷运动是不断寻找方法来改进构建软件的做法。 这不是关于完美的日常站立或回顾。 相反，它就是创造一种文化，其中正确的事情往往发生得更频繁。 像站立和回顾等活动有自己的位置，但他们不会改变组织的文化。
本文详细介绍了每个组织都需要创建敏捷思维模式和文化的基础要素。 不应盲目遵循这些建议。 每个组织都应在给定环境中应用有意义的内容。
计划和节奏
没有完美的冲刺长度。 团队采用一到四周不等的冲刺周期取得了成功。 最重要的是一致性。
选择适合组织文化、产品以及更新频率期望的冲刺长度。 例如，Microsoft 的开发工具部门（约6,000人）以三周为一个周期进行工作。 领导团队没有选择这个冲刺长度：它来自工程团队的直接反馈。 整个部门在这个为期三周的冲刺计划中运作。 自那以后，冲刺已成为组织的 心跳 。 现在，每个团队都步调一致。
必须选取短跑长度并坚持。 如果有多个敏捷团队，他们都应该使用相同的冲刺长度。 如果反馈驱动更改，则接受。 当正确的术语到位时，它就会变得清晰起来。
航运文化
Microsoft首席集团项目经理彼得·普罗沃斯特说：“你不能欺骗航运。该声明的简单性和真理是敏捷文化的基石。 Peter 的意思是，发布软件会教给你不可能理解的事情，除非你亲自发布软件。
人性是推迟或避免做事，直到绝对必要。 在软件开发方面，这不能更真实。 团队将修复 bug 延期到周期结束，把设置或升级的事情拖到迫不得已才去考虑，并且通常尽可能地避免处理像本地化和可访问性这样的内容。 出现这种模式时，团队将建立技术债务，稍后需要支付这些债务。 航运要求支付所有债务。 你不能欺骗发货。 若要建立敏捷文化，请先尝试在每个冲刺结束时交付产品。 起初并不容易，但当团队开始尝试时，他们很快就发现许多应该发生却没有发生的事情。
健康团队
完美的敏捷开发团队没有标准的公式。 但是，一些关键特征使成功更容易实现。
尽可能让团队协同办公
团队成员分布在不同地理位置的情况下，能否取得成功？ 是的，但更困难。 当人们在同一个房间并肩而坐时，有意义的交流自然而然地发生。 仍然可以与分布在全球各地和不同时区的团队合作并取得成功。 但是，没有所有这些障碍，同一个团队不会有优势吗？
保持团队完整，维持合理的时间长度
允许团队一同掌握协作构建软件的艺术。 团队被重新调整时，他们之间形成的任何默契都会被打乱。 有时，重新组织是合适的，但是当团队有机会学习如何协同工作时，团队通常更有效率。 作为指南，尽量使团队保持至少 12 个月不变。
工作负载应该均衡，而非人员配置
有时团队落后，需要帮助。 解决这一问题的常见策略是将一个人从一个团队借给另一个团队。 但是，这可以适得其反。 更好的解决方案是将工作负载均衡给另一个团队，而不是在团队之间对人员进行负载均衡。 把一个人从一个团队调去另一个团队会打乱两个团队的运作，这可能会令被调动的人感到沮丧，即使是暂时的。 这一切会影响团队的工作效率，而且更有可能对恢复计划的能力产生负面影响。
负载均衡工作而不是人员允许已建立的团队介入并提供帮助。它成为关于 优先级的对话，而不是关于 人的谈话。
让团队负责功能区域，而非架构层
努力构建拥有功能区域的垂直团队。 这些团队负责将功能添加到其区域所需的所有工作，从数据库到用户界面更改。 该团队有权提供并拥有端到端体验。
当水平团队拥有体系结构层时，没有一个团队负责端到端体验。 添加功能需要多个团队进行协调，并且需要更高级别的依赖项管理。 解决 bug 需要多个团队调查他们是否拥有修复 bug 所需的代码。 团队判断 这不是他们的 bug 后，Bug 会在各个团队之间转移，重新分配给其他团队。
功能团队没有这些问题。 所有权和问责是明确的。 有些以体系结构为基础的团队可能有其存在的空间。 但是，专注于特定领域的团队更有效。
后续步骤
随着团队开始自己的敏捷转型，请记住这些基本原则。 请记住，对于每个组织来说，没有单一的方案可以适用。 敏捷转换是一个旅程。 进行更改并从中学习。 随着时间的推移，组织将开发所需的敏捷文化。
Microsoft是世界上最大的敏捷公司之一。 详细了解 如何Microsoft采用敏捷文化进行 DevOps 规划。
了解 Azure DevOps 如何使团队 能够采用和缩放敏捷文化。