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

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

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

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

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

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