Posted on Leave a comment

鳳凰專案:看IT部門如何讓公司從谷底翻身的傳奇故事

這本書算是一本故事書,也因為是以故事的型態去描述一間公司如何從谷底翻身,讀者會更能夠明白『管理』對於一間公司有多麼重要。
也能從故事裡面直接理解書中所闡述的管理方式在實際情況是怎樣的去運用,在運用時也不會是直接的一帆風順,而是有重重的考驗並且需要高層的全力支持與理解。
我覺得此本書是管理相關書籍中相當值得一看的書。

因為故事情節用簡述的,就沒辦法讓讀者感受書中情境,因此本文主要為筆者自己讀後的筆記
主要紀錄我認為書中很重要的管理方法和管理思維,書內的附錄也有此書管理思維的整理。

有關故事內容,想了解的話建議自己去買書來看。

Work in process控制

在這邊他們使用工廠管理來比喻我們在開發專案的狀況。

對工廠管理而言,在生產線會盡量的去避免讓工廠內同時有過多的在製品,也就是所謂庫存。
對開發專案來說,在製品指的是開發中但是尚未開發完成的功能,還無法帶給公司收益,也是要極力去減少的。

在生產線上,一定會有處理效率最差的點,我們稱為瓶頸點(或稱約束點),創造約束理論的艾利高德拉特告訴我們,在瓶頸以外任何地方做的改進都是假像
的確,在瓶頸點之後做的任何改進都是徒勞無功的,因為只能乾等瓶頸把工作送過來,而在瓶頸點之前做的任何改進只會導致瓶頸處堆積更多庫存。

因此,在開發專案時,要了解公司的瓶頸點在那,是什麼地方讓最多的專案在等待這個資源而讓需求被卡住無法繼續進行。
以鳳凰專案而言,因為過多的核心資訊被掌握在一個天才員工布倫特手中,只有他知道怎麼處理,導至這個員工每天都必須處理非常多的事也有非常多的事在等待這一個資源。

下圖表示當一個越忙錄的資源,其他資源想等待這個資源的時間會越來越高

因此改善這個狀況,第一步就是要先釐清約束點所在,第二步就是充分利用約束點

以此書案例來說,約束點是天才員工布倫特,那他們首先做的就是保護這個約束點,不讓大家直接指使這個約束點去做他們認為重要的事,他們安排了一位專門的人員來安排這位約束點的工作內容,避免大家一直想私自去使喚他做事。接著他們要讓約束點的時間不被浪費,確認約束點永遠不會因為要遷就其他資源而枯等。再來他們將布倫特的工作標準化,讓更多其他的人也可以去接手做布倫特正在做的事,也就是提升約束點的產出。

總之,我們要記得任何對非約束點的改善都只是鏡花水月

三步工作法

  • 第一步工作法

    幫助我們理解如何建立快速的工作流,讓工作順暢地從開發部移動到IT運維部,因為那正是公司與客戶之間的銜接。

    這邊需要去了解公司的價值點,相較於把更多的工作投入系統,將不需要的工作從系統中剃除甚至更為重要,讓資訊部門能夠很快速的產出最精簡可用的有價值的系統,並且獲得反饋。為此,我們需要知道,與達成企業目標息息相關的東西是什麼,不論是專案,運營,戰略,合規,安全性等,通通有可能(請見下方的訂定組織目標)。

  • 第二步工作法

    告訴我們如何縮短及增強回饋循環,因而能夠從源頭開始解決品質問題,並且避免重工。在這邊我們也必須設法去根除計劃外工作的最大來源。

    所有計劃中的工作,在執行工作前,必須要分門別類地列出完成工作所需的一切先決條件:例如說,筆電型號,使用者資訊的規格,軟體及需要的授權,以及他們的組態,版本資訊,資安要求,處理能力和連續性需求等。

    也就是建構資源清單,亦是物料清單,以及需要的工作中心與生產途程,一旦備妥,加上工單和你的資源,就可以釐清產能及需求為何,並弄清楚可否接受為新的工作,並實際為它進行排程。

    第二步工作法的關鍵部份是以視覺化的方式呈現等待時間,那樣就能知道你的工作正在某人的佇列中排隊好幾天,或者是工作必須往後退,因為未備妥完整的零件。藉由需求清單被列出,也可以讓接受需求的人在接受訂單時,可以先確認每一個必須參與的資源都能夠有需要的投入,讓需求,銷售,開發能夠一起擬定生產計劃。

  • 第三步工作法
    告訴我們如何建立一種文化,既能鼓勵大家探索,從失敗中汲取教訓,又能理解反覆與練習是精通工作的先決條件。

    提升預防性工作是全面生產維護(Productive Maintenance, TPM)這類計劃的核心,精實社群(Lean Community)信奉全面生產維護的精神,主張我們應不惜一切代價提升維護水準。『改善日常工作甚至比進行日常工作更重要』。持續給系統施加壓力,從而不斷強化習慣並且改善某件事情。

    也就是所謂『改善型(Improvement Kata)』,書中是使用為期兩周的改善循環,每個改善循環都要實施一個小型的計畫》執行》查核》行動的專案,持續朝目標邁進。

    在此必要的實務作為包括:建立創新,勇於冒險及高度信任的團隊文化。把至少20%的開發和IT運維週期分配給非功能性需求,並持續強化及鼓勵大家進行改善活動

