联邦政府敏捷交付的成功要素-InfoQ



 写点什么

Paul Gorans（IBM 全球商业服务（IBM Global Business Services））和 Philippe Kruchten （英属哥伦比亚大学）发表了一份指南，敏捷交付关键成功要素指南。本指南讨论了敏捷的价值、好处以及面临的挑战，并提出在联邦政府实施敏捷交付中的关键成功因素。

InfoQ 采访了 Paul，讨论了敏捷实践的实施、敏捷如何影响外包和采购、大规模敏捷沟通及敏捷评审的用途。

InfoQ: 是什么让你们决定写一本有关实施敏捷交付的指南呢，目标人群又是谁？

Paul: 我们负责政府业务的 IBM 中心听说了一个成功的 IBM 敏捷项目，该项目是与美国联邦机构合作。而我曾帮助过他们做敏捷转型，并用我的敏捷技能正式的在联邦 IBM 全球商业服务中实施敏捷。他们推荐我写一个指南来帮助其他机构了解一些基本的敏捷，而且我觉得也有必要描述敏捷交付关键成功的要素，并解决我们经常被问到的，有关美国联邦方面具体的一些问题（例如您如何用敏捷进行 508 测试）。

InfoQ: 用你自己的话说一下组织如何有效的实施敏捷?

Paul：需要从业务 / 使命上以及 CIO 层面获得执行上的大力支持。如果有了这个支持，那么你就拥有了这个能力去处理敏捷成功所需的所有要素，包括指南上提到的那十点。

InfoQ: 在这本指南中，改变采购流程（针对承包商项目）是一个成功要素，它为什么对敏捷交付如此重要？

Paul：在既是商业又是联邦的实体企业，我见过他们要求承包商“敏捷”，但又要求传统的 IT 阶段和窗口，或者评估供应商或绩效的对策只是针对低成本，而不是交付的价值。这样给我的信号就是按照干系人的要求，敏捷这个术语在最后一分钟写入到了建议书中，但其他的当事人并非有同样的理解。这让潜在的伙伴 / 供应商不确定客户要的是什么，不同的回应，使得他们难以对建议书做出评估。任何的采购项目（无论采取何种方法），采购要求应该与商业的要求保持一致（通常是一个解决方案对应一个商业问题，包括 IT），领导就要尽力帮助他们达到这个目标，帮助相关的商业伙伴获得成功。

InfoQ: 敏捷交付指南建议更多的口头沟通和仪表板（Dashboard），这个可以大规模化吗？可否给个例子讲述如何在大规模的组织中做到？

Paul：可以的。口头沟通和仪表板都可以大规模化，对于多个敏捷团队一起工作的项目，应该制定一个适合项目组的沟通计划（注意，我经常转述这个事实，传统的项目管理实践仍然与敏捷相关，但是项目经理 PMs（或者 Scrum Masters）需要重新考虑书面内容的详细层次以及如何管理）。口头沟通就是每个敏捷团队的每日站立会议，以及在团队的站立会议之后, 该项目跨团队的站立会议（例如：Scrum of Scrums），对影响到所有团队的障碍，提高大家对它的意识，并且寻求帮助。

在我们的 IBM 项目上，我使用了一个仅 IBM（IBM-only）的每日站立 / 状态会议，允许我们敏捷项目的组长直接与我们的项目主管（Project Executive（PE））和关键的交付经理沟通。它保证了项目主管对我们进行的状态很少有“意外惊喜”，也给项目主管（PE）提供了一个机会，他可以每日直接与一些初级的项目经理们沟通和给予一定的指导，并提供一些他们与行政级别的客户和合作伙伴们沟通的情况。使用其他的跟进方式，写邮件或一页的状态汇报也应该满足口头沟通的目的。

对于仪表板，Wiki 可以作为一种沟通方式，实际上，现在有很多敏捷工具或工具套装来支持大规模下的多个敏捷团队、项目集以及组织。一旦内容在同一个地方可见，开发人员和主管们都可以看到一样详细的和整合过的信息。不管这些不同的团队和干系人实际在什么地方，从任何的人的桌面都可以看到用户故事、编译统计数据、遇到的困难和燃尽图。

大规模组织的工具对于端到端的可见性的有一个局限就是，在组织当中，多个职能部门经常负责为他们传统的职能（例如需求、测试、配置管理和部署）购买和管理工具。为了支持跨业务和 IT 部门的合作，这又需要行政机构提供一套端到端的解决方案。

InfoQ：用敏捷方式工作需要不同类型的评审会议，就如指南中所提到的，可否详细解释一下？

Paul：当一个用户故事完成的时候，产品负责人要评审这个用户故事，或者通过演示工作的产品让那些广义的干系人在冲刺评审会议中评审（Sprint review）。在敏捷方法中，甚至是被分解到多个敏捷团队或者精益支持团队的大项目，也提供了其他评审的机会，但是为了高效，这些评审需要在更多的迭代发生。例如，负责标准的员工可能需要评审每一个用户故事、迭代或者发布所产生的设计决定或代码（包括从自动代码质量工具中输出的代码）。根据员工每日工作的方式，干系人也需要改变，从而支持敏捷团队的需要（通过在评审 / 反馈循环中与团队的每日沟通合作而不是通过会导致昂贵重构的一些检查点（Checkpoints））。

对于大型项目，我也推荐和高管干系人们（executive stakeholders）一起评审那些优先功能，这些功能是在一个发布周期内计划的（固定时间，固定资源）。大多数时候，团队开始管理敏捷交付，在给定的截止日期内团队可以交付什么，没有设定任何期望，或者开始没有做任何初步的估算。那么在这一点上，他们可能会做错，也可能没有根据团队的能力做充分的计划，因此无法满足高管干系人的需求并做出承诺。敏捷的估算，与我们已经沿用了多年的，可以提前做出“恰好”的估算技术完全不同，它是在产生一个速率样本（这个验证在 2 个迭代之后也是至关重要）之后在做估算。通过这种估算，给干系人提供一些参考，会交付哪些东西，对于那些不确信敏捷交付方法可以带来价值那些干系人，同时也赢得了他们的信任。

InfoQ: 对于想要采用敏捷工作的组织，或者对于正在采用敏捷想提高成果的组织。他们如何使用这个指南呢?