实现非软件 IT 项目的敏捷交付

“你将如何使用敏捷交付模型管理一个战略项目？”Elle 问道，声音中有明显的愤怒，“可以工作的软件在哪儿？你如何及时展示业务价值？”

这个对话的背景是 MotoClaim & Co. 正采用一种面向服务的企业理念开展一项重大变革举措。Elle 是整个项目的交付经理，对敏捷并不陌生。我是该计划的流程咨询架构师。我们都刚刚从一个高层管理会议上出来。会上决定，该计划的第一阶段将包括制定一个战略来执行整个变革以及开发所需的基础架构。在这个会议上，虽然包括 Elle 在内的许多高层管理人员都持怀疑态度，但我还是力争使用敏捷来执行第一阶段。

Elle 的问题绝不是 MotoClaim & Co. 特有的。在我上个十年的敏捷咨询生涯中，我多次同我的客户涉众产生过这种争论，即使它在敏捷交付方面已相当成熟。当涉及 _ 非软件 _ 项目时，任何人都更愿意采用迭代方法。所谓非软件项目，我是指那些不以将可以工作的软件交付生产为目的的 IT 项目，比如战略定义项目、架构项目、内部评估项目、咨询项目。虽然对于组织而言，这些项目包含着丰富的内在价值，但通常，它们对于终端用户而言是不可见的，而且不会影响他们的正常业务。

那么，在非软件项目中使用敏捷交付有什么问题？首先，如果我们看下现有的敏捷著作，其中的大部分，包括敏捷原则在内，都以尽早和频繁地交付“可以工作的软件”为中心——毫无疑问，可以工作的软件与交付生产软件的项目有关。由于非软件项目不交付可以工作的软件，所以很难觉察它们与 _ 通过尽早和持续地交付有价值的“软件”来满足客户 _、_ 频繁地交付“可以工作的软件”_ 以及 _ 将“可以工作的软件”作为衡量进度的主要指标 _ 等敏捷核心原则的契合度。另一个关键的原因是多重所有权，战略项目尤其如此，它们通常会有许多存在利益冲突的知名涉众。没有确定的行业指标可以度量非软件项目是第三个方面的原因。我见过许多架构项目中途停工，因为业务涉众觉得项目结果与花费不匹配。因此也就不奇怪，组织为什么经常会发现很难证明敏捷交付适合于非软件项目。

你可能会问，“那么，这有什么意义，为什么非要在这些非软件项目中使用敏捷呢？通常，这些项目都是短期的，只会持续三个月到一年。我们为什么不能简单地遵循瀑布方法或迭代方法？”要回答这个问题，我们需要从头说说敏捷实施的基本知识。

我们都知道，不是所有的项目都需要敏捷交付。那么，项目是否采用敏捷有什么判断标准呢？可以使用 Ogunnaike 和 Ray[1] 提供的图解，我们说，任何落在“简单区域（simple zone）”之外的项目都必须使用敏捷。而简单区域之内的项目使用敏捷几乎没有什么价值。为了确定一个项目是否简单，我们通常对项目进行“敏捷执行能力评估（Agile Readiness Assessments，缩写为 ARA）”，通过审查各个参数弄清楚以下四个关键因素：

• 涉众对他们的需求了解程度如何？
• 涉众对他们的技术了解程度如何？
• 不同的涉众之间存在利益冲突吗？
• 是不是有很高的失败风险？

不用说，大部分战略、架构和咨询项目在上述四点都存在很大的风险，因此几乎总是需要高可见性、及早缓解风险、适应不断的变化以及快速阐述业务价值。这时，使用敏捷既不可否认也毋庸置疑。事实上，我认为，与其它项目相比，敏捷方法更适合非软件项目。

下一个明显的问题是“我们如何做到这一点？”在我看来，只要组织停止使用“规范的敏捷（prescriptive Agile）”。虽然敏捷的根本是自适应，而非规范性，但规范的敏捷是现如今存在于敏捷交付领域的主要矛盾修饰法之一。在一篇见解深刻的文章中，Abraham Kiggundu 写道：

我已经开始相信，许多敏捷实施之所以失败主要是因为参与者忘了，敏捷宣言只是陈述了一种乌托邦式的理想追求。由此衍生出的任何规范做法，如 Scrum 和看板，都只是在实践中迈向这个理想的尝试，然而，由于敏捷原则的性质，这些做法没有哪个真正地实现了这个理想。

