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