【IT168 评论】我们俩来自于诺基亚西门子网络杭州3G研发中心，本文内容来源于诺西一个通信产品研发部门所进行的敏捷转变，它是典型的多站点开发的研发组织，在芬兰、印度、中国等国家都有研发团队，总计超过600人。我们免去在文中冗述各种功绩和所得，只在这里和大家分享我们所经历的那些误区、陷阱，当然还有那些应对的措施。
本文仅代表徐毅和王献的看法，如此大的组织转变，我们作为不到1%的人口代表，看到的、经历的难免会有误差，恐怕不能概括事件的全貌，如有出入，请见谅。我们认为经历的误区和陷阱大致可以分成如下七个方面：特性团队、人、浪费、局部优化、软件质量、测试自动化、流程。
特性团队(Feature Team)
在组织中想要达到真正的Feature Team是一个很漫长的过程，当在组织中实现局部的端到端的组的时候，更大的端到端的组的演变要求就会出现，因为这时组织中新的瓶颈会展现出来，这也是为什么敏捷虽不能解决问题，但却使问题更显现地表现出来的原因之一。
在组织的转型中，产品有非常庞大的老代码：
1. 通常早期的Feature Team所包括的功能性测试不完全，外部的测试对于这些Feature Team所起到的保护作用还是相当重要的;
随着时间的推移，Feature Team对于自己feature自动化测试加强以及测试能力的提高，发布给外部的产品质量会大大提高;
2. 对于外部其他组的依赖接口会很多，特别是组在不同国家的时候，沟通、交接和等待的浪费会很大;
3. 当产品中开发部门和开发部门的依赖减少后，开发和测试的瓶颈会更突出;
4. 当产品中各个功能部门的依赖减少的时候，产品和产品间的瓶颈会凸显。
想象一下从客户提需求到最终提交功能需要经过多少个过程，特别是大型组织中的产品，端到端意味着几十个过程甚至更多，Feature Team中能容纳多少个这样的过程就意味着这个Feature Team的灵活度有多高，本质上敏捷就是为了减少相互的依赖、等待和传递所带来的消耗。
一个组织是一个庞大的系统，Feature Team的转变过程意味着减少整个系统中的Limitation。
在向Feature Team演变的过程，在相对比较短的时间把原先十几或者几十Component Team打破组成新的Feature Team，这中间的风险在于：
1. 组的成熟度：成熟度需要时间，也需要一些错误的代价;
2. 组的长期成长和短期项目计划：由于为了项目的进度而把对某领域很熟悉的组移出去做不熟悉的领域;
3. 组织的产出效率：怎样合理的利用现有的有经验人员和新人，建立新结构所需要的基础会使组织整体的产出效率减低;
4. 不可控和无序：怎样让这些组高质量的发布产品在转变过程变的不可控。
理想和现实中的平衡是Feature Team所面对一个问题，剧烈的变动意味着剧烈的阵痛。
