Ruddy Lee 分享空間

Emergent Design 演化設計

一個人的Sprint(ppt)

leave a comment »

.

0001

.

0002

.

0003

.

0004

.

0005

.

0006

.

0007

.

0008

.

0009

.

0010.png

.

0010_1.png

.

0011

.

0012

.

{ 作了第一場「一個人的敏捷」研討會,這是PPT。 }

.

參考:

 

廣告

Written by ruddyllee

2018 年 01 月 16 日 at 11:23:21

實踐一日Sprint的個人看板

leave a comment »

.

個人看板

實踐一日 Sprint 的個人看板(一個人的敏捷開發)

.

【代辦事項】

你的生活應該包含一大堆任務(或許你喜歡用工作、事務或是想做的事,任務這二個字只是我習慣的用詞,因為乍聽起來有Tom Cruise的味道),眾多的任務裡有你喜歡會主動去做的任務,也有你不喜歡或是被其他人要求要做的事,或是被強迫去做的事(不用驚訝! 在真實的生活裡,我們大部分時間都是為別人在生活的),不管你有多少任務要做,維持一個看起來井然有序的待辦事項是一件很棒的事。千萬不要放任它一直長大,請適當的給它設限,超過的時候就刪掉吧! 常常要去想一想;一直放在清單最下面的任務,它為什麼會一直擺在底部呢? 考慮一下,在下一個新增項目出現時,把它刪除吧!

50 是我的設限,通常不會真正去算它,但一般我只會關注最前面的任務,後段的任務就很少去注意它了, 數目只是一個拿來提醒自己用的數字而已。(註,請參考单核工作法图解,第1章削減待辦任務裡的集草器清單小節)

.

【Ready】

一日之計在於晨! 在你開始一天的工作之初,先客觀的把最重要的5件任務放進《5件事清單裡》,我的習慣是在前一天晚上睡覺以前就先放好了,這是習慣它可以讓我睡得更好,有時候夢裡我已經想好第一件任務該怎麼去做了! 養成這種習慣還能讓自己不會賴床。但到次日的早上再去做決定好像更敏捷些!

.

 

【Doing】

全景鬧鐘設好,進入「專注模式」開始衝刺今天第一個任務。養成一些好習慣讓周遭的夥伴都知道你正進入全力專注的工作模式,鄰居們會盡量想辦法減少打擾、甚至能自動降低噪音,減少受到別人可以干擾到你的機會。

鬧鐘響了! 立刻切換成「全景模式」,如果對上一個工作意猶未盡怎麼辦?剛剛的工作還沒有告一段落很想繼續把它完成,但鬧鐘響了,該停下來嗎? 不急;先吐一口氣,鬆一鬆雙肩,盡量客觀的看一下所有的工作,如果你覺得該繼續把手頭的任務完成,就在把全景鬧鐘設好,重新進入專注模式再開始你的衝刺作業。全景鬧鐘只是提醒你該審視一下手頭的任務了,並沒有要強迫你進入下一個任務的意思。只有一條規則,就只是要提醒你「重要的工作先做」。

 

專注模式的上限設定 = 2,為什麼?

這是為了避免因為發生另一個突發的工作在全景模式時發現比目前手頭上的工作更重要,造成我們發生一再更換工作,而一再放棄手頭正在做的工作,所以把上限設定成二,只容許有一次更換的機會(除非你把手頭上的任務完成),當再次有這種現象發生時就會被WIP的上限約束住了,所以設定成 2,當然你也可以視自己的工作特性去調整。

.

 

【檢核】

自我評比;目的是替自己做好風險管理,同時確認學到了些什麼。要落實經驗的好方法便是回顧了,而回顧就必須區分做得好的跟不好的地方,不好的就要設法去改善它,好的就要維持或是去放大它。

這個欄位裡有一個很重要的地方就是它有一個「等待」的次欄位。我經常會望著它嘆息,但這就是真正的人生,在生活裡有太多需要你去等待的東西了,甚至你可以把它想成是一種非同步的狀態處裡,因為事情總有會不按照你的預期就發生或結束的,真實的世界裡有太多東西需要去等待了。就好比你用信用卡簽帳,扣款是不會立即發生的,勢必要在等待一段時間後才會發生,但有時你需要提醒自己,時時提醒自己還有一筆債務要償還。這個時候就可以把完成了的任務放入等待的欄位裡,然後標記一下時間做一點註解,讓自己能夠很容易在一眼之下就可以回顧到真實的狀態。這便是等待欄位的責任,它尤其適合用來對付那些自己無法控制的事情。這些便是任務的意外風險了。

.

 

【完成】

