拆分開發團隊

Question

我組織團隊對產品的下一個版本進行並行開發。我被分配該任務到具體的個人分組的團隊

1. 客戶特定
2. 具體的功能

處理跨部門的問題。

想知道項目經理/領導團隊的其他方式嗎？

Answer 1

我們按照組織中特定產品對人員進行分組。每個團隊都爲特定產品編寫代碼。當產品的功能與其他產品相交時，有時他們會在該功能上進行協作。我們做了很多劃分，所以它可能。

寫出大量可重複使用的模塊。這是關鍵。

我的組織也只爲大客戶做特定於客戶的工作。

Answer 2

我對編程的堅定信仰者，我會組隊，使得一對將管理和編寫測試用例（TDD），而其他人會編寫它。我會建立一個基於相同主題的團隊。

Answer 3

1. 如果你的產品涉及多個技術的話，你可以組球隊電子樂明智
2. 技能

Answer 4

它不那麼重要了分裂的時候你怎麼做你的分裂，但也有陷阱一個你需要知道的開發團隊。

集成度決定了您擁有多少風險。碰巧分享一些圖書館的單獨軟件產品風險很小。高度集成的運行時組件帶來了更大的風險。

最壞的可能發生的情況，你可以找到自己是那裏是團隊之間的依賴關係提供一個功能，但沒有明確的所有權。例如，A隊正在B隊等待「後端服務」，但B隊認爲該服務已完成。 A隊表示該服務不符合所有要求。但是B隊已經開始轉向新功能。等等....

我已經看到了這個我們與他們的態度從字面上磨發展陷入停滯。爲了對抗這種行爲，鼓勵交叉團隊配對和共享代碼所有權。不時輪換團隊成員。確保有一位負責人將使某個功能端到端地發生。

團隊，致力於開發可重複使用的模塊通常不起作用。它是因爲一系列可疑價值和治理噩夢的模塊。最好的可重用模塊來自團隊，他們提供類似的功能並自己識別重疊。

Answer 5

的關鍵是讓每個團隊遵循相同的標準，但可以作爲獨立（分離）地工作。

如果它在你的客戶相同的代碼庫，你可能不希望分裂隊以客戶的具體需求，因爲它可能會導致變化的多個重疊。

如果功能跨系統功能（AR，安全性，報告等）區域，您可能希望按功能區域進行拆分。

其它方式分裂隊：

1. 前端（設計實現）和業務邏輯和數據庫/數據存儲
2. 新的開發和維護（更新/更JR人維護）
3. 核心功能和附加模塊（如果基於組件）