Arijit Sarbagna 的文章 [2] 也强调了这一概念：“如果你实践敏捷，那么你一定遇到过那个名为‘规范的 Scrum’的不老恶魔。”

一个著名的演员曾在一部流行的印度电影中说过这样一句话，“宗教无处不在，无法消除。如果你试图消除一种宗教，那么你本身就会‘成为’宗教。”千真万确。多年以来，软件行业一直像信仰宗教那样实践着现在已经过时的瀑布方法，直到敏捷方法向他们展示了自组织团队和更快的交付能力。虽然敏捷方法成功地消除了进展缓慢的瀑布方法，但现在，许多组织已经将敏捷作为他们的宗教。这个在宣言中宣称“人胜过过程”的过程本身现在已经成为一个标准化的、规范的过程。

“敏捷（to be Agile）的工作”，这是使用敏捷成功交付项目所需要的唯一规范的做法，非软件项目也不例外。

为了使用敏捷成功地执行一个非软件项目，我在自己的工作中定义了如下这个“5 点议程（five-point agenda）”。虽然这可能不是一个解决方案，但它可帮助我为涉众设定清晰的期望，理智地执行项目以及挖掘敏捷的好处。虽然这个议程可能看上去与敏捷软件交付项目所遵循的原则类似，但当涉及非软件项目时，它们的用途却大不相同：

1. 定义“可以工作的软件”：虽然这个术语通常被视为一个可执行文件，但它可以用于指代项目生成的任何可以为客户带来价值的交付物。例如，它可以是一个改进的路线图，一个架构原型，一个战略文档，或者是一份成本收益分析。
2. 定义“客户”：在开发领域，很容易知道谁是终端客户。然而，在非软件领域，可能很难确定客户。通常，客户是那些与项目有直接或间接利益关系的涉众。不过，不同于系统的终端用户，这个客户集合可能存在优先级冲突、内部偏见或先入为主的观念。在这些涉众中间，有许多人是高层管理人员，甚至是 C 级高管，这让这项任务变得更加困难。选一个可以控制这种复杂性的‘合适’的产品经理至关重要。
3. 定义“完工”：同项目发起人和产品经理一起确定每个故事 / 交付物的“完工”标准。对于非软件项目的许多交付物，由于传统的质量保证可能并不适用，所以确定成功条件非常重要。例如，一个架构原型的成功标准可以是关键设计评审加演示。这里的问题是，由于这些交付物中的大部分都要后续通过软件开发项目实现，所以涉众可能会延期审批，直到交付物成功地用在了将来的开发项目中。这等于将两个项目都置于失败的境地。如果战略失败了怎么办？现在，我们需要面对两个失败：一个是已经关闭的非软件项目，其战略交付物无效，二是正在进行中的开发项目由于战略错误而无法继续。
4. 度量业务价值：对于非软件项目而言，度量或证明已完工工作的业务价值是一个关键。由于大部分交付物都以理论或原型的方式存在，所以有一点很重要，就是在项目开始的时候准备一个企划案，清楚地描述项目的成本收益，每隔一段时间就对收益进行阐述，最好是在迭代结束的时候。非软件项目的度量指标应该确定并制度化。例如，一个架构开发团队可能会采用风险缓解因子、建议拥有总成本（TCO）、建议节约总成本和“架构相符率（architecture due diligence rate）”等指标。
5. 预测意外：众所周知，战略或咨询项目非常多变。这很正常，因为项目发起人和管理人员还处于头脑风暴模式。项目范围、目标和目的经常会发生很大的变化。因此，要采用更短的迭代、联合研讨会、交付物结对开发、连续的专家和同行评审以及理论和思想的适当社会化。资深策略师、架构师或者顾问非常有用，尤其是如果他们对主题以及整个组织有丰富的经验。

一旦议程确定，整个项目就很容易使用 Scrum 或其它过程运行在敏捷模型中。你会惊讶地看到，像结对编程、测试驱动开发和重构，这些没有可以工作的软件就看似无关的标准敏捷技术可以完美地运用到非软件项目中。我已经在许多不同类型的非软件项目中成功地使用了这个议程，包括战略制定、企业架构开发、业务流程优化、流程定义和制度化、指标开发。下面，我将介绍其中的两个案例。

