1.乐观进度表现的方面有对项目的相关风险考虑不足,没有相关的风险管理计划和对风险应对的处理时间。项目没有预备一定的缓冲时间。项目裁剪或省略掉了生命周期中重要的过程或阶段,如需求分析,设计,或相关评审。
2.乐观进度是项目成员承担过多的压力,从长期来看伤害团队士气和生产率。
3.如果不积极的分析和应对风险,快速开发是一句空话。
4.软件或模块的外包或分包,与外包商的关系管理,接口和边界的定义。没有相关的规程或约定很难说外包能够节约成本和加快进度。
5.这个不多说了,计划是后期执行和监控的基础。不能因为计划不准而不计划。这要造成的后果是你始终都不会计划,计划做多了,多做偏差分析后计划自然就慢慢准确了。
6.进度压力下可以适当调整计划,但绝对不是抛弃计划。项目如果处于一种无序状态或code-and-fix状态带来的将是更多的进度延后和质量问题。
7.在项目开始前缓冲时间做足够多的预备和准备工作以减少项目进行过程中的风险。这些工作包括1)风险分析 2)技能评估和培训 3)团队学习 4)历史经验教训总结 5)项目经验总结,相关约束和规范制定 3)业务需求提前熟悉和调研。
8.虽然说磨刀不误砍柴功,但很多人还是希望先用钝刀去砍柴,先看到一些不多的产出,消除心中的恐惧。别人都去砍柴了还能够耐着性子磨刀的人不是简单的耐心的问题,而是出于对自己的充分信任,而对自己的这种信任又建立在多年经验积累的基础上。
9.这个很难去判定清楚,设计并不一定要体现到正规的文档和设计模型上面。设计人员和开发人员沟通的一句话,一个流程图可能就是一个设计。所以这里指的设计不要局限到设计的形式,而可能是说根本都没有对整个功能有个总体的实现思路就开始编码。
XP更强调开发的迭代和开发人员间的协同。因此对于设计过度也是我们要重点避免的问题。设计过度的一个重点弊端处了是浪费大量时间外,其它就是扼杀了编码的乐趣。
10.这里又说到好质量成本和坏质量成本的概念了。前期通过预防的手段如培训,Review等来保证质量可以减少后期的大量返工。如果COGQ少投入1天,可能会导致COPQ多投入3天到10天。
设计和编码的Review都是重要的预防手段和过程,不要去追求具体的形式,输出多少文档,而是是否确实做了这些工作?
11.项目的监督控制和项目计划一样重要。项目监督控制的目的就是要及早的发现问题和偏差,分析根源,并第一时间采取纠正措施,使项目按预定轨道前进。
12.WBS分解应该考虑到所有相关的工作,包括培训和会议这些。我们在安排进度计划时候经常忽略了预审,评审,培训,会议这些任务,其实这些任务也是很耗时间的工作。
13.进度落后的时候不能够不分析原因而一味的去赶进度。因为进度落后原因往往可能是我们估算的基准数据或生产率数据有问题,这个时候应该采取的措施是调整生产率后重新进行估算,根据新的估算结果对进度计划进行调整。
14.编码的健壮性,可测试性,可维护性不是通过Code-and-Fix来保证的。