揮發性極限編程團隊

Question

您會推薦在團隊組成變化經常的組織中實施極限編程實踐嗎？ 如果在極端的編程場景中，團隊變爲中途變動，您會推薦什麼？ 謝謝。

Answer 1

當團隊組成波動時，什麼樣的過程會起作用？至少在XP中，使用結對編程，你有一些希望，不止一個團隊成員對代碼的所有部分都有一定的瞭解。 FWIW，我沒有練習XP，我只是沒有看到這個問題是如何使用XP加劇的。

Answer 2

我會建議首先解決團隊波動的問題。如果你的辦公室首先有一個旋轉門，那麼沒有哪個流程能夠很好地工作，而且我會說使用一個更加依賴個人表現和貢獻的流程，而不是一個意圖與「如果可能的話，機器中可替換的齒輪「會使事情變得更糟。

配對編程可能適用於這樣的情況，前提是您可以將一些人保留足夠長的時間，以便他們可以將知識傳授給團隊中的新成員。然而，問題的一部分是，你不能真正練習配對編程的「一對平等」部分，你會最終陷入一個隱含的高級/初級情況，只是因爲一半的人不知道代碼足夠好。

大多數開發過程都依賴於一個相對穩定的團隊，他們很好地瞭解代碼庫。如果你沒有這些，你需要圍繞這個事實設計一個過程，你將會與那些試圖在他們努力提高生產力的同時掌握代碼庫的開發人員打交道。

Answer 3

配對編程應該有助於讓新團隊成員加快速度，並在團隊室內進行滲透通信。廣泛的開發人員和客戶測試套件應確保新團隊成員不會破壞現有功能。高代碼質量應該可以幫助他們更快找到解決方法。

話雖如此，不穩定的團隊確實是一個強大的反模式。你爲什麼首先要他們？

Answer 4

高測試覆蓋率和持續集成有助於確保新團隊成員不會破壞以前實施的內容。結對編程是我發現幫助某人熟悉項目的最快方式。在這些迭代中規劃會議，簡短迭代和追蹤速度也可以幫助新開發人員輕鬆咬住更容易管理的小件。

Answer 5

程序員配對成爲必須。工程師實踐（XP）和管理實踐（SCRUM）可以實現可持續發展。你應該強調的一個工作團隊的第一件事是把它放在一起。如果這是不可能的，編程配對就顯得更加重要！

對於瀑布，一個項目開始，人們聚集在一起，然後他們必須通過窗體，風暴，規範然後執行。一旦團隊學會如何一起工作，項目就結束了，工作團隊也被解散了。然後再次重複該過程。你看到問題了嗎？誰擁有如此多的資金以至於他們可以繼續爲團隊支付Form，Storm，Norm的費用，然後一次又一次地執行？

這就是說，每個團隊都會看到團隊成員來來去去。通過程序員配對，您可以爲團隊帶來新人，他們幾乎會立即生效。通過配對，他們將很快學習業務領域，應用程序代碼和工程實踐。

我們帶了一組4對，並增加了3對新隊。我們將所有新開發人員與經驗團隊成員配對。我們給了我們30天的時間，讓新成員加快速度。該團隊擊中了所有可交付成果。您能否將6位開發人員添加到瀑布團隊的8位開發人員團隊中？該團隊幾乎會停下來同化新的團隊成員。

底線，保持一個功能團隊在一起。如果無法做到這一點，可以有效地使用配對，以便迅速將新人帶上。