项目生命体征

项目生命体征

(2009-12-01 17:16:27)转载 标签：

scrum

敏捷

迭代

可视化

分类：IT项目管理 Scrum方法论是很强调项目可视化的，包括了项目的进度，范围，质量等重要的项目属性都需要可视化。如同一个人看病，医生可以观看病人的健康状况图表，得到病人的生命体征数据。因此对于软件研发项目，如果需要快速的响应变化并动态的调整自己，就必须要通过各种简单的可视化的图表，将项目的健康状况暴露出来。很多软件项目之所以失败，往往是在项目执行过程中，问题没有暴露，加上我们风险意识又比较弱，最终病入膏肓的时候已经无药可救。

开放的团队文化，就是要树立开放的沟通环境，勇于发现和暴露问题。先不要去管问题本身的价值，而是应该先树立暴露问题的文化。项目在进行过程中没有问题往往就是最大的问题。项目生命体征是一些可收集的定量度量数据，用于及时反映项目的整体运行状况。这些体征包括：

1.项目范围增量(Scope burn-up):描述某期限时所需要交付的项目范围情况。
2.交付质量(Delivery quality):最终交付的项目状况。
3.预算燃尽(Budget burn-down):根据项目范围交付状况统计的预算使用情况。
4.实际开发状态(Current state of implementation):已经交付的系统功能情况。

我如果对后续太远的时间发生的事件做到准确的预测，那么你需要做的就是把模糊的事件为近期，中期和远期。对近期发生的事件做到准确的预测，通过近期的执行监控一方面随时动态调整自己，一方面使远期模糊化的事件清晰化。

1.项目范围增量(Scope burn-up):描述某期限时所需要交付的项目范围情况。

需求的条目化是能够形成范围增量的一个重要内容，而scrum中的需求条目就是用户故事，为了保证范围增量实际意义，我们还需要考虑用户故事本身的规模和复杂度，对于太大的用户故事可以进行拆分，太小的则可以进行合并。当时前提仍然是用户故事本身是独立可以验证的一个实现业务价值的用户需求。

对于软件项目在项目立项后，项目团队成员基本是固定的，不会产生太大的变动。而进度真正关注的则是范围和需求点的完成情况。因此可以看到很多可视化图表都是围绕用户故事这个范围展开，而不是用常规IT项目管理中的较为复杂的挣值图。

在范围增量图上，通过使用中期里程碑作为对照点可以很方便的发现瓶颈。基于中期里程碑的进度比率会显示出交付流程运行是否良好。通过这一数据的对比可以发现交付瓶颈。比值的不同表明流程中有瓶颈存在。

2.交付质量(Delivery quality):最终交付的项目状况。

没有质量保证的进度是没有意义，因此质量的可视化是另外一个需要关注的重点。而质量的可视化应该关注两个内容，一个内容是缺陷的趋势情况如何？一个内容是缺陷的数量情况，而对于缺陷的数量又必须对缺陷进行等级的划分，除了Bug总数之外，我们必须要关注高优先级的Bug，这些Bug是否能够解决直接影响到迭代结束后的版本发布。迭代完成的标志就是要产生一个可以部署的，保护了实现业务价值的功能的版本。

缺陷数量和趋势图一般由测试人员维护，而且需要在整个项目团队可见。

3.预算燃尽(Budget burn-down):根据项目范围交付状况统计的预算使用情况。

预算燃尽图的X轴是迭代周期或时间进度(可以细化到周或天)，而Y轴既可以是预算的燃尽情况，也可以是用户故事(功能点)的燃尽情况。在我们做完了用户故事到任务级别分解，形成了详细的任务安排后，会由一个计划的燃尽曲线，在项目执行中需要做的就是动态及时的更新功能点的实际燃尽情况。我们的进度究竟是提前还是滞后了？我们的Sprint规划的用户故事是多了还是少了？对于进度偏差我们是否需要采取一些措施？通过该图都可以直观的回答这些问题。

4.实际开发状态(Current state of implementation):已经交付的系统功能情况。

该图最类似于精益生产中的看板，而看板中放置的即是由用户故事和子任务列表组成的故事卡。故事卡上会对故事，责任人，子任务进行说明。在整个看板中故事卡会随着开发实现的过程不断的移动。在软件开发中我们谈到软件生命周期，阶段和状态。而在该图上，可以看到以故事卡为单位，每个故事卡都具有同样的开发状态。随着项目的进行，故事卡不断的移动，我们真实的看到的进度的进展情况。

在软件开发中通过需求的条目化，实现了不仅仅是软件开发本身的组件化，同时实现了需求，设计，测试等各个过程的活动和文档的结构化。而对于全新的系统，在需求，设计和测试环节存在无法根据用户故事全条目化的内容。即我们所说的业务架构，技术架构和产品集成。在全新的产品开发中使用Scrum的时候，需要考虑这三个方面内容的解决方案。