iT邦幫忙

第 11 屆 iT 邦幫忙鐵人賽

DAY 7
0

再來要介紹另一個與Agile很相像的,Lean 精實開發,也是藉由此次鐵人賽探討DevOps我才第一次看到這個名詞,為什麼要介紹他呢?除了是因為跟敏捷很相像,也是因為後面在說DevOps的時候會有關,因此先利用此篇來探討一下

上網多搜尋幾篇文章介紹,大家都會提到Lean Software Development的源起來自於「Toyota 的TPS生產系統」,重點核心為Just-In-Time流程,強調隨時檢討,將各成本降到最低避免浪費

有七個原則呼應Just-In-Time的觀念:

  • 消除浪費(Eliminate waste)
  • 增強學習(Amplify learning)
  • 延遲決策(Decide as late as possible)
  • 加速發布(Deliver as fast as possible)
  • 尊重授權(Empower the team)
  • 嵌入完整性(Build integrity in)
  • 全局思考(Optimize the whole)

消除浪費(Eliminate waste)

任何東西只要對客戶來說沒有附加價值的都屬於浪費,研究指出軟體開發常見的八種浪費:

  1. Partially done work:預先完成成品,但不能確定日後是否真有其功能需求或過時
  2. Extra Processes:過多的流程,例如不必要的紙本簽核
  3. Extra features:開發過多/額外的功能
  4. Task switching:一個人同時需要執行多個工作
  5. Waiting:等待確認、等待簽核、等待文件....
  6. Motion: 當遇到問題的時候是否有去處理協調
  7. Defects:沒有及時發現問題
  8. Management activities:過多不必要的管理

為了要盡量減少浪費,首先要先能夠理解、識別什麼樣的項目是屬於浪費,例如某個項目是可以被跳過或者移除也能夠達到最終目標的,那就是一種浪費;開發過程中不被使用到的功能、程式碼,也是一種浪費.....

增強學習(Amplify learning)

軟體技術不斷地推成出新,開發流程也是一直因應著時間趨勢改變,不管是個人亦或是團隊,都需要不斷的精進才能跟上時代的腳步,可以說這是一條需要不斷學習的路。

  • 使用短週期來檢視與反饋,能夠快速調整先前的不足,加速學習的能力
  • 避免累積問題或技術債,程式寫好就是立即測試,且適量進行重構與整合測試
  • 與其寫一大堆的文件,不如寫好程式和做出測試來驗證一下想法對不對
  • 頻繁與客戶溝通,確認需求,釐清目標與未來方向
  • 客戶可提供回饋供開發團隊調整,開發團隊亦可藉由與客戶溝通更深入了解domain know-how

延遲決策(Decide as late as possible)

專案往往不確定性很多,包含需求不明確,甚至有時候客戶自己也不知道自己要什麼,因此盡量的延遲決策的時間點,保留多方案的彈性是很重要的,因應隨時會調整的變化。我個人的想法是,因為需求會與時俱進,要完全凍結固定需求是有難度的,因此在設計與開發時都要保有彈性空間,好去應變各式各樣的調整,至於怎麼才叫做有彈性,這就要看經驗和運氣(真的還是有遇過上線前一個禮拜,整個UI翻掉的要求,這種不管多大的彈性還是有必然的成本耗損)

加速發布(Deliver as fast as possible)

這是敏捷中很精華的重點,加速發布有助於更快地獲得客戶反饋,來調整產品的品質與內容,透過小批量的調整,快速迭代更新

尊重授權(Empower the team)

讓團隊中的每個成員都有權利提出想法,有別於過去只是將人當作資源看待,讓團隊的人員都有參與在其中,才能更加加深每個人的融入狀況與提升士氣,同時培養人才

嵌入完整性(Build integrity in)

導入自動化測試,輔助每次異動的測試流程,同時在設計與測試時,每個環境都應該考慮整體系統的完整度,不只是內部的,還有包含外部的,甚至系統流程外的商業流程,有更完整的環節,能有更好的品質

全局思考(Optimize the whole)

一個系統開發完成不會只有一個團隊,一定有多個團隊需要合作,要將思考格局放大,將所有相關的夥伴納入,並密切溝通、資訊透明化,得以降低成本消除隔閡

此為精實軟體開法的七大主軸,說來容易,但其實裡面還有很多的細節需要注意,待我們去實作並瞭解

參考資料、延伸閱讀:

下集預告:What is DevOps?


上一篇
Agile 敏捷開發(二)
下一篇
What is DevOps?(一)
系列文
後端功城獅30天DevOps探討挑戰30

尚未有邦友留言

立即登入留言