四種工作類型

在這邊這本書將工作份為四種類型:

  • 業務專案:公司所有的正式專案
  • 內部IT專案:由業務專案衍生出來的基礎架構或IT運維專案,以及內部生成的改善專案(如建立新環境和部署自動化)。這些專案經常未被集中管理,而是隸屬於預算所有者。
  • 變更:包括需求變更或BUG等
  • 計劃外工作或救火工作:包括production issue,通常由上面三類工作導致,而且往往以犧牲其他計畫內工作為代價。在書中說這類型的工作是最具有破壞性的,它並非實質的工作,其他三種工作都是基於需求而事先計劃好的。計劃外的工作會阻止我們進行其他三類的工作,就像物質和反物質,在計畫外的工作面前,所有計劃內的工作都會被延後。
    另外一點則是未被償還的技術債,源自於走捷徑,短時間內,那樣或許行的通,但是就像金融債一樣,久而久之,利息越滾越多。如果一個組織沒有還清它的技術債,那麼,就必須一點一滴,耗費心力,以計劃外的工作的形式來償還那些技術債的衍生利息

訂定組織目標

在這本書有列出了CFO的營收目標:

  • 公司體質健全
  • 營收
  • 市占率
  • 平均訂單規模
  • 盈利能力
  • 資產收益率
  • 財務狀況
  • 訂單轉化成現金的周期
  • 應收帳款
  • 準確且及時的財務報告
  • 借貸成本

在本書他們針對每一個營收目標列出『倚賴IT的區域』及『IT導致的業務風險』以及『倚賴的IT控制』來列出IT在這些目標項目中的角色。倚賴的IT控制指的是防範這些錯誤發生的反制措施,或者至少能夠偵測到問題及做出回應。

在這本書很戲劇化的是SOX-404的稽核專案,資安部門原本一直要求開發部門開發一個安全控制的系統來應付發生錯誤時的資安問題,最後才發現檢測重大錯誤所倚靠的控制手段是人工對帳步驟,而不是上游的IT系統。其實財務部門早已用人工的方式來達到這個資安的要求了,不需額外再開發相關的系統。

因此,不同部門間的資訊透明度真的是一件很重要的事。

遠程目標則包括:

  • 我們具競爭力嗎?
  • 了解客戶的需求和期望:我們知道要創造什麼嗎?
  • 產品組合:我們有正確的產品嗎?
  • 研發效能:我們能夠有效地建立產品嗎?
  • 產品上市時間:我們能夠盡快把產品推向市場,應且搶占一席之地嗎?
  • 銷售管道:我們的產品能夠觸及感興趣的潛在客戶嗎?
  • 我們的作法有效嗎?
  • 按時交貨:我們有尊守對客戶的承諾嗎?
  • 顧客維繫:我們正在增加客戶還是流失客戶?
  • 銷售預測準確率:我們可以把銷售預測準確率納入銷售計畫流程嗎?

相關連結

