传统团队如何转变为敏捷团队？

　　问题51Testing软件测试网`h(P;rB7r)H

　　问：传统的团队如何转化为敏捷团队（步骤，要点，注意事项等）？51Testing软件测试网O3V,~A7onF5D

t2Ay7R%r.G0q/~Dp0　　问：如果使用敏捷开发，在公司组织架构上有没有什么建议？51Testing软件测试网fx T H)S_^!i7j

temX1]Y0　　分析51Testing软件测试网k9n5^$mb#Ckg

　　在谈到何为敏捷团队之前，先看看传统团队的问题，不要把团队转化完了，问题还存在；换言之，解决问题是目标，转化团队是手段。51Testing软件测试网#xv!s}
I$_

UR@A#n&u'O h0　　1、各部门打架严重

　　来自于分工中的灰色地带 / 各自目标和绩效的不一致。51Testing软件测试网 p]/YPSvW

　　典型的是开发/测试团队，扩展而言，还包括市场/销售团队。51Testing软件测试网L:r%nXz7GpU

;@'z8rL,O3?G2cH0　　后两者也很关键，很多时候开发和测试团队和谐了，联合起来和销售团队打架，公司的整体效率仍然上不去。51Testing软件测试网*g,H,btP

7{ S:j(k5H%J*]w0　　不过，如果没有在市场/销售团队的工作经验，或管理他们的经验，谈论和过问与他们跨职能的难度很大。但这不等于这个问题不存在，可以请公司更上层的人去关注这个问题。本博客未来会提到市场/销售/开发团队的跨职能问题。51Testing软件测试网$B:v|wV _o

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

　　为了解决打架问题，需要流程和文档来规范接口。51Testing软件测试网N8hB6K/]fb!R/u c Jg%?

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

"g/`{(TF.K0　　跨职能团队是敏捷开发提出的团队模型（自组织是跨职能的产物，下面会看到），通过消除部门分割，来解决上面的两大难题。51Testing软件测试网)R4l7]B*ZT;Jp7T

{.y#tn1|9WPMI:Y qk0　　直接方案

　　直接方案是那些几乎不需要其他实践，就能直接使用的方案，虽然他们也有一些先决条件。51Testing软件测试网8B+Ud \Gf

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

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

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

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

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

#]4B7s:f"f8G0　　L型代码结构可以有效降低文档量。当积木代码基本形成后，所有功能大致只有界面和业务逻辑的设计，经常一个功能只有50行代码左右，很多设计都可以因此省略。51Testing软件测试网YCIi0Z(wT `o

%Gv@7r+NMH3\%MW0　　生态方案

c3N,{bk;C2\aJA0　　生态方案多半不能直接就上，需要另外一些条件具备。51Testing软件测试网Xyx0CsT._ d8UK`"]

+Pvs5hG0　　10～20人规模的开发组内实现跨职能（项目经理可推行）

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

　　这里所说的跨职能，不是代码级别的，而是在业务接口问题上，大致有以下几种情况。51Testing软件测试网)?2M3`Ky-n'Nq B.Qe

　　一是经常有一些接口类功能，说不上来该谁做，这时候项目经理（就是10～20人的头）要协调其中一方完成，并为这方争取更多的资源（工期和人数）。51Testing软件测试网A;QC+r/c-^o!~

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

　　组织方案51Testing软件测试网 u pm+D5G5}9L

1JMx%eK0　　1、进度-质量目标的合并（研发的部门经理可推行）51Testing软件测试网;d e!WY)Gx:T

　　也就是无论是否还有开发-测试的分割，必须把进度绩效和质量绩效统一管理。51Testing软件测试网2z`7zOC

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

　　测试团队与开发团队融合51Testing软件测试网7E
s!v%lT3jswc

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

#X,vh
Vz M:wL @0　　多数自动化脚本开发团队可以编写，但是多半要配置一些脚本、写一些测试用例什么的，由测试人员执行。

　　这种模式下，对测试团队的人数要求很少。51Testing软件测试网6v5V1de_0Ry

x[ Vi8g0ipO:Xh0　　测试团队与需求团队融合51Testing软件测试网 {)W*@:W#x0J~

w:f gQ#DxU$Lsp0　　质量工作彻底交给开发团队负责，测试团队只负责业务级别的验收测试（还负责早期的需求理解和机遇需求的测试用例编写）。51Testing软件测试网8yT1pcM"_z7@-IG

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

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

　　2、市场/销售/产品/研发的跨职能（总经理/副总经理可以推行）51Testing软件测试网+t/a7tKp KnW

B8Zr)IV$d0　　简单说就是市场/销售/产品团队，要为研发的成本负责（比如销售要先扣除研发成本，再谈提成）；而研发要为销售/市场负责（比如如果销售额上升，研发团队也有一个提成）。51Testing软件测试网 MeI4|:Mpf D Tc

　　日后有机会再谈这个，很多企业都已经有成功经验了，只是都不太分享而已。51Testing软件测试网,`!A2R7V7l&^