Ruddy Lee 分享空間

Emergent Design 演化設計

Archive for 八月 2016

工程師如何自我管理?

with one comment

.

工程師的本質愛好自由自在的工作,不喜歡被管理。

寫程式辛苦嗎?當然辛苦但我們樂在其中。《人月神話》的作者Fred Brooks總結了身為程式設計師辛苦之下的樂趣:

第一、是純粹的創造所帶來的愉悅…。

第二、因為作出對其他人有用的東西而帶來的快樂…。

第三、是設計複雜邏輯元件並看著他們像魔術般的運作所產生的吸引力…。

第四、是持續學習的樂趣,原因是每次的任務總是不相同,沒有重複的特性…。

第五、因為工作的對象是可以自由駕馭的程式碼,這一點令人開心。

.

你很難讓團隊的每個成員都變成傑出優秀的工程師,

但可以確定的是幾個優秀的工程師就能讓團隊變得更優秀。

.

合群會讓人更優秀

程式設計人員大都很能自我享受工作,無形中把寫程式變成了一種樂趣(如果你還是覺得很辛苦,或許是因為頭髮多了些,那就再多寫個幾年吧XD),我們喜好自由自在的工作,也樂於接受它的挑戰,這便是程式設計師與他(她)的工作。我們不喜歡被管,因為管理會無形中降低了這種樂趣,因此造成我們寧可關在房間裡寫程式也不喜歡去與人開會,這正是工程師總是不喜歡被管理的原因。但老實跟你說,如果你想要更快速成長的話,試著接受別人的管理其實是一件好事,它會讓你容易融入團隊,會讓你不會孤獨無援,而且事事有人照應,最起碼在出問題時還有人在上面撐著。

.

程式設計人員天生的主觀意識太強

我們容易為主觀意識所作祟,經常忽視自己的壞習慣,只看到別人的缺點而忽略自己也有著一樣的問題。這是因為「客觀」一直都不是我們所擅長的意識,往往需要借助一些外部的刺激或是設法消除主觀的偏見才可能讓自己客觀起來。至於如何借助外力呢?其中「看得見」可能是消除主觀意識的最簡單的解法。至於如何才能看得見呢? 我要推薦給你的工具就是個人看板 – 一種讓你足以客觀的看見事情真相的看板,我稱之為「客觀的個人看板」。

.

個人看板就是要你表現的更優秀

要習慣於表現優秀。但要如何表現得優秀呢? 《告別失控》的作者Mickey Mantle告訴我們把自己培養成為一位做事有條不紊、遵守紀律的工程師,也就是所謂的匠師Craftsmen,才能成為傑出的工程師。很不幸的是傑出的工程師實在太少了,那些習慣把動力的來源歸於時間計劃表管理層給予的壓力或是金錢的誘因所造成的程式設計人員,他們通常都不會是一名傑出的程式設計師的。因為要變得優秀得要有真正的動機,那種追求卓越的動力應該來自於更高的要求: 也就是對世界做出貢獻並且做出人們實際上樂於使用的程式或產品( Mickey W. Mantle)。

.

重複一下,要如何表現得優秀呢? 就是對自己要求更高,並立志對世界做出貢獻,然後開發出對人們有著實際作用的程式或產品(如果你成功地作到了,財富自然會隨之而來的)

.

Mickey《告別失控》書中強調自我管理的六件事:

  1. 個人風格

  2. 時間與優先級管理

  3. 溝通管理

  4. 管理實踐

  5. 跟蹤管理

  6. 尋找導師

 .

在這裡我想用個人看板來描述第一項、個人風格。至於其它項目,就交給想上進的工程師自己來吧!

.

000 客觀個人看板

可以讓你變得更客觀的個人看板

.

個人看板只要有異動最適合的作法是隨時隨地更新,只有一項原則最好不要異動,那就是睡前一定要靠在枕頭上回顧一下(這個行為我已經作好幾年了,效益驚人)。

 .

個人風格

Mickey書裡頭的「個人風格」所指的是工程師的穿著。所以不論你是要創立個人風格或是試著想要改變別人對你的觀感,請用個人看板來作紀錄,用功的紀錄它一周,每日嘗試改變、改善不同的穿著並勤作回顧,常常問周遭的人士給一點comment,一周之後一定大有斬獲的。如果沒有就去請教服裝專家囉!