Posted on Leave a comment

Agile LEGO City workshop

這是由公司同事Jed所發起的公司內部課程。
Agile LEGO City workshop是用樂高積木來模擬敏捷開發的實際情形的一個小遊戲,藉著遊戲可以從中體認到軟體開發時,可能會遇到的許多狀況,並藉由會後的討論與檢討來讓參與者更能夠理解敏捷開發的意義。

敏捷開發宣言

在一開始時,我們先讀了下面的敏捷開發宣言

藉著親自並協助他人進行軟體開發,
我們正致力於發掘更優良的軟體開發方法。
透過這樣的努力,我們已建立以下價值觀:

個人與互動 重於 流程與工具
可用的軟體 重於 詳盡的文件
與客戶合作 重於 合約協商 
 回應變化 重於 遵循計劃 

也就是說,雖然右側項目有其價值,
但我們更重視左側項目。

讓參與者能夠從中理解敏捷的核心精神,也就是重視團隊間的溝通互動,接受需求的變化
並且讓我們知道敏捷開發最核心的就是這個宣言裡所描述的,所有敏捷實作方法如SCRUM等都需要建構於這個核心精神上。

遊戲規則

接著就是介紹LEGO遊戲的規則:
1. 依照下圖建造客戶所需的樂高城市,項目越前面代表客戶越重視的

2. 這個建城市的PO就是主講人Jed,在開始之前可以先和Jed提問,在每一個sprint的結束也會由PO來做驗收
3. 總共會有8個sprint,每個sprint開始之前要先計劃好這個sprint要做的,並移到TO DO去
PS:在這邊使用如下圖的看板方法去追每一個TASK的進度

4. 有一個計分表去計算每個sprint計劃要做的和實際驗收成功的任務比較表

遊戲進行

在開始遊戲後,本組所交付的任務頻頻被打槍,首先是我們在第一個sprint交付了平房,結果被打槍~原因是,請依照客戶需求優先順序做交付,我們前面都還沒有交付,不接受。
接著河濱公園安全設施因為圍牆沒蓋滿被拒絕,然後開始沒有做門,門沒有面對道路,沒有畫道路,圓環要在市中心,托兒園應臨近住宅….
等等原因一直被拒絕交付退回重改(火大)。

這是我們小組最後所交付的成果圖

會後檢討

我覺得這部份是這整個遊戲中最精華的部份,很感謝Jed還特別為我和Jack再做一次報告,讓我得以有機會聽到這個最精華的部份。

首先他讓我們提出我們覺得在遊戲中的感想,最多人提出的就是我們在一開始沒有搞清楚客戶需求,導致頻頻被退件
以及在一開始沒有先對整個城市做完整的規劃,例如圓環要在市中心等等…
造成我們所做的產品一直無法即時被release

然後Jed分享了敏捷開發的原則

The Agile Principles (敏捷原則)

1. 最為優先的事情是透過早期與持續交付有價值的軟體來使客戶滿意。
有價值的軟體指的是要重視客戶的優先順序,交付對客戶最有價值的東西
2. 歡迎需求的變動,即使是在開發的晚期。敏捷式流程駕馭變動來作為客戶的競爭優勢。
重點在於掌握變更,歡迎改動
3. 頻繁的交付工作產生的軟體,自數週至數月,週期越短越好。(2~4周)
4. 領域專家與開發成員必須一同作業,並貫穿整個專案開發時期。團隊的概念
5. 使用積極的工作成員來建構專案,給予他們環境以及支援所需的一切,然後信任他們能夠完成工作。
支援積極的個人(指願意主動多做更多事的人)帶動團隊氣氛,也就是信任團隊成員
6. 在開發團隊中最快也最有效的傳遞資訊方法就是面對面的溝通。
7. 工作產生的軟體是衡量進度最主要的依據。
這是最主要度量進度的方法,對使用者來說一定要完成的部份,因此找到使用者需求的核心價值十分重要
8. 敏捷式流程倡導水平一致的軟體開發
持續的開發,維持穩定步調,讓團隊狀況保持穩定
9. 專案發起者,開發人員以及使用者都必須持續的維持專案進度。
精簡,避免over design,不做太多額外的設計
10.持續重視技術的優勢以及設計品質
追求優良設計與技術
11.最好的架構、需求以及設計會出現在能夠自我管理的團隊裡
可以不需要PM就可以完成架構需求與規劃
12.在規律的反覆之間,團隊會反省與思考如何更有效率,然後相對的來調整與修正團隊的開發方式。
以天為單位定時自省,適當調整與修正自己的行為

