回覆列表
  • 1 # 曇花一現71742

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

  • 中秋節和大豐收的關聯?
  • 我們國家的足球還能起來嗎?