Ruddy Lee 分享空間

Emergent Design 演化設計

看板驅動開發(KDD)

leave a comment »

.

KDD 與度量.png

在運行DevOps時,倡導用看板來驅動開發作業,是因為看見有人在大力推廣DevOps 度量之下所衍生出來的問題,擔心度量會成為一種浪費,所以推廣將度量融入於看板運行中的方式,讓度量能結合於流程中,化浪費為進行學習改善的助力。

.

看板驅動開發(KDD)的目的是在運用看板來透明化工程師進行程式開發的過程,讓工程師看見自己是怎麼進行開發工作的,並依據記錄來分析自己的開發工作是否有足夠的效率,作為增進效能、持續改善的依據。

.

normal.png

運行工程師實際工作的看板

.

這麼作的原因是:

一、我們經常可以看到工程師在團隊站立會議之後,回到自己的座位上便開始進行一天的工作規劃,他們會用便利貼安排好一天該作的事,然後貼在自己個人的小看板上,開始他們在上班期間的工作。

》這個現象說明了工程師在上班期間不是只有作他在團隊看板上所認領的工作!其實還有許多事情都會佔據他的上班時間,而這些事在大看板上是看不見的,而這類的非開發工作,敏捷開發的因應之道是要求工程師盡量把這些工作之外的事務維持在工時的15%以內,盡量不去影響開發工作便可以了,但實際上;這是一種模糊不清的做法,對看板方法而言是一種不良的假設。

(我常常被工程師問道,這便是個人看板嗎?註1.)

這也是目前在一般團隊在運行看板時最不明確的地方,因為我們常常假設工程師每天都能擁有足夠的時間去進行開發作業,忽略了許多會消耗掉他工作時間的額外工作,例如:開會、協助解決問題、與他人進行溝通、處理緊急事件等等事情,都會大量的消耗掉工程師的上班時間。敏捷的一種解法是在估算的時候,以一個理想的工作日來作範圍的調整(例如在VSTS上頭,把一天設定成5小時)這麼作雖然給我們很大的彈性,但也隱藏了許多真實的工作事項,讓我們看不見事情的真貌不知道要進行改善,這一點很不符合精實Lean的精神。

二、工程師可以運用 KDD來分析自己一天的時間都用到那裡去了,藉此作為改善效能的依據。有一種現象是工程師不管再怎麼忙碌,但總能夠在第二天準時完成他的工作,他們常常會在不到二個真正工作的小時裡卻能完成超過四個小時的工作(Tasks),也就是二倍工作量的開發任務。當然原因可能是因爲他加班了,或是把工作帶回家去作了,但不論如何我們都需要弄清楚真正的原因,因為只有如此才能作為任務評估的真實依據,否則將始終看不到事情的真實樣貌。(主管如果把這種狀態視為是一種合理的現象,這種誤解往往會造成員工不能理解或不願配合公司策略的因素之一,因為它是不正常的,不該忽視它也不能鼓勵,大可私下稱讚一下他的負責盡職精神就好,實在應該找出原因避免重複發生)

 .

 

KDD是自我改善的依據,換句話說就是給自己看的

要先看見問題才能改善。過往寫程式的過程,就是坐下來coding就是了(當然你可能運用 TDD來加強邏輯思維的審密性或是配合團隊採用 BDD的coding模式來兼顧程式的品質),但總覺得好像少了些什麼,效能不夠沒看見全貌。這就好像跑步一般,一個簡單的計時器,能讓你知道自己的速度在那個區間裡,一段柔軟操能讓你一路不抽筋直到終點,小小的紀錄都能對跑步的成績有著巨大的幫助。而KDD就是這麼來的,試著想想看你要從那裡開始改善自己coding 的效能吧!但基本上還是先從客觀的看得見全貌開始,先看見自己一天工作的全貌,認知到自己在那裡,接著再來探討那些是需要改善的。

.

開發工作應該以達成任務為目標而不是依靠估算來作為完成工作的統計依據,所以必需以度量為基礎。

.

 

如何開始運行KDD?

