不同於我們大多數討論持續整合(Continuous Integration)是以工具為主的議題,在敏捷開發中持續整合更接近於團隊之間協作的議題。這是因為我們希望能夠快速迭代,也因此必須持續的將團隊的產出整合在一起。
Kanban
看板是軟體開發常見的一種方式,然而在最先提出這個概念的豐田汽車(Toyota)的概念中,看板是一種 Just in Time(及時)的概念,簡單來說就是當有需求的時候就會進行生產,只需要輪胎就只會製造輪胎。
同時也是一種 Pull System(拉動系統)當我們消化完任務後,會將任務從 Product Backlog(產品積壓)的看板中提取到團隊中進行消化,然而在許多情況下我們都變成了 Push System(推動系統)也就是因為產品需求的累積而將任務往團隊中推送,最後不斷的累積未完成的任務。
在敏捷中,假設一個功能被分為三個 PBI(Product Backlog Item)並且只在衝刺中完成(Done)了兩個,然而有新的需求被放進來後佔用了更高的優先級,那麼我們可以重新的調整將重要的任務提前。
合作
在持續整合中,我們希望消除獨立的工作。也就是每個人分配一個功能,然後不斷的實作直到結束為止。我們更希望是團隊同時進行工作,也就是大家一起協力完成一個功能,正因如此才會採取 Pair Programming(結隊程式設計)這類方式。
在合作之中,我們希望有問題「馬上講出來」並且「透過程式碼溝通」來了解不同團隊之間正在做怎樣的任務,我們也不去「管理依賴」因此每個團隊之間往往會需要互相幫助、協助對方部分任務等等的情況去進行,相較管理依賴更重視「消除限制」也就是我們不需要等待其他人實現任何東西才能繼續工作,而是透過溝通的方式協調要進行的任務,當其他團隊無法立刻解決時,我們的團隊也能協助解決。