.

000 告別失控

 

{我参考了 Mickey W. Mantle Ron Lichty 這二個老學究所合寫的《告別失控》一書,他們雖然展現了古板的思維模式,但對於團隊及工程師如何自我管理的描述,還真是給出了很多優秀的論點,相當值得参考。}

{也參考了Fred Brooks 的《人月神話》第一章第二小節:

程式設計行業“滿足我們內心深處的創造渴望和愉悅所有人的共有情感”,提供了五種樂趣:}

{繪製個人看板我經常是採用 Kanbanflow, 但開發團隊的看板則採用 Trello居多}

.

廣告

Written by ruddyllee

2016 年 08 月 24 日 at 16:42:36

張貼於未分類

Tagged with ,

貴公司的品質如何?

leave a comment »

.

有沒有實施「缺陷管理」是品質好壞的基本分水嶺。

.

品質好還是不好?好抽象!這個問題還真是很難回答。我們作顧問的經常會問客戶這個問題,目的倒不是想聽到什麼特別的回答,其實只是做個開場,問一下客戶是怎麼作專案開發的,有沒有把測試當作是重點。通常;我會接著表明會從「要求品質」開始。(如果你問我為什麼要從品質開始呢?回答是,品質跟紀律是一體的二面,從要求品質開始就是要求紀律。這是從事顧問工作的第一步,先奠定團隊的基礎,雖然要求品質這種做法,效果很難立即看得出來,但是它對團隊而言總是好的,是從長遠作計畫的作法,而對顧問工作來說則是為了紀律,紀律可以幫助團隊更容易接受變革(尤其是由傳統的開發法轉變成敏捷開發),紀律可以幫助團隊更容易邁上自我管理之途,同時也能幫助顧問取得與團隊之間的彼此尊重。反觀;程式設計人員是一種腦力工作者,自由自在的思維容易帶來散漫(這是一種常態),因此亟需要紀律。而紀律是由一群工程師組成的團隊,最容易缺乏的東西。總之;提高紀律是一個成功的開始。

 

缺陷管理系統 Bug tracking system

有沒有實施「缺陷管理」是品質好壞的基本分水嶺。將缺陷記錄在資料庫裡然後便可以持續的去追蹤問題,這是最基本的品質要求。約耳( Joel Spolaky)在 Joel on Software 裡寫過如何來評鑑軟體團隊對質量的測試,寫得很籠統卻十分值得借鏡,就是下面的12條問題,本文想強調其中的第四條問題,然後用「缺陷追蹤看板」來協助那些還沒做到的團隊。

.

The Joel Test (註 1.)

  1. 你有使用原始碼控制系統嗎?

  2. 你能用一個步驟建出所有結果嗎?

  3. 你有沒有每天都重新編譯建立(daily builds)嗎?

  4. 你有沒有問題追蹤資料庫(bug database)?

  5. 你會先把問題都修好之後才寫新的程式嗎?

  6. 你有一份最新的時程表嗎?

  7. 你有規格嗎?

  8. 程式人員有沒有安靜的工作環境?

  9. 你有沒有用市面上最好的工具?

  10. 你有沒有測試人員?

  11. 有沒有在面試時要求面試對象寫程式?

  12. 有沒有做走廊使用性(hallway usability)測試?

.

缺陷與需求具有本質上的差異

負責專案生命週期管理的軟體通常都會包含 Bug Tracking 的缺陷管理機制,它們(一般)把Bug當成需求開發的項目來處理。乍看之下似乎沒有甚麼問題,但實質上對工程師而言需求是運用邏輯創意來達成客戶的要求,一旦達成之後這個成功的功能便可以一再的來複製使用。而缺陷則是處理已知程式不能正常運作的問題,缺少了邁向未來的挑戰性,一旦缺陷解決之後,很少有工程師能夠有機會重複使用解決它的方法。所以當ALM(Application Life cycle Management)的管理程式等閒看待這二者時,缺陷便是經常被忽視的一方,也間接造成了缺陷管理上的不足,而使得品質上難以得到提升。

.

缺陷追蹤看板 – 讓你看見品質

缺陷跟蹤管理系統是用於記錄程式缺陷的報告它出現的時間、嚴重度,異常程式的表現以及如何重現此缺陷的細節;再來就是指出造成程式缺陷的人員和可能修正此缺陷的程式設計人員(註2.繁雜的缺陷屬性細項)。它應該是不斷跟蹤軟件缺陷在其生命周期中被分配的狀態指標。但由於一般的ALM系統把Bug當成需求開發的項目來處理,反而造成了大家忽視持續追蹤的重要性。關於這一點我們可以運用看板來補足它。這種所謂的「缺陷追蹤看板」與一般看板有所不同,很少工程師會在缺陷解決之後,還持續去關注它的,一般都只有主管或測試人員才會願意多花心力來關注它。因此缺陷追蹤看板通常都是置於測試部門或是主管房間,讓有興趣關注它的人持續去追蹤。

.

000 Bug Tracking _3

缺陷追蹤看板

》缺陷經常是俱有即時性的,迅速對缺陷做正確的判定甚為重要。對於緊急事件,可以在看板下方另外開立渠道來做快速處理。

》一般對尚未定義缺陷優先等級或嚴重性時,就應該先行判定是缺陷、待補強功能或是未來的新開發功能。

缺陷管理系統的Queue處理原則就是團隊對於品質要求的原則。這也是缺陷與需求最相像的一個地方,他們都必須持續去關懷(refinement),因為它們都會隨著產品的生命週期而改變。

》工程師被要求針對這個缺陷需要多少時間才能修復完畢去做估算,這才是一種真正有意義的估算。怎麼說呢?因為這跟對還沒做過的需求做估算完全不同(那是對未來的一種猜測,很難猜得準的),這是對自己已經處理過的事情,只是因為某些因素沒有考慮到而表現得不太一樣的行為,進行估算如何修復它,這可是完全合情合理的。而且越是緊急就越能顯示出估算的真諦;也就是不必估算了,就是傾全力去做一直到解題完成為止,這就對了(這是我一直以為最有意義的事)。

.

將缺陷處理步驟分別以欄位的方式依序排列在看板上頭:

欄位一、缺陷與問題

將新的缺陷或是問題(指的是補強功能或是新增功能Feature)由測試團隊或產品經理提交給負責tracking的工具。一般而言除了急件,否則都是先把它放進Queue裡頭,等待下一個步驟被啟動時再來處理。

 欄位二、優先等級與嚴重性

由主管(產品經理)或團隊一同對缺陷(問題)設定優先等級和嚴重性,並將問題分配給特定的程式工程師。

 欄位三、估算

由負責修復的工程師估算修復這個缺陷所需要的時間。(缺陷與需求在估算上完全不相同,所謂解鈴還需繫鈴人,缺陷的估算無法採用類似需求的估算一樣,由團隊一起進行估算,一般只有原作者最清楚自己的程式有缺陷發生了,到底是怎麼一回事呢?因此也只有他本人才能做比較有意義的估算了)

 欄位四、發佈

開發部門或是負責修護的人員針對此特定缺陷或問題釋出新的內部版本。

 欄位五、測試

測試團隊檢查被標記為已修復的所有問題真的都已修復無誤。

 欄位六、完成

由測試團隊關閉此缺陷的跟蹤工具,並完整記錄修復此缺陷的整個過程。開始進行下一個缺陷(也就是回到欄位一)。

.

用圖形來試著做看板每個欄位背後的規則說明:

 

000 場景說明

缺陷處理的場景說明

.

缺陷管理的目標

  • 確保每個被發現的缺陷都能夠被有效的解決。

  • 這裡解決的意思不一定是被修正,也可能是其他的處理方式(例如保留作為功能或列入成為未來開發的新功能。至於缺陷是否在下一個版本中修正或是不做修正只列為保留,也就是持續追縱的意思),總之;對每個被發現的缺陷的處理方式必須能夠在開發組織中達到一致的做法。

  • 持續收集缺陷數據並根據缺陷趨勢曲線圖來識別測試過程的各個階段是否需要修正或加強。決定測試過程是否結束有很多種方式,通過缺陷趨勢曲線圖來確定測試過程(對時間的長短拿捏)是較為有效的一種方式。

  • 持續收集缺陷數據並在其上進行數據分析,並拿來作為組織在開發過程的種種紀錄的參考,最終將成為良好品質的基礎。

.

小結

缺陷處理」與「規格文件」都是評估團隊品質好壞的重要因素。約耳分別把他們列在第四、七項。這是一般團隊最容易忽略的二個項目,我們的理由都說是「等有時間的時候再來做它」,但我們就是從來沒有時間來處理它,而這些疏忽正是造就品質的重要依據。建議主管們就從今天開始採用缺陷記錄看板,用「看得見」來減少忽略問題提升品質吧!

到底是做「規格文件」重要還是處理「缺陷記錄」比較重要呢? 當然;記錄缺陷要重要一些,因為它總是比較緊急需要趕緊處理,一個是內涵另一個則是外觀,現在的Application 就是這樣,如果沒有外觀,則往往第一次被採用的機會都不會獲得,因此還是先把外觀弄好,也才能有機會展現內涵。

.

{ 為什麼只挑這二個項目來做說明呢? 因為它們是我每次做顧問時最常發現,他們可以做得很好卻經常疏忽的地方 }

{缺陷管理的描述細項相當的多,千萬不要用人工來進行,推薦二個工具給大家做參考,用Leangoo看板进行可视化的缺陷跟踪管理 ,另一個是 Lean Testing,它們都是Free的。(其實採用 Trello也行,但就像微軟的VSTS或是著名的 JIRA專案管理工具都已經內含Bug Tracking 的能力在其中了ㄧ樣,務必在製作自己的缺陷管理看板,如此就可以避免遺漏時時提升品質的重要性了)}

.

註1. Joel on test

為 Joel Spolsky 所著,他的 Joel on software 曾經獲得2012 JOLT大獎。

註2. 對缺陷的描述應該包含以下的內容: (參考自台灣word)

  • 可追蹤信息
  • 缺陷ID : 唯一的缺陷ID,可以根據該ID追蹤缺陷
  • 缺陷基本信息
  • 缺陷狀態: 缺陷的狀態,分為「待分配」、「待修正」、「待驗證」、「待評審」、「關閉」
  • 缺陷標題: 描述缺陷的標題
  • 缺陷的嚴重程度: 描述缺陷的嚴重程度,一般分為「致命」、「嚴重」、「一般」、「建議」四種
  • 缺陷的緊急程度: 描述缺陷的緊急程度,從1-4,1是優先順序最高的等級,4是優先順序最低的等級
  • 缺陷提交人: 缺陷提交人的名字(郵件地址)
  • 缺陷提交時間
  • 缺陷所屬項目/模塊: 缺陷所屬的項目和模塊,最好能較精確的定位至模塊
  • 缺陷指定解決人: 缺陷指定的解決人,在缺陷「提交」狀態為空,在缺陷「分發」狀態下由項目經理指定相關開發人員修改
  • 缺陷指定解決時間: 項目經理指定的開發人員修改此缺陷的deadline
  • 缺陷處理人: 最終處理缺陷的處理人
  • 缺陷處理結果描述 : 對處理結果的描述,如果對代碼進行了修改,要求在此處體現出修改
  • 缺陷處理時間 : 缺陷處理所發掉的時間
  • 缺陷驗證人: 對被處理缺陷驗證的驗證人
  • 缺陷驗證結果描述: 對驗證結果的描述(通過、不通過)
  • 缺陷驗證時間: 對缺陷驗證的時間
  • 缺陷的詳細描述: 對缺陷的詳細描述;之所以把這項單獨列出來,是因為對缺陷描述的詳細程度直接影響開發人員對缺陷的修改,描述應該儘可能詳細
  • 測試環境說明: 對測試環境的描述
  • 必要的附件

 

Written by ruddyllee

2016 年 08 月 22 日 at 11:49:41

客戶訪談 -敏捷vs傳統

leave a comment »

.

不寫規格書是軟體專案開發中最大不必要的風險,其愚蠢程度就像不帶裝備就想橫越寬闊的莫哈維沙漠,並心存僥倖能逃過一劫。

–   Joel Spolsky

.

000 requirements

敏捷規格文件的產出物及流程

.

 第一份文件

傳統的開發方法;訪談的目的就是要產生第一份規格書。首先;與客戶約好時間過去訪談,採用一對一或一對多的採訪方式進行並做成紀錄。接著將紀錄帶回公司之後一定要趁熱,在客戶還沒有開始遺忘訪談內容時盡快地整理成文件並讓客戶確認。客戶確認過(簽名蓋章)的這份文件便是專案開發最重要的依據了。如果能夠順利地進行到這裡,系統分析人員便可以依據這份文件開始他的分析作業,接著是系統設計人員上陣把該做的架構設計完備(當然,資料庫的設計也OK了),然後再交棒給程式開發人員的手上來進行實際開發作業,此時專案便可以算是順利地開始運作起來了。整個流程看似人人各盡其職,每個關卡都把任務交給擁有專長的人做它們最拿手的事,這很合理,但敏捷開發並不這麼做。

 

收集使用者故事,弄清楚客戶真正的需求

敏捷開發則是將訪談設定為: 設法收集描述客戶需求所採用的使用者故事(而使用者故事嚴格說起來不能算是功能規格的描述文件,它的目的只是想藉由故事來引出交談討論的效益),而目標則是放在能夠弄清楚客戶真正的需求。

 .

000 客戶訪談

邀請客戶與開發團隊一同進行需求訪談.

.

敏捷開發所進行的訪談方式與傳統開發的正好相反,敏捷開發是邀請客戶到公司來對著整個開發團隊一起做需求說明的方式,讓負責開發的工程師(整個團隊)實際上與客戶面對面一起進行討論,而不是透過SA或PM來進行所謂的專訪紀錄。無疑的這是一種成本較高的訪談方式,但它能給真正負責開發的人員有機會接觸到真正的客戶(這一點未必辦得到,因為要找到真正的客戶,有時候還真是困難)並就需求進行討論,對未來的開發作業有著莫大的幫助,這一點不難理解,但是很多人認為這樣做會太花時間了,還不如把工程師的時間節省下來進行真正的開發工作,其實這便是約耳所謂的最大的錯誤,它就跟不寫文件,認為「寫文件」是浪費一模一樣了。請務必再看一次文章開始那句話。

.

不寫規格書是軟體專案開發中最大不必要的風險,其愚蠢程度就像不帶裝備就想橫越寬闊的莫哈維沙漠,並心存僥倖能逃過一劫。

–  Joel Spolsky

000 JOEL

Joel 有中文名字

 .

邀請客戶與團隊一起做訪談,可行嗎?

如果開發團隊只有一個人,那又要如何來進行訪談呢? 這是普遍開發人員都會碰到的問題,一個人的開發專案要怎麼做呢? 這種單打獨鬥型的開發人士不論國內外或是大的IT單位,都是經常會遇到的情境,那該怎麼進行呢?

 

一種運用資深人才或技術領導Technical Lead的作法,它是讓技術小組的組長或資深人員陪同負責開發的工程師一起進行訪談的作法。除非你是一個人的公司,否則千萬不要讓工程師一個人埋頭苦幹,然後才在背後說完全不知道他都在做什麼(苦笑)! 一定要製造一種讓團隊能夠互相扶持與回饋的作法。敏捷;只要是開發團隊就需要維持著這樣的透明化的行為,才不會讓團隊失去他的聚合力而產生漸行漸遠的現象。

 

.

好吧! 我就是一個人的開發團隊,怎麼辦呢?

》不急;先來弄清楚製作文件的目的,先了解規格文件能幫上你什麼忙,才能抓住重點,要做到敏捷開發所謂的 Just enough的文件製作。只要把握這個原則,一個人或是再多人一起進行開發工作,也就不是問題了。

首先要知道,規格文件可以幫你:

  • 預作程式的功能設計 (所以如果能有多幾個人來幫你,該有多好?!)

  • 維護的好幫手 (幾個月後,保證第一個來看程式的人應該還是你自己)

  • 便利於溝通 (文件並不是好的溝通方式,但卻是一種可以依據的基礎)

  • 作為估算進度的依據 (給客戶作計畫用?這應該是客戶或主管最基本的要求)

 

.

》接著要設法讓這些文件「活起來」

敏捷開發是一種「務實」的開發方法,它不是不作文件,而是不想擁有不正確的文件,當文件能夠擁有足夠的正確(包容)性時,我們就可以繼續相信它,例如一些系統概述、架構簡介之類的高階的說明類文件。這種文件不論是採用傳統的Word或Excel 甚至 Power Point來製作都OK,重點是它能夠抽象的表達它的意圖,並讓觀看的人能夠迅速理解,這才是重點。因此它不能太過仔細,因為一旦太過明確化了它的生命週期就會很明顯地跟著變短了。

 

.

製作活文件;一種可以持續被修改而大家都能看得見的資料。專案開發的時候持續把資料放在Wiki上是最典型的作法,這一點就是幾乎所有的 Github 伺服器都會附帶wiki server的原因。例如會議記錄、結論或各種版本的規格,記載在這裡是最好不過的了。它展現出一種集中的保存方式,隨時可以被看見或是追朔則是最基本的功能要求。

 

.

 

》最後;要讓這些文件「持續地活著」

這樣的要求看起來很簡單,但有很多的單位卻都做得很糟糕。我們就用對Bug的處理方式來做說明。請問貴單位有 Bug Tracking System 嗎? 如果沒有的話,那貴單位的程式品質一定不會太高的。我們都很清楚,沒有程式會沒有 Bug的,但卻又都選擇不去面對它。這一點很有趣,像極了高德拉特的限制理論,我經常拿它來比喻成Bug的修復過程(註2)。以下是Bug Tracking system 至少需要作的紀錄:(請參考 Joel on software )

  • 如何重現此缺陷bug的完整紀錄。

  • 系統應該要有的正常行為表現。

  • 實際觀察到系統在缺陷下的行為表現。

  • 修復的負責人員名字。

  • 最後一次修復後的狀態。

 

持續的tracking 這些系統的缺陷是絕對物超所值的。你只要想想那些星期一剛上班,就收到Bug回報電話,緊接著而來的雞飛狗跳的情景。趕緊下決心就從今天開始啟動Bug Tracking 系統吧!

.

 

真實的訪談

只要是人跟人的溝通,訪談的成果跟參與者的人格特質與技巧好壞就是一個很難避免的問題(當然經驗是絕對可以幫上忙的)。傳統開發經常把訪談看成是一次決生死的場景,即便不是認定一次就OK,也經常會為自己設限訪談的次數,總之是越少越好。但敏捷開發不這麼作,而是採用迭代(iteration)的方式來打破這種需要訪談幾次才夠的思維模式。敏捷把客戶看成是團隊的一員(萬一客戶屬於那種不會出現的類型時,就挑個代理的客戶,由他全權來代理客戶,我們稱它為Proxy PO)。目的是讓需求能夠做到持續優化的改善行為,目的當然是讓產品在長期的開發作業之後,在上市時仍然能夠符合到市場上的需求,不會因此而成為過時的產品。

.

問「問題」是訪談時最基本的工具

但如何才能把問出來的零星解答驟合成一幅較完整的需求描述呢? 我想;大家都曉得問問題的 5個 W理論,它很有效但也很短暫。為何「短暫」呢? 因為你很難從頭到尾都這麼去問問題,受訪者很快就會因此而到煩躁起來,所以這麼問問題可能會造成訪談很快就結束了。敏捷開發主張以故事的方式來描述問題(使用者故事裡只有3個W,Who、What、Why),但明確的指出受益者是誰,這種圍繞者使用者的描述方式,能讓問出來的問題始終有所依歸,問題只有對當事人的輕重區分,而不至於跳過當事人形成方向上的凌亂雜湊。在收集足夠多的使用者故事後你可運用階層式的「使用者故事地圖」來開始拼湊需求的全貌,一種抽象的解題技巧就開始成形了。它可以做為運行 Scrum的計畫會議時最好的依據,讓整個專案能夠自始自終在足夠的抽象層上看見全貌,這種技巧在敏捷開發裡十分受到歡迎(細節請參考:看見的力量 – (III)使用者故事地圖 )。

.

哈哈!受訪者很少會知道如何來講述使用者故事的,因此撰寫故事的工作便成為訪談者的責任,而如何引導問題的描述讓它變成使用者故事便是一種訪談者該有的技巧了,需要多練習(此時Gojko Adzic 的 Impact Mapping 可能最適合排上用場了,請參考影響地圖)。

.

還有一些細節跟作法,請參考 : Agile Documentation 敏捷開發需要哪些文件?

.

 

》要如何讓使用者故事便成規格文件呢?

只要針對使用者故事再加以提供畫面、場景(scenario)描述或是流程說明,它就變成了如假包換的功能規格書了。

 

000 scenario

 

 

.

註 1. Joel Spolsky JOLT 2012大獎得主

         https://en.wikipedia.org/wiki/Joel_Spolsky

 註 2. 高德拉特的限制理論五步聚焦法

       參考:  約耳談軟體 Joel on Software。

Written by ruddyllee

2016 年 08 月 15 日 at 16:16:53

張貼於未分類

Tagged with

如何知道團隊的開發速率 – 累積流程圖

leave a comment »

身為團隊的一員或許你是主管、PO或是Scrum Master,你需要知道團隊的開發速率,你需要依據這個簡單的輸出入模型(註1)。用來做為團隊是否能夠繼續接受新需求的依據。

.

(一些我曾經帶過的敏捷團隊,它們從頭到尾都沒有使用任何一種專案開發的工具,真是可惜! 也就是說,他們從來沒有機會看到工具為專案開發所統計出來的各種資訊。這篇文章是獻給你們的,祝一切順利! 即使不順利,我相信你們一定很快就能克服的)

.

000 死亡行軍

.

上圖,由上往下看: 橘色線是需求、紅色線是開發作業、藍色線是測試、綠色線是完成。從二個軸的交點,也就是由原點往右上方看去,所有的線條都漸行漸遠,沒有交集(如果是直線完全沒有波折那該有多好,那就是Waterfalls 認為的開發過程了)。線條沒有交集到,就表示沒有進度,顯示出一種永無止境的專案開發情境,真是可怕的情境,也就是從開發到完成越行越遠,也就是說產品交付日遙遙無期。除此之外,需求仍在增長。(這正是鳳凰項目小說裡的鳳凰計畫Phoenix project 的寫照,此書若有再版的話,我會建議它採用此圖來做說明的, 哈哈 XD)

.

 

盲目接收需求的後果死亡行軍

累積流程圖Cumulative Flow Diagram: CFD 水平軸的單位是時間,垂直軸線則是工作量。它記錄著這整個專案的開發歷程,從一個product backlog被拿出來(上圖,橘色的線條)開始分析一直到完成為止(綠色線條)的所有過程及時間。它是一種以面積做表示的區域性圖示(這些數據過於繁瑣,千萬不要用人工去收集)。若你有採用專案控管的數位工具,則一般而言你已經擁有了顯示累積流程圖的能力了,只是大家經常忽略了它的重要性。就好像許多IT部門的主管,極少數會去衡量開發或維運團隊是否已經觸及他們的工作極限了,應該設法平衡工作量大小的時候了。而不是等到有人員提出辭呈時才開始思考這個問題。其實答案一直在那裏,只要你翻開累積流程圖就能看到現在在開發上的真正問題,請從累積流程圖來查看你的專案狀態。

 

上面這張圖就是典型的開發團隊,不知節制,猛接需求的後果,結果就是產生著名的「死亡行軍」或是 DevOps小說「鳳凰項目」中的布倫特先生事件。說白一點,就是需求不斷的增加但產能卻越來越下降(開發團隊持續加班但就是不見好轉),交付日期只能不斷的延期,而產品品質卻一直下降。為什麼呢?! (這是鳳凰項目這本小說的第一部分所描述的主要問題,癥結就發生在布倫特先生身上,如果你還沒看過此書,它是DevOps 之下的一本成名小說,由一位CTO 及二位資深IT人共同撰寫的科技小說,全名是: The Phoenix Project: A novel about IT, DevOps, and Helping Your Business Win)

如果我們不知道開發(維運)團隊的能力所在,為他們設下限制的話。又繼續盲目的接受使用者提出的需求,結果可能就是上面這一張累積流程圖所顯示的狀態,所謂的「死亡行軍

 

.

解題方法

想辦法讓累積流程圖變成下面這個樣子。讓WIP半成品數越行越近,讓開發的Lead time 減少(努力設法讓每一個步驟花更少的時間來完成),造成下圖中的虛線部分能夠越快接觸到需求的頂端越好。正確作法: 就是立刻暫停需求。這是「鳳凰項目」小說裡的解題方法,也正是著名的啤酒效應(Beer effect,註2),也稱啤酒游戲(Beer Game / Beer Distribution Game)的正確解答,它一直是生產與供需平衡的一個著名故事。

.

 

000 cfd-03

修正死亡行軍的圖示

.

用暫停生產來換取庫存半成品數量的迅速下降

立刻暫停需求是可以馬上減少WIP半成品數的最好方法,對生產線而言再正確不過了,在沒東西生產的情形下,只要有出貨多少量,庫房裡的半成品數自然就減多少了,這是在簡單不過的算術問題。但理想就是理想,小說終歸小說,你我都知道在真實的世界裡很難有那麼誇張的決策(正確講法是很少有人敢於負起這個責任),那該怎麼辦呢?

.

讓需求分級,讓處理人員分工

在真實世界裡,為了讓主要的維護人員挪出時間進行開發工作,一種權宜的作法(階層化):將需求依困難程度分類,只有最緊急的事件才由主要的人員來處理,其他業務就交給其他人員來處理,便可以逐漸的減少主要人員的負荷(讓團隊能夠平攤負荷)。嘗試看看,然後讓這個歷程所記錄下來的累積流程圖的結果來告訴你,接著該怎麼做(瓶頸理論Bottleneck principle是這麼說的,任何系統都至少會有一個瓶頸存在,解決完一個之後再去尋找下一個,瓶頸會一直存在的),所以這個行為必須是持續不斷的行為就好比累績流程圖的名稱一樣。

.

累積流程圖的效用

累積流程圖是開發歷程的全紀錄(請運用專案開發的工具來做紀錄),它有二部分,其一、基本功能部份,它提供我們一些明確的數據做參考,這部分不在此做說明,請參閱: 累積流程圖 Cumulative Flow Diagram。另一部分是它抽象化顯示的部分(例如上面那二張圖示,我刻意選擇了Pawel Brodzinski 的圖示,就是因為他用手繪的圖形,讓人有著足夠的抽象感,而抽象化的包容度能讓我們拿它來作為決策的依據時有著更大的容錯性),這正是累積流程圖最有威力的一部分,它能夠提供我們對未來做決策時的參考指標。

.

如何檢視累積流程圖

首先;讓他與看板相結合,下面圖示把工作看板畫在上面,而團隊開發歷程的紀錄則採用累積流程圖(cumulative flow diagram)畫在下面。圖上的顏色相互對照,你可以發現,看板上有幾個工作欄位,累積流程圖就會呈現出幾條線,他們是對稱的。很多人以為半成品 WIP是要設定才會產生的,這是一種錯誤的想法(沒設定是因為你有主動去規範它),其實半成品一直存在的,一旦我們將需求抽出來開始工作時(綠色的線)它就誕生了(如圖所示),要一直到它走進完成的區域(紅色的線),才會消失。換句話說,只要有開發流程就一定會有半成品。而我們該在意的是每個步驟之間在時間上的合理消長。也就是盡力去減少WIP的數值,相對的就是加快產能了。如圖上所示,設法讓綠色的線與紅色的線越密集,也就是開發速度越好。當然直接設法縮減每個開發步驟的時間也可以做到。

.

000 cfd

 

.

這部分說來話長,但 Pawel Brodzinski 寫得好極了(就是長了一點),請大家參考: Cumulative Flow Diagram

(我整理了一份中文化後的Ppt檔做為上課用,稍後再放到OneDrive上面。)

 .

 

小結

請善用專案管理工具的力量,尤其是開發歷程的所有統計資料所產出的圖示,例如: 累積流程圖 Cumulative Flow Diagram。當你需要分析細部資料時,請參考它完整的數據(注意,沒有二個開發專案會長得一模一樣的,因此越明確的數據就越是只能做為參考而已)。但當你需要進行預測或做風險決策時,請抽象化的參考它所表現出來的線條狀態就好,因為它在這部分更具威力的多了。

 

.

1. 輸出入模型

團隊的效能一般以他能接受多少工作量然後產出多少成果作為評量。也就是所謂的IPO 模型( Input – Process – Output, 投入- 開發歷程 – 產出)。

 

註2 啤酒效應

啤酒效應(Beer effect)指的並非僅是啤酒行業的現象,而是營銷流通領域一種具有普遍意義的現象。該效應指的是由於鏈中各節點企業之間資訊的不對稱以及為了追求自身利益的最大化,造成了需求資訊在內部的傳遞中失真。

.

參考:

  1. http://leanguru.pro/tag/cumulative-flow-diagram/
  2. http://brodzinski.com/2013/07/cumulative-flow-diagram.html

Written by ruddyllee

2016 年 08 月 02 日 at 18:37:06

張貼於未分類

Tagged with ,