访谈《敏捷和精益项目集管理》的作者Johanna Rothman-InfoQ

重点

项目集管理关乎的是如何优化产品交付。

敏捷和精益项目集管理者呈现仆人式的领导风格。

让人们自愿参与到软件项目集团队。

Cynefin 模型有助于项目集管理者理解什么是未知的。

扩展协作，而不是流程。

由 Johanna Rothman《敏捷和项目集管理者：扩展跨组织的协作》探讨了如何扩展精益和敏捷流程以完成大型项目集工作。它探讨了如何进行跨组织的协作从而创建和引导自适应的、有弹性的项目集。由于团队向敏捷和精益的转型，以及使用了自适应的项目集管理，所以组织可以更快速地交付给市场。

Rothman 在这本书中提到了以下敏捷和精益项目集管理的原则：

采用产品的视角。原则是：“业务人员和开发人员必须在一起工作。”
敏捷和精益方法鼓励以整体法对待产品，在这种情况下你可以更容易做出调整去满足当前的需要。原则是：“欢迎需求变更。这是竞争优势”。
项目集管理人员是仆人式的领导风格。原则是：“围绕积极上进的个人构建项目”、“信任他们可以完成工作”和“把权力授予团队”。

InfoQ 专访了 Rothman，请他谈了谈敏捷和精益是如何共同为所有项目集提供帮助的，以及管理如何支持项目集走向成功。

InfoQ：为什么你会写这本有关于敏捷和精益项目集管理的书？

Rothman：我看到大家都在项目集方面努力奋斗着。

有些人没意识到正在做项目集管理。他们认为自己正在把敏捷从一只团队“扩展”到多只团队。

有些人使用的是公共框架，可能得不到他们想要的和所需的效果。

有些人试图把 Scrum 作为管理手段来用。当然，你可以这么做，但在一个项目集上协作的管理者们却很少作为一个团队在一起工作。他们是有着共同目标的一个组织，但却没有进行共同协作。这意味着 Scrum 对于他们来说不是最理想的，对于如何协作他们需要其他的思路。他们可以看看核心团队法是否适合他们。

InfoQ：谁是这本书的目标读者？

Rothman：当然是项目和项目集经理了。项目集经理有很多不同的类型：软件项目集经理、硬件项目集经理、核心团队项目集经理。

此外，还有 Scrum Masters、技术带头人（比如企业架构师）和其他设法帮助敏捷和精益团队跨组织协作的人。你不一定要成为项目集经理后才来读这个书，你也一样可以从中得到收获的。

InfoQ：传统项目集经理与敏捷和精益项目集经理有怎样的差异？

Rothman：更传统的项目集经理往往会按以下方式工作：

管理者说，“完成这个项目集。这里有 300 个人。要在明年 8 月完成。”传统项目集经理早就意识到要么就是人太多，要么就是时间不够，又或者需求将来要变，或者其他一些可怕的事。对于项目集经理来说，最重要的事就是这个项目集，但在大家长长的工作列表中却并没把它摆在优先的位置。

更传统的项目集经理喜欢告诉大家她需要这在什么时候完成。那是因为更传统的项目集经理喜欢按交付物的最终期限来倒推。

如果你永远都按阶段的流程工作，在第二阶段之前就很混乱。需求无穷无尽。架构把该流程框定在一个狭窄的空间，并通过设计或需求阶段来做，人们发现他们无法在该架构内正常工作。或者，他们通过编码阶段来实现它，架构师早已不见了踪影。

当项目集经理不得不做出压缩的决定时：我们缩减范围还是测试？技术人员就得拼命工作了。我们都清楚会发生什么：我们会做出根本没什么价值的产品，它根本就无法工作。

与之相比，敏捷和精益项目集管理针对项目集采用整体性的方式，并欢迎变更。敏捷和精益项目集经理促进决策的制定和所有层面的交付，而不是项目集经理直接试图进行控制。

核心团队项目集经理帮助大家在业务层的项目集交付。软件团队项目集经理帮助软件组织交付。

项目集经理不要要求团队一定要交付的特性。如果他们提要求，那就是确保项目集层的人交付他们的交付物，即特性团队可以交付特性。

这意味着项目集产品所有者和产品所有者交付敏捷路线图，由它导出划好等级的待办列表。

这就解放了团队，使之尽可能且经常地自己管理交付价值。

项目集经理和项目集团队为该这些团队移除障碍，为这些团队扫清交付的道路。

敏捷和精益项目集经理呈现仆人式的领导风格。架构师、产品经理和产品负责人同样如是。项目集针对的是对产品交付的优化，而不是任何个人或部门。

InfoQ：敏捷和精益如何一起为任何项目集提供帮助？

Rothman：敏捷有助于我们欢迎变更。精益有助于我们理解全局。当你结合这两个强大的思想时，会发现项目集经理是关于针对产品交付的优化的。我们在约束条件下可以交付的最好的产品是什么？

