前段读了《敏捷估计与规划》,这本书很适合开发经理看,我只是很快的浏览了一下,摘录一些体会。
Ø 敏捷的里程碑是功能驱动的,先完成可交付的最“重要”功能,重要取决于功能商业价值、生命周期、实现难度等综合的结果。而传统的瀑布模型的里程碑是任务阶段驱动的,到了项目50%的时间,可能进入“编码”,但对客户来说,等于0%。而且这样的模式会陷入“实现难度决定开发顺序”的不合理模式,因为这里有个不合理的假设前提:所有功能都能够完成、必须完成,中间过程对客户是透明的。
Ø 项目估计的不确定性是会累积的,80%×80%×……,所以开始订的项目计划,在一个月后已经面目全非,强行的遵守是没有意义的,而应该不断的修正计划,当然,更好的做法是一开始的计划中间留有一些柔性的内容。
Ø 随着时间变化,必然有新的信息出现,特别是瞬息万变的互联网业界,死守着开始的项目计划不调整是没有逻辑的做法,敏捷的迭代刚好权衡了变化的成本和不变的成本,就是:不变本次迭代,更新下次迭代,这是一个将项目计划细化粒度的做法。
Ø 需求唯一不变的特征就是“不断变化”(plus不断细化),敏捷的思想就是欢迎变化,拥抱变化。瀑布模型一次性完成的需求分析,会存在“过度需求”的问题,降低整体效率。
项目管理理论的发展,从开始混乱,每个项目自有一套,每个PM自有一套;到后来人们非常想订出一个统一的简单的流程,减少人为影响(瀑布模型等出现),;再后来进入灵活的敏捷,看似又变得混乱,实则有序。又是宛如那个哲学的三段论:见山是山à见山不是山à见山还是山;也如管理的三个境界:人治à法治à无为而治。