Ruddy Lee 分享空間

Emergent Design 演化設計

Archive for the ‘未分類’ Category

聚焦使用者價值為核心原則的系統思維

leave a comment »

.聚焦系統思維.png

以使用者價值為核心的系統思維

.

聚焦於專案開發的敏捷只是部份的敏捷

早期的敏捷化把重點整個放在專案的開發上頭,一直到 DevOps 的出現才喚醒大家的全貌性考量;其實產品不是只有開發階段需要關注,開發完成後還有維運(對敏捷而言似乎沒有開發完畢這回事)工作,再往前看去則是產品部門所負責的產品定義問題(也就是需求的產出、排序)。另外;從市場的角度來看,就是從新創公司的層面來看產品開發,早期是以獲取最高利潤的產品設計為導向 ,現在則是以使用者為導向的需求規劃與開發。聚合這二種理念便成了一種以「聚焦使用者價值為核心原則的系統思維」。上圖中,若以系統思維全面化的考量來看DevOps的話,似乎還少了「產品定義」及「業務規劃」的部份才稱的上是真正的敏捷化。所以企業在實行敏捷化的時候,若是我們仍然只以開發部門或維運部門來進行改革而不是讓整個企業都運行敏捷的話,便會落入了所謂的Water-Scrum-Fall的部份敏捷化,而結果便是業者經常質疑的:『為何我已經實施這麼久的敏捷化了,卻沒有太大的成果呢?

.

看見全貌

看見全貌是個抽象的東西,以系統思維來作詮釋時,其實我們是自己先設定了系統的邊界,才去試著看到它的全貌,是先預設了立場才去追尋全貌的,事實上系統是沒有邊界的,那又那來的全貌呢?一切都是我們自以為是的。因此我們在探索全貌時必需先設定問題(先將解決的問題系統化),接著再讓問題的範圍去形成自然的邊界,然後試著看到所要分析問題的全貌,如此而已。

.

》系統本無邊界,邊界是我們自以爲是的。所以進行系統思維時,需要先給「問題」,讓問題去形成自然的邊界。然後再視我們的需求來調整「問題」。聽起來很繞舌,但這不就是持續改善嗎!

 

繼續閱讀文章 »

廣告

Written by ruddyllee

2017 年 12 月 05 日 at 22:11:00

實踐 DevOps 三步工作法的金幣理論

leave a comment »

.

金幣應該放在高業務價值的專案或是高優先順序的需求上。

當業務價值大於開發工作時,大家都會很高興;

當業務價值低於開發工作時,開發部門就會受到責難。

– 金幣理論

.

 

金幣.png

金幣理論的運作圖示

.

金幣理論 – 讓你善用資源的解題方案

基於供需問題的前提考量下,並為了將DevOps三步工作法實踐在真實世界的軟體公司裡,思考運用玩遊戲時最常接收到的即時回饋方式,也就是金幣的方式來描述整個企業在產品營運開發的資源(就是金幣)上,如何善用資源的運作方式。具體說明如下: 企業在由業務部門聆聽到市場及用戶的心聲後,向業主爭取資源,由企業決定要投入多少資源來進行產品的開發投資,業務部門將從市場獲取的概念搭配足夠的資源委託專門作需求設計的產品部門去設計產品的功能,讓抽象的產品概念逐漸擁有較清晰的輪廓,接著產品部門再將資源分配給開發部門進行需求的溝通以進行開發作業的研發行為,開發部門接著投入開發人力來製作出可供市場接受的產品的開發作業後,再交由維運部門來配置給客戶使用,隨後再經由客戶取得產品使用後的回饋,透過市場傳遞回給企業,使得企業在獲取市場訊息、學得經驗及獲得利潤後,重新運用資源將所學到的經驗,再投入到產品開發的改善及設計上而形成一種持續改善的循環。

.

什麼時候用金幣理論呢?

》當PO/PM不願意區分需求的優先順序時;

》當開發部門人力不足,但PM確堅持所有專案都一樣重要的時候;

這個時候;給他比需求數目大1的金幣數,讓他無法平均分配,或是給他二倍數目再加一的金幣數,請他把金幣放在專案或需求前,代表投入的資源多寡,此時優先順序就出來了!

.

金幣理論.png