先從看見自己的工作流程開始,然後把它紀錄下來,用 Trello 或 Bitrix24都行,重點是要有數據才能進行分析,要有看板才好調整WIP來進行改善作業。

 

.

simple kanban

在座位旁的牆壁,用便利貼試著開始運行KDD

.

找一個在座位旁的牆壁,或是買一塊小板子也可以(最終還是要數位化的,小板子可以維持紀錄著一、二天的進度),給出透明度讓大家都知道自己在做些什麼,數位的紀錄則很像跑步計時的馬錶一樣,是給自己參考的,只是拿來做改善用的(累積流程圖的展示價值會出乎你想像的好用的)。

你都有些什麼工作?!用不同顏色大小的貼紙來表示工作種類及耗時。甚至用特殊符號來展示你在進行工作時的心情、進度如何都OK。就照著實際來的工作忠實的記錄它,一開始先用「待辦 – 進行 – 完成」的最簡易看板作開始, 隨後在視需要進行調整。重點只有一個,就是忠實記錄,原則也只有一個就是維持單工作業,遵守作重要的事而不是作緊急的事(參考: 一個人如何施行敏捷)。用最簡單的方式來養成習慣,因為只有養成習慣才可能持之以恆。所以先設計好流程養成習慣,之後就容易持續下去了。

.

依比例分配.png

.

 

調整工作的比例

試著用比率的方式來看待你的工作項目,因為時間是固定的因此你唯一可以做的就是按比例來分配,然後給他們設定一個目標值,一個讓你覺得適合的比率,並在一段時間後來作回顧,這種作法可以幫助你掌握自己,同時又能增加自己的適應性。

 

.

process

工作項目的心情歷程圖

.

我很喜歡上面這個圖示,它讓人一目了然自己的厭惡及喜好,人應該要盡量忠於自己的感受。心情歷程圖讓我們知道要多做一點上面(高興區間)的工作,少作一點下面(困擾區間)的工作,上班時就會覺得幸福些。(這一點可以作為給公司的回饋)

 .

企業存在的意義有兩個:一是為社會創造幸福,二是為員工創造幸福。

– 智庫百科

.

學習是追求幸福的捷徑

寫程式本來就是一種學習的過程,而學習可以讓人心無旁騖專心沉浸在解題的過程中,事後又能產生高度的成就感(怪不得工程師常常會說,與其去參加無趣的活動,我寧可留下來寫程式),而敏捷所推行的學習型組織,正是一種最穩定又高效的組織型態。但學習確實是需要借助外在的因素的,KDD 可以幫你看見自己工作的歷程,而不是盲目的任憑感覺來模糊的作改善,依據看板真實的記錄來讓你作為行為改善的依據,自然能更為有效。

.

 

註1. 這便是個人看板嗎?

嚴格的說;不是的,因KDD只包括上班時的工作時間,而個人看板理論上應該是24小時的,也就是還包含其它事項,例如: 家庭生活、個人生活、還有興趣 . . 等。

 

廣告

Written by ruddyllee

2018 年 04 月 10 日 at 15:27:32

需求與產品開發中的價值

leave a comment »

.

抱怨團隊的開發速度不佳 …

.

0012需求的業務價值決定產品的開發價值

.

0013需求排序與價值的對照,滿足客戶的要求

.

0014需求排序與價值的衡量,決定敏捷合約

.

敏捷合約以度量業務價值是否達成為依歸

許多執行scrum的團隊仍然以將描述需求的用戶故事全數作完,專案才算開發完成,而不是以達成使用者的需求也就是達成足夠的『業務價值』為驗收的準則,這一點很不敏捷也浪費了許多開發團隊的戰力來作一些低業務價值又客戶很少會用到的功能,解決之道是以度量為主,我們可以運用「影響地圖」作為簽約時的度量依據。

.

impact.png運用影響地圖進行度量

.

註: 需求的柱狀圖形來自Essential Scrum

Written by ruddyllee

2018 年 03 月 23 日 at 09:43:25

衡量: 讓紅黃綠燈更明確化

leave a comment »