在上述的精神底下的意義主要就是承諾,責任與互相信任。
敏捷是一個價值觀,也就是敏捷宣言與原則所述說的這樣的價值觀,Scrum是敏捷開發的一個框架,在Scurm裡所說的站立會議是一個scrum的儀式
優文分享:我對Daily Scrum的理解與看法
一般來說敏捷開發只估算這一回合要做的事情,過去我們在估算專案講的是人/天,這是以成本的角度去切入
而敏捷開發主要講的是故事點,也就是客戶需求的核心價值,重心在於價值。

對敏捷開發而言,估算是為了針對團隊生產力訂出並製定策略,重視的是產品的核心價值
因此可以看成是這樣

因此對於敏捷開發來說,每一個sprint只規劃該sprint要做的事,將客戶所需的功能切分到最小,每2-4週交付一次,每一次的sprint會將所有任務填上相對的一個數字,由多個成員來估算所需工時,並取一個平均值(若有差異較大的則需確認原因)
並在該sprint去計算本來我們預估這個sprint可以完成幾個工時,但實際完成了幾個?
再使用這個實際完成的數字去調整下一次sprint要release的總工時。
在這樣個估算方式下,隨著團隊穩定成長與默契的增加,估算的準確度會慢慢提升,如下圖

也因此在敏捷開發會特別重視團隊的穩定,惟有穩定的團隊才能帶來穩定的產品開發。

參考資料

雖然本文實際上沒有參考到這些文章,不過我去網路上爬了一些別人做LEGO workshop的經驗分享的文章
感覺滿有趣的,因此也在此附上

Posted on

沒有銀彈 – 軟體工程的本質性與附屬性工作

在人月神話裡,花了兩章的篇幅說明在軟體開發上,
不會有類似銀彈這種,可以快速解決開發時程延誤或發生重大錯誤的捷徑

他們提出了三個原因:

(1) 複雜性

軟體開發的複雜度與規模大小並非線性的關係,整個複雜度增加情況也會遠遠超過線性預估的結果。也因為結構上的複雜性,當軟體在擴充新功能時,難保不會產生新的副作用。程式裡的狀態難以一一列舉,也更加難以明瞭整個產品也會變的更不可靠。另外因為複雜性關係,開發時也容易遇到溝通困難、時程落後、成本超支的困難。

(2) 配合性

軟體必須配合其他的領域,例如電腦、不同語言、不同介面等等….。

(3) 易變性

1. 時常面臨修改,因為軟體是純思考的產物,有無限延展性,修改容易,也因此特別容易面臨修改
2. 成功的軟體生命周期會比硬體來的長,因此時常會需要配合硬體環境上去修改。

(4) 隱匿性:過於抽象、難以理解。

在這邊他們也提出了幾項過去曾讓軟體界有所突破的重大發展,但這些突破都是屬於附屬性的,沒辦法突破軟體工程本質上的複雜性:

(1) 高階語言:高階語言的發行的確是最強而有力的一次突破,對生產力而言至少有五倍以上的提升。並伴隨得到可靠度、簡潔性、理解力上的增益。它把和程式內涵一點關係都沒有的那一整層複雜性給去除了。

(2) 分時技術:分時技術對於程式設計師的生產力及產品品質有了重大的提升。因為分時確保了即時性,使我們得以持續保持住腦子裡對複雜的概觀。但緩慢的回復時間是附屬難題。

ps: 分時系統:作夜系統依中央處理器排程(CPU Scheduling),將中央處理器的時間切割為極小的時間片段(Time Slice)

(3) 統一的軟體開發環境:Unix和Interlisp是第一個得到廣泛使用的整合開發環境,藉由提供完整的程式庫、統一的檔案格式、管道和過濾器,以促成軟體的共用。