金幣理論運作模式

.

為什麼用金幣呢?

這是為了替專案區分優先級別、為需求制訂優先順序的作法。例如: 有三個專案需要同時進行的時候,而你手上握有四枚金幣,不可能作平均式的分配,此時決定孰重孰輕、該多做投資在哪一個專案,便成了必然要作的抉擇,完整不可切割的金幣成就了這種自然形成的強迫性抉擇(透過衡量的抉擇),目的是要求專案的執行者能夠對專案進行衡量的作業,而不是盲目地作資源的平均分配。由於金幣是完整的不可再作細化的,這樣規定可以避免專案執行者將所有專案都一視同仁的錯誤作法(就如同PO將所有的需求都設定成相同的重要性一般,這是最糟的抉擇)。

 

不是開發的太慢,而是產出的業務價值不夠高

科技進步的實在太快了,越來越少有團隊在開發速度上受到肯定的。當開發團隊遭到抱怨開發速度太慢的時候,管理階層通常首先會想到的便是增加人手,用加人來解決產品部門及業務部門的埋怨,這個現象幾乎已經是擁有開發團隊企業的常態。但加人的措施真的能解決開發速度太慢的問題嗎? 這一點請參考《人月神話》書裏頭所謂的沒有銀子彈的理論(註2)。

 

{書名所謂的「人月」(man-month),是指在做管理專案時,用來計算投入的人力時間的單位(或「人年」),一個人做一個月,就是一個人月。而人月的計算方式實在是一種迷失,因為人月是不能用線性的方式來計算的。例如: 專案落後了三個月,那麼找一個人來補進去,是不是三個月後就能追上進度了。哪麼假設找三個人進來加入專案,是不是一個月就能趕上進度了,順理推論是不是找10個人來加入專案 3天以後就可以追上進度了。《人月神話》的作者Brooks正是要糾正大家這種用人月來計算專案進度的迷失,議題是: 專案來不及了,增加人手有沒有用。}

 

供需的問題 Supply and Demand

當想要開發完成的需求多過現有人力資源所能完成的工作,這個時候便出現供需不平衡的問題了。我們用存量與流量(stock and flow)的系統水管圖示來簡化所要描述的供需問題。

存量.png

簡化供需問題的流量與存量圖示

.

供給和需求是一個經濟學模型,它被應用作決定市場均衡價格和均衡產量。需求指大眾因需要一件產品而產生的購買要求;而供應就指企業響應大眾的購買需求而提供的產品供給。如果以系統思維來分析上面圖示,當水龍頭注入的水量與塞子漏水的流量趨於一致時,就達到了一種系統平衡的現象。

 

企業經營的目的在追求利潤

企業經營的目的在追求利潤,所以這個供需系統不在平衡,而是在追求更大的相對利益,因此專案開發的速度跟數量並不是最關鍵的因素,開發的產品對使用者是否具有高的使用價值才是重點,也就是說;開發部門應該以開發高業務價值的產品為圭臬,相對的開發的需求必須具有較高的業務價值才值得去開發。在這個DevOps 興起的時代,追求快速開發成了顯學,大家都被這一波快速成長的科技潮流壓得喘不過氣來,幾乎所有開發部門都被埋怨開發速度太慢,但實質上是我們開發的業務價值不夠高所致,是業務的方向需要正確,是產品需要真正具有競爭力,是開發團隊是否能及時讓產品上架才是問題,這是一個環環相扣的系統。這是一場團隊的競賽,而不是單一部門是否能盡到它們的職責所致。因此當我們在埋怨開發速度不良的時候,應該以系統思維的角度去觀察市場的全貌,運用數據收集與智能化來協助我們探索全貌,這也正是DevOps開始第一步強調系統思維的目的。

 

這裡談「供需理論」是為了取捨

我們都知道拍照時,你不能把全景都拍下來,那樣就完全沒有焦點了,你必需有所取捨,用局部來代表全部。把當下要傳達的故事聚焦化,先懂得捨才能取(所以拍照常常被稱為減法的行為)。專案開發也是如此,開發團隊的人力資源往往是固定的,但業務單位總是提出一大堆想要的需求,問它們的重要性,回答常是都重要。該如何做抉擇呢? 敏捷的精神告訴我們,以小的增量作依據,運用小迭代來換取經驗然後持續修正它,在資源固定的情境下當然是務實的選擇有把握而投資報酬率又較高的項目來做抉擇,在取得客戶足夠的滿意度後終止開發作業,而不是把所有的需求都作完,相反的;敏捷開發是遺留下來越多需求時則表現得越敏捷。

 