》什麼時候最適合拿來檢討一天工作下來的成果?

這個時間點是最適合把已經完成的工作在拿出來審視一下的時刻,再做一次最後的回顧,而完成這個欄位便是負責收集已經做完成任務的地方,我們在清除它之前勢必要檢討一下做完這件任務之後的心得,然後便可以把它們放到信裡頭(記得要運用信件的抬頭來註明裡面是放置一些剛剛完成的任務項目)然後直接寄給自己。目的是讓自己在收到信件時進行最後一次的審視。如果有未完成的地方,就記錄下來隨後再回信給自己,運用這種「來回傳遞信件」的方式來提醒自己還有未完成的任務。

.

註:

不要急著去找尋合適的工具程式,就先拿隨手可得的數位工具來用,先run run 看,有一點心得之後才好做評估。我用了 Trello 又換成 Kanbanflow 二個軟體都OK!

.

Written by ruddyllee

2018 年 01 月 11 日 at 20:04:15

一個人如何施行敏捷

leave a comment »

.

one day sprint.png

一個人的敏捷開發流程(一日Sprint個人看板)

.

一個人如何敏捷 (一日Sprint),作法說明

按照事情的重要程度把它們放到5件事清單上(註2,不管我們有多少事要做,就先拿出前五名來放入清單中),啟動全景鬧鐘(在>25分鐘的整點或半點時段設定鬧鐘,註3),接著;開始專注於一件最重要的事,進入專注模式開始工作(衝刺)。當有新工作出現時,不要立即去做,先放到清單裡去。如果有人來打擾你,先問是否可以稍後再來,如果不行,問清楚事情的重要程度如果比你現在在做的工作還要重要,就去幫他處理。否則就繼續做完手頭的工作直到鬧鐘響起時在回到全景模式,停下你的工作,進入休息狀態以客觀的態度審視待辦的工作清單,挑一個最重要的工作設定好全景鬧鐘,繼續衝刺。在這種專注一件工作的專注模式與全景模式之間進行切換,然後繼續去完成工作清單裡的下一個工作。把完成的工作,評估一下工作做得好的、跟不好的地方,寫在Email裡然後寄給自己,直到渡過這一天,最後在就寢前回顧一下這些信件,如果有所感想就把它寫在信裡回給自己(反覆寄信給自己的方式,就稱為自我回饋的模式,例如:我通常在google搜尋到重要資料時,就會把資料作彚整一下,然後寄給自己作成註記及紀錄,便利以後回顧用)。(註1. 參考自單核工作法)

.

全景鬧鐘Panoramic alarm clock

先來談談「全景鬧鐘」,(從最重要的觀念先談)這是一種透過整點或半點時段設定鬧鐘的方法,在鬧鐘響起時強迫自己進入重新客觀的審視,回過頭來看自己手頭所有的工作(很像 Refinement,但更像 Inspection,是一種系統思維的想法),也就是強迫自己回到看見全貌的模式。這種時時提醒自己看見工作全貌的方式,可以避免發生局部優化的現象(讓設定的整點時間來提供我們延遲決策的機會,同時能夠使得決策更正確些)。這個觀念來自於阿蘭·拉金Alan Lakein美國“時間管理之父”(他說;我們一定要在專注工作的時候使用鬧鐘來計時,並強調這個世界上根本不存在“沒時間”這回事)。反過來;我們把它對照到一個正在運行scrum的團隊,這件事便是站立會議了,也就是說我們可以在進行站立會議時用客觀的角度來審視所有的工作項。

.

一個人要如何敏捷呢?

就從把一天當成一個「個人的Sprint」開始,每個Sprint只專注於一件目前認為最重要的工作,用全景鬧鐘來提醒自己應該要切換模式了,一天中持續的在極度專注的工作中(專注模式),以及切換到客觀審視所有手頭上的工作 (全景模式)之間,包括別人的干擾及突然在腦海中浮現出來的工作,都要先做客觀判斷再去做它,也就是在允許的情形下,先把這些突來的工作放入清單中,等切換到全景模式之後,在經過客觀的做判斷後,決定它是不是目前最重要的事,然後才開始工作。

.

敏捷 = 務實,也就是盡量減少去做假設

.

緊急的工作 vs 重要的工作

很多任務會讓人進入所謂的來者不拒的響應狀態,好像你必須立即回應,否則就會錯失良機似的,我們姑且把它稱作是緊急的工作。但那不是它的重要性,緊急的事未必是重要的,而重要的事不去處理它,不久它就一定會變成緊急的事了。我們需要客觀的來判斷工作的重要性,因此需要設定全景鬧鐘,讓自己有機會運用客觀的視野去審視所有手頭的工作,讓最重要的事排在最前面,運用務實的態度來讓自己敏捷起來。

