Ruddy Lee 分享空間

Emergent Design 演化設計

Archive for 三月 2015

與大師對談: 精實軟體開發之看板方法

leave a comment »

我從來不用PowerPoint上課的,所以這份已經放在 Slideshare上面的 PPTX 檔,是提供大家用來做參考的。

這次的課程目標有二個主題:

  • 解釋精實開發的原則

    希望把精實開發的七個原則闡述清楚,這組原則它的影響深遠,可以用來協助企業茁壯或是脫離困境,甚至能拿來做治國(尤其適用在資源貧乏的島國)採用。它所影響的不只是軟體的開發方法,而是企業的文化層面,它讓豐田紡織成長成了今天的豐田企業(Toyota 是1937年成立的,78年的歷史快要是Microsoft的二倍了,微軟是2015/04/04 成立40周年紀念)。很值得推廣的精神原則。(但是話說回來,真得很難拿來講課,難講死了! 只是不去嘗試,又怎麼有機會講的好呢? 所以再來一次了,非講好不可。)

  • 如何提升個人的效能?

    由To Do List 到使用看板來運作自己的生活及工作。仔細的描述了,如何將To Do List 的工作項目搬到看板上來運作。希望對學員有所幫助。

講解中我有提到半成品WIP利特爾法則Little’s Law這些需要進一步做說明的東西,但在課堂上都只是輕描淡寫的帶過,沒有深入去說明,希望讀者有空時自行去研讀。

而精實七原則的說明部分,則刻意的把一直是被放在最後面的「著眼全體」搬到第一個來講解。原因是這些原則本來就沒有重要性的區別,可以一視同仁地來運用,而大家都習慣從「消除浪費」開始,造成聽者容易只記得前面的原則,而忘了後面的這幾個傢伙,所以這回倒過來說明。希望有效。

1_1

課程目標

.

為了說明精實軟體開發是沒有開發方法而只有原則的這一段說明,就把軟體開發法的設計原則拿來做了簡單的說明,採用的範例是最受歡迎的敏捷開發架構 Scrum。

7

設計一個軟體開發法的基本考量

.

從 To Do List 開始到轉成App的形式-卡片化工作事項

抽象化後的工作流程,溶入於看板中,立刻就將視野由單一的表格,變成具有狀態顯示的狀態看板,為要避免呆板不符合現實的狀態,記得要加入次欄位的設計。

to

加入「緩衝區」讓狀態更清晰

buffer

運用次欄位: 加入「緩衝區」讓狀態更清晰

在不影響產能之下限定半成限額 Work In Progress

wip

加入半成品WIP限額 … little’s law

.

解讀「看板」: 輪流由團隊成員進行看板解讀,是避免有人掉隊的最佳方式。

read

透過看板的解讀,才能真正實行拉動系統 Pull System

.

沒機會到現場的朋友,歡迎參考一下SlideShare 上的PPTX,但有一點可以肯定的是,我一定講不完的,所以60頁的資料僅供參考。

※ 廣告一下;我預計只會講完第一部分,也就是精實開發那段說明。To do list 轉換到看板這一段,來上我的看板課程就聽得到了

cc

.

回顧

果然如預期,只講完了上半段,也沒有講得太很好,精實原則;它是那麼好用,怪不得有許多人花了整本書就在描述這個,我在書裡只寫了一章、只用了10張 Slides當然講得不完整,再改進了…。但是學員們還是很捧場,感謝大家!

image

讓大家空著肚子等候許久真不好意思,工作人員也辛苦了,謝謝!

<補一些照片>

IMG_8298 IMG_8301 IMG_8303 IMG_8314 IMG_8322 IMG_8325 IMG_8326 IMG_8331 IMG_8075 IMG_8252 IMG_8261 IMG_8264 IMG_8269 IMG_8270 IMG_8273 IMG_8277 IMG_8278 IMG_8287 IMG_8292 IMG_8293 IMG_8295

廣告

Written by ruddyllee

2015 年 03 月 31 日 at 22:24:55

張貼於未分類

專案估算: 高估了好還是低估比較好?

leave a comment »

業務與工程師爭執,每次專案都沒有辦法估算的準確,那到底是高估工時好呢還是低估好?

基本上;高估要比低估好上許多!

因為低估的損失遠大於高估,如下圖所示:中間的箭頭部分表示上升的越高則工作量、成本越大而開發時程也越長。

估算1

.

當然是估準了最好! 可是那種估中的機率就像抽中了過年的第一大獎一樣少有! 但又不太一樣,因為工程師們經常是靠著努力工作來換取準時交件的。所以如果我們能在高估的情形下,再靠努力來換取專案的提前完成,不是皆大歡喜嗎!(因此;人,才是專案開發最大的變數)