綠燈的顏色是世界共通的,不論走到哪裡都是『紅、黃、綠』三色。(英文用的黃色是 Amber 琥珀色,所以紅、黃、綠簡寫成 RAG.) 採用這三種顏色的理由是,因為對人類而言,最容易辨識的顏色依序是紅、黃、綠的緣故。顏色有隨著光線減弱而不好分辨的傾向。而紅色不管多遠、多小,依然可以清清楚楚的看到,而且從進入眼睛的光、傳入腦中的速度也以紅色最快,所以拿紅色來做警示訊息最洽當不過了。

 .

{ 紅綠燈最初問世是在1868年,是在英國的西敏寺使用紅綠兩種信號裝置。三燈式信號機則首見於1918年於紐約啟用的手動裝置;日本則是隔年的1919年在東京的十字路口利用紅、綠色板的手動式機械燈號,台灣是在1940年中山北路上設立了第一個紅綠燈。 }

.

燈號須先取得團隊對燈號的明確共識,以避免誤判(draw by Gina Abudi)

.

專案開發的紅黃綠燈

用燈號標示狀態,來關注它的風險,具有淺顯易讀的效益。聽起來或是看起來都似乎很容易又好用,在看板上也容易表現出來。一般的解讀是,「紅燈」拿來表示有重大問題發生了,專案時程可能會因此延誤或超出預算,需要我們立即的關注。「黃燈」表示有出現問題的可能性,需要開始關注它了。「綠燈」表示一切按照預期,沒有脫軌的現象。在運行看板的時候,我們常會在無法控制的工作卡片上,用標註燈號的方式來顯示它的狀態。(例如一些委外開發的工作項目,比較困難取得即時的資訊,就採用亮燈的方式來做風險管理。)

.

簡單但不夠明確反而容易造成誤解

顏色容易隨著亮度的不同而造成誤判。虛擬的顏色則容易跟隨著描述者所採用的詞彙而造成聽者的不同詮釋。例如:在看板的站立會議上,最怕出現QA人員描述最近的Bug必較多要亮黃燈了,提醒大家要注意品質。聽起來沒什麼問題,是QA人員在報告時,提醒大家要多注意品質,但這種描述的方式對透明度並沒有幫助,反而容易造成誤解,工程師可能解讀成「QA對我們的品質感到不滿」或是「我們害了QA人員需要加班才能完成測試的工作」。若以明確化為目的;較正確的說法應該要透過數字來的作報告,譬如:「 昨天Bug的解決比例是5/15,新增15個Bugs解決5個Bugs,品質亮黃燈。用這種方式來陳述事實而不帶容易讓人誤解的形容詞」。

.

站立會議作報告時;應該盡量提出可供衡量的數據,讓會議的內容更明確化。

.

範例

燈號在加上數據的陳述

.

適當的加入度量值

估算只是估算,基本上只是對未來即將完成工作的一種預計性時間的猜測。在沒有做完以前實在很難做成比較明確的度量,但如果因此而不去做衡量,就失去修正、改善的機會,犯了不敏捷的錯誤。

.

Measure

衡量Measure;只要能让你知道得比以前多,就是一项成功的衡量

.

追求敏捷化,我們需要知道得更多一點點
只要能夠獲得比以前多一點的訊息,就是一项成功的衡量。大家都知道傳統的開發方式就是做了一個最大的假設,假設我們能在專案一開始就把所有的事都想清楚的前提下,而犯了最大的錯誤假設,為了修正它,敏捷便以小增量、多個迭代的方式來取代它。至於,有什麼方法能使我們更敏捷呢? 那就是運用衡量measurement 來設法去減少假設跟猜測。至於要衡量什麼呢? 如何來衡量呢?(請參考,註1.如何衡量萬事萬物. by 道格拉斯‧哈伯德)

三件我們必須做衡量的事:

  • 不確定的事 – 為了做成決策,必須先做些假設的事

  • 有風險的事 – 我們害怕會出問題的事

  • 對訊息的判讀

