如果我們有多個敏捷團隊在同一個代碼庫上工作時，如何將彼此之間代碼互相沖突的風險最小化？如何確保每個迭代結束時擁有一個干凈的、可發(fā)布的軟件版本？本文講述了關于如何在敏捷的環(huán)境中與多個團隊共同進行版本控制工作的實例——這正是我們在《Scrum and XP from the Trenches》中描述的公司所采納的方式。
本文并非專為版本控制專家所寫，實際上這樣的專家在本文中找不到新東西。本文是為我們這些希望進行簡單、有效的協(xié)作的人所準備的。任何直接參與敏捷軟件開發(fā)的人，無論他承擔何種角色，都有可能對其感興趣——每個人都會用到分支和合并，而不只是配置經(jīng)理。
介紹
本文講述了關于如何在敏捷的環(huán)境中與多個團隊共同進行版本控制工作的實例。我假定你已經(jīng)熟悉了Scrum的基本元素、XP方法和任務板。這些方式不是我發(fā)明的，它們是基于“主線（mainline）模型”或“穩(wěn)定主干（stable trunk）模式”。想閱讀更多信息請查看引用部分。
撰寫本文，是因為我一直在遇到需要類似內容的團隊。許多團隊在理解了模型之后，似乎非常喜歡這些模型。它也正是我們在《Scrum and XP from the Trenches》中描述的公司所采納的方式。它真的可以幫助我們以更敏捷的方式來開發(fā)和發(fā)布軟件。通過以易于閱讀的方式來描述模型，也許我不再需要反復在白板前做解釋了。:o)
注意這只是眾多模式中的一種，不是“銀彈“。如果你決定采用該模型，也許你需要做出一些變更來適應你自己的特定上下文。
目標
在多個團隊構成的敏捷環(huán)境中，版本控制模型必須達成以下目標：
快速失敗
代碼沖突和集成問題應該可以被迅速發(fā)現(xiàn)。
經(jīng)常修復小問題要勝過不常修復大問題。
一直可發(fā)布
即使經(jīng)歷了一個混亂的Sprint，也要保證至少有些可以發(fā)布的內容。
簡單
所有的團隊成員每天都會使用這些模式，所以相關規(guī)則和程序必須要簡單明了。
單頁總結（對于掛在墻上的內容）
如果該圖讓你覺得很迷惑，別著急，閱讀本文即可。如果其中的理念對你來說很明顯，讀讀本文也無妨。
文章來源：中國項目管理資源網(wǎng)
|
Leadge.com首頁 > 知識庫 
