敏捷是一個很流行的一個詞語，但是在敏捷裡面，包括很多團隊也是剛開始用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之間出現問題，最後辛苦開發出來的功能，使用者抱怨難用，就是價值和質量出現了問題，現在分工越來越細，在很多團隊集中在某一層，比如程式設計師關心寫程式碼，不關心價值和產品，產品經理只關心價值，不關心技術實現，這些鴻溝會影響整個質量。
敏捷是一個很流行的一個詞語，但是在敏捷裡面，包括很多團隊也是剛開始用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之間出現問題，最後辛苦開發出來的功能，使用者抱怨難用，就是價值和質量出現了問題，現在分工越來越細，在很多團隊集中在某一層，比如程式設計師關心寫程式碼，不關心價值和產品，產品經理只關心價值，不關心技術實現，這些鴻溝會影響整個質量。