案例

案例 1：基础架构开发

为了将现有的遗留平台现代化并迁移到面向服务的模式，组织着手进行一项大规模的变革计划。由于组织中现有的所有架构元素均是特定于遗留平台的，所以，为了实现面向服务的交付，I.S. 领导人希望在初始阶段识别、获取并建立一个基础架构。按照资深架构师的估计，创造服务开发所需的最基本的架构元素需要一年的时间。作为一项高风险的任务，I.S. 领导人希望在敏捷模型中运行该项目，以便尽早消除风险，建立所有层面的、完整的可见性。

作为描绘项目愿景的一部分，我与关键涉众一起确定了 5 点议程：

1. 定义“可以工作的软件”：对我们而言，每个重要的交付物都是“可以工作的软件”。确定主要交付物是必不可少的活动，因为待办事项列表很快就被涉众和团队希望通过这个项目提供的东西填满了。这既包含基本的基础元素，也包含高成熟度功能。我们仔细排定优先级，并且，只有在团队觉得某项工作可以为组织提供可观的业务价值同时组织也已经准备好接受这种变化时，我们才会同意交付这项工作。为不同的环境创建技术基础设施 / 工具、设计文档开发以及技术 / 概念可行性验证是“ 可以工作的软件”的主要类型。
2. 定义“客户”：由于这个项目是一个企业级项目，我们需要同大量的涉众共事。我们开发了一个“影响力 - 兴趣网格（influence-interest grid）”[3]，帮助我们理解沟通需求和潜在的变革阻力。我们指定其中一位“兴趣高、影响力大”的涉众作为产品经理。这位产品经理是部门的一名助理副总裁，他的影响力帮助我们很好地排定了优先级，并让我们获得了所需的社会化和支持。
3. 定义“完工”：每个“可以工作的软件”都有“完工”标准， 是同各涉众讨论确定的。例如，对于基础设施创建，我们同企业基础设施支持团队一起得出了一组测试用例和抽样测试数据，用于验证基础设施是否正确安装。对于设计文档，企业体系结构委员会（EAB）会进行关键设计评审。我们同指定的 EAB 评审员一起起草了一份详细的检查清单，他们会根据这份清单评审文档。
4. 度量业务价值：甚至在项目开始前，一份包含成本收益分析的企划案就提交给了管理层，清楚地阐述了投资回报率（ROI）。在每一次冲刺中，我们都会对我们同已承诺 ROI 的相符度进行高水平的度量（有时候定量，有时候定性）。例如，在创建服务注册中心后，我们阐述了企划案中提出的可重用价值的实现。我们实际地创建了一个小而简单的生产者 - 消费者服务场景，清楚地展示了，消费者服务如何通过注册中心轻松地发现和重用现有服务。
5. 预测意外：这更多的是为团队所接受的一种文化。我们有四周的冲刺，我们不断地同产品经理一起回顾我们的目标。作为一名 Scrum Master，我勤奋地维护着风险和障碍日志，经常与项目发起人进行面对面的交流。有一名具有很高组织影响力的产品经理是有好处的，因为我们可以及时跟进组织内正在进行的高级战略变革，并为即将到来的变革做好准备。另外，我们还创建了惯常的组织变革管理规程，那样，可以对项目范围和目的变更进行适当地社会化和系统阐述。

在确定了 5 点议程后，我们使用 Scrum 和若干 XP、DSDM 做法成功地完成了项目，并且用时低于预期。现如今，该组织已经成为一个著名的、面向服务的解决方案提供商，而且已经接受了“开放组织服务集成成熟度模型（Open Group Service Integration Maturity Model，缩写为 OSIMM）”[4] 的五级评估。

案例 2：业务流程优化

在对价值链进行了多次不成功的升级后，该组织启动了一项重要的计划，彻底重建其端到端的业务流程。该项目的第一阶段主要包含业务架构工作，设计目标流程。这是一个高风险的项目，因为变革几乎会影响到组织的每位成员以及终端客户。作为一名流程教练，我被要求协助团队使用敏捷模型执行这一项目。

再一次，我与关键涉众一起确定了 5 点议程：

