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

　　分析

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

　　1、各部门打架严重

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

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

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

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

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

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

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

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

　　直接方案

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

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

　　3~5人规模的小组内实现跨职能(小组长可推行)

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

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

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

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

　　生态方案

　　生态方案多半不能直接就上，需要另外一些条件具备。

　　10~20人规模的开发组内实现跨职能(项目经理可推行)

　　实际上没有办法让10~20人可以互相修改别人的代码，但在这个规模上，合作的需求更高，代码的复用利益更大，跨职能势在必行。

　　这里所说的跨职能，不是代码级别的，而是在业务接口问题上，大致有以下几种情况。

　　一是经常有一些接口类功能，说不上来该谁做，这时候项目经理(就是10~20人的头)要协调其中一方完成，并为这方争取更多的资源(工期和人数)。

　　这里多少要建立团队可以提请要人的机制，而且项目经理能临时分配人员，比如把小李交给老王那组工作一段时间之类的。在139团队里边这个相对好办一些，如果是1个人管理12个人，就很难办。

　　组织方案

　　1、进度-质量目标的合并(研发的部门经理可推行)

　　也就是无论是否还有开发-测试的分割，必须把进度绩效和质量绩效统一管理。

　　一个项目延期了，测试也有责任;一个项目质量差，开发也有责任。结果大致会变成：

　　测试团队与开发团队融合

　　一般是测试团队分解到开发组，从事自动化测试的执行工作。

　　多数自动化脚本开发团队可以编写，但是多半要配置一些脚本、写一些测试用例什么的，由测试人员执行。

　　这种模式下，对测试团队的人数要求很少。

　　测试团队与需求团队融合

　　质量工作彻底交给开发团队负责，测试团队只负责业务级别的验收测试(还负责早期的需求理解和机遇需求的测试用例编写)。

　　开发团队分化出一些人负责执行测试，这些人的数量一样要求很少;开发团队同时对进度和质量负责。

　　这两种方法都不容易做到，而且还有无穷无尽的问题，但告诉大家一个方法来解决：那就是每当自己心里想问：“可是，怎么……呢?”,自己要先想三个答案，然后再问;有时候会发现不用问了，答案已经被自己说出来了。

　　2、市场/销售/产品/研发的跨职能(总经理/副总经理可以推行)

　　简单说就是市场/销售/产品团队，要为研发的成本负责(比如销售要先扣除研发成本，再谈提成);而研发要为销售/市场负责(比如如果销售额上升，研发团队也有一个提成)。

　　日后有机会再谈这个，很多企业都已经有成功经验了，只是都不太分享而已。