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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

产品设计体会(7007)当交互设计遇到敏捷开发

让我们先回到2002115日,交互设计之父Alan Cooper和极限编程创始人Kent Beckpk,话题是“当交互设计遇到敏捷开发。就像小说里两大高手对决一样,双方大战三百回合还是没有分出胜负,终归握手言和(或者小气的赌气分手,呵呵),引用一些对那场战斗的评论:

Ø Cooper大师认为子弹很贵,因此在每次开枪之前一定要精确地瞄准。负责瞄准的人应该是专业的交互设计师。

Ø Beck大师认为有了极限编程,子弹变得很便宜,我不需要瞄太准,打不准就再放一枪,没什么大不了,最终总能打中目标。

Ø Cooper大师很适合做一个狙击手,点射的命中率几乎能够达到100%

Ø Beck大师很适合做一个机枪手,机枪是不可以点射的,一般都是扫一片,用密集的火力消灭敌人。

Ø 两者考虑问题的角度不大一致,其实并不存在非常大的冲突。相反,交互设计与敏捷开发方法能够结合起来,以更小的成本交付令用户满意的产品。Patton在这方面做了成功的尝试。

还是那个道理,方法只有是否合适,没有好坏之分,也许“交互设计”比较适合传统领域、成熟公司、时间资源充裕的时候,使用者在某领域中已经出于领先地位,目的是求稳,不犯错就是胜利;“敏捷开发”适合新兴行业、创业公司、时间紧迫,大家都在赶,谁先出头谁就能占得先机,或者作为挑战者进入某个行业,团队本身灵活,失败了损失也不大,重来的成本低。从这点上看,互联网行业、SAAS模式似乎更偏向于使用敏捷开发的方法,但敏捷绝不是在时间紧迫下的被迫放弃交互,而是主动为之的一种思想,并且要将交互融入其中(敏捷设计?)。

从另一个角度想,“交互设计”适合设计型公司,“敏捷开发”适合技术型公司,各个公司都有其强势的部门,这里就不展开了。

“交互设计”之于“敏捷开发”,有点像那个“大象与猴子”的寓言(一时找不到),最后结合在一起最好,又像楷书与草书,同样是写字,没法评价哪个好哪个差,也许结合一下又出现了很赞的行书