敏捷開發中如何作質量管理？

 

 

本文爲蔡建斌 -國際物流公司亞洲 IT 交付團隊經理分享

導語

敏捷是一個很流行的一個詞語，可是在敏捷裏面，包括不少團隊也是剛開始用Scrum，怎麼讓質量成爲敏捷的一個助力而不是拖累，這個是我主要想談的。

關於質量的定義，我前不久接觸到一個文章，裏面有一個圖講到質量的五個維度，可是我作了一些微調，改爲了四個。接下來就從我定義的4個維度的質量分別探討一下。

 

 

1. 基於價值的質量，交付影響而不是交付產品

在IT業有一個很著名的人叫作 溫伯格 的諮詢師， 他提到質量的定義叫作質量是對某些人的價值，價值是什麼意思？

福特問客戶想要什麼，他說要一匹更快的馬，可是福特提供給了客戶汽車。馬和汽車是提供給客戶的產品，價值是什麼？客戶可能有每天從各個城市飛來飛去需求，他但願有更快的馬來助力，這個就是價值的意思。客戶的需求每每是方案，它不多告訴你這個東西背後是什麼目的。因此User Story的背後，就是價值。

在工做上，我認爲咱們不是在交付產品，而是是交付影響力，就是交付對用戶的影響。你讓我開發一匹更加的馬，我要問這個馬用來幹什麼，對你有什麼影響，由於我交付的是影響而不是產品。

Impact Mapping經過 Why Who How What獲得一些想法：咱們作產品是爲了什麼？影響哪些人？

 

 

-若是說一個咖啡館老闆，他想賺一個億，誰能幫助他達成這個目標？

-若是說顧客能夠幫助他達成這個目標，那怎麼幫助他達成？

好比顧客（who）買了咖啡以後，以爲不錯而後會推薦給其餘朋友（how），因此顧客經過把咖啡店推薦給好友的行爲能夠幫助他賺到一個億（why）的小目標，可是須要注意的是，這個"who"能夠不少。

有了前面的鋪墊後就能獲得"what"

爲了鼓勵顧客去推薦好友這個行爲，我可能會開發一個「推薦賺積分積分換咖啡」（what）的功能系統。咱們開發Story不是Story自己，產品自己不是咱們直接的目標，咱們的目標實際上是爲了影響「顧客去推薦好友」這樣一個行爲，這個影響，最終達到業務目標，就是這個why。

咱們跟產品合做，他們給咱們作了一次what，他會說你給我作一個積分換咖啡的功能，其實背後這些功能會帶來什麼樣的價值，纔是更須要探討的。可是這樣的思想框架並非真的去問why 、who等等，而是告訴咱們真正須要交付的東西，而不是真正的產品。因此說提出一個可能符合背後目標的更好的what出來，這纔是框架的一個根本目的。

2. 基於產品的質量，利用反饋

例如，咱們要研發更快的馬，或者研發一輛汽車，這個就是產品自己，定下來仍然有質量因素在裏面，就是怎麼把東西作對。

Cynefin模型：
​

 

simple ：你要解決問題很簡單，你有一些最佳實踐套用就能夠了，若是你的公司，你的研發在這個象限上，實際上是恭喜你，實際上是很是舒服的

complicated ：比較繁雜的場景，這個場景下你的解決方案可能有多個，可能不存在最佳實踐，又或者可能有多個實踐，可能找幾個專家來幫你搞定，這個是一個場景

complex ：沒有辦法簡單找幾個專家來研究得出結論，這個應付的東西是各個維度，有多是質量出問題，加上預算有限，加上產品方向不清，需求不清，產品跟架構師之間合做不來，各類交織在一塊兒，可是有一個目標須要推動。

chaotic ：就是混亂，若是碰到這種，這個挑戰確實是很是大，可能不是通常的管理者可以應付得了，須要CXO坐在一塊兒給出方向。

disorder ：管理者把解決問題分解成多個子領域，分解成多各個情境來逐個擊破。

產品研發大部分屬於第二和第三象限，這兩個維度的實現就是先作，而後再反饋。反饋有一個原理：越早的反饋越便宜。

舉個例子

