I'm a mother of two precious kids and a professional programmer.
這本書算是一本故事書,也因為是以故事的型態去描述一間公司如何從谷底翻身,讀者會更能夠明白『管理』對於一間公司有多麼重要。 也能從故事裡面直接理解書中所闡述的管理方式在實際情況是怎樣的去運用,在運用時也不會是直接的一帆風順,而是有重重的考驗並且需要高層的全力支持與理解。 我覺得此本書是管理相關書籍中相當值得一看的書。 因為故事情節用簡述的,就沒辦法讓讀者感受書中情境,因此本文主要為筆者自己讀後的筆記 主要紀錄我認為書中很重要的管理方法和管理思維,書內的附錄也有此書管理思維的整理。 有關故事內容,想了解的話建議自己去買書來看。 Work in process控制 在這邊他們使用工廠管理來比喻我們在開發專案的狀況。 對工廠管理而言,在生產線會盡量的去避免讓工廠內同時有過多的在製品,也就是所謂庫存。 對開發專案來說,在製品指的是開發中但是尚未開發完成的功能,還無法帶給公司收益,也是要極力去減少的。 在生產線上,一定會有處理效率最差的點,我們稱為瓶頸點(或稱約束點),創造約束理論的艾利高德拉特告訴我們,在瓶頸以外任何地方做的改進都是假像。 的確,在瓶頸點之後做的任何改進都是徒勞無功的,因為只能乾等瓶頸把工作送過來,而在瓶頸點之前做的任何改進只會導致瓶頸處堆積更多庫存。 因此,在開發專案時,要了解公司的瓶頸點在那,是什麼地方讓最多的專案在等待這個資源而讓需求被卡住無法繼續進行。 以鳳凰專案而言,因為過多的核心資訊被掌握在一個天才員工布倫特手中,只有他知道怎麼處理,導至這個員工每天都必須處理非常多的事也有非常多的事在等待這一個資源。 下圖表示當一個越忙錄的資源,其他資源想等待這個資源的時間會越來越高 因此改善這個狀況,第一步就是要先釐清約束點所在,第二步就是充分利用約束點。 以此書案例來說,約束點是天才員工布倫特,那他們首先做的就是保護這個約束點,不讓大家直接指使這個約束點去做他們認為重要的事,他們安排了一位專門的人員來安排這位約束點的工作內容,避免大家一直想私自去使喚他做事。接著他們要讓約束點的時間不被浪費,確認約束點永遠不會因為要遷就其他資源而枯等。再來他們將布倫特的工作標準化,讓更多其他的人也可以去接手做布倫特正在做的事,也就是提升約束點的產出。 總之,我們要記得任何對非約束點的改善都只是鏡花水月。 三步工作法 第一步工作法: 幫助我們理解如何建立快速的工作流,讓工作順暢地從開發部移動到IT運維部,因為那正是公司與客戶之間的銜接。 這邊需要去了解公司的價值點,相較於把更多的工作投入系統,將不需要的工作從系統中剃除甚至更為重要,讓資訊部門能夠很快速的產出最精簡可用的有價值的系統,並且獲得反饋。為此,我們需要知道,與達成企業目標息息相關的東西是什麼,不論是專案,運營,戰略,合規,安全性等,通通有可能(請見下方的訂定組織目標)。 第二步工作法:…
這是由公司同事Jed所發起的公司內部課程。 Agile LEGO City workshop是用樂高積木來模擬敏捷開發的實際情形的一個小遊戲,藉著遊戲可以從中體認到軟體開發時,可能會遇到的許多狀況,並藉由會後的討論與檢討來讓參與者更能夠理解敏捷開發的意義。 敏捷開發宣言 在一開始時,我們先讀了下面的敏捷開發宣言 藉著親自並協助他人進行軟體開發, 我們正致力於發掘更優良的軟體開發方法。 透過這樣的努力,我們已建立以下價值觀: 個人與互動 重於 流程與工具 可用的軟體 重於 詳盡的文件 與客戶合作 重於 合約協商 回應變化 重於 遵循計劃 也就是說,雖然右側項目有其價值, 但我們更重視左側項目。 讓參與者能夠從中理解敏捷的核心精神,也就是重視團隊間的溝通互動,接受需求的變化。 並且讓我們知道敏捷開發最核心的就是這個宣言裡所描述的,所有敏捷實作方法如SCRUM等都需要建構於這個核心精神上。 遊戲規則 接著就是介紹LEGO遊戲的規則: 1. 依照下圖建造客戶所需的樂高城市,項目越前面代表客戶越重視的 2. 這個建城市的PO就是主講人Jed,在開始之前可以先和Jed提問,在每一個sprint的結束也會由PO來做驗收 3.…
在人月神話裡,花了兩章的篇幅說明在軟體開發上, 不會有類似銀彈這種,可以快速解決開發時程延誤或發生重大錯誤的捷徑 他們提出了三個原因: (1) 複雜性: 軟體開發的複雜度與規模大小並非線性的關係,整個複雜度增加情況也會遠遠超過線性預估的結果。也因為結構上的複雜性,當軟體在擴充新功能時,難保不會產生新的副作用。程式裡的狀態難以一一列舉,也更加難以明瞭整個產品也會變的更不可靠。另外因為複雜性關係,開發時也容易遇到溝通困難、時程落後、成本超支的困難。 (2) 配合性: 軟體必須配合其他的領域,例如電腦、不同語言、不同介面等等….。 (3) 易變性: 1. 時常面臨修改,因為軟體是純思考的產物,有無限延展性,修改容易,也因此特別容易面臨修改 2. 成功的軟體生命周期會比硬體來的長,因此時常會需要配合硬體環境上去修改。 (4) 隱匿性:過於抽象、難以理解。 在這邊他們也提出了幾項過去曾讓軟體界有所突破的重大發展,但這些突破都是屬於附屬性的,沒辦法突破軟體工程本質上的複雜性: (1) 高階語言:高階語言的發行的確是最強而有力的一次突破,對生產力而言至少有五倍以上的提升。並伴隨得到可靠度、簡潔性、理解力上的增益。它把和程式內涵一點關係都沒有的那一整層複雜性給去除了。 (2) 分時技術:分時技術對於程式設計師的生產力及產品品質有了重大的提升。因為分時確保了即時性,使我們得以持續保持住腦子裡對複雜的概觀。但緩慢的回復時間是附屬難題。 ps: 分時系統:作夜系統依中央處理器排程(CPU Scheduling),將中央處理器的時間切割為極小的時間片段(Time…
花了很多天終於看完了著名的專案管理聖經─『人月神話』在此整理一下大致的重點 1. 開發一個軟體系統產品要付出的代價是一般組件程式的九倍。因為產品化是一般組件程式的三倍時間,設計整合測試又是三倍時間,這兩方面的成本計算基本上是獨立的。 2. 以成本會計為基礎的時程預估方式,使我們誤把工作量和專案進度混為一談,人月是一個危險並容易遭到誤解的迷思,因為他假設人力和工時可以互換。 在此本書裡面,提到,專案管理人員不應該把人/月這樣的標準來做為專案規劃的標準,因為當人員多起來後,整個專案的運行會需要花更多的時間在溝通、管理、協調上,人月之間的關係並非線性關係。 並且勿忽略掉新的程式師要學習上手的開發時間,以及要耗費掉的老手的教育時間。因此,在一個已經延遲的專案中增加人手,只會讓它更加的落後,這邊較建議的方式是重新安排時程、或者刪減工作。 在這一章裡,也提出建議的專案軟體時程安排方法 1/3 規劃 1/6寫程式 1/4組件測試和早期系統測試 1/4系統測試和完成所有的組件 3. 從第三章到第七章,都是在討論保有『整體概念性』的重要。 一個專案的規劃必需出由同一人之手,也就是說,一個專案不應該有兩個領導者。我們必須選出一個能力強的人,來帶領整個專案的開發及方向,我們寧可忽略掉一些可能新奇、或很棒的想法,也必須讓整個專案都能呈現同一個設計理念。此一概念便是這本書所一直提及的整體概念性。 在第三章裡,此本書提出了一個外科手術團隊的做法,來解釋該如何去達到這個整體概念性的目的。 (1) 首席程式設計師:也就是整體概念性裡所提到的做決策的主腦。負責定義功能、設計程式、測試程式並撰寫文件。ps: 此本書也提到,真正優秀的專案管理人員,也應該要寫程式,沒有真正去撰寫一些程式的PM,是無法做好專案管理的工作的。 (2) 副手:外科醫生的分身,可以做所有首席設計師所做的事,或提出想法,但是首席設計師不一定要接納他的想法。 (3) 行政助理:幫忙處理首席程式設計師的所有庶務。一位行政助理可同時處理兩個以上團隊的工作。 (4)…
17年資歷女工程師,專精於動畫、影像辨識以及即時串流程式開發。經常組織活動,邀請優秀的女性分享她們的技術專長,並在眾多場合分享自己的技術知識,也活躍於非營利組織,辦理活動來支持特殊兒及其家庭。期待用技術改變世界。