老虎機前端開發 Part 3

大家好，本篇將會為各位介紹和整理適用於博弈業的敏捷開發，相信有接觸過軟體產業的，對敏捷開發這個名詞一定不陌生，而以目前博弈軟體開發的潮流趨勢，還有競爭者眾和技術更迭的情況下，博弈的軟體開發一般來說可能會有以下特性:

• 多平台發布的需求
• 項目累積速度快
• 需要快速且穩定的產出
• 需要對發生的問題能快速找到原因並解決
• 更改變化的需求頻繁

在上敘的特性下，博弈產業的軟體研發其實是很適合導入敏捷開發。

本篇適合對象:

• 公司/部門已經在執行敏捷開發
• 公司/部門未執行敏捷開發，但想導入
• 不管公司/部門有無導入，想成為敏捷的高效率開發者

在進入正題之前，這是首先必須打預防針的事情，這幾年"敏捷"一詞幾乎已經變成新式軟體開發的代名詞，但也造成了非常多的誤解，以為形式上做到了就可以加速專案開發，但經常造成更多合作上的誤解和更混亂的工作排程。

其實他的核心理念是需要每個成員都有共識，並從自身開始提升，嚴格說起來並不太適合以往台灣大家的工作習性，絕對不是導入敏捷開發就可以改變一切。因此當導入這個方法不順利時，不一定要強制執行，也許會有更適合的方法。

宣言的撰寫是於早期敏捷開發觀念剛起始時，而透過以下宣言，我們可以明白敏捷最重要的核心觀念:藉著親自並協助他人進行軟體開發，我們正致力於發掘更優良的軟體開發方法。透過這樣的努力，我們已建立以下價值觀：

也就是說，雖然右側項目有其價值，但我們更重視左側項目。

敏捷開發最常用到的一種形式 - SCRUM，下面這張圖是我看過描述最生動的一張，很清楚地可以看出觀念和流程

從上圖來看，簡單來說可以拆成以下步驟:

• 成員為 - 產品負責人(Product Owner - PO )、Scrum主導者(Scrum Master - SM)、其他的開發成員(Development Team)
• 由PO提供所有的需求，SM召開規劃會議，開發成員領取任務
• 決定任務後開始衝刺(Sprint )，1-4週為一個週期，目標衝刺出可用的軟體
• 由SM來主導每日的站立會議，會議不超過十五分鐘
• 針對衝刺的產出做檢視和討論及改善

但對於敏捷開發的程序和流程，更重要的其實是單位成員自身的認知。 若沒有工程師的配合，再順的敏捷開發流程，再厲害的 Scrum master 都將無法順利讓專案團隊給敏捷起來。想成為一個適合敏捷開發的高效率工程師，或許你可以這麼做:

• 提高專案整體細節的掌握度
  • 即使該項目的負責成員不在，也能短時間頂替另一個人的項目；有人詢問專案狀況，都能明確回答對方並協助解決問題。
• 掌握git flow的使用方法
  • 呈上，需要對專案細節有高度掌握，知道git flow如何使用和運作是必須的，看code、找問題、管理版本都可運用。
• 提升開發工具的熟練度
  • 熟系IDE的熱鍵、編輯工具熟悉度，甚至英打的速度。
• 提升單位時間的專注度
  • 並不是整天上班都要完全集中，但要提升效率唯有專注，一定要分配每日專注在任務上的時間，可參考"番茄鐘工作法"的概念。
• 提升估算工時的精準度
  • 呈上，在對自己的產出效率加上對任務的掌握度，同時提升估算任務工時的能力。
• TDD
  • 做功能一定要檢查和測試，不要交付一個有問題的東西，這也是身為工程師的道德。
• 掌握CI/CD
  • 能夠自動化的就自動化，減少重複的操作，增加可運用的時間。

若你是資深的人員(或主管)，或許可以更進一步的:

• 最佳化重複步驟(iteration)的速度
• 建立正確的軟體抽象層
• 使用程式碼審查流程專注產出高品質代碼
• 建立程式碼共享所有權
• 分配 20 ％的時間策略
• 建立一個持續學習和改善的文化

敏捷開發這名詞其實在資訊業界已經流行很久，累積的資訊和各方經驗談的含量都非常的大，所以容許本篇比較介紹性的帶過，若有需要請留言，可以另外提供書單或關鍵字。而敏捷開發觀念同樣適用於各種(資訊)產業或專案管理，也沒有特別劃分前後端，本篇因本身對前端經驗較多，偏向前端軟體開發的角度來分享，也非常歡迎各界朋友提出看法和討論。