(4) 物件導向程式設計:抽象資料型別和階層式型別的使用。允許介面可以用次一層級的型別去做進一步的細緻化,隱藏類別裡面的實際操作,讓開發者可以在開發時專注於設計該類別的邏輯,排除掉許多附屬性困難

(5) 人工智慧:ex語音辨識、圖形辨識

(6) 專家系統:一支具有廣義推理引擎與知識庫的軟體程式,被設計成可接收輸入資料和假設條件的軟體程式,然後藉由知識庫來推導出邏輯上的結果。這項技術所帶來最重要的進步,是將應用領域的複雜性從程式中區隔出來

(7) 『自動化』程式設計:換句話說是用更高階的語言來編寫程式。未來可能我們會是用『建構』的方式來寫程式,也就是更完備的函式庫,可以讓寫程式的複雜度更加的降低。

(8)  圖形化程式設計(graphical programming):一個博班論文提出的新想法,但本書覺得要有成果應有些困難。

(9) 軟體的驗證:編輯軟體自動驗證程式的某些錯誤。例如比對資料型態、變數是否已宣告等等。

(10) 環境與工具:用來除錯、或是搜尋該類別曾被用在那些地方的開發工具。

(11) 工作站:也就是編輯所消耗的時間,若是機器的編譯時間減少,程式師能花在思考上的時間就會變多。

Posted on

人月神話讀後筆記


花了很多天終於看完了著名的專案管理聖經─『人月神話』
在此整理一下大致的重點

1. 開發一個軟體系統產品要付出的代價是一般組件程式的九倍。因為產品化是一般組件程式的三倍時間,設計整合測試又是三倍時間,這兩方面的成本計算基本上是獨立的。

2. 以成本會計為基礎的時程預估方式,使我們誤把工作量和專案進度混為一談,人月是一個危險並容易遭到誤解的迷思,因為他假設人力和工時可以互換。

在此本書裡面,提到,專案管理人員不應該把人/月這樣的標準來做為專案規劃的標準,因為當人員多起來後,整個專案的運行會需要花更多的時間在溝通、管理、協調上,人月之間的關係並非線性關係。

並且勿忽略掉新的程式師要學習上手的開發時間,以及要耗費掉的老手的教育時間。因此,在一個已經延遲的專案中增加人手,只會讓它更加的落後,這邊較建議的方式是重新安排時程、或者刪減工作。

在這一章裡,也提出建議的專案軟體時程安排方法

1/3 規劃

1/6寫程式

1/4組件測試和早期系統測試

1/4系統測試和完成所有的組件

3. 從第三章到第七章,都是在討論保有『整體概念性』的重要。

一個專案的規劃必需出由同一人之手,也就是說,一個專案不應該有兩個領導者。
我們必須選出一個能力強的人,來帶領整個專案的開發及方向,我們寧可忽略掉一些可能新奇、或很棒的想法,也必須讓整個專案都能呈現同一個設計理念。此一概念便是這本書所一直提及的整體概念性

在第三章裡,此本書提出了一個外科手術團隊的做法,來解釋該如何去達到這個整體概念性的目的。

(1) 首席程式設計師:也就是整體概念性裡所提到的做決策的主腦。負責定義功能、設計程式、測試程式並撰寫文件。
ps: 此本書也提到,真正優秀的專案管理人員,也應該要寫程式,沒有真正去撰寫一些程式的PM,是無法做好專案管理的工作的。

(2) 副手:外科醫生的分身,可以做所有首席設計師所做的事,或提出想法,但是首席設計師不一定要接納他的想法。

(3) 行政助理:幫忙處理首席程式設計師的所有庶務。一位行政助理可同時處理兩個以上團隊的工作。

(4) 文件撰寫人員、秘書(負責專案協調事宜及產品無關文件)、程式助理、測試員、語言專家、工具專家。

4. 第五章的地方,提到了第二系統效應,這個效應是指說,最容易失敗的專案,反而是我們第二個設計的系統,原因是加入了太多不相關功能。我們要慎防在設計第二個系統的時候過度設計(自律)。

