敏捷思想中有一條原則指導我們進行過程改進：每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然後相應地對自己的行為進行調整。由於很多不確定性因素會導致計畫失效，比如專案成員增減、技術應用效果、使用者需求的改變、競爭者對我們的影響等都會讓我們作出不同的反應。敏捷不是基於預定義的工作方式，而是基於經驗性（empirical）的方式，對以上這些變化，敏捷團隊通過不斷的反省調整來保持團隊的敏捷性。敏捷為我們提供了過程改進相關的工程實踐、工作流程和工具。
1. 敏捷中的過程改進實踐
與cmmi所提供的重量級解決方案不同，敏捷方法為我們提供了針對過程改進的很多簡單但又實用的工程實踐，這裡列舉4個作為參考：
（1）五個為什麼
5個為什麼也是敏捷領域比較推崇的乙個過程改進實踐，原理很簡單但確實很有效。所謂為什麼，也就是對乙個問題點連續以5個「為什麼」來自問，以追究其根本原因。當然，這裡的數字5知識一種虛數，使用時不限定只做5次為什麼的**，主要是必須找到根本原因為止。5個為什麼的關鍵在於鼓勵解決問題的人從結果著手，沿著因果關係鏈條，直至找出原有問題的根本原因（如下圖）。
（2）學習矩陣
學習矩陣相對比較少用，但在有些場景下也是我們可以用來進行靈感觸發的有效工具。如下圖中，針對分布式協作下的團隊開發，我們首先總結做得好的和做得不好的方面，再看看有沒有新的想法，如果實在不行我們也可以看看找誰幫忙，這些過程性成果都可以通過類似的學習矩陣進行細化和明確。
（3）頭腦風暴
頭腦風暴（brain storming）是我們經常使用的一種觸發靈感的活動，下面是需求和ui介面匹配問題團隊成員之間一次簡單的頭腦風暴，通過討論大家就工作流程做了一項改進：
開發人員：現在由於開發周期比較短，產品經理在沒有完全梳理清楚產品需求的情況下就召開需求評審會議，導致後期開發過程**現很多問題，返工的現象比較嚴重。
技術管理者：我們可以開展二次評審，也就是說在面向所有開發人員的正式需求評審之前，先可以找部分技術代表作第一次評審，通過第一次評審對需求存在的問題先修訂之後再召集所有人開第二次評審
產品經理：那我這邊在產品初稿出來之後會找前後端的技術負責人先碰下
（4）親和圖法
親和圖（kj法/affinity diagram），把大量收集到的事實、意見或構思等語言資料，按其相互親和性（相近性）歸納整理這些資料，使問題明確起來，求得統一認識和協調工作，以利於問題解決的一種方法。下圖就是親和圖的一種表現形式，通過對團隊成員提出的想法從「繼續保持」、「停止」』和「嘗試」者三個型別進行歸類。
2. 敏捷中的過程改進工具
敏捷的各種方法中存在一些工具可以用於幫忙我們實施過程改進：
（1）燃盡圖和燃燒圖
燃盡圖（burndown chart）和燃燒圖（burnup chart）來自於scrum，用於作為專門的工具對sprint執行過程進行監控。burndown chart（見下圖a）關注於剩餘功能，而burnup chart（見下圖b）關注已完成功能。圖中我們在burnup chart中新增了一條異常情況下的曲線（下圖b中位於下方的曲線），可以看到這種異常很大程度上源於使用了water-scrum-fall模式，在sprint的前一半時間內，團隊並沒有產出任何可交付成果導致後半程發力不足。
（2）價值流圖
價值流圖**於tps，tps 的核心思想是，工作流中有以下三種製造約束的浪費必須要消除掉。你不得不做的事情中，有沒有哪些是無用的或多餘的？這類事情就屬於徒勞，就是你不得不做，卻不創造價值的事情。有沒有一些時候，你只是閒坐著不能開工，焦急地等待某人給你答覆？這就是不均衡，工作總是一陣多一陣少。是不是還有些時候，你不得不加班加點，因為你被要求完成比你所能承受的大得多的工作量？這就是超負荷，被要求做到不合理或不可能的事情。價值流圖的作用就是通過視覺化的效果讓我們能夠發現這些問題，從而通過拉動式系統等方式解決這些問題以達到持續改進的目的。關於價值流圖的詳細討論可以參考《精益之識別和消除研發過程中浪費的思路和模式》一文中的內容。
（3）累積流量圖
管道理論的一大話題是我們需要測量並管理管道中的流量，而在看板方法中，累積流量圖（cumulative flow diagram，cfd）為我們提供了這方面支援。下圖就是一張累計流圖示例，可以看到測試所對應的條帶在變寬，這就告訴我們測試可能正在成為整個工作流中的一項瓶頸。圖中還可以新增一些額外的線，用來表示平均到達速度（arrival rate，每天新增的工作項的數目）和平均工作存量（inventory，工作流中工作項的總數），並展示平均交付時間（lead time，每個工作項在系統中存在的時間）。
使用cfd 管理系統流量的關鍵在於尋找那些能夠表明存在問題的特徵。看板可以告訴你今天你的工作流中**存在不均衡，並且幫助你通過新增在製品上限的方法來管理每一天的工作流。而cfd 的作用則是讓你能夠看到「在乙個時間段內，你的整個流程的表現如何」，這樣你就可以採取措施來找出並修復那些長期的問題。
結合上述限制在製品上限的方法，就可以通過cfd實驗在製品上限的值並管理系統流量。乙個軟體開發的過程一開始可能處於不穩定的狀態，通過對開發、測試等各個環節設定不同的在製品上限值，並觀察對應的平均交付時間，找到基於現有資源的最合適的在製品上限值組合，確保開發過程的穩定性。
我出版了《系統架構設計：程式設計師向架構師轉型之路》、《向技術管理者轉型：軟體開發人員跨越行業、技術、管理的轉型思維與實踐》、《微服務設計原理與架構》、《微服務架構實戰》等書籍，並翻譯有《深入rabbitmq》和《spring5響應式程式設計實戰》，歡迎交流。
敏捷實踐的一些過程項
上次說到了我們在專案中 敏捷溝通 的實踐，順著再補充幾點專案過程中的敏捷實踐。任務認領，我們沒有完全實施，現在是利用開發經理對工程師能力的了解安排任務。任務認領的假設是 每個人都是足夠聰明和職業的，應該被安排在最合適的工作上，所以最了解自己能力的就是自己，於是應該每個人制定自己的工作計畫，其他人幫著...
敏捷測試的方法和實踐
有一次，當開發人員完成當前sprint 任務的 之後，測試人員 開發人員和產品經理一起來瀏覽產品 從頭到尾走一遍，產品經理發現了問題，認為需要對功能進行比較大的修改。這時開發人員估計需要兩天時間才能完成 但測試人員反對這樣做，我們本來只有5天測試時間，加上這次新做的功能比較多 開發 質量不高，驗收測...
敏捷測試的方法和實踐
有一次，當開發人員完成當前sprint 任務的 之後，測試人員 開發人員和產品經理一起來瀏覽產品 從頭到尾走一遍，產品經理發現了問題，認為需要對功能進行比較大的修改。這時開發人員估計需要兩天時間才能完成 但測試人員反對這樣做，我們本來只有5天測試時間，加上這次新做的功能比較多 開發 質量不高，驗收測...