做敏捷项目管理时应该注意什么

摘要：如果你开始思考在自己的IT组织中真正需要的角色时，发现建立项目管理能力并不是那么简单。

关键词：敏捷方法项目管理

我正在我的IT团队中建设项目管理能力。从历史上看，无论谁是项目的技术负责人，也需要做项目管理的工作。

尽管我们的系统和流程变得更加相互依存，然而，我们却开始看不到未知的依赖关系和涟漪效应。

当我决定使我的IT团队能够胜任项目管理时，我想这将是非常简单的：培训或聘请一些好的项目经理，并让他们做这些工作。

但当我开始思考在我的IT组织中真正需要的角色时，发现建立项目管理能力并不是那么简单。正如我在我的项目管理需求中反映的，我确定了三个对我的成功非常关键的非传统项目管理的特点：

·敏捷或迭代法必须是项目管理的基础。

·项目管理必须积极主动地管理并化解风险。

·项目和项目状态必须是可见的。

项目管理的敏捷或迭代方法

正如我前面所述，敏捷方法帮助解决了传统IT项目问题的范围。我们应该将每一个IT项目分解成更小、更易于管理的块。这样在每一块的结束，我们可以适应变化。然而，这项建议不应意味着我们可以自有改变一切。有效的敏捷项目管理的规则之一是，在当前的块中，我们确定将做什么，然后让团队交付该块。如果有人改变了主意，当我们计划下一块时，我们应该考虑这些变化。

敏捷项目管理必须主动减轻风险

若干年前，我开始思考以一种更加自觉地、积极主动地方式管理风险。传统上，项目管理使用紧张的控制过程缓解风险。然而，那些过程和敏捷这种要适应变化的方法共同存在是有困难的。

我的用于积极主动的风险管理的方法在最初的项目规划期间就开始了。我创建了一个项目风险概况，将项目风险划分为三类：交付风险（时间、预算和目标上的风险）；业务案例风险（不正确的假设的风险）；和附带损失风险（当该项目交付承诺的、但在别的方面有可怕的涟漪效应时）。

一旦我们在这三个类别中识别到风险，我们就会确定其来源。它们是因为不确定性？（例如，有商业案例的风险，由于预期收益是没根据的猜测。）或者是因为复杂性吗？（例如，交付风险，因为我们使用的是一项极其复杂的集成技术。）

随着风险类别和来源被确定，接下来我们确定具体的项目任务，它们将遇到和减轻风险。在一般情况下，如果风险的来源是不确定的，我们使用敏捷或迭代的方法来降低这些风险。例如，我们会做一个小规模的试点来确定尚未明朗的好处。然而，如果风险的来源是复杂的，我们分离并简化我们所能做的。在每个项目块或迭代周期结束时，我们更新风险状况和缓解步骤--再像其他事情上以上，预期风险将会发生变化。

项目和项目状态必须是可见的

持续过程改进的格言之一是，我们应该能够通过简单的查看，说出每一件事情的状态。同样的格言适用于项目管理能力。我们现在生活在一个每个人都想获得一切的环境中！那么，为什么我会让我的项目利益相关者等待我去收集、记录和分发有关他们的项目信息？相反，我应该有一个项目状态可见的方式--这意味着，利益相关者可以通过简单的查看告知项目的状态--几乎实时。

这怎么可能呢？首先，我要保持我的项目状态需求在最低限度。否则，状态报告可以是繁重的--繁重的任务具有不能实时完成的倾向。其次，我应当使项目状态信息可访问。我们使用可视化的显示（在我们中间的那些"敏捷开发者"应当考虑典型的信息传播源），以及简单的、项目团队可以更新且利益相关者可以访问的技术仪表板--再没有太多的麻烦。

项目管理在我们的成功中起着至关重要的作用，但它必须适应我们的组织对我们的要求。在我的生活中，我既没有时间也没有空间用于官僚的项目管理过程。当我做迭代项目时，我得到我需要的。迭代项目主动管理风险，对任何人以及所有利害关系方可见。

责编：zhangyexi

04 C 语言的标准

02 为什么选择 Nginx

01 SQL 简介

TypeScript 混入(Mixins)