敏捷開發模式下，如何進行質量管理敏捷開發並不只是一個“速度遊戲”，而是一個強調敏捷的“質量遊戲”。在敏捷開發過程中，如果只滿足了進度而忽視了質量，最終會影響專案的成功。越來越多的企業希望採用敏捷開發模式，但卻困於沒有把握，缺乏相應的質量管理方法。如何在敏捷開發模式下進行質量管理，達到質量與效率的雙贏呢，不妨試試本文的方法。
我們今天可以想一些與眾不同的點子，然後我們可以很快就看到效果，因為我們可以很快把它上線了，然後可以去驗證，如果不對就下線，如果還有改進餘地，下個星期再去改它。這是一個能夠持續實現你的想法的過程。
傳統的開發流程採用瀑布式開發，從設計到編碼，從測試到交付，每個階段都必須全部完成，才能進入下一階段。而在敏捷開發中，軟體專案的構建被切分成多個子專案，各個子專案的成果都經過測試，具備整合和可執行的特徵。
“敏捷開發”是網際網路產品開發的典型方法論，是一種以人為核心、迭代、循序漸進的開發方法，允許有所不足，不斷試錯，在持續迭代中完善產品。
敏捷開發有兩個點，一個“微”，一個“快”。
“微”是指從小處著眼，微創新。可能你覺得是一個不起眼的點，但是使用者可能覺得很重要”。從細微的使用者需求入手，貼近使用者心理，在使用者參與和反饋中逐步改進。
“快”是指快速迭代。“天下武功，唯快不破”。只有快速地對消費者需求做出反應，產品才更容易貼近消費者。
近年來，越來越多團隊開始探討如何進行敏捷規模化，提出了很多有效的框架，都是基於精益和敏捷的理念，在這個過程中透過系統思考產品開發流，讓它形成一套完整有效的方法，進行整體的最佳化。公司有廣泛而深入的精益和敏捷的理念來支撐，才能從區域性最佳化上升到整體最佳化，才能走的更加長遠健康。
敏捷模式下的質量管理更具有挑戰性。
在推動敏捷開發的同時，如何降低專案管理成本，提高研發人員工作效率，保證專案交付質量，變得日益重要。在敏捷開發中，衡量過程質量一直以來沒有一個廣泛的方法，在推廣敏捷開發的過程中，總結歸納了專案過程中的常見問題，彙總了一套敏捷開發過程質量判斷方案。這種方法用明確的資料從各個維度來說明一個迭代的質量問題，長期還可以看出一個專案多個迭代之間的質量變化趨勢，如果多個專案同時進行，也可以輕鬆對比出各個專案的迭代質量優劣和質量發展趨勢。
以一個迭代為統計單元，每個迭代中的story完成情況和bug解決情況從以下6個角度，綜合考慮了時效性和完成質量。
評價功能開發是否按時並達到質量基礎要求完成，使用“story延期率”和“story打回率”兩個指標，評價在功能開發過程中的時效和質量。
① Story 延期率：統計功能是否按時提測，以實際提測時間（story到“開發完成”狀態）與story的“計劃提測日期”欄位中的時間對比，若晚於計劃時間，那麼story即標記為延期提測；
② Story 打回率：統計story開發完成提測後能否滿足提測標準，以冒煙測試用例的滿足情況為準，如果測試驗證未滿足則會將story打回開發狀態，同一個story如果被多次打回，打回次數按照實際記錄，也就是說打回率會急劇增加；
評價在測試過程中所發現的問題是否按時解決並達到質量要求，使用“Bug打回率”、“Bug不收斂率”、“Bug引發率”和“Bug 重啟率”四個維度，分別介紹如下。
④ Bug 不收斂率：測試提出的bug未按照解決時效要求修復的，例如，解決時效要求：P0:2小時內未修復視為不收斂；P1:半天未修復視為不收斂；P2：一個工作日內未修復視為不收斂；P3，P4（必修）：2個工作日內不修複視為不收斂；
⑤ Bug 引發率：是指開發人員在解決一個bug時，引起了其他的bug；
⑥ Bug 重啟率：已經關閉的bug在開發人員解決問題的過程中或者程式碼部署的誤操作等導致不過重新出現。
在考慮各個指標分值佔比時，從各個指標的意義、影響等方面綜合考慮，6個維度指標優先順序從高至低排列為：story延期率，story打回率，bug打回率，bug引發率，bug不收斂率，bug重啟率。story延期率分值佔比最高，因為story如果延期提測，那麼後面的工作將整體受影響，並且可能會導致測試人員的工作安排衝突。
以100分為總分，各個指標劃分一定的分值，輸入sprint結束後6個維度的質量統計資料，按照下面的積分模型，計算出這個sprint的過程質量總分。
敏捷開發的核心就是小版本迭代，快速出產品，所以專案一般會延續多個版本。所以專案過程質量可以在每個sprint結束後均有對應的質量資料輸出，經過一系列迭代後，可以看出這個專案的質量趨勢。如果同期有多個專案在進行，那麼也可以透過質量資料的對比，對比出各個專案的質量優劣，同時輔以圖表來直觀分析對比。
例如，同一階段有3個專案在進行，同一個時間這3個專案的迭代質量和質量波動幅度資料如下，那麼按照質量均分和波動幅度使用柱狀圖進行排序，各個專案的對比情況立刻見分曉。
對於多個專案的質量對比，採取專案質量平均分的方式，以及專案質量多個迭代版本的質量波動資料來表示。
質量平均分採取專案從第一個迭代至當前迭代的質量分數的平均值，代表專案截止當前的質量平均水平；
質量波動資料採取基於截止當前的迭代質量分數計算方差，資料越小，說明質量波動越小。
多個專案並行時，從質量均分和質量波動資料兩個維度分別對比，同一時間將每個專案標記在一個二維象限（象限的質量均分和質量波動資料兩個維度的分割值可以視具體的專案情況而定，例如採用多個專案這兩個維度的平均值）中，專案質量以及波動情況即顯而易見，在“質量好，波動小”到“質量差，波動大”之間一目瞭然。
以上介紹的質量判斷方案需要有一定的工具支撐，我們使用了JIRA進行專案管理，管理需求和開發過程以及bug，story的計劃提測時間和打回次數可以進行記錄，在迭代結束後只要花很少的時間就可以進行快速得統計，迭代質量資料也可以呈現出來。專案經理在很短時間內就可以統計出專案的質量分數並進行後續分析。
好的研發工具可以簡化質量統計，質量統計方案在實施過程中，往往需要配合組織架構、流程、文化建設等多方面，才能達到有效推動改進迭代質量。
敏捷開發模式下，如何進行質量管理敏捷開發並不只是一個“速度遊戲”，而是一個強調敏捷的“質量遊戲”。在敏捷開發過程中，如果只滿足了進度而忽視了質量，最終會影響專案的成功。越來越多的企業希望採用敏捷開發模式，但卻困於沒有把握，缺乏相應的質量管理方法。如何在敏捷開發模式下進行質量管理，達到質量與效率的雙贏呢，不妨試試本文的方法。
我們今天可以想一些與眾不同的點子，然後我們可以很快就看到效果，因為我們可以很快把它上線了，然後可以去驗證，如果不對就下線，如果還有改進餘地，下個星期再去改它。這是一個能夠持續實現你的想法的過程。
什麼是敏捷開發傳統的開發流程採用瀑布式開發，從設計到編碼，從測試到交付，每個階段都必須全部完成，才能進入下一階段。而在敏捷開發中，軟體專案的構建被切分成多個子專案，各個子專案的成果都經過測試，具備整合和可執行的特徵。
“敏捷開發”是網際網路產品開發的典型方法論，是一種以人為核心、迭代、循序漸進的開發方法，允許有所不足，不斷試錯，在持續迭代中完善產品。
敏捷開發有兩個點，一個“微”，一個“快”。
“微”是指從小處著眼，微創新。可能你覺得是一個不起眼的點，但是使用者可能覺得很重要”。從細微的使用者需求入手，貼近使用者心理，在使用者參與和反饋中逐步改進。
360安全衛士當年只是一個安全防護產品，後來也成了新興的網際網路巨頭。“快”是指快速迭代。“天下武功，唯快不破”。只有快速地對消費者需求做出反應，產品才更容易貼近消費者。
Zynga 遊戲公司每週對遊戲進行數次更新。小米MIUI系統堅持每週迭代。敏捷開發質量判斷方案近年來，越來越多團隊開始探討如何進行敏捷規模化，提出了很多有效的框架，都是基於精益和敏捷的理念，在這個過程中透過系統思考產品開發流，讓它形成一套完整有效的方法，進行整體的最佳化。公司有廣泛而深入的精益和敏捷的理念來支撐，才能從區域性最佳化上升到整體最佳化，才能走的更加長遠健康。
敏捷模式下的質量管理更具有挑戰性。
在推動敏捷開發的同時，如何降低專案管理成本，提高研發人員工作效率，保證專案交付質量，變得日益重要。在敏捷開發中，衡量過程質量一直以來沒有一個廣泛的方法，在推廣敏捷開發的過程中，總結歸納了專案過程中的常見問題，彙總了一套敏捷開發過程質量判斷方案。這種方法用明確的資料從各個維度來說明一個迭代的質量問題，長期還可以看出一個專案多個迭代之間的質量變化趨勢，如果多個專案同時進行，也可以輕鬆對比出各個專案的迭代質量優劣和質量發展趨勢。
以一個迭代為統計單元，每個迭代中的story完成情況和bug解決情況從以下6個角度，綜合考慮了時效性和完成質量。
評價功能開發是否按時並達到質量基礎要求完成，使用“story延期率”和“story打回率”兩個指標，評價在功能開發過程中的時效和質量。
① Story 延期率：統計功能是否按時提測，以實際提測時間（story到“開發完成”狀態）與story的“計劃提測日期”欄位中的時間對比，若晚於計劃時間，那麼story即標記為延期提測；
② Story 打回率：統計story開發完成提測後能否滿足提測標準，以冒煙測試用例的滿足情況為準，如果測試驗證未滿足則會將story打回開發狀態，同一個story如果被多次打回，打回次數按照實際記錄，也就是說打回率會急劇增加；
評價在測試過程中所發現的問題是否按時解決並達到質量要求，使用“Bug打回率”、“Bug不收斂率”、“Bug引發率”和“Bug 重啟率”四個維度，分別介紹如下。
④ Bug 不收斂率：測試提出的bug未按照解決時效要求修復的，例如，解決時效要求：P0:2小時內未修復視為不收斂；P1:半天未修復視為不收斂；P2：一個工作日內未修復視為不收斂；P3，P4（必修）：2個工作日內不修複視為不收斂；
⑤ Bug 引發率：是指開發人員在解決一個bug時，引起了其他的bug；
⑥ Bug 重啟率：已經關閉的bug在開發人員解決問題的過程中或者程式碼部署的誤操作等導致不過重新出現。
在考慮各個指標分值佔比時，從各個指標的意義、影響等方面綜合考慮，6個維度指標優先順序從高至低排列為：story延期率，story打回率，bug打回率，bug引發率，bug不收斂率，bug重啟率。story延期率分值佔比最高，因為story如果延期提測，那麼後面的工作將整體受影響，並且可能會導致測試人員的工作安排衝突。
以100分為總分，各個指標劃分一定的分值，輸入sprint結束後6個維度的質量統計資料，按照下面的積分模型，計算出這個sprint的過程質量總分。
敏捷開發的核心就是小版本迭代，快速出產品，所以專案一般會延續多個版本。所以專案過程質量可以在每個sprint結束後均有對應的質量資料輸出，經過一系列迭代後，可以看出這個專案的質量趨勢。如果同期有多個專案在進行，那麼也可以透過質量資料的對比，對比出各個專案的質量優劣，同時輔以圖表來直觀分析對比。
例如，同一階段有3個專案在進行，同一個時間這3個專案的迭代質量和質量波動幅度資料如下，那麼按照質量均分和波動幅度使用柱狀圖進行排序，各個專案的對比情況立刻見分曉。
對於多個專案的質量對比，採取專案質量平均分的方式，以及專案質量多個迭代版本的質量波動資料來表示。
質量平均分採取專案從第一個迭代至當前迭代的質量分數的平均值，代表專案截止當前的質量平均水平；
質量波動資料採取基於截止當前的迭代質量分數計算方差，資料越小，說明質量波動越小。
多個專案並行時，從質量均分和質量波動資料兩個維度分別對比，同一時間將每個專案標記在一個二維象限（象限的質量均分和質量波動資料兩個維度的分割值可以視具體的專案情況而定，例如採用多個專案這兩個維度的平均值）中，專案質量以及波動情況即顯而易見，在“質量好，波動小”到“質量差，波動大”之間一目瞭然。
使用工具以上介紹的質量判斷方案需要有一定的工具支撐，我們使用了JIRA進行專案管理，管理需求和開發過程以及bug，story的計劃提測時間和打回次數可以進行記錄，在迭代結束後只要花很少的時間就可以進行快速得統計，迭代質量資料也可以呈現出來。專案經理在很短時間內就可以統計出專案的質量分數並進行後續分析。
好的研發工具可以簡化質量統計，質量統計方案在實施過程中，往往需要配合組織架構、流程、文化建設等多方面，才能達到有效推動改進迭代質量。