在Lean Software Development中以Mary and Tom Poppendieck著的書最有名.
在他們著的書中 "Implementing Lean Software Development - from Concept to Cash"(Mary and Tom Poppendieck著作)提出7個實作Lean的原則, 呼應JIT的觀念, 且反應軟體開發的特質. Lean Software Development背後的想法是: 讓客戶在還沒有清楚資訊以供做正確的決定前, 儘量延後"定型". 不過只要客戶一提出要求, 開發團隊可迅速做出客戶所要的, 在客戶來不及改變主意前出貨給他. 這個作法, 就如我們線上一下單購物, 隔天東西就寄來了, 大多收貨者都不會說要退貨或做任何變更.
這七個Lean的原則是:
1. 避免浪費
如JIT的「徹底的なムダの排除」（徹底排除浪費）, 只要在客戶看來沒有任何附加價值的過程或產出都被視為浪費. 軟體開發的七浪費:
- Particaly Done Work (開發過程中的預先完成品)
- Extra Processes(以文件中心來管理的開發最容易有這種現象)
- Extra Features(應該只開發客戶要的功能)
- Task Switching(每人應一次只專心完成一件事)
- Waiting(等待指示或簽核, 等待資訊..)
- Handoffs(換手的過程一些默認的知識很有可能跟著遺失)
- Defects(無法馬上測到的問題)
- 結合市場與技術領導 -整合市場與技術的專家才有可能激發出先進創新的產品. 你必須了解什麼是對你的客戶有價值, 以及你擁有或可以採用什麼技術來實現.
- 僅聚焦於價值鏈- 小心過分的流程改造, 確定這些流程是你必須的, 你應該聚焦在可以創造價值的流程. （想到軟體專案界常講的CMMI嗎? "裁適"應該比"完美"來得重要)
- 精簡程式碼 - 越多程式碼相對需要越多的測試,如此增加工作量. 所以如果有的功能沒必要, 就不要浪費時間在上面.
- 是否有例行的報表, 會議, 或文件但無濟於價值創造呢?
- 每個人寫的codes在專案範疇內嗎?
- 需求分析有切中要領, 規劃出真正對客戶有價值的東西嗎?
- 是否能將工作儘量獨立切分, 平行運作, 避免相依?
- 如何從coding的品質要求, 即早發現瑕疵?
- 團隊溝通是否要跑很冗長的流程, 有辦法達到如神經組織般的溝通效能?
2. 增強學習能力
軟體開發這途需要不斷精進技術, 也面臨團隊和專案的scale挑戰, 客戶需求變更的不確定性, 和是否熟悉domain know-how的問題. 所以
- "增強學習能力"是改善軟體開發競爭力的最佳法門.
- 避免累積瑕疵, 最好是控管coding的品質或一寫好馬上測試
- 與其寫很多文件或做詳細的計畫, 不如儘快寫code跟做個build來測試一下想法是否行得通
- 客戶需求的收集與整理應簡單明瞭,建議以screens的方式與終端使用者討論需求
- 運用短的開發循環週期(short, full-cycle)來加速學習過程--短週期指的是一個星期到一個月的週期, 每個週期都應做出working software, 週期應包含重構(refactoring)和整合測試(integration testing)
- 簡短且多次地和客戶溝通, 讓開發者與客戶雙方頻繁的對話, 可清楚釐清現階段應投入的功夫(efforts), 以及未來改進的方向. 客戶可以就每次開發團隊完成的結果更明確給與意見, 開發者也可在多次客戶回饋中更釐清domain know-how以及如何做才能滿足客戶.
- 建立有設計能力的建築團隊 - 開發團隊的領導者必須能傾聽團隊成員的聲音並聰明提問讓所有成員有辦法很快地自己找答案或解決問題, 或醞釀更新更好的解決方法- 創造一個可以讓人們在工作中持續改善的環境, 他們應該被知會沒有最完美的, 永遠有更好的方法, 且一定要不斷改善別無他途.
- 培訓問題解決技巧 -開發團隊應該像小的研究單位, 其應該有辦法建立假設, 然後快速執行實驗求證.
- 團隊是否做daily build?
- 如何控管coding的品質? 個人能力和自我把關? 有coding style的check或輔助工具?
- 如何才能即時方便地有記錄地和客戶討論需求, 報告進度, 或做需求變更, 瑕疵回報,文件分享並讓所有參與者知悉呢?
- 如何才能切出可掌控的工作大小, 排出有效的開發循環週期, 而其中的refactory和integration testing的準則和方法又是什麼?
- 如何建立持續改善的機制和環境?
3. 儘量延遲決策
軟體開發不確定的變數很多, 在剛開始時很難預測後面的變化, 所以建議儘量多留活口, 採用options-based approach. 應該根據事實而非根據假設來做決策. 不到清楚明朗, 最後關頭, 都要留多個選項. 另一方法是運用iterative approach(如上述的short, full-cycle), 來應變軟體不可避免的需求變更和機動修正錯誤.
實行重點:
- 到最後關頭才做無法逆轉的決定 - 你應該要知道往哪裡去但你有可能不知道應走哪條路, 但有可能越走越清楚. 最重要的是要往正確的方向走.
- 打散依賴度 - 元件的關聯應該越鬆越好, 如此才可以任意的次序來開發.
- 保持彈性 - 為所有關鍵決策開發多種解決方案以便能從中挑出最好的. 運用Set Based Development的方法:儘可能拆解"產品生產"為可平行運作的"零件生產", 並清楚定義各零件間的整合介面. 如此您可以多頭同時進行, 每個零件也可有多種生產進行的方法. 到要整合的時候, 您將更清楚如何定義這些零件間的整合介面, 且有多種選擇以做出最佳的產品.
- 將部分完成的設計資訊分享(不只是團隊內, 也可以權限分級的分享給客戶)
- 建立團隊每位成員能直接溝通的協同作業機制
- 建立何時應該做決策的共識
- 建立如何吸收變更的共識(避免重複, 分散關連, 打包變數, 延遲使用未來開發資源)
- 致力於重構(refactoring)
- 採用自動化測試工具
4. 儘快出版
儘快出版的目的是讓您的客戶能在最佳的資訊了解狀態下做最好的決策. 一旦客戶一決策, 您的團隊就能很快提供一個可用的版本. 以市場觀點來看, 越快將沒啥大問題的產品上市讓客戶使用, 可以越早獲得客戶的回饋, 併入下一輪開發排程中. 越短的開發週期, 能越快讓開發團隊從市場獲得即時的資訊, 也讓團隊有辦法快速應變市場的變化. 採取可快速應變後續變動的短週期開發法, 才能降低貿然決策後所遇到客戶或市場需求轉向所造成的衝擊.
實行重點:
- 以小批生產方式 - 切割專案成多個release cycles,讓每次release間隔不要太長, 保持開發的速度與穩定的開發環境, 如發現窒礙的原因和作法, 請儘量移除.
- 就資源安排適量工作 - 儘量減少排隊等待的工作(在一兩個iteration後來做還可以), 建議如果要排很久才會輪到的工作, 可以考慮直接排到下一輪, 且如果自己的list裡還有等待自己完成的工作, 就應該拒絕接新的工作.
- 聚焦 cycle time而非利用人力到最大限度 - 在排程中應該將工作切割成小量, 儘量減少因需時太長而看不到工作完成日的問題. 請降低每一iteration的需時, 將每個工作範圍切少一些, 減少排隊等待完成的工作.
5. 授權與尊重
相較傳統的命令式管理, Work-out技巧已被很多有經驗的經理人證實, 反過來做的成功率比較大, 讓你的組員深入參與並決定怎麼做比較好, 自己給commitment, 經理人僅提供如何加強或改進的建議. 如果回顧管理的歷史(請參考Mary Poppendieck走過歷史的演說 The role of leadership in software development), 團隊成員不應只被當reources(資源)看待, 並不是給成員工作的list, 然後就可以完成. 激勵(Motivation), 知道為什麼而做, 以及時常的溝通, 讓成員知道所有相關工作者正在發生什麼事, 對於整體的工作士氣會有很大的幫助. 另外, Lean Software Development很鼓勵讓開發者直接面對客戶,如此開發者對於domain kow-how, 以及自己到底為什麼而做, 會有更深的感觸. 而團隊領導者應提供所有團隊成員應有的支援和幫助, 以克服困難, 維持團隊的合作默契和士氣. 至於所有的團隊成員, 應該給與他們在什麼情況下如何應付的經驗分享和培訓, 已幫助他們做正確的決定.
實行重點:
- 訓練團隊領導者和專家- 訓練你的團隊領導者和專家, 讓他們有能力分享他們的專業, 訓練組員, 建立可實行Lean的環境.
- 將責任與決策權轉移到有可能的最底層- 讓你的人自己思考和決定, 他們應該知道如何運用複雜的演算法或運用完美的軟體架構來寫程式與運用完美的軟體架構.
- 加強工藝的自豪感 - 鼓勵團隊成員熱情的參與他們所有的執行工作與方法
6. 整體經驗
客戶對於軟體的感覺不是只有產品本身, 而是整體產品經驗(integrity), 一種是perceived integrity, 包含產品如何行銷, 出貨, 上線, 接觸, 直覺反應, 價格, 和問題解決經驗. 這是客戶不會告訴你的需求, 需要團隊本身細膩的市場觀察. 另外一種是conceptual integrity, 指系統每一零件的運作和合起來運作的在彈性度, 維護度, 效能, 回應效率等整體狀況是否協調,達到某一定的水準. 要達到令顧客滿意的程度一方面要靠對於問題領域有深度了解的基礎, 一方面要能同時快速解決, 而非要按順序一個一個解決. 所需的資料與其要等全部完整寫成一大篇文件或開冗長的會議,不如持續不斷的雙向溝通, 每次溝通的資訊可以是短短的,不浪費太多時間的. 儘量避免長久隔離後才一次給與大量資訊的方式, 這會讓雙方的溝通充滿挫折感, 也較難給客戶好的整體經驗.
實行重點:
- 順暢詳細的資訊流 - 建立客戶, 使用者, 開發者間快速同步溝通的聯絡網. 正如Agile強調: Customer collaboration over contract negotiation.
- 與人同步前的品質保證 - 為了讓你的軟體達到高品質, 你應該在一行程式都還沒寫之前就開始操心, 如果你是等到要與別人同步時才開始操心, 會很慘的.
- 自動化 - 強調及早, 經常, 全面性的測試. 所以如果能夠自動化test, build, deploy,只要是例行作業都能自動化, 將有助於提昇 integrity.
- 重構(Refactor) - 將程式碼複製降到"零"-每次運用程式重構, 測試, 或文件來降低複雜度
7.系統思考
如果我們去觀察大多數的管理理論, 多強調工作拆解後被分析出來的個個元素的最佳化. 但Lean thinking認為如果你從局部來做最佳化, 常常導致整體的次等化. 為何會這樣? 作者舉例, 如果你想要最佳化測試資源的運用, 那麼你將降低一定時間內整體產生測試過且可用code的數量. 此外, 就算你傾全力來降低個人的瑕疵, 還是避免不了一個有名的事實-80%的瑕疵來自系統工作方式, 也就是管理上的問題. 欲避免這樣的問題, 建議應該去鼓勵人與人之間的溝通協調, 著重"我能影響什麼"而非"我能控制什麼". 由高於"個人"一層來觀察, 如去看整個團隊的瑕疵數量, 而非去探討個人的瑕疵數量. 改善的方式與結果評量也以整體表現來考量. 要求系統思考的原因是: 作者發現加強個人並不會真的提高整體表現, 但發覺如果是整個團隊一起探討改進, 修改系統工作方式, 整體表現可以很顯著的提昇.
實行重點:
- 聚焦於整體的價值鏈 - 專注於贏得整體的比賽, 不要只看到每個局部的改善, 要從整個組織產品整體來考量最佳化.
- 完整的出貨 - 整個團隊需要好的領導也需要好的工程師, 業務, 市場專家, 助理秘書...全部合起來以最好產品和服務呈獻給客戶.
總而言之, Lean的基本想法是如果開發者能被尊重且互相有效的溝通協調, 這群開發者就比其他團隊更有可能做出好的產品來滿足客戶---- 聚焦人本與溝通協調.
如果你看上面那7個原則感覺還不夠的話, 建議看看Mary Poppendieck走過歷史的演說 The role of leadership in software development 應該可以更清楚了解整個Lean概念的啟蒙, 以下擷取幾張片段, 看過後應該有更深的感觸.
1. 對於傳統的MRP模式, 作者認為這不是working hard就能100%達到規劃好的進度.
沒有所謂的SOP, 只有how to constantly improve the way to get work done.
2.第一個提出Perl管理專案概念的Polaris專案成功的原因並不歸功於Perl, 而是以下幾點：
3. 發現Mission Critical Job能夠成功做到不危及生命的Mind Set是:
<
4. US Army 發覺戰勝的Leadership應該是給mission command而不是detailed command. 重點在delegate(委派), 如果你要讓人發揮他的價值, 就要授權讓他思考判斷. 主要讓他知道What need to be achieved, 而不是What to do.
5. 整個組織要訓練expert能分享他的經驗, 教育其他人, 在產品Concept到Cash的階段, 是個不斷Technology與Marketing marriage的collaboration和創造, 與知識的創造和分享.
6. 你要找的是認知自己在建教堂的工人, 而不是認為他在切石頭或填飽肚子的工人.
參考資料:
Youtube: The role of leadership in software development
agilesoftwaredevelopment.com Seven Principles of Lean Software DevelopmentLean Software Development
Wikipedia: JIT生産システム
Wikipedia: Lean software development
