問題
問：傳統(tǒng)的團(tuán)隊(duì)如何轉(zhuǎn)化為敏捷團(tuán)隊(duì)（步驟，要點(diǎn)，注意事項(xiàng)等）？
問：如果使用敏捷開發(fā)，在公司組織架構(gòu)上有沒有什么建議？
分析
在談到何為敏捷團(tuán)隊(duì)之前，先看看傳統(tǒng)團(tuán)隊(duì)的問題，不要把團(tuán)隊(duì)轉(zhuǎn)化完了，問題還存在；換言之，解決問題是目標(biāo)，轉(zhuǎn)化團(tuán)隊(duì)是手段。
1、各部門打架嚴(yán)重
來自于分工中的灰色地帶 / 各自目標(biāo)和績效的不一致。
典型的是開發(fā)/測試團(tuán)隊(duì)，擴(kuò)展而言，還包括市場/銷售團(tuán)隊(duì)。
后兩者也很關(guān)鍵，很多時(shí)候開發(fā)和測試團(tuán)隊(duì)和諧了，聯(lián)合起來和銷售團(tuán)隊(duì)打架，公司的整體效率仍然上不去。
不過，如果沒有在市場/銷售團(tuán)隊(duì)的工作經(jīng)驗(yàn)，或管理他們的經(jīng)驗(yàn)，談?wù)摵瓦^問與他們跨職能的難度很大。但這不等于這個(gè)問題不存在，可以請公司更上層的人去關(guān)注這個(gè)問題。本博客未來會提到市場/銷售/開發(fā)團(tuán)隊(duì)的跨職能問題。
2、各部門流程/文檔繁雜
為了解決打架問題，需要流程和文檔來規(guī)范接口。
常常被過度寫作的需求文檔和設(shè)計(jì)文檔，就是因?yàn)橐邕^多個(gè)部門，才需要被“簽字”“確認(rèn)”“協(xié)調(diào)一致”，所以其寫作的水平，往往超過“以能編寫出軟件為準(zhǔn)”，而是達(dá)到“能交給下一個(gè)部門，讓他們看完以后能編寫出軟件”為準(zhǔn)。
跨職能團(tuán)隊(duì)是敏捷開發(fā)提出的團(tuán)隊(duì)模型（自組織是跨職能的產(chǎn)物，下面會看到），通過消除部門分割，來解決上面的兩大難題。
直接方案
直接方案是那些幾乎不需要其他實(shí)踐，就能直接使用的方案，雖然他們也有一些先決條件。
世界上沒有無條件的事，也沒有生下來就有條件的人，所以很容易把喜歡找借口勝過方法的人卡住。如果下面這個(gè)事情仍然覺得很難辦，那么多半還沒有到談?wù)搱F(tuán)隊(duì)轉(zhuǎn)型的階段，請繼續(xù)努力吧！
3～5人規(guī)模的小組內(nèi)實(shí)現(xiàn)跨職能（小組長可推行）
這個(gè)是無需行政授權(quán)，小組長就能做的事情。
本人非常推崇通過1-3-9團(tuán)隊(duì)形成L型代碼結(jié)構(gòu)（文后有鏈接），局部的“部門”打架和文檔問題迎刃而解。
139團(tuán)隊(duì)中，整個(gè)小組的目標(biāo)是一致的，而且成敗都由師傅負(fù)責(zé)，因此他會成為跨人員的橋梁，把整個(gè)團(tuán)隊(duì)的事情當(dāng)作自己的事情，解決個(gè)人的打架問題。
L型代碼結(jié)構(gòu)可以有效降低文檔量。當(dāng)積木代碼基本形成后，所有功能大致只有界面和業(yè)務(wù)邏輯的設(shè)計(jì)，經(jīng)常一個(gè)功能只有50行代碼左右，很多設(shè)計(jì)都可以因此省略。
生態(tài)方案
生態(tài)方案多半不能直接就上，需要另外一些條件具備。
10～20人規(guī)模的開發(fā)組內(nèi)實(shí)現(xiàn)跨職能（項(xiàng)目經(jīng)理可推行）
實(shí)際上沒有辦法讓10～20人可以互相修改別人的代碼，但在這個(gè)規(guī)模上，合作的需求更高，代碼的復(fù)用利益更大，跨職能勢在必行。
這里所說的跨職能，不是代碼級別的，而是在業(yè)務(wù)接口問題上，大致有以下幾種情況。
一是經(jīng)常有一些接口類功能，說不上來該誰做，這時(shí)候項(xiàng)目經(jīng)理（就是10～20人的頭）要協(xié)調(diào)其中一方完成，并為這方爭取更多的資源（工期和人數(shù)）。
這里多少要建立團(tuán)隊(duì)可以提請要人的機(jī)制，而且項(xiàng)目經(jīng)理能臨時(shí)分配人員，比如把小李交給老王那組工作一段時(shí)間之類的。在139團(tuán)隊(duì)里邊這個(gè)相對好辦一些，如果是1個(gè)人管理12個(gè)人，就很難辦。
組織方案
1、進(jìn)度-質(zhì)量目標(biāo)的合并（研發(fā)的部門經(jīng)理可推行）
也就是無論是否還有開發(fā)-測試的分割，必須把進(jìn)度績效和質(zhì)量績效統(tǒng)一管理。
一個(gè)項(xiàng)目延期了，測試也有責(zé)任；一個(gè)項(xiàng)目質(zhì)量差，開發(fā)也有責(zé)任。結(jié)果大致會變成：
測試團(tuán)隊(duì)與開發(fā)團(tuán)隊(duì)融合
一般是測試團(tuán)隊(duì)分解到開發(fā)組，從事自動化測試的執(zhí)行工作。
多數(shù)自動化腳本開發(fā)團(tuán)隊(duì)可以編寫，但是多半要配置一些腳本、寫一些測試用例什么的，由測試人員執(zhí)行。
這種模式下，對測試團(tuán)隊(duì)的人數(shù)要求很少。
測試團(tuán)隊(duì)與需求團(tuán)隊(duì)融合
質(zhì)量工作徹底交給開發(fā)團(tuán)隊(duì)負(fù)責(zé)，測試團(tuán)隊(duì)只負(fù)責(zé)業(yè)務(wù)級別的驗(yàn)收測試（還負(fù)責(zé)早期的需求理解和機(jī)遇需求的測試用例編寫）。
開發(fā)團(tuán)隊(duì)分化出一些人負(fù)責(zé)執(zhí)行測試，這些人的數(shù)量一樣要求很少；開發(fā)團(tuán)隊(duì)同時(shí)對進(jìn)度和質(zhì)量負(fù)責(zé)。
這兩種方法都不容易做到，而且還有無窮無盡的問題，但告訴大家一個(gè)方法來解決：那就是每當(dāng)自己心里想問：“可是，怎么……呢？”，自己要先想三個(gè)答案，然后再問；有時(shí)候會發(fā)現(xiàn)不用問了，答案已經(jīng)被自己說出來了。
2、市場/銷售/產(chǎn)品/研發(fā)的跨職能（總經(jīng)理/副總經(jīng)理可以推行）
簡單說就是市場/銷售/產(chǎn)品團(tuán)隊(duì)，要為研發(fā)的成本負(fù)責(zé)（比如銷售要先扣除研發(fā)成本，再談提成）；而研發(fā)要為銷售/市場負(fù)責(zé)（比如如果銷售額上升，研發(fā)團(tuán)隊(duì)也有一個(gè)提成）。
日后有機(jī)會再談這個(gè)，很多企業(yè)都已經(jīng)有成功經(jīng)驗(yàn)了，只是都不太分享而已。