.

結論

敏捷不能沒有回饋,沒有回饋的敏捷就幾乎就沒有敏捷。怎麼說呢?因為敏捷是針對需求多變的特性所衍生出來的處理方式。但是一個人怎麼敏捷呢? 無形的解答是去遵循敏捷的價值觀,只要思考方式符合敏捷宣言(敏捷四大宣言)即是敏捷了。至於有形的部份,Scrum的框架則是最受歡迎的了,但它有三種角色,單單一個人是無法運行的。因此每當被問到一個人如何施行敏捷時,總是以自己寄信給自己,用自我回饋的方式來實踐敏捷。但一直等到看見《單核工作法》,Staffan為個人的時間管理所作的佳作才改變了我的思考方式。如果我們將每次專注工作的方式當成是小增量,把在全景模式與專注模式的切換視成是進行迭代,不就完成了一種敏捷的典行工作方式了嗎?試想一個人在一天裡運用小增量加上運行一日的迭代開發不正是實踐了敏捷開發嗎!因此試著將它畫成了類似Scrum的圖形,希望對實行敏捷有興趣的個人可以來嘗試看看!

.

回家的路上跟睡覺前都是評估風險的最佳時刻。

.

看遠一點

專注一天的工作得以完成一日的小增量也就是獲得一日的小成就,我們若能夠把目標放得更大一些,也就是專注於更大的時間區間,例如一週,則便能夠完成更大的目標。如果你已經嚐試過一日Sprint的效能了,則或許你應該看得更遠些,擁有更遠大的目標,請試著把一日的衝刺放大成一週的衝刺,試著讓你的目標能夠實現, 人生也將會變得更美好。祝 有恆!

.

 

註1. 參考自單核工作法

單核工作法圖解》by: Staffan Nöteberg. (瑞典)

註2.  5件事清單

將所有你想要做的事,遴選前五個最重要的工作放入工作清單中,就稱之為5件事清單。至於你想多放幾件進來,我也沒意見。

註3. 整點或半點時段設定鬧鐘。

目的是維持有25分鐘以上的時間差距。例如: 10:03 分的整點或半點時段為10:30,10:15 的整點或半點時段則為11:00. 是一種運用鬧鐘在一段時間後提醒我們做決策的方式,它既可讓我們專注於手頭的工作又具有延遲決策的效應。

 

Written by ruddyllee

2018 年 01 月 08 日 at 21:00:29

需求落點分析模型

leave a comment »

.

目的

提供團隊在開發完一個Sprint的增量後針對需求的價值給出回饋,讓工程師有機會就自己所剛剛完成的任務有發表意見的機會,同時運用專家的視角將回饋傳達給PO。

.

步驟

首先;在便利貼上畫一個 2X2的矩陣,垂直軸是對市場的差異化影響的大小,水平軸表示我們作了哪些工作(任務與努力)的多寡。

接著;讓團隊成員針對剛剛完成Sprint的使用者故事的落點進行評估。

layout

(團隊在進行點評時,務必再說明一回各個方塊的意義,讓點評更明確些)

.

該怎麼點評呢?

差異化活動

右上角的方框是用來表示我們完成的這些個使用者故事,它對市場差異性是有所幫助的任務。如上圖的 U1及 U2.

 

校驗活動

右下角是指我們完成的任務僅僅是用來追上目前市場的水平,也就是市場上其他品牌基本上都已經有的功能。一般新的產品通常都要向已有產品靠齊,但如果花太多功夫在這個方塊中,產品是不會有更大的成長的。反過來應該做剛剛好的人力調適,多朝右上方的方塊靠攏才是比較具有價值的任務。

 

合作夥伴活動

左上角是指如呼叫後台的API或是其他廠商所提供的支援API等,算是與合作夥伴共同完成的任務,但這對產品的差異性是有幫助的,雖然不是自己做,但卻也有一定的價值。

 

無用的活動

左下角,指的是我們作了一些對產品在市場差異化上完全沒有幫助的功能。

.

基於目的的對準模型(Purpose-base Alignment Model)

工程師對需求的認知圖一、依據 Kent J. McDonald的Purpose-base Alignment Model 所改良的需求落點分析模型 (1上面的紅色說明是依據Kent 所發表的白皮書所加上的,黑色字體則是Niel Nickolaisen 原著的翻譯)

上面二位作者的宗旨都是針對專案尚未開始時所設計用來「理解情境」用的模式。因此稱之為基於目的的對準模型,下面則是我把程序反過來;拿來用在工程師開發完需求後的落點評估說明。

