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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

------------------------------------------------------------如果你想第一时间看到最新内容, 就猛击此处订阅吧!

发表评论

电子邮件地址不会被公开。 必填项已用*标注