现在越来越多的互联网公司都在以敏捷的形式进行开发，可是在实践中慢慢发现每个公司似乎又感觉敏捷开发的形式并不适应自己公司的需要，经过几番的折腾之后看不到敏捷的效果，又改回了之前的工作模式。
为什么？
我个人总结有以下几个原因，
1.人不对，
2.说不清，
3.听不懂，
4.忍不住，
人不对
我觉得在敏捷的团队中对于每一个人的要求是相当高的，在敏捷宣言的原则中有一条是：最好的架构、需求和设计都源自自我组织的团队。自我组织的团队，短短几个字其实暗含了对敏捷团队人员的要求，什么样的要求呢？一个优秀的敏捷团队的成员应该像构成木桶的木板一样，朝着不同的方向有着各自的优势，几个模板紧紧的箍在一起才能装水。所谓的朝着不同的方向是什么？
a.架构，有人要有很强的架构能力，使用什么样的架构来满足开发需求，这将影响团队的相应需求的能力
b.产品，有人要产品能力强，能快速的勾勒产品形态，组织团队内部对于产品形态的评定，
c.设计，有人要设计能力强，根据产品迅速给出交互原型，并在组织团队评定，
d.测试，在敏捷的世界里理论上，每个人都应该是测试人员，
e.开发，在敏捷的世界里理论上，每个人都应该是程序员，这里的开发包括，前端、后端、终端等几方面的开发人员。
如果您的敏捷团队里还没有发现在架构，产品，设计方面特别突出的人员，那就要有意识的去寻找或者培养这样的几个人员了。
说不清
这个说不清有两方面，第一成员沟通说不清，第二代码“说”不清。先说第一成员沟通说不清的状况，在上面对人不对这个问题进行分析的时候里面提到了一个词是组织，这里的组织我认为有沟通，协调的意味在里面，所以，说，这件事很重要，不仅要说，还要能说的明白，以最大限度的降低沟通过程中所消耗的时间，我称之为沟通成本，解决这个问题，需要通过训练，有几个小方法可以试试：
a.在工作中训练，一方在说完需求或者任务的时候，听的一方要主动反馈，
b.在展示中训练，我之前的一家公司设立了一个会议形式叫做分享会，在分享会上，一个人个几个甚至十几个人分享一些内容， 对于内容不限范围，主要就是为了训练主讲人的表达能力，建议一试。
接下来说代码说不清， 因为在敏捷团队中，人人都是开发者，所以团队开发的代码风格就会有不统一的问题，在以后的代码维护这个层面来说就会花费大量的时间去熟悉每个人的代码风格，所以在团队中，要建立相对统一的代码风格，这个事也很重要，很重要，很重要，所谓的相对统一就是有个标准，有些标准可以相对宽泛一些，比如变量命名的方式，但是在一些容易出现问题的地方做一些强制的要求，比如在java中if判断中即便是只有一行代码也要加大括号，类似这样的规范需要有一些。
听不懂
听不懂是说不清的一个延伸，一是团队内听不懂，这个能通过团队内的训练得到缓解，相对来说问题不大，二是团队外听不懂，客户提的需求团队没听懂，团队的解决方案客户没听懂，由于这个原因造成的无用劳动也不少，所以，听懂，这个事很重要，很重要，很重要。
以上两点对应在敏捷宣言的原则里:
1.业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。一方面是提高沟通效率，另一方面也增进是成员的相互了解
2.在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。这样的沟通效率最高，也是反馈效果最好的方式。
忍不住
客户有时候会将一些没有经过深思熟虑的需求提出来，这个时候团队需要对这样需求经行讨论和细化，以判断要不要加，怎么加，什么时候加，而不要觉得问题不到就随手加上了，这样的情况要能忍住，这是一个敏捷团队的纪律。