在產品研發中，有一個很大的問題，就是你的技術團隊和產品經理的鴻溝。這個鴻溝很常見，可是在我本身的工做場景裏面這個鴻溝不常見，我一直是技術領域的人，可是我在產品上或者需求上跟產品經理一直是通力協做的，用實時的反饋來跨越反饋，而不要等產品經理已經設計了兩個月，而後給咱們開發完上線後，再提出需求不對，這樣就比較被動。

若是反饋能作到實時，下面就是實踐。在新的產品研發開始的時候，我與技術人員產品經理會一塊兒先把概念模型畫下來，由於一個團隊有不少的角色，包括架構師、開發、US、甚至外包人員，不一樣的角色怎麼確保理解的一致，最後明白如何作本身的工做。你怎麼確保這份活動基於統一的理解，沒有共識就比較容易出現鴻溝。把概念模型畫下來就是爲了現實上的例子，能夠很簡單，咱們有什麼業務對象，他們之間關係是什麼樣，把這些東西畫下來，你們基於一份共識去作各自的活，這個鴻溝會少一點。

3. 基於產出的質量，定義完成，以終爲始

我本身是研發出身,研發質量產出是什麼？就是須要創建條目化，短週期以內能夠交付的東西，這個是產出，第一個產出是代碼，尤爲在軟件行業，代碼佔了80%的產出，怎麼把代碼寫對，就是第三個維度。

代碼質量有一個心法叫作定義完成；

舉個例子，不少程序員你問他這個Story作了沒有，他給你的答案是什麼？度量BUG是爲零，程序員作完以後交給QA，QA告訴開發有沒有BUG。你的QA下一道工序是個人客戶，我應該告訴你有沒有BUG或者有多少個BUG，而不是反過來。

需求質量也是很重要的產出；

 

 

你要保證你的產品經理作的需求是否是符合，是否是條目化，是否是按照優先級，你是否是作最重要的事情。你有三個團隊，每一個團隊都在按照優先級來作事，可是三個團隊是否是有統一的優先級，不少團隊是沒有作到的。

有些需求你不作用戶會不高興，可是你作了也不會很高興，就像咱們的實踐同樣，項目大的時候不作實踐會很慘，可是作了項目也不必定會成功。

工做中當你問程序員說這個作完沒有，不少程序員告訴你90%完成，或者完成了可是沒有測，或者有幾個BUG，或者須要重構一下，這種心態是很差的，可是沒有反饋。

咱們叫作以終爲始，用戶故事只有兩種狀態，只有完成和沒有完成，沒有可是，沒有完成你要把它完成掉。程序員會說這個作了90%，而後去作下一個故事，結果是沒有一個能夠工做。而咱們倡導的是把一件事情所有作完，才作下一個。

4. 過程質量，拆

有這樣一句話，若是你用一樣的方式去烤麪包只會獲得相同的麪包。

過程質量就是寫代碼的質量，這個心法就是拆，拆成小的東西，拆成一個可交付的東西，其實寫代碼也是須要拆的。

舉一個例子，不少程序員寫代碼，一天下班的時候代碼尚未編譯，咱們寫代碼方式應該是這樣,不少程序員寫代碼是東寫一點，西寫一點，這個意味着什麼？沒有透明度，他不知道寫哪個，這樣的過程想代碼質量好是不可能的。

總結

咱們已經講了四個維度的質量，價值和成本，可不少團隊的人沒有辦法控制價值的部分，有些人卻能夠。咱們是一個技術負責人，產品都不是咱們能控制的。你要考慮定製權在哪裏？影響權在哪裏？你能控制的東西就是你的成本，你不能控制的地方就是你不能提供的。

誰爲質量負責?若是開發工程和QA之間出現問題，最後辛苦開發出來的功能，用戶抱怨難用，就是價值和質量出現了問題，如今分工愈來愈細，在不少團隊集中在某一層，好比程序員關心寫代碼，不關心價值和產品，產品經理只關心價值，不關心技術實現，這些鴻溝會影響整個質量。

 

文章來源：Worktile敏捷博客

歡迎訪問交流更多關於技術及協做的問題。

文章轉載請註明出處。