.

為甚麼要工程師來評比呢?

因為剛剛完成任務的工程師,正是對該功能最熟悉的人士(專家),他可以用最專業的立場來看它的價值。雖然主觀了一點,但這不正是專家的意見嗎?

 

下圖說明,工程師在接收到開發任務之前對所要完成的功能及相關信息是全然無知的(中間藍色點鏈線),必須透過持續的摸索與學習,在無數次的嘗試失敗之後,才能累積完成工作的足夠能耐,然後才能把工作完成。(綠色點線即為PO的認知,我們的目的正是將藍線在峰頂的知識回饋傳達給PO產品的負責人)

 

認知

圖二、開發人員對需求了解的時間曲線

如上圖的紅點,是在描述在開發工作中我們持續的學習到相關的新知識並把它們轉化成實際能工作的程式,這時候我們總會認為除了自己之外再沒有一個人能比我們更了解這段程式碼了,此時我們達到了一種專業的領域,一種將需求轉化成可工作軟體的境界。而「需求落點分析模型」正是要在你成為領域專家時對需求進行評比的工具。原因是這個時候你具有最專業的視野,正是可以對所完成的需求進行回饋的最好時機點。回顧會議似乎是一個好時機點。這個簡單的模型是這樣進行的:

.

範例: 假設這個Sprint完成了7個使用者故事,Scrum Master 可以在回顧會議時,首先把需求落點模型的圖示畫在白板上頭並加以簡單說明,接著要求團隊就剛剛完成的工作以他們自己的認知點在便利貼的四個方塊上。然後由Scrum Master 收齊,交給PO做參考用。

IMG_20180101_083503

實際運作時一個工程師的點選結果

說明:

  1. 在 差異化活動裡有U1,U2.

這是有意義的需求開發工作。越多越好!

  1. 在 校驗活動裡有 U3,U4及U5.

我們正在追上市場的基本水平中,團隊雖然忙碌但距離市場的期望越來越近了。

  1. 在 合作夥伴活動裡有 U6.

有協同合作的機會,交互配合度的好壞可以拿出來分享。

  1. 在 無用的活動 裡有 U7一個,這表示該團隊成員認為 U7是一個較無意義的需求工作。平白耗費了工程師的資源。

 

{ 上面這一張落點圖示,是以一個人為標的一次評打完所有的使用者故事,適合在 Review會議後進行,另一種方式則是一次一個使用者故事但包含所有人的點評,團隊每個人依序輪流點評,這種方式會進行得更為快速但不適合較大的團隊採用,優點是不需要事後再做統計的動作。 }

 

※ PO若有感興趣的地方(例如發覺團隊跟自己的認知有差距時),可以在與團隊進行溝通,而這種直接來自專家的回饋,可以提供PO做需求排序時的參考,當然有必要時更可以做為進一步溝通的依據。

需求落點模型可以讓PO與負責開發作業的團隊成員,透過回饋的方式交換彼此的意見,並藉以提升二者對需求的共同認知。

.

說明文檔在這裡

 

參考:

  1. Using the Purpose Based Alignment Model by Kent J. McDonald
  2. 超越需求: 敏捷思維模式下的分析 (Beyond Requirements: Analysis with an Agile Mindset)
  3. 精益創業實戰  原作名: Running Lean, 作者:Ash Maurya , 2013

 

Written by ruddyllee

2018 年 01 月 01 日 at 16:41:36

敏捷需求的分析工具

leave a comment »

.

敏捷探討需求的分析工具

圖示.png

敏捷說明敏捷探討需求的分析工具說明

.

專案負責人Product Owner的利器

  1. 產品心經: 產品經理應該知道的60件事
  2. 超越需求: 敏捷思維模式下的分析 (Beyond Requirements: Analysis with an Agile Mindset)
  3. 用戶至上 (Understanding your users: a practical guide to user research methods) 用户至上(用户研究方法与实践原书第2版)
  4. 如何衡量萬事萬物:大數據時代,做好量化決策、分析的有效方法 (How to Measure Anything: Finding the Value of“intangibles” in business
  5. Essential Kanban Condensed  by David J Anderson and Andy Carmichael
  6. 使用者故事對照 (User Story Mapping: Discover the Whole Story, Build the Right Product)
  7. Google 創投認證!SPRINT 衝刺計畫:Google 最實用工作法,5天5步驟迅速解決難題、測試新點子、完成更多工作!(Sprint: How to Solve Big Problems and Test New Ideas in Just 5 Days)

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

leave a comment »

.系統思維_systemThinking.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