《敏捷迭代开发》书评

再理解敏捷

2008年春，项目做的对敏捷有了点兴趣，花了两个晚上浏览了《敏捷迭代开发——管理者指南》，理念式的书，看起来比较轻松，摘录一些自己的体会。原文在 http://iamsujie.com/7000/7008/，欢迎大家来探讨相关话题有些需求在开始的时候是提不出来的，或者说没法细化的，强行的过渡需求分析是浪费时间的行为，到后来多半还是要改。瀑布（其实Royce大大提出的瀑布模型初衷里也是有迭代思想的，不过被后人误读了）的问题是最后集中暴露矛盾，当然对需求固定的项目还是不错的。敏捷迭代开发，如果断章取义是极其危险的，比如没有迭代的测试跟上，到最后发现问题的时候就已经晚了。介绍了四种敏捷的模式：Scrum、XP（极限编程）、UP（统一过程）、Evo（Evolutionary Project Management），他们的共同点如下：Ø 拥抱变化，大问题分而治之，先解决最核心的，风险最大的部分。Ø 会议室中集体工作，每日例会（<20min），站立会议，充分利用白板和墙壁。（iamsujie补：每日例会每个人说三句话：昨天做了什么，今天要做什么，碰到什么问题。）Ø 较短的迭代周期，通常一周到一个月，团队人数不要太多（小于十几人），太多了可分割为多个团队。Ø 一个迭代周期内绝不再加任务，有多的需求放入以后的迭代，如果迭代周期内任务无法完成，可以为了时间点的要求，移出一部分任务到下一个迭代。Ø 把迭代周期内的事情列出来，很小时间粒度（天为单位）的跟踪。Ø 不停的发布/交付，让需求方看到结果，获取反馈。Ø 需求方充分投入，包括需求人员一起办公，验收测试的迭代。Ø 需求方代表要有话语权，不然半途杀出个老板说三道四是极其郁闷的。Ø 轻文档，通过开发和测试来细化和纠正。Ø 程序员自主选择任务点，安排时间点。Ø 反对加班，这点其实很难做到，特别是在中国，呵呵。Ø 极其多的口头沟通，其实这点对团队成员要求很高，特别是对中国的技术人员。Ø 强调测试，更早的测试（TC编写早于coding），重度的测试，测试驱动项目。