人人都是产品经理——iamsujie

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

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

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

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

介绍了四种敏捷的模式：Scrum、XP（极限编程）、UP（统一过程）、Evo（Evolutionary Project Management），他们的共同点如下：

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

Ø  会议室中集体工作，每日例会（<20min），站立会议，充分利用白板和墙壁。

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

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

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

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

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

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

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

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

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

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

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

Ø  强调测试，更早的测试（TC编写早于coding），重度的测试，测试驱动项目。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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