5.爲何要作設計評審和測試用例評審

    敏捷開發系列文章目錄

 

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

 

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

    咱們團隊敏捷開發前期也是沒有搞設計評審和測試用例評審的，是有幾個迭代產品的質量總是提不高，在迭代回顧會議中你們討論出，就算設計評審和測試用例評審會佔用咱們的開發時間也必需要搞，否則產品的質量永遠提不上來。

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

 

設計評審實例：

 病歷維護工做站

用例設計

概要類圖

 

界面原型

1)病歷樹節點維護

2)數據源維護

3)病歷模板

表結構設計

 

    敏捷開發系列文章目錄