試著回想一下,我們在玩電動遊戲的時候,過關則獲得金幣(還有哪令人聽得興奮不已的音效)回饋,沒過關則可能被消滅必須重新來過。試想我們是怎麼過關的,即便是電玩高手也往往要透過失敗來獲取經驗,習得改進的策略後再來通關。所以經由實驗改進策略來獲取勝利似乎是玩電玩再單純不過的原則了。在玩電玩的時候;通常的結局都是明確的,回饋更是立即的,所以我們可以很快的學到訣竅,很快的就能再試一次,學到技巧了自然能夠過關,所以我們願意一玩再玩,即便是明明知道
沒有戰勝遊戲的機會,但是這種樂趣就已經足以支撐我們玩上幾個小時不會放棄了。軟體開發則有著異曲通功之妙,只是真實世界裡的成敗與回饋都來的好慢,時間延遲的效應無處不在,很少能有快速又明確的回饋現象,但這並不代表我們就不能依樣畫葫蘆。敏捷開發的做法是採用小作小錯的學習模式,運用小的增量來減少花大功夫,然後依循著小的迭代時間,來快速的學到經驗,採用務實而持續的改善模式來達到終點。每一次的小迭代都會換來一次的抉擇,你都在做取捨,你也都有重新修訂方向的機會,你要盡快弄清楚方向,並做好抉擇。這一點是 DevOps 理論出現後,最被在意的一件事,也就是說快不是唯一重要的事,方向要對了快才有意義。換成軟體開發來說;需求的業務價值要夠高,真正滿足了用戶的需求才是開發的重點,開發團隊做得在快、完成再多需求,如果沒有滿足到用戶的需求,一樣意義不大。

 

三步金幣理論.png

金幣理論是用來實踐三步工作法

.

結論

金幣理論是看著資源不足的開發團隊,卻把所有專案視成一樣重要的行為,所激發出來的處理方法。人們習慣均勻的去分配資源,沒有通過數據化的衡量來做為決策時的依據,但在真實世界裡;幾乎所有的事情都具有優先順序,只是我們偷懶了,沒有去收集數據就直接做決策,犯了胡亂猜測的錯誤,試想;今天如果有三個專案,但我們有四個金幣可以使用來提供支配資源的時候,依照過去的習慣,我們在每一個專案都押下一枚金幣,試問多出來的一枚金幣要給誰呢? 我們是要依據業務場景跟開發週期來作判斷呢? 還是依據專案對企業的重要性來作抉擇呢?不管你做什麼樣的決定,該依據什麼準則來做衡量的標準,應該才是重點。前提是任何衡量總比不作衡量就直接以平均分配的方式來得合理。基於這個理由,所以我才會想到金幣理論。其實使用點數或百分比也可以進行重要性的區分,但獨獨金幣具有不可分性,所以才會逼得你去衡量,再依靠衡量後的數據作較合理的抉擇。這是產品經理人該學會的技能,衡量(3.)

 

想解決的問題

金幣理論的目的在解決長期以來專案及需求被視為一樣重要的問題。設法觸發專案及需求進行數據收集式的衡量行為。簡化企業在部門與部門之間的供需問題。做到符合DevOps 的放大回饋訊息,加強單項工作的意義。促進三步工作法的第三步、加速實驗、學習持續改善的迴路。

 .

所有的需求都一樣重要?所有的專案都一樣重要?

問題不在專案或需求是否一樣重要,而是在有限的資源下,我們該如何善用。

.

拍照

將專案開發與拍照相提並論

.

註1. 典型系統中使用的特性/功能

只有20%的功能是使用者經常會使用到的,有將近 45%的功能用戶一被子也不會用到。

2. 《人月神話》書裏頭所謂的沒有銀子彈的理論

The Mythical Man-Month: Essays on Software Engineering是由IBM System/360系統之父佛瑞德·布魯克斯所著經典文集。

