为什么敏捷没有成功： 关于敏捷的一点思考 (3)
续上篇 ：关于敏捷的一点思考 (2)
这一篇文章主要讨论一下“虚”的东西：
1. 特性团队
大家都知道绝大多数的软件公司都是按人的技能来划分组织的， 一般包括业务分析，架构，开发，测试，这种组织结构很适合瀑布模型的开发，上游的产出被传递到下游去进一步加工，最后输出软件。 弊端也很明显，难以应对变化，要不敏捷也不会出现了。
敏捷开发要求“特性团队”，IBM 称之为whole team , 一个团队中既要有业务分析和架构师，又要有开发，测试等人员， 这就意味着需要打散现有组织，然后根据特性进行重组。
实际情况怎么样呢？ 除了一些非常小的团队之外，我还没有观察哪个组织能够按照敏捷的要求来组成真正的 特性团队，我相信大多数公司都是采用了一种折中的办法： 组建“虚拟 ”的特性团队，从各个部门抽取不同角色的人员来组建， 值得注意的是，这些人员的组织关系还属于原来的部门， 绩效考核仍然由原来的部门来进行。
由于每个人的利益不同，目标很难一致，这样的团队注定是一个松散的，无法团结一致，努力想冲刺，完成一个个迭代开发的组织。
2. 团队协作
敏捷软件开发是一个特别要求深度团队协作 的组织活动，特别强调面对面的沟通和交流，这就是为什么Scrum有Plan meeting,daily scrum meeting 和定期demo 的原因。通过这些会议我们要澄清需求，暴露开发测试中的障碍，以及定期的获取客户的反馈。
Scrum 很容易做到形似，因为各种会议很容易组织起来，但是很难做到神似： 因为大多数团队中的人协作和沟通不够
例如：
当开发人员对业务有问题的时候业务人员是否能马上给予现场解答？
我观察的情况是，业务人员通常很忙，大部分时间都不能和团队待在一起，更别说马上解答问题了
更有甚者，业务分析师和团队根本不在一个时区，每周定期电话会议来讨论问题，效率极其低下
测试人员是否真的能和开发坐在一起，讨论需求，理解需求？
客户或者客户的代表是否真的能参加Demo，提出反馈？
3. 平等和主动
敏捷开发希望团队中的成员都是Peer,都是平等的。这一点在绝大多数公司都做不到，一般都是一个主程序员带着几个开发来干活。
老大发话小弟们当然要听着，理解的要执行，不理解的也要执行。
老大分配任务小弟们只有乖乖的听着，分到什么干什么
现在很多公司为了降低成本，招了很多的外包的程序员，更加造成了团队的分化
Team Lead > 程序员 > 外包程序员
这里并不是贬低外包，但事实是残酷的，除了个别积极主动的人以外，很多外包的程序员就是只等着分配任务，干完回家
这种不平等的情况下，怎么可能在迭代计划会议上主动的认领User story, 在daily scrum meeting 中主动的更新状态，并且在开发和测试中主动的发现问题，解决问题呢？
敏捷开发不要听话的程序员，敏捷开发需要主动思考，主动解决问题的程序员。