5. 第六章在說意念的傳達設計必須出於同一人之手,那些有規範那些沒有應定義清楚。溝通方式包括:將定義(指規格書裡的定義)直接融入實作、開會(分為每週召開的會議、和公開大會,討論一些重大議題及無法預見的瑣碎事項)、多重實作(當規格與程式衝突時兩方都有可能要更改)、電話紀錄(現在可用email)、產品測試(專案經理最好的朋友)

6. 在第七章探討了巴別塔失敗的原因

(1) 充分的溝通十分重要

(2) 工作手冊的結構十分的重要,且每一位成員都應看到全部的文件內容

(3) 專案管理的權力結構應該要是樹狀的,也就是第三章所講的整體概念性,任何人都不能同時聽命於兩個老闆。而組織內的溝通結構則應該是網狀

7.  第八章是在討論專案時程預估要注意的點

(1) 員工只有50%的時間真正在寫程式

(2) 溝通時間應要納入估算

(3) 開發程式的類型不同以及大小之間的關係必須算進去。專案大小及費力程度大概是1.5的指數關係

8. 必須做好整體空間規劃,不單包括常駐空間的、背後有連帶關係的動作也應納入考量(ex: 記憶體分頁錯亂)
方法1. 確保大家的本事是真正通過程式設計的訓練而來
方法2.認知組件是去創造才有,每個專案都應有個手冊是專門蒐集關於佇列、搜尋、堆疊、雜湊(hashing)、Sorting的副程式且要有兩套方法,一個是用的空間最少的、一個是速度最快的。

9. 規劃軟體開發的文件:目標、產品規格、時程、預算、場地配置、組織編製圖

10. 把一次必然的失敗納入正式計劃之中(失敗是成功之母)

(1) 表格驅動技術:將設定值寫在表格檔案之中

(2) 軟體開發十分容易面臨無窮無盡的改變,因此 將改變量化,使組織利於改變

(3) 軟體測試在維護時期要用更多的資源(要做迴歸測試),也會需要進一步、退兩步,任何修改都有可能會破壞掉原有的軟體結構。

11. 第十二章在講開發工具的重要性,通常我們開發時的工具機器和最後程式要跑的目標機器是不一樣的,因此我們需要採用成熟的機器避免偶爾出現/偶爾正常的問題被忽略。程式語言的選擇也是工具的選擇之一,在這邊提到採用高階語言可以大量提高生產力。

12. 在專案開發中要如何避免錯誤的發生呢?在第十三章的地方提到了幾點重點

(1) 整體概念性的具備:也就是不同開發人員做出了彼此不協調的假設,具備了整體概念性的軟體容易使用、易於開發、也比較不容易發生錯誤。

(2) 規格審查:規格書應交給獨立的測試小組進行審查,而不應該給程式設計人員去審查

(3) 由上而下的設計方式:這是一種持續細分精製的步驟,先勾勒出粗略的工作定義和執行方案以得到主要的結果,然後做更深入的探討,看看跟我們真正要的東西有何不同。也就是把大步驟細分成幾個更小的步驟。

(4) 結構化程式設計:由Dijkstra所提出的最短路徑方式,在說由某一節點到另一個結點的最短路徑。

13. 要如何避免大災難的發生,有以下幾點:

(1) 里程碑應要明確、不模陵良可,要明顯到無法讓人自己騙自己,可以輕易查證

(2) 團隊應充滿幹勁,我們亦可提出計劃評核圖(PERT chart)或要徑時程表(critical-path schedule)來顯示什麼做完才可以做什,並告訴我們什麼事情是重要的需要先做

PERT chart
a:最樂觀時間 (Optimistic Time)為最短時間
m:最可能時間 (Most Likely Time)為適中時間
b:最悲觀時間 (Pessimistic Time)為最長時間

要徑的概念:通過網路最長的路徑,稱為要徑。若最長路徑的作業延遲了,整個專案就延遲,若要縮短專案完成時間,只要縮短要徑作業的工期即可。要完成專案,所有的路徑都必須通過。

(3) 避免隱匿不報的狀況發生:為了避免下面的人明知專案延遲卻不往上報的狀況,在組織上應降低角色衝突(老闆不應干涉部屬可以自己解決的問題),並且訂定一些審查技巧。