沒有銀子彈是布魯克斯所出的經典論文集之一。

3. 參考 如何衡量萬事萬物作者: Douglas W. Hubbard

.

Written by ruddyllee

2017 年 11 月 29 日 at 09:34:02

需求分析的設計模式

leave a comment »

.

需求不只是需求.

– Kent J. Mcdonald

特性分析法(Feature Injection)是需求分析的一種方法。它的關鍵是理解專案期望的交付價值,並以交付能夠提供價值的特性為目標,同時運用實例來進行溝通與特性有關的信息. 作法:

  • 識別價值

  • 注入特性

  • 提供實例

.

首先、識別價值

0002.png

.

注入特性

Feature Injection

.

》提供實例;是讓模型的整體認識更加清晰的最佳方法。實例可為模型產生測試。

 

.

  1. Chris Matts :  Given-When-Then 的發明人之一( 另一位是Dan North)。
  2. 參考自"超越需求“第五章、交付價值.
  3. 特性分析法;當我們從系統中拉取業務價值時,我們注入產生價值的特性。它與看板的拉動有著相同的原理,但相反的價值流動方向。

.

Written by ruddyllee

2017 年 11 月 09 日 at 14:19:55

三步工作法思維導圖

leave a comment »

.

0002_8.png

三步工作法思維導圖

.

 

.

0002_8.png

Written by ruddyllee

2017 年 10 月 28 日 at 11:04:58

張貼於未分類

Tagged with ,

看見全貌

leave a comment »

.

專案開始之初,首重看見全貌。

一旦;當你把眼光投注在哪一個要項的時候,實際上你就只看到那一部分,你的思緒將被那一部分的內容所牽動,很難再看見其他的事…

所以我們要退後一步,

不! 有時要退後很多步,才能比較清晰地看見全貌。

(好有趣喔! 退遠了卻反而看得更清晰)

所以要調整範圍,試圖把我們在意的事放進視線可及之處,

淡淡的審視它,不帶一點情緒,就是這樣,我們看見了全貌。

.

開發團隊被抱怨開發速度太慢的案例層出不窮…

0054.png

軟體影響開發速度的因素

其實當你努力的去改善開發環境還有程式,祈求開發速度能夠跟上需求時,其實;還不如從提升需求的業務價值來著手改進會快上很多,請參考"需求分析的設計模式“一文。

.

一旦你看見全貌之後,要怎麼做呢? 

一種全貌.png

演講內容:  DevOps 教战守策:三步工作法 ,內容 PPT 的全貌( XPS展示)

首先;把它畫下來。畫下來不論對自己或閱讀的人都是一種極具價值的事。

.

0002_8

將演講內容整理成 圖示 (演講: DevOps 教战守策:三步工作法 )

畫出來;可以具像化(產生 Avatar)的整理出資料的脈絡,告訴學員運用圖示來回憶上課的內容,當遇到有疑惑的地方時再去細看 PPT的內容會效果會更好。

.

see the whole

整理出來的心得

.

註:

  • 拉遠原則 (Pulling principle) 

就是在更大的範圍內觀察事物。我們可以試著將一個產品放置在更大的背景環境中去考慮,這樣可以避免見樹不見林的現象。(例如: 坊間一些書籍的試讀軟體,就有這種效果。) 雖然我們這麼去觀察,但還是只看到它的外觀,好的作品,設計者的品味(taste) 卻還是能隱然呈現,尤其是那些優秀的產品。至於內涵的部分,就需要細細的去品味了。

.

Written by ruddyllee

2017 年 10 月 27 日 at 09:53:55

張貼於未分類

Tagged with ,

工程師多任務單工的作業方式

leave a comment »

.

「解決多工作業的多任務單工作業 Multi-mission but Single Task

– Multitasking is evil

.

Coding! 基本上進行的方式就一定是一個人一個鍵盤的形式,當然或許你同時使用多個畫面,但基本上在做邏輯思考時,一定是一次思考一件事情,程式寫這麼多年來還沒有看過能夠用二隻手同時間寫二支以上程式的人。這是寫程式的天性,一次寫一支程式的進行方式。因此單工作業是不可避免的,跟我們平常一邊走路一邊嚼著口香糖是絕然不同的事。如果你同時間進行多個程式撰寫的工作的話,可以預期的是,工時一定會更長,Bug也會變得更多(請參考下面圖示)。這種弊多於利的作業方式;你還要繼續嘗試嗎?

 

