敏捷開發系列文章目錄

設計評審和測試用例評審我們都是叠代的第二天做，一般會給開發人員半天的時間思考一下他自己故事的設計，然後抽出1-2個小時進行設計評審，設計評審完後就做測試用例評審。
設計評審就是讓團隊幫你查遺補漏完善你的設計，而測試用例是測試、PO、開發三者又一次落到實處的交流。

設計評審和測試用例評審都是為了解決產品質量問題而提出來的解決辦法。

我們團隊敏捷開發前期也是沒有搞設計評審和測試用例評審的，是有幾個叠代產品的質量老是提不高，在叠代回顧會議中大家討論出，就算設計評審和測試用例評審會占用我們的開發時間也必須要搞，不然產品的質量永遠提不上來。

我覺得定這個制度的由來可以好好說一下，那是在雲HIS項目第二個階段臨床部分開發的Sprint2的回顧會議上提出來的，因為這個叠代失敗了。團隊在做sprint 評審會議展示產品成果的時候錯誤百出，藥品入出庫的流程都跑不通，當場PO就拒絕驗收本次叠代的故事，宣布叠代失敗。接下來的叠代回顧會議時，大家表現得比較沈重，SM就安慰大家，失敗的叠代也是叠代，對團隊也是好事，正好可以總結經驗嘛。X君脾氣比較火爆，一下就開火了，“我就搞不明白，為什麽要這麽趕，一個叠代塞這麽多故事，這還是不是在搞敏捷？”這是現實情況，因為這個項目周期比較緊張，所以一些功能就按系統倒排，就導致每個叠代的故事多了一些。T君是SM，“這個叠代故事多是一方面原因，但不是降低質量的根本原因，搞敏捷有時候搞些強的沖刺也是正常的，並且叠代計劃會議大家已經對這些故事做出了承諾，所以我們應該找出這次失敗的原因，而不能抱怨找理由推卸責任”。Y君平時話不多，但寫代碼做事非常踏實，“產品的質量不好，我覺得是設計這個環節做得太倉促了，沒搞敏捷之前我們開發經管部分是花了一個月時間做設計的，設計表結構、畫用例圖、時序圖、類圖，編寫設計文檔，但一個叠代才兩個時間根本沒有留時間做好設計。就像Y君和H君，你們兩個同時使用的那個字段狀態的定義，在叠代快結束了還在變來變去，一方剛修正bug，另一方又產生新的bug，如果提前大家一起把這些設計細節討論請求就應該不會出現這種問題。”H君認為Y君說得很有道理，問題是設計該怎麽做，像以前那樣花一個月時間寫設計文檔肯定不行，那不是有回到以前傳統的那種開發模式上去了？接下來大家深入討論怎麽做符合敏捷的設計，首先像以前那麽詳細的設計文檔肯定沒時間寫出來，為了節約時間設計文檔不寫了，本來敏捷就提倡輕文檔重溝通，重點是一定要提前做出設計，而不是在編碼過程中思考設計，所以決定每個人提前做好設計，然後進行設計串講，每個人把自己的設計講出來讓大家提建議，沒有設計文檔建議畫一些流程圖或者在白板上講解自己的思路，講完之後再拍照下來，分享在群裏。後面的叠代按照這個想法嘗試，效果還不錯。再後來由於每個人講解設計的方式差別太大了，沒有統一的表述方法，為了提升溝通的效率，又制定了一個簡單的設計文檔模板，所以慢慢的就形成了現在的設計評審的流程。

設計評審實例：

病歷維護工作站

用例設計

概要類圖

界面原型

1)病歷樹節點維護

2)數據源維護

3)病歷模板

表結構設計

敏捷開發系列文章目錄

5.為什麽要做設計評審和測試用例評審