从第二条敏捷原则理解："学会热爱变化"

探讨敏捷原则所面临的实施挑战

[

Andy Watt

[

安迪-瓦特

[

1月24日-6

上周我提出了一个问题："你读过《敏捷宣言》吗？"，并开始了一系列的文章，探讨12条敏捷原则，并对实施挑战进行了一番探讨。

我觉得敏捷没能兑现它的承诺。我认为失败的原因并不是敏捷过程的根本缺陷，而是因为它在大多数情况下实施得不好。

这一次，我关注的是第二个原则，它有点像这样。

欢迎不断变化的需求，即使是在开发后期。敏捷过程为客户的竞争优势驾驭变化。

我想我我想我最终可能会对所有这些原则都这么说，但很直观的一点是，对产品进行修改，给客户带来竞争优势，对客户来说是个好主意，对软件公司来说也应该是这样。

一款软件需要几个月甚至几年的时间才能交付，而在这段时间里，业务需求发生重大变化也是很正常的。真正应该预期的是，需求会在项目的过程中发生变化，包括项目的后期阶段。

如果开发公司能够管理这些变化，并在整个过程中纳入客户的反馈意见，那么客户的结果最终就会得到保证。这对软件公司来说应该是好事，因为他们的声誉会受益，而且可能他们的底线也会随之而来。

我们很快就会讨论技术和关系管理方面的挑战，但在践行这一原则时有一个非常明显的问题，那就是律师。

或者更具体地说，合同。很多时候，如果不总是这样的话，会有一个合同，以提供做某种事情的软件，或满足某种要求。这份合同将在编码开始前达成一致，并将规定交付日期、支付里程碑、惩罚条款、性能要求以及另一个明显不是敏捷的东西清单。

遵守具有法律约束力的合同并没有什么 "敏捷 "可言。而且，永远不会有真正的敏捷--这只是商业运作的方式。

许多所谓的 "敏捷 "项目一开始就被一系列必须实现的合同条款所束缚。然后由技术团队来实现敏捷，但前提是他们不能错过任何最后期限，或跳过任何功能，或触发任何惩罚条款，或......你明白的。

这种合同的无力感是双向的。随着项目的进展，一个功能可能会被发现是多余的需求。但是，开发人员可能会发现自己还是创造了上述功能，因为有一个合同要求来交付它们。同样，客户或顾客可能会发现他们不能添加他们所发现的东西，因为它不在合同中，或者被特别排除在外。

在陷入合同纠纷的项目中工作，对参与其中的团队来说是一种灵魂的摧残--无论是哪一方。没有什么比在一个应用程序中建立你和客户都知道永远不会使用的功能更糟糕的了，但这样做是在履行合同义务，而双方都不会退让。我敢打赌，这是个徒劳无功的做法，我敢打赌，这篇文章的许多读者都能认同这一点。

尽管有合同和法律问题，但在一天中的晚些时候进行修改可能是令人难以置信的技术挑战，有时甚至是不可能的。如果客户突然决定他们真正想要的是一个网络应用，而不是一个桌面应用，那么无论产品的架构有多好，都会有大量的 返工工作要做。

即使是不那么极端的例子，在后期改变需求也是一种挑战。随着项目接近尾声，对产品功能的改变变得越来越难。即使非常勤奋地坚持良好的编码实践，关注点的分离等，也根本没有办法绕过这个问题。

当然，这些晚期的变化也不会在合同中得到考虑。

为了使这一原则得到真正的应用，并按预期的方式工作，必须在组织层面上接受这一原则，并在项目开始时得到承认。

这就要求建立一个非常强大的变更管理系统，而且合同要承认变更管理系统，并对范围的变更做出明确的规定。 (我希望任何律师在读到这段话时可能刚刚心脏病发作）。

变更管理过程和程序的写法必须能够支持不交付商定的功能，并且不会导致客户要求退款。(这很难）。同样地，它要求顾问可以在不增加价格的情况下提供最初没有指定的功能。这也很难。

良好的变革管理始于软件组织内部和外部与客户的公开和诚实的个人沟通。比如说。

必须有一个正式的程序来记录这些讨论中出现的变化，并为其设定成本（如果需要的话），并将其附加到合同中。

为了使技术团队能够纳入这种 "项目级的变更管理"，软件必须以极其模块化的方式编写，这样，在程序的一个部分进行变更就不可能在程序的另一个部分产生最大程度的副作用。有许多模式、实践和编码风格在这方面有帮助。

如果接受功能，也就是代码，在整个开发过程中必须改变，那么实施强大的自动回归测试将是至关重要的。这将使开发人员有信心做出改变，也应该使管理层和客户有信心，这样做不会引入任何（或许多）新的错误。

建立合同和技术变更管理流程来支持这一原则是非常具有挑战性的。其好处（当然）是显而易见的，但通往极乐世界的道路却充满了危险。

根据支持工作的合同，将其改造成棕地项目很可能是不可能的。

但是，如果以真正的 "敏捷 "方式工作是目标，那么这12条原则中的任何一条都不能被忽视，因此必须努力使团队和整个组织进入这种心态，在项目的整个生命周期中接受技术和合同的变化。

Want to Connect?