估高了;容易導致帕金森法則(Parkinson’s Law)的現象,工程師只在意準時做完份內的事,並不在意工作效率這回事,就好比學生們做暑假作業一般,沒到暑假結束前是不會動工的,因此導致時間上無謂的浪費。

估低了;專案可能因為時間不足而做不完,甚至導致專案失敗。從統計的角度來看,降低了按時交付的可能性,還可能有意外的損失(員工被要求拼命加班,很容易產生離職的考量)。專案基礎不穩固,即使驗收過關,未來的維護作業也會蒙上一層陰影,導致信譽與金錢上的雙重損失。

高估的時候,可能賠上右側那條紅色的斜直線性的損失。估低了;則不只是專案可能遭致失敗的命運,同時還賠上其他維護、信譽受損等非線性的損失(如上圖左側的紅色曲線)。估高了的時候,產生的帕金森法則可以用管理來克服,但低估了就只有勞民又傷財了。

.

如何避免低估了呢?

先問自己: 你都怎麼做估算的呢? 估算牽扯到的是直覺、比較或是猜測。務實的工程師會跟我辯解說他可是一項一項功能既努力有辛苦的加總起來的數據,怎麼說都不會差很遠的。是的,你的努力通常是不會白費的,透過breakdown分成細部功能,再一一加總起來絕對是有幫助的,最起碼你又review了一次。這裡有幾個基本動作在你開始這些行為之前需要弄清楚的。首先;

範圍第一」:有一個圖表對範圍的判斷會有一些幫助 — Stacey Matrix.

 

89

 

先客觀的看一下手頭的專案在 Stacey 博士的「專案複雜度判斷」的落點在哪裡? 先用這個落點來判斷專案的範圍。專案隨著工程師的開發與學習過程,落點也會隨著改變。結果應該是代表橫軸的需求代表縱軸的技術都趨向軸心點,也就是進入"簡單“的範圍。這是成功的專案的必經之路。口語化的描述是: 工程師弄清楚了客戶的需求,也學習到了開發的技術,因此專案變得簡單了便容易做成功。依據"複雜度判斷"的方式你可以客觀的知道專案落在哪裡,再採取相對的措施。提醒你: 先客觀的審視一下專案,看看需求(他是否指向真正的問題),再看看技術(你是否有足夠的資源讓團隊在時程內學會這項技能),這是讓專案成功的最基本要求。

 

dilbert

不要因為估算而相互責難,其實只是立足點不同所致。

.

估算前後的心情「客觀第一」

不要因為估算被責難,而懷恨在心,這是不值得的,其實只是立足點不同所致。

不要為估算而產生意氣之爭,因為只要是估算,基本上都不會太準確,當然隨著時間的過去,時間越晚在做估算自然就會越準確,快做完的時候估得最準。(請參考Steve McConnell的不確定性錐)

Cone01

不確定性錐

Fred Brooks 曾說因為時間不足所導致的軟體專案失敗,比其他所有原因導致的專案失敗全部加起來還要多。(人月神話)

經驗讓我們容易低估專案的時程

不是只有業務或老闆希望估低一點開發的時程(能夠盡快做完才有錢拿)。有時候經驗豐富的工程師也會估得比年輕工程師低一些,因為他對自己的能力有相當的信心。但是如果做的人是年輕的工程師的話。寧可高估也比低估來的好些!

 .

參考: 1. Is It Better to Overestimate or Underestimate? 2. 帕金森法則 Parkinson’s Law 1958年,英國曆史學家、政治學家西里爾·諾斯古德·帕金森(Cyril Northcote Parkinson)通過長期調查研究,出版了《帕金森定律》(Parkinson’s Law)一書。帕金森經過多年調查研究,發現一個人做一件事所耗費的時間差別如此之大:他可以在10分鐘內看完一份報紙,也可以看半天;一個忙人20分鐘可以寄出一疊明信片,但一個無所事事的老太太為了給遠方的外甥女寄張明信片,可以足足花一整天:找明信片一個鐘頭,尋眼鏡一個鐘頭,查地址半個鐘頭,寫問候的話一個鐘頭零一刻鐘……特別是在工作中,工作會自動地膨脹,占滿一個人所有可用的時間,如果時間充裕,他就會放慢工作節奏或是增添其他項目以便用掉所有的時間。

Written by ruddyllee

2015 年 03 月 24 日 at 19:15:10

軟體估算: 黑夾子揭密