.
衡量很難嗎?
為什麼要做量? 量的目的是減少風險,面對假設。因為敏捷很務實,不做太多假設,要做到這一點,要減少假設,只有透過度量的方式才能對一些訊息明確化。哈伯德教我們要做衡量:「宣稱萬事萬物沒有不能衡量的」。第一次聽到這句話時,你可能不以為然,但是如果你拿Bill Burnett所著的《Design your life》(註2. 為比爾‧柏內特與戴夫‧埃文斯所合著,是教人如何運用設計思維來設計生活的書,獲5顆星級亞馬遜圖書)裡面對你人生的衡量或是對個人健康、愛情的衡量方式,也就是拿狀態表的方式來作衡量,是不是就不會太排斥了呢(看起來是不是很像紅、黃、綠燈的形式,只是它多分了一份,我個人偏好使用5等份的評估方式)?

Measure_love對愛情做度量的狀態表

.

》請避免黃燈效應;影射人們在遇到需要下決策時,停下來觀望做了拖延的動作,也就是錯失良機的問題。在公共交通管理中,人們常常見到這樣的標語或口號:“紅燈停,綠燈行,黃燈亮了等一等”;“一慢,二看,三通過”;“寧停三分,不搶一秒”等。由此就產生了對決策過程中人們冠冕堂皇進行拖延的一種形象比喻--黃燈效應

.

什麼是好的度量

度量.png會改變行為的度量,才是好的度量

 

.

結論

請把衡量拿來當成減少不確定性、優化問題的有效手段. 這一點應驗了管理學之父. 彼得·德魯克 Peter F. Drucker 所說的: 「如果你不能衡量它,就不能管理它」。我們拿公司的老闆來做比喻,你可以相信所有做老闆的人心中都有一把尺吧! 他拿它來衡量整個公司、所有有關的事物(怪不得做老闆的人都容易失眠)。 我們若把衡量放到敏捷開發裏頭來,前提是針對系統而非個人所進行的一種度量,它減少了許多的猜測,撇開了那些沒必要的假設,它讓我們更容易看到風險,也務實多了。(度量跟衡量被我混為一談了,原文是measurement)

.

Measure_all

from Peter F. Drucker 

.

註1. 書: 如何衡量萬事萬物:大數據時代,做好量化決策、分析的有效方法,作者: 道格拉斯‧哈伯德。這是一本麻省理工學院指定教材,長踞亞馬遜網站商業類暢銷書榜,為一生受用的衡量技術!

註2. Bill Burnett所著的《Design your life》,史丹佛大學最夯的生涯規畫課圖書,中文書名: 

做自己的生命設計師:史丹佛最夯的生涯規畫課,用「設計思考」重擬問題,打造全新生命藍圖 (Designing Your Life: How to Build a Well-lived, Joyful Life) 

 

Written by ruddyllee

2018 年 03 月 14 日 at 11:49:07

張貼於未分類

Tagged with ,

一個人的Sprint(ppt)

leave a comment »

.

0001

.

0002

.

0003

.

0004

.

0005

.

0006.

