只有當兵才需要「精實」一下?五分鐘了解軟體「精實開發」七大心法

先前小編已經先行介紹過Scrum和Kanban的原理和使用方式，來讓大家加深對Agile(敏捷式開發)的概念，但如果大家有去上過agile課程時，通常還會聽到另外一個專有名詞「Lean Software Development，精實軟體開發」一開始連穩如泰山的小編如我，在聽到精實兩字都嚇到吃手手了。

 

 

但其實精實這兩個字，著眼點並非是在體能上的考究(難道要你邊深蹲邊打Code?)，而是在轉換自己在軟體開發上的想法，讓他可以更彈性，更敏捷卻不失去把事做好的方法之一。如果說看板和Scrum都是一種agile視覺化呈現的開發方式的話，那精實開發應該可以堪稱為「輔助Agile的必修心法」，也就是敏捷開發模式中最重要的「思考模式」，但到底有多精實呢?

 

首先大家應該還記得，之前的看板方法是起源來自工廠生產線吧?而「精實軟體開發」也正是從Toyota 汽車生產線衍生而來，之後由Agile社群導入了軟體工程的開發領域中，在經過多年來的討論和修正之後，現在也成為了新創產業中不可或缺的重要管理思維。

 

但精實講究的，並非是像國軍操演的那種精實訓練，而是在考究如何把有效益的產出最大化的概念，畢竟這也是二戰之後的日本，面臨到因經濟蕭條造成的產業危機。

 

 

而精實開發的原理，基本上可以分成下列七大準則：

 

1. Eliminate Waste 消除浪費

 

消除浪費在過去汽車產業中，如果生產出來的零件並非是急迫需要，或是在生產過程中多餘的動作，都可視為一種浪費行為，而這樣浪費的概念也並非只是在物件上作討論，包含良率、已經產線等待的時間消耗上，都是消除浪費需要解決的問題。

 

所以換句話說，如果你在產品上的設計，無法給客戶增加價值，或是需求無法帶來有效的業績，那其實都是一種浪費行為，甚至是那些繁文縟節的Paper work，以及程式代碼上不必要的邏輯等，都是一種浪費，而消除浪費的重點，就是要把產品及客戶的價值有效化，最大化。如果有一件事(或一個功能)做或不做都沒差，相信我，不做就是避免浪費的方法。

 

 

 

2. Amplify Learning 增強學習

增強學習的概念上比較模糊，但我們可以把她想成「如何快速讓團隊了解(學習)到開發的需求以及重心，並定期檢核每一次的工作成果，去做改善」，所以重點會在「更有效的溝通」以及「持續的反饋上」，而這也是Agile一直再強調的重心之一。

 

而實作方法就如同Agile強調，把每一次的產品交付週期縮小化，透過每一次交付產品後作團隊間的回饋討論(Retrospective)，來知道這一次開發的瓶頸，是否有訊息上的落差..等等，這樣的改善也才能有效把產線的調整更敏捷，而也因為交付週期的縮小化，讓團隊間的工作效率如何有效提升，例如Wireframe如何可以更簡短有效、測試如何可以更自動、更詳盡..等等，也都是增強學習要改善的目標。

 

3. Decide as Late as Possible 推遲決策

我們有需要在今晚決定明天的晚餐嗎?還是等到明天再決定呢?這其實就是一個顯而易見的例子，若沒有時間上的限制，我們都應該把決策的時間點往後推移，因為越往後走，所有關鍵影響的要素才越能顯現，如果下一個決定之後終究會因為時間因素被推翻，那就不如最後一刻再決定吧!因為只有蒐集完整決策資訊那做出來的決策才會是有效的。

 

 

 

4. Deliveras Fast as Possible 盡快交付

越早把產品(或功能)交付給客戶，才能越早發現問題，越早反饋，而這也是為了和增強學習搭配不可或缺的一環，所以如何縮小開發範圍，並交付給客戶(或是Product owner)驗收..等等，都是盡快交付的實作法則，而不是等大樓蓋好才發現蓋錯地方。

 

5. Empower the Team 團隊授權

不論看板還是Scrum，機制成行的重點都是在團隊自決上，讓團隊成員都可以針對產品去作出建議，定立目標，而並非是由過去的領導獨大等方式，這樣才能讓團隊間的火花萌生，創造出產品更大的可能性。而當然把權利授予團隊後，不僅可以凝聚士氣，也可以讓團隊為自己產出的結果負責。

 

 

 

6. Build integrity in 整合思維

當客戶或使用者在使用產品時，並非會以功能的角度來思考一個產品的價值，而是會用「整個產品好不好用」的概念，來給產品作為評分的標準，所以團隊除了要將分工作出明確且細微的切割外，也必須要思考「組合起來」之後，整個產品的架構、服務或是可用性，到底好或不好。

 

而產品本身也必須再靈活性及易維護性上面作出平衡，這也是為什麼可以把產品透過功能面來作出切割的理由之一，因為過於巨大的產品容易因為改動而牽一髮動全身，也很容易因為大型的更新造成使用者上的不習慣，相反若是一點一點的作出功能面上更新，也比較容易讓使用者去適應，所以在整合思維上，在產品的「拆解」和「組合」上相當重要，而拆解和組合上更需要透過直接與客戶/使用者作溝通，才能了解這樣的拆解和組合是否如同團隊想像。

 

另外在整合上還有一個重要的概念「refactoring，重構」，因為當產品作出多次的更新改版後，功能以及不像過去的單純，程式面也會愈趨肥大，屆時代碼上的調整難度也會隨之變高，如何適時的把產品重構也是一個重要的概念，而DevOps裡的自動化，也是幫助重構的一個重要方式。因為唯有透過自動化重構及測試的導入，才有辦法讓重構的過程中保持重構效率及產品的穩定性，當然這其中也會牽涉到過去開發品質上的問題，所以藉由重構中也可以省思這些過去開發中，是否有造成不必要浪費等。

 

但記得，重構的砍掉重練重點是在產品效益的提升，而並非是導入自動化的手段。

 

 

7. See the whole 著眼全局

一個產品不僅牽涉到顧客的服務面，包含維運、行銷..等等，都是一個產品必須注意的枝微末節，而當開發團隊作每一個最佳化的思考時，也必須從整個產品面的思考去下手，因為每一項改善，都有可能對整體產品作出蝴蝶效應，只有局部的最佳化是不夠的，整體產品的最佳化，並且讓跨組織間的合作更為平滑，才應該是團隊專注的課題。

 

 

如果把上述七點作出簡短的總結，就是「Think big, act small, fail fast; learn rapidly」，思考時必須著眼全局，但改動時必須要小而巧，就算失敗的快，也可以透過反饋機制來快速學習，這也是精實開發最希望帶給團隊間去思考的重要準則，所以在DevOps中，精實開發的思維也佔了很重要的角色。但記住，任何方法都是手段，而非目的，如何依據自己組織和產品的特性來作方法上的調整，而非為作而作，才是學習的最終精神。
 

最後，如果你喜歡我們的文章，別忘了到我們的FB粉絲團按讚喔!!