敏捷移交

我在敏捷專案中看到最常見的問題之一，是如何處理移交給其他團隊。如果有一個開發團隊離開並將支援移交給支援團隊，當敏捷專案往往產生的文件比計畫驅動流程少得多時，他們該如何應對？

要考慮的一件事是問問自己，替代流程產生了多少有用的文件。我注意到，產生強制性文件的文件流程通常會產生沒有什麼幫助的東西，並且在最後期限的壓力下往往無法保持最新。在許多方面，敏捷方法偏好數量較少但品質較高的文件。

敏捷專案偏好面對面的溝通，因此我遇到的常見方法是在開發團隊離開之前，讓支援/維護團隊的成員與開發團隊合作一段時間。透過讓兩個團隊同時參與，開發團隊可以在他們操作系統時，向維護團隊教授系統。我遇到過許多關於這個主題的變體。

• 一個團隊在每個迭代中輪換一或兩個人，在兩或三個月內逐漸取代整個團隊。
• 當我們將專案轉移到印度時，我們確保一位在岸開發人員至少在岸外待幾個月，與新團隊合作
• 一個團隊在開發的最後一個月將一位支援人員帶入團隊。

最後一個例子來自我的同事喬納森·拉斯穆森，他指出在開發結束時引入一些支援團隊人員的另一個好處是，它可以建立關係，讓部署新系統變得容易得多。開發與營運之間的溝通常常很緊張；開發人員經常忽略營運的需求。讓營運人員成為團隊的一員一段時間，有助於雙向溝通。

這讓我回到文件。Jonathan 提及的一件事是，他們讓支援人員擔任系統文件的客戶。結果，他們製作出比他們通常看到的更好的文件。

Jonathan 後來帶著一個全新的團隊回來進行一些加強時，必須親自體驗自己的狗食。他們發現文件非常有幫助，因為它是根據需求編寫的，而不是根據流程。品質勝過於數量。了解系統的另一個大幫助是 XP 大量的自動化測試，正如 XPers 從不厭倦地指出的，這本身就是文件的一種重要形式。