{ 大家都知道"健康第一“這句名言,但卻很少把它放在心上 }

健康」包括: 身體健康,和心靈、環境健康,三者缺一不可。

.

0007

.

0008.png加入用戶故事地圖可以讓我們看見全貌

.

0009

.

0010.png

.

0010_1.png

.

0011

.

0012.png

.

個人故事地圖_1

試著為自己的任務編排個人用戶故事地圖,會有意外的收穫!

.

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

.

執行步驟.png

.

全景鬧鐘Panoramic alarm clock

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

.

一個人要如何敏捷呢?

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

.

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

.

緊急的工作 vs 重要的工作

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

.

善用個人看板

個人看板可以讓你腦袋裡的想法透明出來,這樣子的記錄可以幫助學習、增強記憶又能提供事後回顧時的軌跡,好處多多。(請參考Jim Benson 的 Personal Kanban)

.

0006

一個人的敏捷看板

.

{ 大家都知道"健康第一“這句名言,但卻很少把它放在心上 }

健康」包括: 身體健康,和心靈、環境健康,三者缺一不可。

.

克服無法持之以恆的焦點定律

要想養成一種持之以恆的習慣是不容易的。我們往往在聽完演講或有所見聞之後會開始計畫實行改變自己的生活方式,或是想要養成某一種好的生活習慣,但常常結果是三天打魚兩天曬網,無法持之以恆。為什麼呢,為什麼我們無法持之以恆呢? 失去焦點可能是一個失敗的最大因素。

.

kepler_2nd_law

根據克卜勒第二定律,在同樣時間間隔內,行星繞著太陽公轉所掃過的面積相等。

生活應該是多焦點的

行星的運行是有恆的,它依據橢圓的軌跡,運行規則是;橢圓軌道上的任意點到二個焦點距離之和為一定值。也就是說;在同樣時間內太陽和運轉中的行星的連線,所掃過的面積是相等的。這有一點「天行健,君子以自強不息」的味道。用橢圓來詮釋天體的運行是著名的克卜勒(Kepler)定律。橢圓形是一個有趣而特殊的圓形,它有二個焦點,就好像我們每一個人,都有在公司與家庭之間的生活一般,如何尋求像行星一般的運行規則,讓工作和家庭生活能夠取得好的平衡,明顯的是人生的一個重要課題。當你在運行個人敏捷開發的時候,便很容發現自己會將公司的工作和私人的生活混在一起的現象。上面的個人看板就展現了這種狀況。這是事實也是真正的現象,這樣畫的看板是正確的,千萬不要把生活上的任務跟公司的工作分成二個不同的看板來執行。因為如何取得二方面之間的平衡點才是重點,分開來便無從比較,看不出二者之間的比重了。下面是我的建議:請運用個人用戶故事地圖來實踐多焦點的視覺化。

.

個人故事地圖運用個人的用戶故事地圖來尋求「生活焦點」

.

個人任務的用戶故事地圖

日常生活裡,不論在公司或是家裡,都有太多任務等著我們去處理了,如果我們不能經常看見全貌,可能就會造成一些自己所無法預期的後果. 而把任務排成用戶故事地圖正可以協助我們看見全貌。(如果你很熟悉用戶故事地圖的話,可能會發現地圖的最左側欄位多了些什麼,那是我拿來簡單分類用的目標欄位,是不是讓整個視野一下子變得容易規劃多了呢?).

個人用戶故事地圖可以讓人好像看到了自己的未來,一些我們每天急急忙忙過生活都沒花時間去注意的事情,現在看到了,然後有機會去規劃實踐它了,它讓我們彷彿看見了生活的全貌。接著該作的是排序,依照事情的輕重緩急排列一下,然後把最重要的幾個任務放進待辦清單理頭,設定好你的全景鬧鐘,讓自己進入專注模式,開始衝刺吧!

.

結論

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

.

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

.

看遠一點

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

.

 

註1. 參考自單核工作法

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

註2.  5件事清單

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

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

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

註4. 時間管理. 史蒂芬·柯維

著名管理學家科維提出了一個時間管理的理論,把工作按照重要和緊急兩個不同的程度進行了劃分,基本上可以分為四個“象限”:既緊急又重要(如人事危機、客戶投訴、即將到期的任務、財務危機等)、重要但不緊急(如建立人際關係、新的機會、人員培訓、制訂防範措施等)、緊急但不重要(如電話鈴聲、不速之客、行政檢查、主管部門會議等)、既不緊急也不重要(如客套的閑談、無聊的信件、個人的愛好等)。時間管理理論的一個重要觀念是應有重點地把主要的精力和時間集中地放在處理那些重要但不緊急的工作上,這樣可以做到未雨綢繆,防患於未然。在人們的日常工作中,很多時候往往有機會去很好地計劃和完成一件事。但常常卻又沒有及時地去做,隨著時間的推移,造成工作質量的下降。因此,應把主要的精力有重點地放在重要但不緊急這個“象限”的事務上是必要的。要把精力主要放在重要但不緊急的事務處理上,需要很好地安排時間。一個好的方法是建立預約。建立了預約,自己的時間才不會被別人所占據,從而有效地開展工作。

.

0017.png你該這麼處理

註 5. 請參考: 斯蒂芬·科维的《高效人士的七个习惯》

積極主動、以終為始、要事第一、雙贏思維、知彼解己、集思廣益和自我更新。

.

 

 

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