leave a comment »

這本書是屬於軟體的估算類的書籍,這是 Steve McConnell 在2007年的佳作(獲獎無數的Code Complete作者 )。雖然書中缺少敏捷的觀念,主要是面向軟體發展專案中要進行估算的開發人員和技術管理人員。但所涉及的與軟體估算有關的背景知識,以及有關估算談判和表達方式的討論,對於非技術人員出身的主管和專案的其他有關人員同樣大有裨益。

Cone01

根據日曆時間得到的不確定性錐 Cone of Uncertainty

 

.

有一個很重要但也是很難理解的概念,就是不確定性錐代表了軟體專案在不同時刻所能得到的最佳準確度(Base-case accuracy)。錐形代表了由有經驗的估算人所建立的估算中的誤差。情況很可能更糟。估算結果不可能比不確定性錐給出的限制更準確,只可能是碰巧很接近。

–Steve McConnell

  • 我的「信心點估算」中的1/5 到 1/3開發時間的信心點,剛好落在圖上的在需求詳細(Requirements Complete)化到使用者介面設計(User Interface design complete)之間。正是專案未知數在大量收斂的地方,也是程式開發人員逐漸獲得信心的地方。

 

不確定性錐 Cone of Uncertainty

上圖中,它顯示了(範圍、代價、功能的)估算值是如何隨著專案的進展變得準確的。隨著時間的推移,專案的不確定性逐漸降低,當專案即將結束時,開發團隊能夠準確預期專案的結局。但是它也提醒我們專案在開始階段,不確定性非常高,甚至可能高達4倍(Initial Concept)。

他闡述了軟體估算的深入含意。簡單區分了良好的估算和不良估算的方法。讓你個人或團體可以用來建立良好估算的種種方法。並教我們如何穿越估算時的危險泥沼。

估算中沒有甚麼是完全不受其他事情影響的。估算活動是海森堡不確定性原理在軟體方面應用的一個例子。必須要三者一起考量: 估算、目標和承諾。當對這三者一起考量時也同時間觸發著估算的準確性。因此看清楚估算的真正目的,才是重點。

我們進行專案估算往往不是要得到結果,而只是想知道可能實現嗎?

(這是工程師們開發程式的必經階段也是最佳練習,務實才是上策!)

 

515Ft6t++kL

無意間找到談估算的佳作,卻是工程師必須要知道的基本功。

 

 

Written by ruddyllee

2015 年 03 月 16 日 at 10:19:56

張貼於未分類

精實軟體開發之步驟二、幫To do list加入狀態: 看板篇

leave a comment »

todolist

傳統的待辦工作清單(To do list)

待辦工作清單(To do list)在多工的情形下確實幫不上什麼忙。看起來像一串的表單,即便我們紀錄了工作狀態,當想知道工作事項的狀態時就得一個一個的去查看,很是麻煩! 但;若是我們向旁邊加入第二個欄位或更多欄位,用來描述工作事項的狀態,在視覺上就完全改觀了。

kanban_0

工作事項列表加入流程狀態後就成了看板

 

.

上面的圖示裡,我們為工作清單(To do list)加入了,開始作業的「進行中」In progress欄位,以及作業完畢之後的「完成」Done二個欄位。這樣的改變,使得工作清單一下子變成了描述流程的工作看板。把「完成」圈起來的目的,是想強調在多工作業時完成的意義更重於單工作業。因為多工所帶來的作業轉換除了轉換工作時的消耗、時程壓力,其實最可怕的是缺陷的產生,錯誤是其次因為它容易被看見,但隱藏著的缺陷才是在未來必須付出龐大代價的東西。因此值得在這裡強調Done的定義。

 

將流程據實的對照到工作看板上

上圖只顯示了「待辦 – 開始 – 完成」三個很抽象的流程狀態。當我們想多知道一點目前工作的狀態時,免不了還是需要去翻閱各個工作事項的紀錄,然後再試著跟流程結合起來,才能夠看出整個工作流程的現況。如果要改善這個問題,就必須讓真正的工作流程能夠與工作看板有著一致的流程對照,如此便能夠清楚的看到每個工作項目在工作看板上的流動過程。這種繪製實際工作流程的各種活動的對照行為就稱之為繪製價值流程圖(Value Stream Mapping,它的價值巨大這是無需多說的,它是豐田精益製造Lean Manufacturing的製程控制基礎)。

realflow

將流程據實的對照到工作看板上

 

.

緩衝區的設計

