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