CMMI还是Agile：为何不拥抱彼此！（五）

第五部分 · Agile的真相

敏捷宣言如下：

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value [the following]:

individuals and interactions over processes and tools

working software over comprehensive documentation

customer collaboration over contract negotiation

responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.”

“我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：

个体和互动高于流程和工具
工作的软件高于详尽的文档
客户合作高于合同谈判
响应变化高于遵循计划

也就是说，尽管右项有其价值，我们更重视左项的价值。”

敏捷宣言的最后一句经常被忽略（太多的敏捷的支持者和反对者一样出现这样的情况），“右项”（常见于太多的计划驱动，驱动项目合同，标准和审计驱动环境）不仅重视较少，也认为它们有效性也是零价值。因此敏捷宣言经常被敏捷的支持者所引用，作为没有过程、没有工作记录，没有计划的理由。这解释给了他们正当理由，批评者指责敏捷支持者是“散漫的仆人”。然而，这些对于敏捷宣言的解释是不完整的，虚伪的。

在一个真正的论述层次，谁重视“左项”胜过“右项”？记住敏捷宣言试图脱离的范式。在太多的执行中，有计划、流程和标准，过于详细，僵化，只是被人们、项目、产品、客户和技术进行滥用。

与敏捷方法相关的常见做法包括以下内容：

使用迭代和短时间增量开发。
频繁和持续的客户反馈。客户通常嵌入开发人员。事实上，广泛使用隐性知识是敏捷开发和实践的关键。隐性知识的使用是最有利的，在一个高的信任环境，可以直接受益于低交易成本的软件工程活动。使用隐性知识的风险，虽然往往没有明确管理，可以使用以下领域进行缓减：

项目的周期（以及产品的预期生命周期）
代码的自动生成文档
使用的工具，可以重构和持续集成
团队规模小

每个增量潜在价值（例如工作代码）。价值也可以是什么不做。
交付的产品是完全测试的。产品通常是首先通过编写严格的测试，然后通过测试来优化产品。
每个人都拥有质量，包括客户（或客户代表）。开发团队往往是多元化的，其中所有的开发者都是通才，统称为“自己的”产品。客户同样负责确保产品符合他们的期望。当项目的功能、范围、限制性条件都达到一个统一的认识后，项目才可以被推进。错误发现的越早，错误的成本越可以低到可以忽略不计。
随着对产品理解的越来越清晰，需要及时开发详细的需求。工作量不是通过猜测需求和期望来浪费的。随着产品交付的不断推进，产品的需求也越来越详细。
在任何时候，变更时被期望、被拥抱、被欢迎、被接受的。预期的变化驱动设计决策。通过设计，产品和体系结构组件没有被锁定，使得开发人员可以进行连续的权衡，直到所有组件需求可用为止。
使用自我驱动和授权团队。这样的团队任务成熟，训练有素，凝聚力强，高度信任，需要很少的指导，管理，或任务分配。广泛的产品，项目和业务目标与团队共享，以便明智的管理，组织和技术决策，可以由团队来决定什么必须做，由什么时候，由谁，以及什么标准。允许团队应对当前的情况，而不是坚持过度强调，过度详细的计划。因此，计划书和做计划实际上是经常更新，与上级沟通（无论是组织或团队）经常发生，几乎每天都会进行。与管理者或客户的正式状态会议，被替换为与利益里相关者频繁的互动。
定期评估和调整过程。任务成熟的团队拥有调整他们过程的权利，他们基于工作的反馈进行调整。