Ruddy Lee 分享空間

Emergent Design 演化設計

工程師如何自我管理?

leave a 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 ,

敏捷開發為何會比較快?

with 5 comments

.

敏捷開發的目的不是為了快速交付!

它是一種用來應付需求快速變化的軟體開發方法。

–          Wiki

》許多IT主管或是工程師,都把敏捷開發誤以為是一種快速交付的方法,就因為它比傳統開發方法快一些,當然;還有它叫做「敏捷」的緣故。因此我們常常聽到主管們在會議上抱怨:「不是已經在RUN敏捷開發法了嗎,為什麼開發速度還是那麼慢呢?」

 .

「敏捷」二字的誤導

這一篇文章的目的不在回答上面那個說來話長,必須用聽診器仔細推敲才能回答的問題,而只是想修正一下大家對「敏捷」這二個字的誤解。敏捷二字其實是針對需求變化的快速反應而來,而不是過去所謂的 RAD 快速應用程式開發法(附註1)。下面的說明則是在解釋敏捷開發為何會比傳統開發方法快的原因。

.

 透過遊戲來做說明

敏捷開發不是一種快速的開發方法,為了解釋這件事敏捷課程的講師們經常會在課程裡依靠遊戲的方式來作說明(這是效果最好的一種方式,大家玩上一回便知道前置時間所造成的浪費之處了),但時間不夠的時候,則會改成放影片的形式。請欣賞上課時我們經常會放的一段翻銅板遊戲(Coin Flip Game: https://www.youtube.com/watch?v=HW2DEZLRAhw)。放這段影片的目的在導正大家對敏捷的誤解。尤其是給高階的主管知道 – 敏捷開發不是一種為了快速交付而出現的方法,它之所以比較快則是因為避開了許多浪費的處理方式 。下面這一張圖是為了更容易作說明而畫的,希望能解決困擾。

.

 透過圖示的方式作說明

000 敏捷快的原因

 

 上面這一張傳統vs敏捷的開發流程圖示,強調四個實施敏捷開發時為何會快於傳統開發流程的地方:

 .

※   前置時間

傳統開發法依循計畫、分析、設計、程式開發、測試再進行修改整合後發布的步驟進行,是一種順序性的開發模式,也就是說當前一個步驟還沒完成之前,後面的步驟就會位在等待的行列,當前一個步驟用掉越多時間時則後面步驟的前置時間就會越長,而形成時間上越多的浪費。也就是說傳統開發浪費了太多的時間,在前置作業上的意思。前置時間造成了一種沒有充分運用資源的現象,當進行到分析或設計的步驟時,程式設計人員仍然處於等待的狀態,因此形成了時間的浪費。

反觀敏捷開發,實行的是一種務實的做法,例如:在進行需求蒐集的步驟時,當收集到足夠一次迭代開發的需求時即向下一個步驟前進,盡量縮短前置時間的浪費,然後將"分析、設計、開發與測試“形成一個開發步驟,減少了步驟與步驟之間的銜接時間,這種開發方式形成了一種所謂的「衍生式的設計」,也就是遇到實質上的問題時才採用設計方法來克服它,而不是預先作好設計的方式。 因此讓起步顯得輕量化了,再加上只有少少的規範,所以敏捷才有了輕量化的開發方法的稱謂。

 

(在銅板遊戲中,我們通常會用一張A4的紙張作為前置時間的限制,要求學員把10或20個銅板放上去,遊戲進行時只有在所有在紙張上的銅板都完全翻轉過之後才能傳遞給下一位,形成後面的學員空等待的時間,也就是前置時間的浪費。在銅板遊戲中,我們通常會分成三次來進行遊戲,第一次採用 A4的紙張,代表最大的前置時間,接著將A4紙張撕成四等分,也就是採用四分之一的前置時間大小的紙張,最後一回則完全拿掉紙張,也就是極小化前置時間的限制,目的在讓學員更容易意識到速度上的差異)

 .

※      首次發布的時間

敏捷開發採用迭代的開發方式,每個循環都會有一個潛在可以進行發布的小增量用來展示開發的成果,透過這種展示給了我們要求客戶在看完之後給予回饋以便進行改善的機會,這種讓客戶體會開發成果的作法同時也給予了客戶決定開發方向的絕對主權(客戶可以在看到需求如何被達成,然後評估產品的堪用程度,是否已經達到提前上線的水準,也就是產品足以提前交付了嗎?)。

通常這個展示時間會設定在 1到 4個星期之內,因此客戶幾乎可以預期在這段時間之後可以看到預期的開發成果。這與傳統開發只在產品完成後才做一次發布的方式,客戶只有在這個時候才看得到成果,在開發過程中完全沒有改善的機會。這種迭代展示的形式,給予了客戶提前驗收的機會,也給予了開發團隊自然提前完工的機會。

 .

※      資料需求

敏捷開發不作完整的需求分析(因為計畫總是趕不上變化的),當需求的蒐集量及品質,已經足夠一個開發週期的工作量時就可以開工了。這便是敏捷開發著名的「需求夠二個星期的工作量了,可以開幹了!」,一種盡快開工不浪費時間去等待需求全部收集完整的開發模式。(需求的品質,就是所謂的 Definition Of Ready: DOR,它才是決定開發速度的決定性因素)

.

 

※      測試方法

敏捷開發對軟體帶來的最大影響便是測試了。傳統的α(內部測試,註2)、β(交付客戶測試)、γ測試(優化處理)方式在採用敏捷開發後幾乎不存在了,因為敏捷開發在開發週期內即不斷的在進行測試的動作,因此也就沒有了在交付做α、β、γ測試時必須停下開發作業來,凍結程式開發的時間浪費了。

 走了近二十年的敏捷開發,有二個明顯的趨勢成為了敏捷團隊的持續研究重點,一個就是測試,也就是從頭到尾都要測試。另一個則是組織上頭的徹底改變,這個較難,因為觀念要變。有空再來聊一聊.

.

 小結

這是觀念的問題,當你知道敏捷開發是針對需求變化的快速反應而來以後,便容易意會到為什麼它會花費那麼多的功夫在處理需求的變化了。例如Scrum 目前很流行的 Refinement會議,為什麼它每周都要召開一次呢,有必要嗎?是不是太浪費時間了呢?其實,它的目的正是在應付隨著時間而善於改變的需求變化罷了。

 

如果想要加速開發的時間,則前提是把需求弄好,擁有好的需求品質,當需求越能抽象的解題(注意不是明確的解題,一旦太明確化就失去變化的能力了),抽象解題提供了巨觀上的 Big Picture, 讓我們能夠看見全貌,然後據此擬定正確的開發方向,方向對了返工(rework)的次數自然變少,減少了在返工時所浪費的時間,減少了浪費的時間開發作業也就自然地變快起來了。

 

》為何要抽象化呢? 因為抽象時比較能包容那些屬於不確定的因素,也就是未來還沒發生的事情,他可以減少我們提前做決策時的方向偏差。而敏捷開發對抽象化最大的貢獻大概就是採用使用者故事(User Story )來描述需求了,它實現了我們用抽象化來做快速解題的能力。如果你尚未或是正準備進入敏捷開發的領域,記得從需求開始,而需求的撰寫請不要忘了採用使用者故事。

.

》如果一定要把敏捷開發說成是一種快速的開發方法的話,則應該要正名成〝一種快速處理需求變化的方法〞。是的;用來處理改變需求它就變得快得不得了了。原因是它在迭代中採用了使用者故事作為需求描述的方法,所以比起傳統的文件規格更能應付需求的變化,更加擁有彈性,所以特別能夠變通。而你運用使用者故事來描述需求的好壞,也決定了你應付需求變化的速度及能力。

.

 

附註1.

快速應用程式開發法 RAD

速應用程式開發(Rapid Application Development: RAD)是指一種以最小幅度的 … 技術設計的報告"。 快速應用程式開發的方法正是需要在功能與效能間取得一個平衡點,藉此來加速應用程式的開發時間,並減少之後所需的維護成本。他是對應到1970至80年代間的非敏捷流程開發,例如說結構化系統分析與設計方法以及其他像是瀑布模型等所誕生的一種開發法。(wiki)

註2.

α、β、γ 常用來表示軟體測試過程中的三個階段: α (Alpha) 是第一階段,一般只供内部測試使用; β (Beta) 是第二階段,已經消除了軟件中大部分的不完善之處; γ (Gamma) 是第三個階段,此時產品已經相當成熟,只需在個別地方再做進一步的優化處理。

.

Written by ruddyllee

2016 年 07 月 21 日 at 18:59:53

張貼於未分類

Tagged with

需求變化太過頻繁?

leave a comment »

解決需求變化太過頻繁的最好方法,就是提升需求的品質。

提升需求的品質的良方 — 使用者故事地圖。

.

User Story Mapping  使用者故事地圖 / 使用者故事對照

000 Jeff-Patton-Headshot-200x200.jpg

Jeff Patton

.

化繁為簡,看見全貌

使用故事地圖的二個最大功能,第一、是化繁為簡;把一堆使用者故事用階層的方式加以排列出來之後,便可以讓需求的主從關係透過誰包含誰的方式逐漸的清晰化。讓你宛如在瀏覽書籍一般,那些個章、節、細節以至於小節及附錄都變得層次分明,確確實實的可以看得見需求的整體、看得見專案的Roadmap了。尤其可以讓你從龐大的需求中找出開發的起始點來,看到哪裡才是這次開發上的主要章節。

.

第二、是看見全貌 The Whole Picture。

我們往往要擁有足夠的抽象化才看的見全貌。例如:在畫廊裡欣賞畫作,想要細細品味時我們會站得近一些,想看見全貌時我們會往後退一些。尤其當有人請我們批評一下這幅畫作時,勢必要向後退個兩步,設法來看見全貌免得偏頗的妄下定論,避開以偏蓋全的小家視野。在英文著作裡常常可以看到作家寫道「從三萬英尺的高空看地面」正是這個意思。

常常有人批評我老是把「抽象」掛在嘴上,一副很容易的樣子,但對別人而言其實是很難的。我要辯駁一下,其實覺得空泛只是缺少練習罷了。請多練習讓自己退一步! 退一步有多難嗎? 就是不要看得太仔細了而已,先把細節拋在腦後,不要太快看到細節,因為這樣你反而不容易看見全貌了,是細節的內容先佔據了你的主觀。隨後要在逐步弄清全貌就要反反覆覆花上許多工夫了,這是需求必須反覆變動的一大因素 — 沒能夠在一開始,先看到全貌(這便是我們經常要求工程師不要太快將使用者故事 breakdown 成 Task 的主要原因)。

.

哈哈! 我知道你要埋怨我講得太容易,不急,我們不要空談,我們用工具來解決這個問題。

.

工具能夠能夠讓你事半功倍,尤其是 User Story Mapping

.

介紹二個我最喜歡的工具: Featuremap & StoriesOnBoard.

這二個工具都讓我學到一些運用使用者故事地圖的技巧,都很棒! 不論你用或不用他們,請一定要看完它們的廣告簡介,設計的真好,能一眼就教會你它是怎麼設計、怎麼來詮釋使用者故事地圖的。唯一不好的是,它們都要花錢去買,而且是按月計費的不是很便宜,這一點便很難讓人輕易的下決心將整個需求的大業就這樣子的交給他,但老實說,他們是絕對值得的。

.

我在太多地方推行過使用者故事地圖了,但客戶用得很成功的例子卻少之又少,原因是它們缺少好的工具(這一點微軟的 VSTS 或 Atlassian 的 JIRA都太讓人失望了),這些挫折事後給我的教訓便是上完課後盡快推薦上面二個工具給他們,藉由好的工具來協助它們能夠化繁為簡,確實地掌握需求的全貌。

 

FeatureMap

這是一家法國公司Salience 的佳作,他採用的是平鋪直敘式的陳列使用者故事,我已經使用好幾年了,因為他針對個別的使用者帳號可以免費製作二個地圖。這一點確實很方便,我的"精實開發與看板方法"一書裡附錄的地圖就是用他編輯的。用起來像在編課表很簡單又好用,還可以列印出來分享。

.

0 看板方法 map

實施"看板方法"的使用者故事地圖

.

 

 StoriesOnBoard

匈牙利一家叫做 DevMads 的公司的傑作。他最精彩的地方是擁有二個操作模式,一個是創意模式,可以大量的放入使用者故事。 另一個是規劃模式,PO可以依據已有的使用者故事,開始區分相對功能的重要性及何時作甚麼版本的Release。他可以讓擁有構想的人們的抽象視野變得清晰可見(這是我最喜歡他的地方)。

.

這一 張圖的左右二邊,說明了二階段的運作。

000 StoriesOnBoard

.

不能再寫下去,再寫下去就有幫廠商廣告的意思了。純粹是把好東西介紹給大家,不過如果你已經試過採用 Excel 或 Powerpoint 來製作使用者故事地圖,而始終覺得少了些什麼的話,請試試上面的工具吧!

.

是的,敏捷宣言是這麼說的;「人與互動 更勝於 流程與工具」,但當你需要化繁為簡的時候,還是運用工具吧!這不就是我們身為軟體人所努力的方向嗎?

 

參考自:  Top Tools for User Story Mapping: From Post-Its to the Best Digital Apps

.

請用影響地圖講故事

有了架構良好的使用者故事地圖之後,該是PO把願景透過使用者故事逐步傳遞給團隊的時候了 — 講故事。這段前置作業的時間十分重要,雖然因為運用了抽象化的使用者故事來描述需求,讓我們擁有了避開傳統 waterfall 的計畫枷鎖,但過度的注重故事的細節將會導致團隊的開發時間的受到壓縮,會導致團隊因此而沒有了足夠的開發時間,這是一種浪費。但什麼時候才可以開始說故事呢? 正式的回答是在需求達到 Definition Of Ready 的時候,這是一個較大的議題,我們先不談他,跳過這個問題,我們來談談如何講故事?

.

使用者故事地圖不是一個講故事的好工具。因為好的故事總是從主角開始,然後描述了他的生長環境及背景,接著帶引大家一窺在各種遭遇之下他的種種反應成就了現在的他 – 這正是影響路徑。哈哈! 故事就是要這麼開始才有吸引力。所以我介紹大家要運用影響地圖 Impact Mapping 來說故事。因為他可以輕易的把你辛辛苦苦所寫出來的功能對應到他所要實現的業務目標上(我們稱他為影響路徑)。這裡不在贅述,請大家參考Gojko Adzic 的 Impact Mapping《影響地圖》這本只有73頁的小冊子。(我的說明在這裡)

.

使用者故事地圖可以讓你看見全貌、化繁為簡,

但影響地圖卻足以讓你開始講故事。

.

適合講故事用的《影響地圖》

強調一下,不是所有故事都該做 Impact Mapping 的(這麼做就太浪費時間了),但他實在比使用者故事地圖要適合用來講故事用了。我通常會慎選在主要的網頁上那個主要的元件來做說明(一般就是這一個網頁的特色所在),因為他值得我們多花一些時間來弄清楚,寫了這麼多的程式到底是為了甚麼。而相對的,目的通常是拿來評論(讓大家都看見)這麼做是值得的嗎?

.

 

 

 

Written by ruddyllee

2016 年 07 月 16 日 at 10:47:29

敏捷開發顧問模式

leave a comment »

敏捷開發顧問模式 Agile Development Consultant Pattern  ver 1.1

.

000 Agile Consultant Pattern

.

Version 1.1 更新

分別在 Sprint I 及 Sprint II 執行期間,運用看板欄位的 增加/刪除 來調整團隊開發流程的增減關卡。第一個 Sprint 以加入「測試欄位」的關卡。第二個 Sprint除了繼續加強測試之外,則以加入「文件製作」為主。

.

只有在開始繪圖之後才意識到,在任何模式之後還有一塊看不見的東西。看的見的可以畫下來,透過圖形做成紀錄讓人們看到細節末支。看不見的則需要意會、需要透過巧妙的文字來做解說,那就是「講故事」了

.

Written by ruddyllee

2016 年 07 月 11 日 at 17:00:45

張貼於未分類

關注

有新文章發表時,會立即傳送至你的收信匣。

加入其他 46 位關注者