5xRuby 的敏捷開發法 (1)：從啟動到準備

「敏捷開發」是現今在軟體開發的主流概念，但因應執行方法不同，企業未必能體感到他的好處。本篇將依照過去實際專案操作的經驗，揭開實戰中如何運用敏捷開發，達成任務。

敏捷並不絕對等於快速，但比起其他開發方式更加有彈性，能快速適應規格變化。

Step1.確認目標

專案的起點，從釐清 idea 的商業模式開始。開發前，客戶用一到二週的時間，與我們密集工作，訂定專案的規格以及開發計畫。

在這個案例中，客戶並非定好規格才來找我們，手上並沒有任何文件化的需求。

五倍紅寶石團隊與客戶在會議室用一整週的時間，用白板上手繪商業邏輯、使用流程、定好 MVP（最小可行性產品）核心功能等定好必備項目。常見開發必須資訊會包含：

• 人：使用者是誰，有哪些角色
• 事：使用者要在這平台做什麼
• 時：希望什麼時候上線
• 地：預計在哪裡上線
• 物：專案資源，預算與金錢，服務上線後的營運人力等等。

即便再克難再緊急的需求，我們依然能透過許多方式具現化客人對產品的想像，以確保認知一致，並在動腦過程中找出更適合的解決方案。

具現化的方法包含在白板上用 Sitemap繪出服務結構，進而延伸出產品 Flowchart，Wireframe。Flowchart 只會運用在最關鍵最複雜的功能上，其他小功能則是用 Wireframe 確認即可。

過程中，客人會再更細節的補足需求，像是業務邏輯、必要頁面、必填欄位等。而我們會根據客戶的反饋，將規格釐清並精煉，調整至讓商業邏輯可運行的最佳可行方案。

有時會發現客人也不太清楚自己要什麼，或是聊過後發現客人的想法難度很高，手邊資源無法現實地實現他的期待。此時我們會提供建議幫助客戶取捨，另外我們也大致掌握產品所需頁面和功能，專案成員就能把功能、畫面拆解成一個一個工作項目，並列出先後順序，記錄在專案管理軟體上。

Tip：找出產品關鍵價值
在需求確認時，許多客戶都面臨功能取捨的難題。決定需求時，常見的誤區是把「Nice to have」：例如 UI 優化，全部視為 Must have。這時候我們會估算這些處於模糊地帶的需求需要額外花多少時間，如超過 2週，則視為投入成本太高，建議捨去。

如何在 MVP 階段盡力不要 Over design（過度設計），是我們不間斷在協助客戶克服的。

Step2.點數估計

將所有開發項目賦予點數，並藉由總點數來評估各項工作的規模。點數評估是將軟體開發量化的方式。

一般來說：「總點數 / 每人每天可做的點數 = 開發時程」。

評估點數時，我們會將功能拆解成更細的工作內容，賦予點數時，各個工作的點數級距也會盡量拉大，當切分級距夠大時，就可以看出每樣工作的複雜程度，並計算出進度和投入資源開發的投報率，以便客戶評估該工作量的重要程度。如果各項工作的點數級距不夠大，則較難評量重要性。

透過總點數除以可用的工作點數可以計算出每日團隊所要完成的點數，在點數估計完成後，我們也會視點數分配，如果在這個階段發現每日分配到的完成點數超出團隊成員所能負荷的工作量，再提供一次客戶開發建議。

Tip：將資源花在刀口上
如果說在「確認目標」時還有無法下決定取捨的，那麼點數估計時就可以具體量化這些無法取捨的項目，在成本有限下，對專案的影響有多大。因此在這個階段，我們還是會再協助客戶釐清一次需求，力求把成本花在刀口上。

Step3.Sprint 規劃

Sprint 是一個固定時間的開發週期，我們以 10 個工作天（2週）做為一次 Sprint 來安排工作內容。 我們將所有工作項目分配到各個 Sprint 中，每個 Sprint 底下分配的工作項目就是 Sprint Backlog，而同樣的 Sprint 規劃在實際的開發中會依據狀況做調整，但這份規劃表能夠幫助團隊成員以及客戶瞭解開發節奏。

下一章，我們來聊聊正式進入開發後。

想要閱讀更多來自五倍紅寶石軟體開發的技術分享？歡迎訂閱我們的月報，每月將自動幫你送上最新文章。