多團隊敏捷開發的組織架構和協作模式（續）

在部落格中，我介紹了在實踐中多團隊敏捷開發的組織架構和協作模式。這裡在補充介紹一下「技術專家」團隊的一些特別做法。

這裡的技術專家團隊可以由內部工程師組成，但一些場合也可以考量外部的技術資源。

我們在實踐中有這樣的場景：系統處在試執行中，效能的問題比較突出，但客戶使用後的新需求不斷提出，所有人的精力都在新需求的實現上，對效能的優化沒有足夠的熱情，或者說已經「疲」了，所有的頭腦風暴已經不能得到有價值的反饋。

為此，我們嘗試了外包。我們的目標是在本次sprint使客戶感受到效能的提公升，我們是這麼做的：

1.找出客戶最抱怨的三種頁面（登入、統計、詳單）以及**的首頁作為本次優化的需求

2.在我們以前合作的承包商中，選擇技術最優的（客觀的說，並不是合作最好的）

3.和承包商溝通出乙個合作模式：承包商負責找出瓶頸，提出方案，測試並提交測試報告以證明方案的可行性。和承包商的溝通和評定，是由架構師團隊來完成，換句話說，架構師團隊是承包商的po，負責技術需求的提出和驗收。

4.根據承包商提出的方案，結合sprint的週期，選擇最後的方案。我們的原則是：改動量最小，效果相對最明顯。

5.由team進行**修改，由承包商進行技術支援。承包商需要有乙個人和我們一起工作。

我們發現：其實承包商不一定可以提出特別讓人「眼前一亮」的方案，但卻找出了一些明顯的常識性的問題，這些問題很可能就是進度緊的時候倉促寫的，但再沒有人進行重構，更確切的說是沒有人有熱情進行重構。