您是水平敏捷的吗？

引言

敏捷是现代项目交付和迭代开发的首选解决方案。人们的关注点自然会放在Scrum或Kanban等敏捷框架上。

但是，有多少人在参与第一个敏捷项目之前，真正参考过《敏捷宣言》呢？

本文着眼于敏捷的更广泛视角，探讨其原因以及为何可能失败。

敏捷宣言

回归基本。敏捷的核心是交付客户价值，并将客户满意度放在首位。它建立在支持宣言的12个原则之上。

• 我们最优先考虑的是通过早期和持续交付有价值的软件来满足客户。
• 欢迎需求变更，即使是在开发的后期。敏捷过程能够利用变化来为客户的竞争优势。
• 频繁交付可工作的软件，周期从几周到几个月不等，倾向于较短的周期。
• 在整个项目期间，业务人员和开发人员必须一同工作。
• 围绕积极主动的个人建立项目。给他们所需的环境和支持，并信任他们能够完成工作。
• 向开发团队以及团队内部传递信息最有效的方法是面对面交谈。
• 可工作的软件是衡量进展的主要标志。
• 敏捷流程促进可持续发展。赞助商、开发人员和用户应该能够长期保持稳定的步伐。
• 持续关注技术卓越和良好设计可以增强敏捷性。
• 简约——即最大化未做工作的艺术——至关重要。
• 最佳的体系结构、需求和设计源于自组织的团队。
• 团队定期反思如何提高效率，然后相应地调整其行为。

什么是横向敏捷？

Scrum和Kanban等框架是基于敏捷原则的交付模型，并实现了上述大多数目标。

这有助于团队应对变化，在优先排序、自我改进、为团队提供工作以及促进面对面沟通方面。

但这些交付模型不会指导您如何进行敏捷架构设计，或者如何组织企业以促进敏捷。这取决于您自己。

忽视敏捷的这些方面，就是我所说的“横向敏捷”。

这是因为您的组织可能仍然按照部门和孤岛进行水平划分。这使得实现敏捷的一些原则变得更加困难，也是敏捷可能失败的原因。

在某些情况下，与其它替代方案相比，横向敏捷可能是最好的折衷。它能解决一些交付和规划问题，但会限制敏捷性，从而限制您的竞争力。

关键在于，单独的敏捷交付框架或流程并不能让您完全实现所有12个敏捷原则。

成为真正的敏捷

要完全实现敏捷，除了采用的交付模型之外，还有一些缺失的环节。这可能需要对组织进行转型。对于初创公司来说，则需要从一开始就建立支持敏捷的组织结构。

让我们回顾敏捷原则并探讨其中的一些。

频繁交付可工作的软件，周期从几周到几个月不等，倾向于较短的周期。

通过敏捷交付模型，您无疑可以塑造需求进入团队的方式，并以小批量迭代的方式开发有价值的产品。但是，您如何可靠且频繁地将这些价值交付给客户呢？

如果答案是一个独立的运营团队负责管理整个组织的IT基础架构和发布流程，那么这对团队来说就是一种限制。它还会导致交接问题，并剥夺一个以业务为中心的团队的控制权。

我们最优先考虑的是通过早期和持续交付有价值的软件来满足客户。

发布频率在多大程度上影响您了解客户需求的能力？您只能像运营团队支持的那样频繁地发布，而您的项目可能不是他们的唯一重点。运营部门限制了您的技术选择和支持这些选择的工具。它将开发团队置于一个狭窄的范围内。

这引出了

最佳的体系结构、需求和设计源于自组织的团队。

如果团队无法选择其架构和工具，那么产品的最佳架构将受到限制，并且无法随着需求的变化而轻松演变。

无论是您将运营团队称为DevOps，还是将部门内的运营人员安排到团队中并称之为DevOps，这都是一样的。请不要这样做。

DevOps是一种文化，它补充了敏捷，并有助于解决这些具体问题。它要求完全消除孤岛，以便开发和运营能够无缝地作为一个整体协同工作。

围绕积极主动的个人建立项目。给他们所需的环境和支持，并信任他们能够完成工作。

如果另一个部门基于对组织需求的认知来做架构决策，或者与业务脱节太远，那么关键的敏捷性就会丧失。

敏捷团队应具备支持产品需求所需的所有技能。他们应该能够根据需要频繁地将工作软件交付到生产环境。它促进了一种简单的精益方法，这种方法也能补充敏捷。它还使技术解决方案尽可能简单，以满足特定的业务目的。

简约——即最大化未做工作的艺术——至关重要。

通过部门孤岛，沟通开销增加，面对面沟通也更具挑战性。

向开发团队以及团队内部传递信息最有效的方法是面对面交谈。

治理流程也是如此，例如外部技术评审委员会（其职能是收紧控制）或服务于组织需求的架构团队。相反，应该在支持产品的单一团队内部建立能力，并保持其自主性。

“伟大的领导者知道何时退居幕后。”——Tara Jaye Frank

组织越支持跨业务水平协作的学科，就越会削弱必要协作的力度，并限制其应对变化的能力。

许多公司这样做是因为他们除了传统的结构之外缺乏信任，并且很难摆脱这种思维模式。

摘要

敏捷原则不仅仅是一个交付过程。它们需要思维方式和方法的根本性转变。因此，它需要相应的组织结构和文化心态来支持。DevOps文化与精益原则相结合，将有助于塑造一套完整的敏捷原则。

实现所有敏捷原则的好处是为业务和团队带来了高度的敏捷性。它允许快速响应变化，并促进竞争优势。

如果一个组织在没有必要的组织支持的情况下尝试敏捷方法，那么它就是“横向敏捷”，无法完全实现所有12个敏捷原则。在这种情况下，孤岛团队或部门议程的限制最多只会限制敏捷团队。最坏的情况是导致失败。

强大的领导力在于退居幕后，信任、培养和赋能他人朝着共同的愿景前进。放弃对整个组织的控制和治理是一项勇敢的举动，但可以在小范围内进行尝试和测试。

有了优秀的团队，业务和客户满意度的提升应该会显而易见。所有需要的是团队拥有自主组织和完全自主的自由空间。

在整个组织范围内进行更广泛的文化转变更加困难，但从小处着手，根据早期结果扩展理念可以促进变革。John Hagel 将这种方法称为“扩展边缘”。没有强大的领导力和勇敢的决心，这是无法实现的。