andy singleton所著的《unblock! a guide to the new continuous agile》一書為基於雲的分布式開發提供了持續交付的思路和實踐。書中講述了如何構建、測試、頻繁發布**，以及如何讓處於持續交付環境中的管理團隊、產品和企業做到持續敏捷。
\\ 關於什麼是持續敏捷、它和scrum有何不同、如何與使用者故事負責人一起使用服務矩陣擴充套件軟體開發，以及為什麼要在持續改進中使用快樂調查等話題，infoq採訪了andy。
\\infoq：為什麼你會寫一本關於新的持續敏捷的書？
\\
\\\
infoq：這本書名是\"unblock! a guide to the new continuous agile\"。你想開啟（unblock）什麼？
\\
\\\andy：如果你不能發布**，那麼你的路就不會通暢。我們試圖開啟這種障礙。這會讓你的開發更有可靠性和可擴充套件性，因為團隊或者功能的問題阻礙不了其他的人。
\
infoq：能分享下你是如何看待新的持續敏捷的嗎？比如和頻繁發布或者持續交付有什麼不同？
\\
\\\andy：持續交付是持續敏捷的最重要的基石。持續交付是構建、測試和發布**的方法。持續敏捷是基於持續交付環境中，管理團隊、產品和企業的策略。所以，我們開始從持續交付**入手，然後通過加入團隊、產品和企業相關的策略構建持續敏捷。
\
infoq：新的持續敏捷和scrum最大的不同是什麼，他們可以用到一起嗎？
\\
\\\andy：所有的敏捷方法有著相似的策略，如使用者故事、頻繁發布和提高過程的回顧。然而，scrum把大家鎖定在同乙個週期性的發布迴圈裡，並迫使他們在「多功能的團隊」中「自我組織」 ，然後為擺脫這個框框而奮戰。持續敏捷是乙個較新的、更簡單和更可擴充套件的過程，讓每個人，尤其是技術帶頭人和產品經理，用更少的儀式以最佳的速度前進。幸運的是，它很容易從scrum轉型到scrumban、看板和持續敏捷，只是去掉scrum多餘的儀式、加入一些測試層，變得更精益。我已將這個程序描繪在這本書裡。
\\ 從根本上說，敏捷過程中的多次發布比瀑布過程中的一次大發布更好，因為越多的發布，帶來越多的實踐。基於這個論點，發布越頻繁，生產率越高、壓力越低。在實踐中，如果允許開發者為每次變更做發布，他們將越來越頻繁地發布，比scrum團隊更頻繁。這使得發布更小，更容易除錯。
\\ 在一些基本理念上，新的持續敏捷與scrum就不一樣。 scrum是一套團隊管理的建議。事事都與團隊掛鉤。持續交付和持續敏捷更看重使用「技術規範」（構建、測試、部署、呈現和度量軟體的運轉）。使用雲計算，我們會有更多、更大的伺服器來採集和挖掘資料，用以提高個人的生產力。來自於提公升團隊管理的收益是有限的，而來自於自動化的收益是無限的。
\
infoq：書中描述了「服務矩陣」或「maxos」。你能解釋一下它是什麼，以及公司該如何使用它來擴充套件軟體開發嗎？
\\
\\\andy：maxos是服務矩陣（matrix of services）的縮寫。在maxos架構中，軟體拆分成多個web服務，每個服務可以分配給乙個開發團隊做持續交付。所以，數百或上千個元件可以並行地做持續交付。 maxos解決了一些巨大的、代價高昂的問題。那麼你就可以管理大型系統了，因為你沒必要搞清楚專案計畫中的全部依賴。相反，使用持續測試和整合系統，可以找到相關服務的依賴問題，並通知責任相關的團隊。這種方法的天才之處在於測試機實際上可以代替很多管理者。這是革命性的、令人興奮的變化。
\\ 我稱之為「maxos」是為了突出它與safe（dean leffingwell提出的可縮放敏捷框架）的不同。safe很幼稚、用非自動化的方法在scrum團隊之上堆砌管理，沒什麼技術含量的公司才這麼做呢。他們不能堆砌管理，得自動化起來。
\
infoq：能說說持續敏捷交付的好處嗎？
\\
\\\andy：持續敏捷消除了發布的壓力或延期發布的問題。對於經常飽受發版壓力折磨的開發團隊來說，這或許是最大的好處。對於掙扎於延期發布的管理者來說，也是件好事。我們一直處於發布狀態，這就變得容易了。我講過，在恰當的時候開啟新功能開關，把精力放在最有價值的功能上去。
\\ 當你開始啟動精益或者開發精益產品，亦或頻繁度量和調整營銷過程，你將需要持續敏捷。持續敏捷以更快的交付和適應性為競爭提供了勝機。如果競爭對手用更快的開發周期超過了你，那麼持續敏捷能幫助你趕上他們。
\\ 如果你正在構建具有很多元件的大型系統 ，持續敏捷同樣非常重要。就像《人月神話》中所說的，在過去，這麼做具有極高的成本和風險。矽谷的大公司使用持續敏捷過程（就是我說的矩陣服務——maxos）解決了這個問題。
\
infoq：你在書中說，「**審查是獲取測試最有效的方法」。能解釋一下這是什麼意思嗎？
\\
\\\andy：持續交付需要自動化測試。在發布乙個變更之前，你要通過一系列的自動化測試層去執行這個變更。開發者必須為此寫測試。一些開發經理試圖威逼他們的開發人員去寫測試。這種方式是沒用的。強制性的**審查是最可靠的獲取測試方法。你可以讓評審人員檢查自動化測試，這些測試應該和新功能或者缺陷的修改一同提供。如果相關的自動化測試沒有覆蓋這次變更，評審人員可以拒絕並退回提交。這樣的方式總會取得立竿見影的效果。
\\ 我還注意到，在成功的持續交付工作中，開發者決定了發布。開發者必須測試變更，然後按下按鈕啟動發布過程。他們不能只是將變更發給質量保障的人並期待他們去完成測試、做出發布決定。這種責任制度讓開發者有了強大的動力去構建良好的測試和測試框架。這是在**評審之上，為良好的自動化測試的提供了第二層激勵。
\
infoq：在assembla，你用故事負責人代替產品負責人。你為什麼採取這種方式，兩者有何不同？
\\
\\\andy：故事負責人不能只是規劃功能，然後把它丟給設計和開發就不管了。故事負責人得和開發人員一起完成設計、beta測試、推出新功能和度量反響。工作變多了，但功能變好了。我覺得為了爭取實現更好的功能，以及更加重視每個功能的使用資料，故事負責人是必要的角色。
\
infoq：能否闡述一下團隊如何利用快樂調查持續提高嗎？你提到這比回顧更好，能解釋一下為什麼嗎？
\\
\andy：我們希望可以不斷地改進過程。回顧會議旨在幫助過程改進，通過提問：「最近發布的過程中哪些做得很好？哪些做得不行？未來的幾個星期我們應該怎麼改進？」這是偉大的理論，但在實踐中，它往往令人乏味和痛苦。我不知道為什麼。從henrik kniberg和jeff sutherland那我們學到了「快樂調查」的格式，這讓我們拿到更好的效果。它的問題略有不同：「現在感覺**做得最好？現在感覺**做得最差？改進什麼能使你快樂起來？」你會想到這變成了無關緊要的個人問題，但在實踐中，它會指引提高生產力的實際行動。而且，我們可以在任何時間做這件事情，無需按照發布計畫來。
andy singleton是assembla創始人, 這是一家致力於幫助分布式軟體團隊一起工作的saas公司。他此前創辦過一家做企業專案管理系統軟體公司powersteering，以及一家做電子商務顧問的公司cambridge interactive。在2023年，他曾使用一屋子的單板計算機去執行可以發現完美學習引數的「元遺傳演算法」，檢視揭開進化和創新的奧秘。他持續學習創新方法，自哈佛本科畢業後，發布了20多款軟體和資訊服務產品。
\\\\
檢視英文原文：q\u0026amp;a with andy singleton on unblock! a guide to the new continuous agile
\\ 感謝夏雪對本文的審校。
\\
訪談 關於持續敏捷交付與服務矩陣
andy singleton所著的 unblock a guide to the new continuous agile 一書為基於雲的分布式開發提供了持續交付的思路和實踐。書中講述了如何構建 測試 頻繁發布 以及如何讓處於持續交付環境中的管理團隊 產品和企業做到持續敏捷。關於什麼是持續敏捷 它和...
CI CD 持續交付
軟體開發的最終目標是快速，高質量的交付客戶價值。行業實踐證明，持續整合 continuous integration 持續交付 continuous delivery 是微服務交付的最佳實踐。ci 開發人員將 提交到版本控制系統 gitlab 以後，將後續的軟體構建，單元測試，整合測試 etc.這些...
持續整合 持續交付 持續部署
持續整合 持續整合強調開發人員提交了新 之後，立刻進行構建 單元 測試。根據測試結果，我們可以確定新 和原有 能否正確地整合在一起。持續交付 持續交付在持續整合的基礎上，將整合後的 部署到更貼近真實執行環境的 類生產環境 production like environments 中。比如，我們完成單...