有一句古话说的好，
“
有人的地方就有江湖”。
与瀑布模式相比，
敏捷开发
更注重人与人的交流。
所以在开发过程中更有
可能会发生
各种争论、争吵。
首先说为什么会吵起来？个人原因咱就不说了，只说说项目过程中时引起的争论甚至是争吵吧。
1. 对于同一个问题，2个人有不同的观点，谁也说服不了谁
2. 自己的想法或设计被多次否定，自己说不出来哪好，对方说不出来哪差
3. 双
方理解不一致，导致结果偏离太大
以上三条是我认为在项目开发过程中经常遇到的情景。
咱们逐条分析一下。
第一种，对于同一个问题的解决方案，有不同的观点是经常的事儿。如果2个人的设计预期结果一致，只是实现方式不一致，那么大家可以讨论一下谁的方案更优，如果没有明确结果，可以2个方案都做，用实践来证明。当然现实的开发过程中，由于时间有限等各种原因，我们必须做出取舍，可以选择投票表决。但是如果2个人的设计方案导致最终结果差异很大，那么就必须需要认真讨论一下了，这是不可避免的。根据业务需求来定主调，用户习惯和体验度为基准进行评判。实在评判不出来，还是推荐使用投票表决的方式去解决，“失利”的童鞋需要尊重结果。
第二
种
，这种情况多发生在开发人员与项目经理之间。开发人员接到任务，突破重重难关，
然后
提出某个想法或设计，项目经理觉得
如果用这种设计可能导致很大的问题
，但一时又说不上来理由。而开发人员只是用这种方式可以实现需求，自己也说不上来哪好哪不好。谁也无法反驳谁，所以想法或设计就暂时被毙掉了。对于这种问题，我觉得首先是项目经理的经验不足所致，他要尽可能的说出来有可能产生什么问题，那么大家才能根据问题去探讨，开发人员也可以据此去优化。而开发人员必须能说出这么设计的出发点与好处。才有可能说服项目经理肯定你的想法或设计。
第三
种
，双方理解不一致导致争吵的现象是最常见的，也是最让人头疼的。
开发人员会认为当初按项目经理说的去开发，结果最后项目经理说开发人员
做的与他说的不一样，会认为项目经理是故意跟他过意不去。
如果导致出了大问题，还有推卸责任的嫌疑。双方的矛盾也可能会扩散到项目以外去。这是大家都不愿意看到的。如何解决这个问题？我觉得文档是最好的解决途径。敏捷开发中是需要有必要的文档的。需求和需求更改都需要简要的文档，出了问题就查文档，这就是最好的证据。
其实我觉得项目中的争论是很有必要的。
争论可以让大家更深刻的理解需求，可以集大家的知识与智慧快速提出合理的解决方案
，可以使得大家的相互了解
，还可以活跃开发气氛。这些都是非常有益于项目开发的。
但是争论不是争吵，争论的有意义的，争吵是无谓的，如何控制争论的节奏，不至于升级到争吵，是作为项目经理要做的重要工作。
