国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

敏捷開發中如何做質量管理?

lingdududu / 1494人閱讀

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

蔡建斌 -國際物流公司亞洲 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. 過程質量,拆

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

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

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

總結

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

誰為質量負責");


文章來源:Worktile敏捷博客

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

文章轉載請注明出處。


文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。

轉載請注明本文地址:http://m.specialneedsforspecialkids.com/yun/6958.html

相關文章

  • 如何確定敏捷是否適合你的團隊?

    摘要:但敏捷是不是真的如坊間傳聞的那樣,是一個可以解決所有項目困境的萬能藥當然不是但敏捷的確是一種比較好的項目管理方法。因為協作的團隊成員可以隨時訪問和更新故事板,這將有助于團隊協作的順利開展。敏捷教練希望創建一個積極并表現出主動性的團隊。對從事項目管理的人員來說,敏捷已經成為一場席卷全國的風潮。但敏捷并不是什么新事物,它已經有20多年的歷史。正如社交媒體圈子所說的那樣,敏捷的聲勢與流行程度正在逐...

    Lemon_95 評論0 收藏0
  • 測試如何敏捷團隊工作?

    摘要:測試的工作量更加分散,不會出現一段時間無事可做,一段時間忙的要死的情況。如果測試一味地只管提交,而不考慮開發的工作習慣和目標的可執行性,就會導致效率大大降低。這種看似投機取巧的方法會讓測試的用例編寫工作事半功倍,效率大大提升。 臨近年末,各家公司都進入了緊張的年前項目沖刺階段,我們也不例外。每天開完早會,就聽大家在抱怨任務太多做不完、一個月都沒正常過周末了云云。 據開發部門的同事說,他...

    taowen 評論0 收藏0
  • 何勉:第一性原理和精益敏捷的規模化實施

    摘要:摘要什么是第一性原理第一性原理如何指導我們的精益敏捷開發阿里資深解決方案架構師暢銷書精益產品開發原則方法與實施作者何勉,結合實踐案例,詳述第一性原理和精益敏捷的規模化實施。前言今天分享的題目是第一性原理和精益敏捷的規模化實施。 摘要: 什么是第一性原理?第一性原理如何指導我們的精益敏捷開發?阿里資深解決方案架構師、暢銷書《精益產品開發:原則、方法與實施》作者何勉,結合實踐案例,詳述第一...

    233jl 評論0 收藏0
  • Simon Brown:架構師與程序員的區別

    摘要:從根本上講,架構師是一個技術領導者的角色,這就是最大的區別。對于這個問題來說,沒錯,有一些相關主題沒有出現在這本書中,這些主題可以構成一本與程序員必讀之軟件架構相互補的書。我從軟件架構的視角特別能注意到這件事。 非商業轉載請注明作譯者、出處,并保留本文的原始鏈接:http://www.ituring.com.cn/article/178034 Simon Brown 是全球知...

    Turbo 評論0 收藏0

發表評論

0條評論

最新活動
閱讀需要支付1元查看
<