進行中的欄位下方的二個次欄位的部分就是所謂的「緩衝區」的設計,也就是增加「進行中」和「完成」的次欄位,它的目的是讓主欄位的工作狀態更清楚。同時可以顯示哪裡出現了「盈餘時間」。

加入半成品(Work In Progress)限額

為欄位設定WIP限額是看板方法的必要步驟,如果你發現工作板上沒有為WIP設限,那基本上它就不是在實施看板方法(依據看板之父 David J. Anderson所述)。為流程設定同時可以進行的工作數,目的是為了追求最大產出而有效的限制半成品數,他是依據利特爾法則(little’s law)而來。(詳細資訊參考: https://ruddyblog.wordpress.com/2014/10/19)

add_wip

完成半成品限額的設定

 

.

上圖中在檢核(Verify)欄位中我們將WIP設成2,表示這個欄位最多只能同時有2件工作項目在進行中,而他的前一個欄位(進行中欄位)則有3個半成品的額度,這表示當進行中的項目只要遇到粒度較小(較容易完成)的工作項目時,就很容易會產生阻塞的現象。既然知道容易出現阻塞的問題,那為何還要做這樣的設計呢?理由很簡單;因為它可以盡快找到問題。如果你的產品不容許有任何差錯的話,則可以嘗試將檢核欄位的限額改成1,這表示只要有任何工作項目出問題,整個流程就會被強迫停下來,一直到它被解決了為止。

啟動拉動系統

依照重要性排序完待辦事項之後,接著就可以開始由最重要的工作事項來啟動流程了。流程由左往右、由上往下,只要前面的關卡沒有發生阻塞(依據各個欄位設定的限額大小),就可以把它拉進來開始進行工作。這個拉動的行為就稱它為實行拉動系統(Pull System),通常由團隊成員自己主動做拉動(Pull)的工作,而不是被上級所指派(Push)去做某一項工作。這是典型的自主行為,完全符合團隊自主組織的定義,是屬於效能最佳的一種工作方式。

pull system

拉動系統事主動挑選工作事項的行為表現

 

.

阻塞的現象

當欄位前面的關卡到達半成品(WIP)的設限時,流程就被迫停止下來了。我們稱它為阻塞(Blocked)的現象。這個時候,所有的團隊成員都會發覺流程不動了,此時,通常手頭工作已經做完的成員為主動過來幫忙,因為它甚麼事都不能做了,無法拉動新的工作事項進來工作,當然就只能來幫忙了(這是團隊發生共同面對問題的時間,團隊精神在這裡將會得到發酵,主管可以客觀的觀察整個協作的過程,這是得知成員個人個性的好時機)。

blocked

流程阻塞

 

.

沒有產能! 這對流程而言是一大傷害,所有的人瞬間都會勒緊褲帶、戰戰兢兢的過日子,此時盡快找出解決方案才是上策。主管要切記;千萬不要由釐清權責的怪罪或責難工作不力開始。工作流程因為跟大家都息息相關,所以非常容易勾起情緒上的反應,如果是針對個人的話;它容易反映你的工作效能及待人處事的能力。對於團隊而言,就更為有趣了,請參考以下的分析:

【剛剛做完手頭工作的成員】

  1. 會有機會再肯定手頭的工作事項是不是真的、踏實的做完了。

  2. 會思考是不是自己先前工作所造成的,或是評估是否會對自己未來的工作事項有所影響。

  3. 會主動去幫助跟自己最熟悉的夥伴。

【手頭還有工作的成員】

  1. 雖然抽不出時間來幫忙,但會詢問狀態並嘗試提供意見。

  2. 思考是不是自己先前工作所造成的,或是評估是否會對自己目前的工作事項有所影響。

【主管】

  1. 避免直接聽取問題的來源,減少干擾正在奮戰解決問題的工作人員,應該選擇信任成員能夠自行解決問題。

  2. 採取事後檢討的方式,避免直接介入問題,並應該保持樂觀的態度。

  3. 藉著每次危機處理,增強團隊協作的能力。

  4. 認識成員的人格特性,引導他們朝正面發展。

 

更完整的看板漫畫可以參考

精實軟體開發之步驟一、識別浪費

 

 

 

Written by ruddyllee

2015 年 03 月 05 日 at 15:29:09

張貼於未分類

Tagged with , ,

如何形成簡單的團隊規範

leave a comment »

敏捷開發一再強調要讓團隊自我管理,也就是所謂的「自主組織團隊」。

此時主管應該跟團隊一起制定「簡單的規範」,然後就可以放手讓團隊依循這個規範來協同合作進行開發作業;只要成員不逾矩,主管就盡量採取在一旁觀察的模式,讓團隊自動自發自我管理。這是一種公認效能最高的團隊管理方式,但難為的是即便主管有心這麼做,團隊成員也願意配合,但是要怎麼制定簡單的規範(pptx在這裡)呢?這個問題幾乎普遍存在於所有敏捷開發團隊裡。

imagesF4MJPKS9

自我管理的團隊,是效能最高的團隊。

.

從改善品質開始

 人們通常都害怕改變,當你用命令的方式去下達規範,希望藉由嚴格的紀律去改變他們的行為,反而會降低他們的自信心,因而表現得更被動,或是產生反抗的心態。那該怎麼做呢?處理團隊的問題就該用團隊的方式做考量,答案是先讓他們團結起來,先從建立其他團隊對這個團隊的信譽開始,沒有比捍衛團隊榮譽更能讓大家團結起來的方法了。因此,我總是由改善質量(quality)開始,對外,用逐漸改善的品質讓其他團隊更加尊重自己的成員;對內,用改善品質的做法建立紀律,讓團隊成員收斂鬆散的心態。品質是一種很有趣的東西,當你開始注意它的時候,它就已經開始在改善了,當品質開始改善的時候,你會發覺紀律也會跟著建立了起來。因此;第一步關注品質,從改善品質來建立團隊紀律是實施「簡單規範」的基石。

7

.

提供我習慣的做法給各位做參考,我會規定所有會議的前 3 ~ 5分鐘一律做缺陷(Bug)的檢視,把缺陷建立成表格隨時可以調閱到它。開會時先由第一大嚴重缺陷開始問起,是誰負責的?何時會解決?有必要提升或降低重要性嗎?請讓我再強調一次:

品質是一種很有趣的東西,當你開始注意它的時候,它就已經開始在改善了。

.

團隊永遠都是繁忙的

 一個繁忙的團隊就好像已經盛滿了水的杯子一樣,它是沒有辦法再加進任何東西了!你必須先把盛滿了的杯子空出一些空間來,才可能再往裡頭加東西。所以在你開始進行改革之前,先要設法幫團隊找出空閒的時間,怎麼做?就是在不影響產能的情況下減少他們的工作,甚麼是不影響產能的工作呢?「半成品」正是那個不會影響產能的工作,說穿了就是減少「半成品」的數量。

water

盛滿了水的杯子,沒有辦法再加進任何東西

.

對軟體開發而言,半成品就是指那些尚未能做到完成的工作,例如:進行了一半的設計,好比 API 的設計作業,負責寫 API 的人與需要呼叫它來取得服務的人,如果不能協同開發,當一個做好了必須等另一半也完成後才能進行測試作業,則工作就懸在那裡了,這個懸在那裡的工作就叫做半成品(Work In Progress)。能夠減少進行中的設計工作,這對品質的提升也會有所幫助的。

WIP

半成品 (Work In Progress)

.

把現行的工作仔細的畫下來可能是找出半成品(做一半的工作項目)最好的方式了。因此第二步是畫出現有的工作流程,找出現有的、不影響產能的半成品設計作業,然後減少做半成品的設計工作,如此便可以找出空閒的時間來了(在看板方法中,我們稱它為「盈餘時間」)。

到這裡,我想你已經知道我的葫蘆裡在賣甚麼膏藥了。上面的陳述裡,我們引用「當嘗試改革一個團隊時,如何替這個團隊建立一套簡單的規範」做為需求,而採取的步驟正是建立看板方法的基本步驟。所以實施看板方法基本上就是在建立一套簡單的規範,當看板上的工作項目開始流動時,只有當有工作完成被移動出去之後,才會再有新的工作被拖拉進來,這種作業方式就稱為「拉動系統」。團隊成員在看板牆上自行拖拉更新工作項目的動作,就是一種另類的簡單規範,他不需要被命令,完全沒有指派工作的作業動作,而是以拉動的方式持續工作流程的進行作業。這是一種即時的作業方式(Just In Time),具有最佳的效能表現。

實施看板方法基本上就是在建立一套簡單的規範。

.

rules

.

難道就不用制定實際的條文了嗎? 不;既然是簡單的規範當然就需要有簡單的條文,請參考該團隊在 Scrum Retrospective 會議裡的決議,就是很好的依歸。請謹記,任何開發方法都不該與公司的文化相違背,如果有所衝突,當然以公司的文化為重。

.

找個共同的工作來輪值,也是落實團隊自我管理的好方法。例如:以值星的方式來輪流作看板的整理及維護工作。

.

Written by ruddyllee

2015 年 03 月 04 日 at 11:34:13