1. 定义“可以工作的软件”：自然，目标流程模型是可以工作的软件的关键候选。对于更大、更复杂的流程，团队会将其分解成多个逻辑阶段，每个阶段均被视为可以工作的软件。交付物是使用业务流程工程语言（BPEL）创建的流程模型。
2. 定义“客户”：虽然客户的定义很简单，而且可以从角色 - 流程映射中识别，但真正的挑战在于满足他们的预期。客户很多，而且对目标状态的要求相互非常矛盾。部分人想要更多的控制权，而其它人则倾向于更大程度的自治。市场部希望产品更灵活，那样可以增加销售额，而索赔部门则希望产品不那么灵活，那样索赔过程更快。我们知道，产品经理是其中一位业务负责人，但每位业务负责人都要迎合一个特定的部门，并且会偏袒那个部门的需求。在我作为敏捷教练的漫长职业生涯里，这是第一次，我们真正地同三位产品经理一起翻新整个价值链。虽说要“敏捷的工作（being agile）”，但我们仍然设定了一些基本原则。首先，团队从三位产品经理那里获得的方向应该始终保持一致。其次，产品经理之间的任何意见分歧要内部解决，团队不参与其中。最后，产品经理的任务和决策都有时间限制。
3. 定义“完工”：这一部分简单。产品经理们同他们各自的部门交流，准备一份他们希望从新系统获得的完整的“特性”列表。然后，经过过滤和排定优先级生成一个短列表。该短列表将在冲刺评审报告期间、团队在 BPEL 工具中展示理论上的流程时供业务经理和终端用户使用。会议上提出的任何新特性都会添加到待办事项列表中，并排定其在下个冲刺中的优先级。
4. 度量业务价值：度量业务价值并不是非常复杂。当前业务流程的现有模型里指定了每项活动所耗用的最佳、最差和平均时间。这是组织先前完成的一项研究工作的一部分。当创建目标模型时，我们可以确定时间的减少和其它效率的提升。例如，如果在现有的流程中索赔过程需要两周，那么在目标流程中，我们可以展示，我们如何通过自动化处理规则将处理时间缩短到四天。用这种方式阐述业务价值可以确保获得用户社区的持续关注和对项目的支持。
5. 预测意外：再说一次，这点更多的是一种文化。我们有四个周的冲刺，我们不断地同三位产品经理回顾我们的目的。我勤奋地维护着风险和障碍日志。我们欢迎所有新需求或对现有需求的变更。但是，我们设定了一个明确的预期，就是变更的加入取决于它的优先级。所有的客户都能看到待办事项列表和燃尽图。另外，我们还建立了传统的组织变更管理规程，那样，项目范围和目的的变更可以得到适当地社会化和明确地阐述。

小结

正如上述两个案例所阐述的那样，敏捷的使用可以跨越学科边界，而且非常有效。此外，对于非软件项目，由于它们固有的风险和复杂性，敏捷交付是必要的。模型可能会变，但敏捷的概念不会变。我们需要遵循整个敏捷宣言，而不是遵循规范的敏捷方法：

• 个体和交互胜过过程和工具；
• 可以工作的软件（或者交付业务价值）胜过面面俱到的文档；
• 客户合作胜过合同谈判；
• 响应变化胜过遵循计划。

请记住——“敏捷的工作，自适应”。

参考资料

[1]Process Dynamics, Modeling, and Control，英国牛津大学，1992。

[2]规范的Scrum——这是世界末日或危情时刻的需要吗？，发表于Scrum 联盟社区。

[3]Mitchell, R. K., B. R. Agle 和 D.J. Wood. (1997)，“Toward a Theory of Stakeholder Identification and Salience: Defining the Principle of Who and What really Counts.”，发表于 _Academy of Management Review_ 22(4): 853 - 888。

[4]开放组织服务集成成熟度模型

关于作者

Dipanjan Munshi是 Tata Consultancy Services （TCS）的一名资深流程和质量顾问，有超过 17 年的 IT 经验，而且涉及多个领域，包括保险、金融服务、制造、嵌入式系统、交通和酒店业。他拥有印度奥里萨邦乌特卡尔大学计算机应用专业硕士学位。

查看英文原文: Implementing Agile Delivery for Non-Software IT Projects