摘要：蔡建斌國際物流公司亞洲交付團隊經(jīng)理導語敏捷是一個很流行的一個詞語，但是在敏捷里面，包括很多團隊也是剛開始用，怎么讓質(zhì)量成為敏捷的一個助力而不是拖累，這個是我主要想談的。管理者把解決問題分解成多個子領(lǐng)域，分解成多各個情境來逐個擊破。

蔡建斌 -國際物流公司亞洲 IT 交付團隊經(jīng)理

導語

敏捷是一個很流行的一個詞語，但是在敏捷里面，包括很多團隊也是剛開始用Scrum，怎么讓質(zhì)量成為敏捷的一個助力而不是拖累，這個是我主要想談的。

關(guān)于質(zhì)量的定義，我前不久接觸到一個文章，里面有一個圖講到質(zhì)量的五個維度，但是我做了一些微調(diào)，改成了四個。接下來就從我定義的4個維度的質(zhì)量分別探討一下。

1. 基于價值的質(zhì)量，交付影響而不是交付產(chǎn)品

在IT業(yè)有一個很著名的人叫做 溫伯格 的咨詢師， 他提到質(zhì)量的定義叫做質(zhì)量是對某些人的價值，價值是什么意思？

福特問客戶想要什么，他說要一匹更快的馬，但是福特提供給了客戶汽車。馬和汽車是提供給客戶的產(chǎn)品，價值是什么？客戶可能有天天從各個城市飛來飛去需求，他希望有更快的馬來助力，這個就是價值的意思。客戶的需求往往是方案，它很少告訴你這個東西背后是什么目的。所以User Story的背后，就是價值。

在工作上，我認為我們不是在交付產(chǎn)品，而是是交付影響力，就是交付對用戶的影響。你讓我開發(fā)一匹更加的馬，我要問這個馬用來干什么，對你有什么影響，因為我交付的是影響而不是產(chǎn)品。

Impact Mapping通過 Why Who How What得到一些想法：我們做產(chǎn)品是為了什么？影響哪些人？

-如果說一個咖啡館老板，他想賺一個億，誰能幫助他達成這個目標？

-如果說顧客可以幫助他達成這個目標，那怎么幫助他達成？

比如顧客（who）買了咖啡之后，覺得不錯然后會推薦給其他朋友（how），所以顧客通過把咖啡店推薦給好友的行為可以幫助他賺到一個億（why）的小目標，但是需要注意的是，這個"who"可以很多。

有了前面的鋪墊后就能得到"what"

為了鼓勵顧客去推薦好友這個行為，我可能會開發(fā)一個“推薦賺積分積分換咖啡”（what）的功能系統(tǒng)。我們開發(fā)Story不是Story本身，產(chǎn)品本身不是我們直接的目標，我們的目標其實是為了影響“顧客去推薦好友”這樣一個行為，這個影響，最終達到業(yè)務目標，就是這個why。

我們跟產(chǎn)品合作，他們給我們做了一次what，他會說你給我做一個積分換咖啡的功能，其實背后這些功能會帶來什么樣的價值，才是更需要探討的。但是這樣的思想框架并不是真的去問why 、who等等，而是告訴我們真正需要交付的東西，而不是真正的產(chǎn)品。所以說提出一個可能符合背后目標的更好的what出來，這才是框架的一個根本目的。

2. 基于產(chǎn)品的質(zhì)量，利用反饋

例如，我們要研發(fā)更快的馬，或者研發(fā)一輛汽車，這個就是產(chǎn)品本身，定下來仍然有質(zhì)量因素在里面，就是怎么把東西做對。

Cynefin模型：
?

simple ：你要解決問題很簡單，你有一些最佳實踐套用就可以了，如果你的公司，你的研發(fā)在這個象限上，其實是恭喜你，其實是非常舒服的

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

complex ：沒有辦法簡單找?guī)讉€專家來研究得出結(jié)論，這個應付的東西是各個維度，有可能是質(zhì)量出問題，加上預算有限，加上產(chǎn)品方向不清，需求不清，產(chǎn)品跟架構(gòu)師之間合作不來，各種交織在一起，但是有一個目標需要推進。

chaotic ：就是混亂，如果碰到這種，這個挑戰(zhàn)確實是非常大，可能不是一般的管理者能夠應付得了，需要CXO坐在一起給出方向。

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

產(chǎn)品研發(fā)大部分屬于第二和第三象限，這兩個維度的實現(xiàn)就是先做，然后再反饋。反饋有一個原理：越早的反饋越便宜。

