以纵轴的性质区分,燃尽图可以分为两大类,即纵轴可以是时间或是事件。以范围区分,燃尽图至少可以分为三类:项目级的、任务级的和需求级的。透过燃尽图,我们可以看到项目进行的情况,项目需求是否按计划进入开发流程,工作是否有延时,或者工作安排的饱和度是否适合。如上图所示,我们可以轻易地看到,照着现在的进度,这项目可能会延期6到7工作天。当高层看到这图时,可以在资源上做调动,以避免延期产生的不良后果。

  我们刻意使用了这个较理想的图做讲解,为的是让读者更容易理解。它不是个典型的图。在大多情况,使用燃尽图会是比较复杂的,因为它可能包含了需求搜集、编程、单元测试、集成测试和缺陷修复,并且还可能有迭代。所以估算时间会较困难。这个燃尽图的过程是比较稳定的,结果是比较理想的,其原因至少有二:(一)项目里单纯地只有编程、单元测试和缺陷修复任务,全都由程序员搞定;它里头没有需求搜集、集成测试或其他任务。(二)这个项目复杂度低,约一半的编码任务是机械性的,所以估出来的时间较为准确。

  (2)固化工作流以管控过程

  对于公司里既定的流程,我们在DevSuite里以图形化的工作流将其固化。下图是以前面王总监提到的需求变更流程设计出来的。

  这工作流指明了,在一个变更事件被创建后,它需要经过一个《评审》状态。在评审阶段里,有三个人(A,B和C)要全部同意,才能到达《通过》状态。有任何一人不同意,状态转到《拒绝》。当一到达《评审》状态,系统马上促发邮件和手机通知,将信息寄给A,B和C。系统可以预先设定这三人有两天的时间评审该变更。假如两天过了,状态仍为《评审》,那是有人未及时处理该事件。这时候,系统会自动将事件升级,把状态转换为《升级处理》,系统马上促发邮件,将信息寄给研发部王总监。王总监可以斟酌情况,做妥善的处理。

  使用固化的工作流至少有四个优点:1)提高通知效率 ?邮件和手机自动通知提高效率,沟通出错的机会减少了;2)避免流程出错 ?DevSuite的工作流将流程完全自动化,每个人在收到邮件或短信通知时,照着工作流中既定的步骤操作行了,省心又省力; 3)工作流变动时处理很容易 ?当流程或人员变动时,系统配置员可以轻易地花几分钟做完调整,之后所有团队成员照着流程走便行了;4)避免摩擦?人是有情绪的,固化的工作流使得操作完全对事不对人,避免了人和人之间不必要的摩擦。

  以上提到的软件项目风险实例几乎在每个项目中都出现,而且,它们造成的损失也是严重的。所幸,从实际操作中,我们发现处理它们的成本并不高:1)培训团队成员照工作流中既定的步骤操作,学会填写任务花费时间和任务所剩时间,并理解意图,所花时间不超过1小时,2)系统配置员要了解需求,设计工作流,并设置人员(如例子中的A、B、C和走流程的人)的权限等,所花费时间在1到3天之间,也算合理,3)以往当团队人员或评审流程有变动,管理人员要更改文档并向所有人宣布;现系统配置员只要花几分钟改系统配置,一切绪了。

  小结

  这并不是一个全方位的风险管控系统;相反的,它是个相当简化,只对关键点作处理的系统。虽然只是做在关键点上,但效果却十分明显。拿需求变更来说,需求变更一直都是项目中让人恨得牙痒痒的瘤。既然需求变更是不可避免,那我们所能做的是,尽可能减少变更的次数,降低变更造成的冲击。以往大多数人审核需求变更时较为草率,导致同一个功能点变了又变。在一轮又一轮的返工后,程序员和测试人员会产生倦怠感,编码和测试的质量一再下降。使用了DevSuite后,所有的操作都在系统里留下记录,这统计在年终时可以作为考评的参考材料。自然而然地,审核人员很严谨地审核每一个需求变更。而且,因为系统设置了每人只有两天的时间处理,审核人员处理需求变更时不仅是快,而且较仔细。单单这个变化,使得整个团队的气象焕然一新。

  在系统实施后半年,我们做了客户回访,我劈头问王总监,说的那位产品经理还跟项目经理还吵架吗?瞪了我一眼,停了一下,然后皱了皱眉头说:倒是不吵架了。他们俩现在成了好朋友,联合起来一起对付我了。他自己呵呵呵地笑了起来