产品设计体会(7009)敏捷估计与规划

前段读了《敏捷估计与规划》,这本书很适合开发经理看,我只是很快的浏览了一下,摘录一些体会。

Ø     敏捷的里程碑是功能驱动的,先完成可交付的最“重要”功能,重要取决于功能商业价值、生命周期、实现难度等综合的结果。而传统的瀑布模型的里程碑是任务阶段驱动的,到了项目50%的时间,可能进入“编码”,但对客户来说,等于0%。而且这样的模式会陷入“实现难度决定开发顺序”的不合理模式,因为这里有个不合理的假设前提:所有功能都能够完成、必须完成,中间过程对客户是透明的。

Ø      项目估计的不确定性是会累积的,80%×80%×……,所以开始订的项目计划,在一个月后已经面目全非,强行的遵守是没有意义的,而应该不断的修正计划,当然,更好的做法是一开始的计划中间留有一些柔性的内容。

Ø   随着时间变化,必然有新的信息出现,特别是瞬息万变的互联网业界,死守着开始的项目计划不调整是没有逻辑的做法,敏捷的迭代刚好权衡了变化的成本和不变的成本,就是:不变本次迭代,更新下次迭代,这是一个将项目计划细化粒度的做法。

Ø      需求唯一不变的特征就是“不断变化”(plus不断细化),敏捷的思想就是欢迎变化,拥抱变化。瀑布模型一次性完成的需求分析,会存在“过度需求”的问题,降低整体效率。

项目管理理论的发展,从开始混乱,每个项目自有一套,每个PM自有一套;到后来人们非常想订出一个统一的简单的流程,减少人为影响(瀑布模型等出现),;再后来进入灵活的敏捷,看似又变得混乱,实则有序。又是宛如那个哲学的三段论:见山是山—见山不是山—见山还是山;也如管理的三个境界:人治—法治—无为而治

产品设计体会(7008)再理解敏捷

2008年春,项目做的对敏捷有了点兴趣,花了两个晚上浏览了《敏捷迭代开发——管理者指南》,理念式的书,看起来比较轻松,摘录一些自己的体会。

有些需求在开始的时候是提不出来的,或者说没法细化的,强行的过渡需求分析是浪费时间的行为,到后来多半还是要改。

瀑布(其实Royce大大提出的瀑布模型初衷里也是有迭代思想的,不过被后人误读了)的问题是最后集中暴露矛盾,当然对需求固定的项目还是不错的。

敏捷迭代开发,如果断章取义是极其危险的,比如没有迭代的测试跟上,到最后发现问题的时候就已经晚了。

介绍了四种敏捷的模式:ScrumXP(极限编程)、UP(统一过程)、EvoEvolutionary Project Management),他们的共同点如下:

Ø  拥抱变化,大问题分而治之,先解决最核心的,风险最大的部分

Ø  会议室中集体工作,每日例会(<20min),站立会议,充分利用白板和墙壁

iamsujie补:每日例会每个人说三句话:昨天做了什么,今天要做什么,碰到什么问题。

Ø  较短的迭代周期,通常一周到一个月,团队人数不要太多(小于十几人),太多了可分割为多个团队。

Ø  一个迭代周期内绝不再加任务,有多的需求放入以后的迭代,如果迭代周期内任务无法完成,可以为了时间点的要求,移出一部分任务到下一个迭代。

Ø  把迭代周期内的事情列出来,很小时间粒度(天为单位)的跟踪。

Ø  不停的发布/交付,让需求方看到结果,获取反馈

Ø  需求方充分投入,包括需求人员一起办公,验收测试的迭代。

Ø  需求方代表要有话语权,不然半途杀出个老板说三道四是极其郁闷的

Ø  轻文档,通过开发和测试来细化和纠正

Ø  程序员自主选择任务点,安排时间点。

Ø  反对加班,这点其实很难做到,特别是在中国,呵呵。

Ø  极其多的口头沟通,其实这点对团队成员要求很高,特别是对中国的技术人员。

Ø  强调测试,更早的测试(TC编写早于coding),重度的测试,测试驱动项目

产品设计体会(3004)项目外包不适合“敏捷”

2008春,前几个月尝试做了PM(这次是Project不是Product了),亲身经历了一个项目是怎样一步步不顺下去的。先说明一点:这里的“敏捷”是指甲乙双方配合的“敏捷”,而不是说外包项目本身内部的开发过程不合适“敏捷”。

先说一下背景,项目时间太紧,工期是由商业谈判决定的,没有及时评估工作量,做着做着产生delay,先试图简单的用加班的方法赶上进度,后来被迫注入“敏捷”项目方法,但事后发现“项目外包”模式不适合敏捷。

首先,项目外包使得甲方不愿意砍需求。为了敏捷灵活,公司内部的项目需求在很大程度上是可以砍的,是“保质不保量”,这是符合敏捷的原则的。但是项目外包,甲方在提需求的时候不愿把任何一个功能像平时那样推到2期做,因为项目结束后2期在哪里都不知道,所以“保质保量”变成了“不保质保量”。

其次,敏捷必然导致文档工作不细致,使甲方游离于项目之外的“验收测试”模式难以适应。敏捷从模式上会导致提交测试的产品和最初的需求之间必然有很多变化,并且文档很难跟上,而这种敏捷在公司内部之所以运行的很好,是因为PD、开发、测试在项目过程中可以充分交流,测试在TCTest Case)评审的时候会叫上PD和开发,有些属于详细设计的细节是在评审的时候与开发直接确认,在测试执行过程中也会协助确认需求细节并迭代测试。而项目外包的时候,甲方会从一份颗粒度过粗的需求文档上派生出“验收测试”的TC,又因为验收有“考试”的性质,所以不允许乙方的开发参加甲方的TC评审,导致只能和甲方需求人员确认细节,而需求人员对如此细节又没有要求,无奈之下只能按照自己的想法说,必然导致两边对需求的理解有鸿沟。另一方面,验收测试是一次性的,只有passfalse的结论,没有迭代的过程,不符合敏捷的思想。

最后,国内的乙方通常没有“敏捷”的经验和意识。一般甲方没有独立软件研发能力才选择项目外包(否则多用开发外包),职业性质/国内的项目管理现状决定了外包工程师的习惯是按照详细的设计文档开发/测试,抗拒需求改变,所以强行“敏捷”会导致失控。因为没有一份完整的详细设计文档,开发人员会按照自己的想法编码,测试人员也照自己的想法测试,没有做TC评审的意识,加之没有和需求人员即时沟通反馈的习惯,没有一个迭代的过程,再为了工期的死命令削减测试强度,结果就是发现做的与需求不符的时候已经晚了。

很多原因共同造成不好的结果,还有些没说,总结下来就是不能再这么做了,对敏捷的理解很粗浅,欢迎指正。