每个项目集都有约束。而且项目集有着数不清的交流途径。你什么何时与何人交流？作为一名项目集经理你与人交流得越多，那么项目集就会越好。你将清楚风险在哪里，而不必等他们暴露出来，然后大家就更喜欢与你交流潜在的问题了。

我们从敏捷和精益获得透明度和信任，我们可以信任大家去做正确的事。他们每次都将做出正确的选择吗？不是的，但这是可以接受的。因为我们是敏捷和精益的，所以只要每个人总保有透明度并随时交付些什么我们就能够从风险中恢复过来。

使用敏捷和精益，我们会得到交付的环境。特性团队、项目集团队，每人每天都在交付着什么。在每天交付的时候，你不需做太多的计划、风险管理和调整计划。所有计划的制定都很有帮助且很简捷，于是你就可以保持做下去了。因为事情总会发生变化的，所以如果你可以及时地制定计划和调整计划，你就不需要制定太大的计划或太大幅度的调整计划。你不会有太大的惊喜，但会有点惊讶的。

InfoQ：你在书中提到了 Cynefin 框架。在项目集管理中如何来使用它呢？

Rothman：我发现 Cynefin 很有帮助，因为它能指导我解决问题。在 Cynefin 的框架中我处于什么位置？如何创建小型的“失败安全”的实验？我需要在此就此问题请教内部专家吗？我需要找能给予我们指导的外部专家吗？我需要运行所有项目集进行实验吗？或者先在那里运行一些东西看看会发生些什么？

项目集，本身不在明确的象限内。在项目集末期它可能会到一个地方，但我们刚开始的时候，可能会处于 Complicated（繁杂的）或者 Complex（复杂的）象限。我们可能会在 Chaos（混乱的）象限，但可能性不大。我发现搞明白我们是否已知未知或未知未知会很有帮助。

如果我理解了越来越多的风险，可能会询问些不同的信息或询问团队能交付什么。

Cynefin 帮我们理解什么是未知的，而且作为一名项目集管理者，我需要做什么去揭露这些未知并使更多的未知变成已知？这有助于我去推动团队的交付。

InfoQ：如果要创建好的敏捷项目集管理团队，哪些方面是最重要的？

Rothman：因为项目集团队是问题解决团队，我需要知道每个人都能在此帮助解决问题和消除障碍。我需要他们各自领域的代表人物并有时间参与。

以下是我为软件项目集团队做的事：

请每支团队决定他们是否需要某人参与到软件项目集团队里。如果多支特性团队协同工作，可能恰恰需要一个人在项目集层的参与。

询问每个说将参与的人是否有时间和贯穿该组织的能力，并能参与到项目集团队中。如果是，那就太好了。如果否，我会和他们一起确定谁将有时间。

对于核心团队来说，也是类似的。对于核心团队，我想要确保参与的人都能够陈述出这份职责，而不仅仅是他或她。

InfoQ：管理人员如何帮助项目集走向成功？

Rothman：管理人员能够提供以下种类的支持：

确保项目集产品负责人清楚管理人员在路线图中想要或需要什么。这个路线图是每个人能否交付的关键。有一种情况极为常见，那就是管理人员下令一个特性集必须在一个时间点内以特定成本完成。这种方式会极大地约束项目集产品负责人和项目集经理。反之，是请管理人员帮助一起定义成功是什么样的。

我看到有些没有受过敏捷训练的组织试图在一个项目集中变得敏捷。大家不知道做什么。他们不懂在一个团队中的协作，永远不会跨组织思考。大家需要培训。他们可能需要辅导。如果你想要成功，就规划如何去达成。

不要为项目集配备多余的人员。在我们准备好之前我已经成了过多人员的接收者。使用敏捷和精益，你甚至可能不需要所有这些人。

通过特性团队进行组织。不要使用组件团队或服务团队。这些类型的团队会产生难以理解的依赖关系，并在你不能再冒险时突然冒出风险。

InfoQ：你愿意给读者们说点什么吗？

Rothman：我主要想传达这样一个信息：扩展协作，而不是流程。

流程很有用。一旦你理解了敏捷和精益的原则，差不多就能做任何事了。而且，成功的项目集需要跨组织的协作。项目集团队和小型世界网络都有助于大家的协作。针对交付物使用滚动计划，经常交付（至少每月一次）将有助于大家看到进展、仍需要做什么以及哪里存在风险。

你要更经常地去关注进展，更经常地收集该项目集各个层面的反馈意见。如果领导有着仆人式的领导风格，就能完成伟大的成就。

关于本书作者

Johanna Rothman ，知名的“实用主义管理者”，会针对你棘手的难题提出中肯的建议。她帮助领导者和团队理解问题和解决风险以及管理他们的产品开发。Johanna 是十多本书的作者，其中包括：《敏捷和精益项目集管理：扩展跨组织的协作》、《项目投资组合秘决：把精力集中于你需要开始和结束的工作的十二个思想》、《潜水探宝：在项目投资组合中寻找价值》（与 Jutta Eckstein 合著）、《预见不可预知：评估项目计划或成本的实用方法》。她的更多著作请点击此处查阅。