问题

　　问：传统的团队如何转化为敏捷团队（步骤，要点，注意事项等）？

　　问：如果使用敏捷开发，在公司组织架构上有没有什么建议？

　　分析

　　在谈到何为敏捷团队之前，先看看传统团队的问题，不要把团队转化完了，问题还存在；换言之，解决问题是目标，转化团队是手段。

　　1、各部门打架严重

　　来自于分工中的灰色地带 / 各自目标和绩效的不一致。

　　典型的是开发/测试团队，扩展而言，还包括市场/销售团队。

　　后两者也很关键，很多时候开发和测试团队和谐了，联合起来和销售团队打架，公司的整体效率仍然上不去。

　　不过，如果没有在市场/销售团队的工作经验，或管理他们的经验，谈论和过问与他们跨职能的难度很大。但这不等于这个问题不存在，可以请公司更上层的人去关注这个问题。本博客未来会提到市场/销售/开发团队的跨职能问题。

　　2、各部门流程/文档繁杂

　　为了解决打架问题，需要流程和文档来规范接口。

　　常常被过度写作的需求文档和设计文档，是因为要跨过多个部门，才需要被“签字”“确认”“协调一致”，所以其写作的水平，往往超过“以能编写出软件为准”，而是达到“能交给下一个部门，让他们看完以后能编写出软件”为准。

　　跨职能团队是敏捷开发提出的团队模型（自组织是跨职能的产物，下面会看到），通过消除部门分割，来解决上面的两大难题。

　　直接方案

　　直接方案是那些几乎不需要其他实践，能直接使用的方案，虽然他们也有一些先决条件。

　　世界上没有无条件的事，也没有生下来有条件的人，所以很容易把喜欢找借口胜过方法的人卡住。如果下面这个事情仍然觉得很难办，那么多半还没有到谈论团队转型的阶段，请继续努力吧！

　　3～5人规模的小组内实现跨职能（小组长可推行）

　　这个是无需行政授权，小组长能做的事情。

　　本人非常推崇通过1-3-9团队形成L型代码结构（文后有链接），局部的“部门”打架和文档问题迎刃而解。

　　139团队中，整个小组的目标是一致的，而且成败都由师傅负责，因此他会成为跨人员的桥梁，把整个团队的事情当作自己的事情，解决个人的打架问题。

　　L型代码结构可以有效降低文档量。当积木代码基本形成后，所有功能大致只有界面和业务逻辑的设计，经常一个功能只有50行代码左右，很多设计都可以因此省略。