Agile Project 初體驗
這篇文章主要是寫我在五倍紅寶石所參與的專案開發，從規劃、設計、開發到最後的交付過程中，我們是怎麼試著將 Agile 這個開發方法實際應用至開發當中。
Kick Off
開發開始前，客戶與我們用一個多禮拜的時間，訂定專案的規格以及開發計畫。
傾聽願景
專案開始的那天，一切都從客人的簡報開始
這個案件客人並不是帶著規格書來找我們開發，而是描述他們對這個產品的想像，比方說：人（使用者有誰、有哪些角色）、事（使用者可以在這個平台上做什麼）、時（這個產品希望什麼時候上線）、地（預計上線的國家）、物（在這個專案中已經有的資源），讓專案成員（工程師、設計師與 PM）開始對產品有些想像，並在會議中提出技術上的建議，讓客戶與我們對於產品的範疇能夠有些共識。
User Story
透過許多方式具體化客人對產品的想像，包含在白板上用 Site Map 的方式先概括產品的基本架構，進而再延伸設計出產品的 Flow Chart，WireFrame。過程當中，客人會更細節的表達出他的需求，像是業務邏輯、必須要有的頁面、必填的欄位等等。而我們根據這些需求，列出每個功能的規格，並且將產品的流程調整至客戶價值最佳的可行流程。
在這個階段，我們有時會發現客人也不太清楚他自己要什麼，或是在溝通過程中發現客人的想法難度很高，此時我們可以提供一些專業的建議來幫助客人做選擇；另外我們也大致知道產品所需要的頁面、功能有哪些，此時專案的開發成員就能夠將功能、畫面拆解成一個一個工作項目，並且由上而下的列出先後順序，也許打在專案管理的軟體上，而我們這次是將工作項目打在共享的 Google Spreadsheet 上管理。
開發前點數估計
以相對難易度的方式估計所有工作項目，藉由得到的總點數來評估專案的規模。
評估點數，是一種能將軟體開發量化的方式，最理想的開發狀況「總點數 / 每人每天可做的點數 = 開發時程」 ，不過敏捷開發的思想考慮到產品開發過程中有各式各樣的變數，會影響到最初的點數評估，許多談 Scrum 的文章都有提到點數評估的方法，以及為什麼需要點數評估。
在開發前評估點數時，除了估計點數也會視情況降低每個工作項目的粒度，例如：當團隊覺得某個功能評為最高點數（例如：5）都不夠時，我們會將功能在拆解成更細的工作內容，這樣一個個把點數評估出來後，得到一個本次專案預計要完成的總點數。
透過總點數除以可用的工作點數可以計算出每日團隊所要完成的點數，如果在這個階段發現每日要做的點數超出團隊成員所能負荷的工作量，我們也更能夠具體的向客戶表達調整所需要工作的內容。
Sprint 規劃
Sprint 是一個固定時間的開發週期，我們以 10 個工作天做為一次 Sprint 來安排工作內容。 Sprint 規劃則是將每條記錄在 Google Spreadsheet 上的工作項目，分配到一個一個的 Sprint 中（如下圖），每個 Sprint 底下要做的事情就是 Sprint Backlog，而同樣的 Sprint 規劃在實際的開發中會依據狀況做調整，但這份規劃表能夠幫助團隊成員以及客戶瞭解開發上的步伐。
開發階段
Sprint 起始會議
這次的專案我們一個 Sprint 是指 10 個工作天，在 Sprint 開始的那天早上，會有個Sprint 起始會議，團隊的成員會瀏覽看這一次的 Sprint 所要完成的 Backlog ，並且依據上一次的 Sprint 狀況做增減點數或是做工作內容上的調整。
這次專案中我們並沒有明確的區分起始會議(Sprint Planning)、衝刺檢視會議（Sprint Review）以及回顧會議(Sprint Retrospective) 這麼多樣完整的會議。
以這次的專案來說，由於我們的客戶並不在國內，開發時間也不是很寬裕。我們認為讓整個團隊都視訊參與衝刺檢視會議會佔用太多的開發時間。所以這部分我們作法是讓客戶透過看 Google Spreadsheet 上的工作進度表主動追蹤我們完成的進度，並且在測試站上實際操作功能。
好處在於我們不用常常開會，開會實在很耗時間，但我們面對的風險在因為沒有與客戶在每次 Sprint 結束後實際展示功能，有很大的機會發生我們做出來的功能跟客戶想像要的功能會有貨差的問題。 比較幸運的是，這次的案子客戶與我們聯繫的狀況很頻繁，許多小問題都能夠開發過程中做調整與改善。
每日站立會議
進到開發階段後，開始每天 15 分鐘的站立會議。 正好公司有個舒適的吧台區，因此每天固定的時間到，團隊成員們就會到移動到吧台區，互相詢問團隊成員幾個問題，來同步彼此的資訊：
- 昨天做了哪些工作項目？
- 今天預計開始做哪個工作項目？
- 在昨天的工作中，有沒有遇到什麼問題或是阻礙？
開會主要內容就這樣，其實一開始時常會超時，遇到的狀況可能會是講到某個問題時就會不自覺得往怎麼解決的方向討論，但這並不是站立會議的用意。
我們後來調整成，站立會議時會有個同事定時，如果正在分享的成員有提到問題時，我們會先記錄下問題，等到站立會議結束後再另外安排會議或是分配資源來解決遇到的問題，最後在隔天的站立會議中再回報問題是不是有解決。
燃盡圖
在敏捷開發的過程中，除了計畫每個 Sprint 階段所要完成的工作項目外，我們同時使用燃盡圖追蹤每日的專案進度，同時客戶也能根據然據圖動態的看到每日專案的發顫狀況。
燃盡圖會依據每天完成的點數、增加的點數，上下移動。當燃盡圖進到危險區塊的時候，我們也會在站立會議中花一點時間看造成進度落後的原因是什麼，以及怎麼調整。
開發過程
- 設計圖確認
- 測試驅動開發 TDD
- Code Review
- 合併分支
對於網站開發，版本控制幾乎是一個不可或缺的要素，我們除了程式碼在非公開的 GitLab 上版控之外，設計圖也在 Zeplin 上做版本的管理，使得開發以及設計更有效率。 當工程師以測試驅動開發的工作方式完成功能開發後，將程式碼發佈至 GitLab 並要求合併時，須經由團隊中其他工程師審查後才能進行合併與發佈。
交付
內部測試與客戶測試
在上線以前，團隊也依據使用者情境做手動的測試，主要確保商業邏輯的正確性以及極端的使用情境的測試。
並邀請客戶，在上線前進行驗收測試，實際操作與測試不同的情境與功能。
部署與維護
最後的調整後，撰寫自動部署的腳本，完成產品的發佈。
結語
調整，直到達到目標
這個專案在搭配敏捷開發的工作流程下，四人的小團隊在 68 個工作天，使客戶的產品能夠順利上線。
專案開發並不是一條直線的道路，過程中往往因應商業模式的調整、時程的壓力而有功能上的調整與變更。
本次的專案，可以感受到藉由敏捷開發的特性，幫助我們與客戶雙方都能及早發現需求的變更並為這些改變做開發上的調整，降低整個專案到交付才發現重大問題的風險。
過程中我們曾經遇到審核設計圖的流程過於耗時導致其他工作的延遲，在站立會議中團隊成員主動表示有這個問題的發生，使我們能夠適時的與客戶調整審核的流程，將專案的進度拉回至預定的進度上。
運用敏捷開發的工作流程，我們相信更能夠幫助開發團隊與客戶之間的溝通，降低資訊的落差並在有限的時間開發出有品質的產品。