敏捷开发一千零一问系列之二十五：传统团队如何转变为敏捷团队（一）？
这是敏捷开发一千零一问系列的第二十五篇。（在这里提问，之一，之二，之三，问题总目录）
也是敏捷开发团队管理系列的第六篇。（团队管理栏目目录）
问题问：传统的团队如何转化为敏捷团队（步骤，要点，注意事项等）？
问：如果使用敏捷开发，在公司组织架构上有没有什么建议？
分析在谈到何为敏捷团队之前，先看看传统团队的问题，不要把团队转化完了，问题还存在；换言之，解决问题是目标，转化团队是手段。
1. 各部门打架严重
来自于分工中的灰色地带 / 各自目标和绩效的不一致。
典型的是开发/测试团队，扩展而言，还包括市场/销售团队。
后两者也很关键，很多时候开发和测试团队和谐了，联合起来和销售团队打架，公司的整体效率仍然上不去。
不过，如果没有在市场/销售团队的工作经验，或管理他们的经验，谈论和过问与他们跨职能的难度很大。但这不等于这个问题不存在，可以请公司更上层的人去关注这个问题。本博客未来会提到市场/销售/开发团队的跨职能问题。
2. 各部门流程/文档繁杂
为了解决打架问题，需要流程和文档来规范接口。
常常被过度写作的需求文档和设计文档，就是因为要跨过多个部门，才需要被“签字”“确认”“协调一致”，所以其写作的水平，往往超过“以能编写出软件为准”，而是达到“能交给下一个部门，让他们看完以后能编写出软件”为准。
跨职能团队是敏捷开发提出的团队模型（自组织是跨职能的产物，下面会看到），通过消除部门分割，来解决上面的两大难题。
直接方案直接方案是那些几乎不需要其他实践，就能直接使用的方案，虽然他们也有一些先决条件。
世界上没有无条件的事，也没有生下来就有条件的人，所以很容易把喜欢找借口胜过方法的人卡住。如果下面这个事情仍然觉得很难办，那么多半还没有到谈论团队转型的阶段，请继续努力吧！
3～5人规模的小组内实现跨职能（小组长可推行）
这个是无需行政授权，小组长就能做的事情。
本人非常推崇通过1-3-9团队形成L型代码结构（文后有链接），局部的“部门”打架和文档问题迎刃而解。
139团队中，整个小组的目标是一致的，而且成败都由师傅负责，因此他会成为跨人员的桥梁，把整个团队的事情当作自己的事情，解决个人的打架问题。
L型代码结构可以有效降低文档量。当积木代码基本形成后，所有功能大致只有界面和业务逻辑的设计，经常一个功能只有50行代码左右，很多设计都可以因此省略。
生态方案生态方案多半不能直接就上，需要另外一些条件具备。
10～20人规模的开发组内实现跨职能（项目经理可推行）
实际上没有办法让10～20人可以互相修改别人的代码，但在这个规模上，合作的需求更高，代码的复用利益更大，跨职能势在必行。
这里所说的跨职能，不是代码级别的，而是在业务接口问题上，大致有以下几种情况。
一是经常有一些接口类功能，说不上来该谁做，这时候项目经理（就是10～20人的头）要协调其中一方完成，并为这方争取更多的资源（工期和人数）。
1. 进度-质量目标的合并（研发的部门经理可推行）
也就是无论是否还有开发-测试的分割，必须把进度绩效和质量绩效统一管理。
一个项目延期了，测试也有责任；一个项目质量差，开发也有责任。结果大致会变成：
测试团队与开发团队融合
一般是测试团队分解到开发组，从事自动化测试的执行工作。
多数自动化脚本开发团队可以编写，但是多半要配置一些脚本、写一些测试用例什么的，由测试人员执行。
这种模式下，对测试团队的人数要求很少。
测试团队与需求团队融合
质量工作彻底交给开发团队负责，测试团队只负责业务级别的验收测试（还负责早期的需求理解和机遇需求的测试用例编写）。
开发团队分化出一些人负责执行测试，这些人的数量一样要求很少；开发团队同时对进度和质量负责。
这两种方法都不容易做到，而且还有无穷无尽的问题，但告诉大家一个方法来解决：那就是每当自己心里想问：“可是，怎么……呢？”，自己要先想三个答案，然后再问；有时候会发现不用问了，答案已经被自己说出来了。
2. 市场/销售/产品/研发的跨职能（总经理/副总经理可以推行）简单说就是市场/销售/产品团队，要为研发的成本负责（比如销售要先扣除研发成本，再谈提成）；而研发要为销售/市场负责（比如如果销售额上升，研发团队也有一个提成）。
日后有机会再谈这个，很多企业都已经有成功经验了，只是都不太分享而已。
139团队链接：http://blog.csdn.net/cheny_com/article/details/6598812
L型代码结构链接：http://blog.csdn.net/cheny_com/article/details/7889796