有趣的是,老闆們就是一直把工作丟下來,這一點;造成了幾乎所的工程師都兼具多個任務在身上,很少有工程師能夠一次只作一件工作的(那是一種福氣!)。因此多工作業便成了常態性的現象。而許多工程師會在上一個工作尚未完成時就放下來跑去作別的工作。當然;有時是在工作上遇到障礙或落入苦思無解的情境,就藉著轉換工作的形式來讓思維能多出一些空間來,試著讓自己進入解題的狀況。因此就多工了,這種多工 Multi-tasking的現象,實質上正是殘害邏輯完整性跟程式品質不佳的元凶。下面這一張圖,顯示同時做三件事,跟順序的完成這三件事的時間差異。

.

多工_task3

醒醒吧! 多工只會多增加switching task所花的時間

.

用看板來可視化多工

多工的行為牽扯到的不只是工時上的問題,還有團隊工作分配是否合理的問題,除了能讓團隊更勞累之外同時也會帶動員工的情緒起伏。多工;不管從哪一方面來看對公司或團隊都是一種傷害,但事情一直來,就是那麼多工作要完成,而且它們總是會挑相同的時間一起來,那工程師該如何處理這種情形呢? 這裡運用「多任務單工看板」來處理它,請參考。

.

多工多任務單工作業看板

.

多任務單工作業看板

Multi-mission but Single Task

這是一種以人員為主的看板,上圖中第二個欄位【負責人】就是以工作負責人的姓名為主的欄位,在他左邊陳列的是它所背負的任務,分別依它們的重要性由右至左來排列在【TO Do】欄位裡。接下來是第三個欄位【分析】;這裡可能有工作的細分或進一步的拆解、估算。然後是【執行】、【測試】及【完成】欄位。看板的下方則是緊急渠道。目前正在負責完成工作的人是 Allan。他之前正在做A3的工作,但遇到緊急事件,就先暫停下來,做好了紅色倒三角的標誌之後就下來解決急件了。

它完全符合看板的基本原則,也就是單工的拉動系統作業。工程師在同一時間內只能做一件事。而【TO Do】欄位裡排列的是他所被要求要完成的任務。

.

看板是敏捷迭代開發的縮影

        看板方法沒有任何固定的會議或是角色的定義,它針對的就是流動在欄位之間的工作項目。至於這個工作;可能是一個任務或是一個較大的使用者故事所描述的需求,或單純就是一個工作項目(Task),當然也可能是一個缺陷(Bug)。這一點要看你的工作性質來做定義。上圖中的【TO Do】欄位就像是敏捷開發中按重要性所排列的需求 Queue.而全部的 【TO Do】欄位內的總合就像是敏捷開發在迭代循環中所必須完成的全部工作項目(Sprint backlog item)。它就是整個迭代開發流程的縮影,這正是讓看板十分適合拿來取代Scrum工作板的主要原因。而看板的單工作業原則,就更適合工程團隊拿來解決一般工程師被要求多工作業的問題,拿來設計成看板就成了「多任務單工的作業」的看板了。讓可視化的現象,提供主管看見每位工程師的負荷,讓進度據實的呈現出來,讓相關人員可以容易進行協調工作。它也正常展現了精實開發的基本精神 – 單工作業。

.

工程師千萬別要因爲你被同時指派多個工作就忙著進行多工的開發作業,請務必繼續單工開發的作業模式,但必須讓你的工作透明化,如此其他人才好配合。

.

.

Written by ruddyllee

2017 年 10 月 26 日 at 15:46:14

近代的软件开发

leave a comment »

.

DevOps 隨想…

大家都想要速度,追求開發到布署在速度上的極致,

試想你可以發布得多快,比子彈還快嗎?!

然後呢?

作對的產品!對的「方向」才是王道。

.

近代的軟體開發.png

這是ㄧ個動態的網頁是拿來作演講用的,在這裡只放了靜態的首頁,期待下次的巧遇…

Written by ruddyllee

2017 年 10 月 14 日 at 18:40:48

張貼於未分類

Tagged with