舉個例子

在產(chǎn)品研發(fā)中，有一個很大的問題，就是你的技術(shù)團隊和產(chǎn)品經(jīng)理的鴻溝。這個鴻溝很常見，但是在我自己的工作場景里面這個鴻溝不常見，我一直是技術(shù)領(lǐng)域的人，但是我在產(chǎn)品上或者需求上跟產(chǎn)品經(jīng)理一直是通力協(xié)作的，用實時的反饋來跨越反饋，而不要等產(chǎn)品經(jīng)理已經(jīng)設(shè)計了兩個月，然后給我們開發(fā)完上線后，再提出需求不對，這樣就比較被動。

如果反饋能做到實時，下面就是實踐。在新的產(chǎn)品研發(fā)開始的時候，我與技術(shù)人員產(chǎn)品經(jīng)理會一起先把概念模型畫下來，因為一個團隊有很多的角色，包括架構(gòu)師、開發(fā)、US、甚至外包人員，不同的角色怎么確保理解的一致，最后明白如何做自己的工作。你怎么確保這份活動基于統(tǒng)一的理解，沒有共識就比較容易出現(xiàn)鴻溝。把概念模型畫下來就是為了現(xiàn)實上的例子，可以很簡單，我們有什么業(yè)務對象，他們之間關(guān)系是什么樣，把這些東西畫下來，大家基于一份共識去做各自的活，這個鴻溝會少一點。

3. 基于產(chǎn)出的質(zhì)量，定義完成，以終為始

我自己是研發(fā)出身,研發(fā)質(zhì)量產(chǎn)出是什么？就是需要建立條目化，短周期之內(nèi)可以交付的東西，這個是產(chǎn)出，第一個產(chǎn)出是代碼，尤其在軟件行業(yè)，代碼占了80%的產(chǎn)出，怎么把代碼寫對，就是第三個維度。

代碼質(zhì)量有一個心法叫做定義完成；

舉個例子，很多程序員你問他這個Story做了沒有，他給你的答案是什么？度量BUG是為零，程序員做完之后交給QA，QA告訴開發(fā)有沒有BUG。你的QA下一道工序是我的客戶，我應該告訴你有沒有BUG或者有多少個BUG，而不是反過來。

需求質(zhì)量也是很重要的產(chǎn)出；

你要保證你的產(chǎn)品經(jīng)理做的需求是不是符合，是不是條目化，是不是按照優(yōu)先級，你是不是做最重要的事情。你有三個團隊，每個團隊都在按照優(yōu)先級來做事，但是三個團隊是不是有統(tǒng)一的優(yōu)先級，很多團隊是沒有做到的。

有些需求你不做用戶會不高興，但是你做了也不會很高興，就像我們的實踐一樣，項目大的時候不做實踐會很慘，但是做了項目也不一定會成功。

工作中當你問程序員說這個做完沒有，很多程序員告訴你90%完成，或者完成了但是沒有測，或者有幾個BUG，或者需要重構(gòu)一下，這種心態(tài)是不好的，但是沒有反饋。

我們叫做以終為始，用戶故事只有兩種狀態(tài)，只有完成和沒有完成，沒有但是，沒有完成你要把它完成掉。程序員會說這個做了90%，然后去做下一個故事，結(jié)果是沒有一個可以工作。而我們倡導的是把一件事情全部做完，才做下一個。

4. 過程質(zhì)量，拆

有這樣一句話，如果你用同樣的方式去烤面包只會得到相同的面包。

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

舉一個例子，很多程序員寫代碼，一天下班的時候代碼還沒有編譯，我們寫代碼方式應該是這樣,很多程序員寫代碼是東寫一點，西寫一點，這個意味著什么？沒有透明度，他不知道寫哪一個，這樣的過程想代碼質(zhì)量好是不可能的。

總結(jié)

我們已經(jīng)講了四個維度的質(zhì)量，價值和成本，可很多團隊的人沒有辦法控制價值的部分，有些人卻可以。我們是一個技術(shù)負責人，產(chǎn)品都不是我們能控制的。你要考慮定制權(quán)在哪里？影響權(quán)在哪里？你能控制的東西就是你的成本，你不能控制的地方就是你不能提供的。

誰為質(zhì)量負責");

文章來源：Worktile敏捷博客

歡迎訪問交流更多關(guān)于技術(shù)及協(xié)作的問題。

文章轉(zhuǎn)載請注明出處。