如何在敏捷项目中,进行项目治理和监督?

敏捷的迭代性和增量性使得敏捷方法似乎与项目治理或监督不太相同。传统的、连续的项目管理方法更符合管理层对项目监督。

项目监督(通常称为治理)的目的是确保项目不会误入歧途。

 

例如,有效的项目治理可以识别出项目是否超出预算,从而引发关于是否应该取消该项目的讨论。治理还可以识别偏离其原始目标太远的产品、偏离体系结构标准的项目,或任何对组织重要的类似高层考虑。

 

项目治理不是一个新概念,但它在任何阶段关卡过程中都找到了最自然的归宿,如下图所示。

 

工作计划软件|工作日志软件|团队管理工具|团队协作软件|电商erp|知识管理软件

 

 

中心思想是,在开发过程的每个阶段之后,项目都被迫通过一个阶段。每个阶段都是项目的正式审查检查点; 该项目可能被批准继续前进,在前一阶段返回返工,或取消掉。

 

在敏捷项目上可以运作监督吗?

软件团队可能会在不同时间阶段的治理检查点:

  • 及早审查他们的范围,预算和时间表计划

  • 审查建筑和设计决策

  • 审查应用程序是否已准备好进行系统或客户验收测试

  • 审查产品可以交给支持组织; 等等。

这些检查点经常对敏捷团队造成一些破坏,因为这种类型的治理模型与以「迭代」方式完成的工作不兼容。例如,一个Scrum团队允许系统设计出现,这将很难清除一个早期检查点,该检查点考虑到系统架构的适当性和正确性。

 

协调敏捷和治理

 

团队要协调项目治理需求和使用Scrum的的第一步是认识到「项目治理」和「项目管理」不是一回事。

 

将项目治理与项目管理分开是可以的

 

但在分离它们时,我们希望能够拥有高级检查点来提供必要的监督,同时仍然允许团队以敏捷的方式自由管理自己的项目。

 

治理本质上不是邪恶

 

其次,重要的是要理解治理本身并不是邪恶的。假设您突然晋升为贵公司的总裁或首席执行官。作为新的老板,如果你需要了解公司的主要项目,也许你需要建立了一个规则,你个人需要批准任何项目的启动,预期成本超过一定数额。

 

而且,当您计划尽可能多地参加Sprint评论时,您希望任何持续三个月以上的项目每三个月向您提供一个两页的关键信息摘要。

 

这将是一个轻量级的治理模型,并且是一个合理的模型。因此,治理的存在不是令人反感的;通过治理,它会影响我们如何运行我们所反对的项目。

 

 

运行具有非敏捷治理的敏捷项目

由于很少有组织最初会到目前为止完全改进其当前的治理方法,因此敏捷团队需要采用各种方法来处理其组织的非敏捷治理。采取以下行动应该有所帮助。

 

在前面谈判并设定期望

 

毫无疑问,第一个通过公司治理流程的敏捷项目将面临挑战。

 

几乎肯定会有这个第一个敏捷团队无法提供的信息或工作产品。例如,在获得开始编码的许可之前,团队成员将无法提供完整的设计,因为设计和编码将同时进行。

 

解决这个问题的唯一方法是让团队提前与必要的治理小组进行谈判。一个团队对此的支持越多,这个支持在组织中达到的越高,效果越好。

 

团队无需请求治理政策的永久性变更。这种变化可以作为一次性实验。

 

使你的报告符合当前的期望

 

提供项目治理的项目审查委员会或监督委员会,需要对每个项目在每个检查点提供的信息都存在期望。

 

 

不要打击这些期望。

 

如果他们希望提供甘特图,请提供甘特图。但是,当你可以通过提供额外的,更敏捷友好的信息来尝试慢慢改变期望。

 

如果燃尽图表适合展示,请执行此操作。或者您可能希望包含一个报告,显示团队在迭代期间每天部署的频率。

 

邀请治理审核员加入您的流程

 

Scrum团队可以通过邀请治理委员会成员参加常规的Scrum会议,来补充不太详细的正式治理检查点。

 

一位客户告诉我她的团队如何与建筑审查委员会进行互动:

 

敏捷团队邀请建筑评审委员会的人员尽早进行冲刺回顾会议。他们仍然有一个正式的检查点,但到那时大部分主要问题已经解决,这就会使得监管变得不是那么痛苦,而且监管委员会会和团队成员之间建立信任和协作。

 

我喜欢通过站在管理者的周围走来走去,扩展著名的管理技术。鼓励参与项目治理的经理和执行人员参加日常的Scrums,他们可以站在那里,倾听项目中发生的事情。

 

在项目报告中,需要发生同样的从文档到讨论(通过使用用户案例创建)的转换。鼓励人们参观团队或参加团队会议,亲眼看看正在建设什么。

 

引用成功的案例

 

没有什么能像成功的案例一样有说服力。尽你所能通过减轻或减少治理检查点来获得第一个或第二个项目。然后指出这些项目的成功,作为未来项目也应该被允许通过的证据。

一旦你让一些敏捷团队显示出有利的结果,你就会建立信任感。然后,您可以处理更大的整体治理流程。

 

敏捷和治理根本不是反对的

 

敏捷性和项目治理的概念并未从根本上相对立。每一种都是为了改善产品。

 

敏捷致力于通过密切合作以及时间限制冲刺的短期检查和调整周期来实现这一目标。

 

项目治理力求通过我们称之为检查和批准(或拒绝)检查点的方式来实现,其中将产品或项目与一组期望的属性进行比较。

 

然而,在追求类似目标的同时,敏捷和项目治理采用完全不同的途径来实现这些目标。正是在这些不同的路线中,两者混合时会出现问题。

 

幸运的是,双方的一些妥协,再加上这里的建议,可以带来敏捷性和监督的成功结合。

 

你的经历是什么?

您在具有治理监督要求的敏捷团队中的经验是什么?

其他