進度條

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

又敏捷、又精實,工程師的生活充滿著苦難

作者: Vincent Ke 更新日期:

先前小編已經先行介紹過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粉絲團按讚喔!!

Medium vincent

Vincent Ke

喜歡把混亂的事情變的簡單 用嘴巴做事其實很可以 但要結合靈活的腦袋思考 就一起來拆解吧