采纳敏捷文化

如果从过去十年的“敏捷转型”中吸取了一个教训，那么采用或实现 敏捷 方法没有一个适合一切的解决方案。 每个组织都有不同的需求、约束和需求。 盲目关注处方不会导致成功。

Agile 运动是关于不断寻找方式来改进构建软件的方法和实践。 这不是完美的日常站立或回顾。 相反，这是关于创建一种文化，其中正确的事情发生的频率比不多。 像站立和回顾这样的活动有自己的位置，但他们不会改变组织的文化。

本文详细介绍了每个组织需要创建敏捷思维模式和文化的基础元素。 不应盲目遵循它们，而是在给定环境中应用有意义的内容。

计划和节奏

请务必了解没有完美的冲刺长度。 Teams已经成功，不同的短跑长度从1-4周不等。 真正重要的是一致性。

选择适用于组织的区域性、产品和希望提供更新的冲刺长度。 例如，Microsoft 开发人员工具部门 (大约 6，000 人) 在为期三周的冲刺中工作。 领导团队或其他经理没有选择为期三周的冲刺：它来自工程团队的直接反馈。 整个部门在这个为期三周的冲刺计划中运作。 自那以后，冲刺已成为组织的 检测信号 。 现在，每个球队都在游行到同一鼓的节拍。

选择短跑长度并坚持它很重要。 如果有多个敏捷团队，则他们都应该使用相同的冲刺长度。 如果反馈驱动更改，则接受。 当正确的任期到位时，它就会变得清晰起来。

航运文化

彼得·普罗沃斯特 说：“你不能作弊运输”。 该声明的简单性和真理是敏捷文化的基石。 彼得的意思是，寄送你的软件会教你不能和不会理解的事情：除非你实际上正在寄送软件。

人性是推迟或避免做事，直到绝对必要。 在软件开发方面，这不能更真实。 Teams周期结束时的标点 bug，在强制安装或升级之前不要考虑安装或升级，并且通常尽可能避免本地化和辅助功能等内容。 当这种模式出现时，团队正在建立技术债务，需要稍后偿还。 航运要求支付所有债务。 你不能欺骗发货。 若要建立敏捷文化，请先尝试在每个冲刺结束时交付产品。 起初这并不容易，但当团队尝试它时，他们很快发现应该发生的所有事情，但不是。

健康团队

完美的敏捷团队没有食谱。 但是，有一些关键特征使敏捷团队取得成功更容易实现。

尽可能共同定位团队

团队能否找到成功与分布在不同地理位置的人？ 当然，但比较困难。 当人们并坐在同一个房间时，正确的谈话往往发生。 仍然可以与全球和不同时区的团队成功。 但是，没有所有这些障碍，那同一支球队不会有优势吗？

使团队保持完好无损的时间长度

允许团队共同掌握构建软件的艺术。 当团队争吵时，它会破坏他们可能发展的任何化学。 有时，重新组织团队是合适的。 但是，当团队有机会了解如何协同工作时，团队通常效果更好。 作为一个准则，尝试使团队保持至少十二个月不变。

负载均衡工作，而不是人员

有时团队落后，需要帮助。 解决这一问题的共同策略是将一个人从一个团队借到另一个团队。 但是，这可以适得其反。 更好的解决方案是将工作负载均衡到另一个团队，而不是在团队之间对人员进行负载均衡。 将一个人从一个团队中拉下来，以帮助另一个团队中断两个团队，并可能会挫败被感动的人，即使临时。 这一切会影响团队的工作效率，而且更有可能对恢复计划的能力产生负面影响。

对另一个团队进行负载均衡工作允许已建立的团队介入并提供帮助。它成为一个 优先 对话，而不是 一个人 对话。

Teams应拥有功能区域，而不是体系结构层

努力构建拥有功能区域的垂直团队。 这些团队负责将功能添加到其区域所需的所有工作，从数据库到用户界面更改。 团队有权提供并拥有端到端体验。

拥有体系结构层的水平团队意味着没有一个团队负责端到端体验。 添加功能需要多个团队进行协调，并且需要更高级别的依赖项管理。 解决 bug 需要多个团队调查他们是否拥有修复 bug 所需的代码。 当团队确定它 不是他们的 bug 并将其分配给另一个团队时，Bug 被击中。

功能团队没有这些问题。 所有权和责任是明确的。 某些基于体系结构的团队可能有一个位置。 然而，更垂直关注的团队是，他们将更有效。

后续步骤

随着团队开始自己的敏捷转型，请记住这些基本原则。 请记住，没有单一的食谱将适用于每个组织。 敏捷转换是一个旅程。 进行更改并从中学习。 随着时间的推移，组织将开发所需的敏捷文化。

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

了解 Azure DevOps如何使团队能够采用和缩放敏捷文化。