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