第一次聽到敏捷開發這個詞的我，直覺是這個作法應該是環繞在效率至上為核心進行開展，直到瞭解並實行後，我發現敏捷的精神在於不厭其煩重複溝通、小量產出一定的成果並快速驗證，每一次的進度都能更接近開發完成的成果。
為什麼需要敏捷 Why Agile?
市場上有非常多前輩是敏捷開發的資深好手可以與他們請教，雖然我在實作的過程還不算非常久，但有一些心得可以和各位分享，比較不會以定義式的硬派講法闡述敏捷實作，專注在我怎麼看以及所遇到的問題。
團隊組成
我認為敏捷開始的第一步需要先定義清楚：誰會需要加入這個敏捷開發的流程？通常是以實際做出產品的角色，像是技術主管、前端或後端工程師、UIUX設計師、產品經理或專案經理為主。
數位產品的誕生可以想像成傳統工廠製程的產線，生產線透過輸送帶傳遞商品，過程中可能會經過自動化的機器賦予加工，但重要的樞紐帶免不了人為的介入確認，而這個環節就是數位產品開發的各位重要角色們。
接著，需要釐清每個角色對敏捷運作流程的認知程度，以我自身經驗為例，團隊過去都是以專案式的角度在開展專案，也就是普遍都是熟悉瀑布式開發（Waterfall）的方式，但卻又沒有一個明確的交付時間點，這個不小心影響的習慣可能影響的負面層面非常廣泛，包含：
(1) 其他團隊同事（產品經理的利害關係人）對於產品功能釋出的時間相當困惑，對於產品開發團隊或是產品經理無法準確回答功能釋出的預計完成時間，只能獲得一問三不知的答案，可能導致信任感低下，不利於組織營運發展。
(2) 做出來的功能不是使用者真正需要的，從開始開發時就不小心正在累積未來的技術負債。產品經理在做前期市場調研與使用者訪談以瞭解需求如果不夠明確，直接會形成開發團隊在規劃產品時的漏洞，不要小看一個小功能或許不小心牽一髮聯動整個產品時，產品經理不只白費工，此舉更可能導致開發團隊士氣低迷，因為收到的回饋僅是「這個功能不好用」、「這個功能我不會用」等負面聲浪。
(3) 產品迭代效率慢，被競爭對手超車。數位產品的變形速度相當快，一旦開發時間無限延遲 Delay 將與生意機會成反比，也準備面對如何與老闆報告。
梳理清楚為什麼不採用瀑布式開發的原因後，採納敏捷開發的原因可以和團隊做簡易的分享，且引言的部分可以先提到團隊整體大目標，這時可以納入產品經理先行規劃好的產品路線圖（Product Roadmap），告訴團隊每個階段分別的里程碑，至於如何做？則是與團隊一起討論而得的。
敏捷需要的工具
產品經理的工作很常像是一個多工的文字工作者，但卻又不能投入太多時間著墨語意美感，精簡重點切中要害才是首要關鍵。在文件檔案更是考驗每個人的收納能力，極簡主義者和囤物狂都不適用，大至從電腦資料夾分類開始進行檔案管理；小至 Excel 的每個分頁（Sheet）排列順序、點進去後的呈現的內容等。一再地考驗產品經理的文件撰寫與專案管理能力，但在這篇文章中僅列出我與團隊執行敏捷開發時會用到的工具：
(1) 產品項目清單 Product Backlog
預覽蓄勢待發的每一個功能項目，以及回顧辛苦的完成的每一個功能項目，正是 Product Backlog 存在的價值。一開始我規劃文件內容時感到相當期待，把表格製作好、欄位就緒後，按照預計完成時間開始排序每一個待開發的功能。感謝網路的諸位大神們的參考範例檔案，最後我製作的版本包含的內容如下（內容經過重製用以 demo）：
首欄放上 TK 代碼，這一欄表示每個待開發項目的身分證 ID 的概念，獨一無二！同時也對應在下面將會介紹的 Trello 卡片應用，因此也同為 Trello 的卡號（TK = Ticket）。至於編號前面有沒有放置英文字母沒有差別，只是我同時管理其他產品，希望在編號上也可以對應產品做出區隔，因此以產品的英文首字縮寫為主，組成 N+001 = N001。
接著放上功能優先級，我會先在另一個分頁中製作此表單中所有會用到的資料驗證內容，屆時像在優先級的儲存格中，可以直接點擊三角按鈕下拉選擇項目。分級的部分分為 P1 – P3 以及完成，至於各項目怎麼定義出是哪一個程度，將在之後的章節 3. 敏捷的儀式感 說明。
需求類別分為 4 種：加功能／優化／待確認／待討論，依照項目屬性選填。
區塊的部分我會按照產品的架構劃分，所以這部分就會與我展示用的檔案完全不同了，且也要記得納入考量多種裝置的情況，區塊的部分會呈現非常多的項目，我建議是盡可能將區塊切割得越明確越好。
此份表格的核心登場：項目。以敏捷開發的精神，我會試著自己先將預計開發的功能先做拆解，原因是當功能項目放得越大，開發時間勢必會變長，反之功能越小，越可以掌握小項目的完成時間與狀態。例如：目標是新增一個關於受眾輪廓的圖表；我會簡單的拆解成：圖表需要包含 2 張圖 – 長條圖與折線圖，而長條圖與折線圖我會列為 2 個不同的項目呈現。甚至可能其中一張圖完成後，我會先以最陽春的版本先請公司同事（內部使用者）檢視，確認需求符合程度與觀察滿意度。
接著會依序列出該項目的版本號、負責該項目的團隊成員：設計師、前端與後端工程師或是有無需要其他人支援。表格中團隊成員我會直接放上夥伴的名字唷，以利各成員瞭解自己的項目。
最後是 3 個重要的時間點，分別為：預定完成日／實際完成日／發布日期。發布日期我的定義是版本發布日期，我需要記載該項目對應的版本是在哪一天釋出的。
(2) Trello
比較多種專案管理工具後，以免費、協作成員無限量的 Trello 勝出，自擔任產品經理後，Trello 不僅是敏捷開發的好夥伴，同時也是我紀錄自己每天工作內容的好用工具（之後有機會分享）。基本上我會與上方的 Product Backlog 並行處理，通常是完成 Product Backlog 後緊接著會開始調整 Trello 的列表與卡片，對應 TK 代碼 + 項目名稱，成為一個 Trello 的卡片，請參考下圖：
敏捷的儀式感
(1) 每日站立會議（Daily Stand-up Meeting）
當團隊成員瞭解準備要進入敏捷思維與實作，怎麼開始做會是產品經理需要引導的第一步。我的做法是先讓團隊養成每日站立會議 – 站著，因為腳容易痠，所以講重點即可。
比較進階的敏捷團隊，會讓成員自行輪流說明事項，而非由產品經理或是 Scrum Master 指定由誰發言；而我現在所屬的團隊我也兼作 Scrum Master 的角色。（註 ▹ Scrum Master 指的是主持敏捷會議的主事者，有餘力時會從中優化敏捷會議或是開發流程）
回到每日站立會議，除了產品經理和 Scrum Master，其他成員們需要說明今日預計完成項目、昨天執行的項目執行狀況（完成度／是否遇到困難）、其他問題討論。通常，產品經理在成員們說明時不會介入提出意見，我喜歡的站立會議是讓成員間可以互相交流，例如前端工程師在實作某個功能時遇到問題，需要與設計師確認；但如果是實際功能規格團隊成員認為需求不明確或希望討論，產品經理隨時回覆是沒有問題的。
(2) 預備開發產品項目確認會議（Product Backlog Refinement, PBR）
依照上述提及的產品項目清單 Product Backlog 為依據，請準備進入這個專案的夥伴都需要參與此會議，並照著各個項目逐一認領、討論預估工時及評估可行性或潛在問題。因此在安排此會議時通常會安排 1 – 2.5 小時為限，若會議時間過長也容易造成注意力下降，反而降低品質。
評估工時的方向會以每人在一個衝刺區間（Sprint）可以完成的項目。舉例：1 個 Sprint 為 2 週，而 A 功能需要 4 週的開發時間，因此需要拆解功能實際可以做的功能細項；可以做到 50 % 的功能，進度會落在第 1 週的 Sprint，全部完成需要在第 2 週的 Sprint。
(3) 產品開發回顧會議（Product Sprint Retrospective）
這個項目老實說按照我目前的團隊比較少落實，與現況開發時程很趕有關，沒有適宜的時間可以好好回顧與檢討，因此這塊也是我未來想要努力的面向。不過在優化開發效能時，我們團隊會在每日站立會議作即時的調整，像是開發人員的工作調度、backlog 抽換調整等，要先做到不要遺漏必須掌握的進度與產出，進而優化效能（腦中浮現燃盡圖）。
敏捷需要的產品經理
所以，產品經理可以賦予整個開發流程什麼力量呢？
我覺得像是一個隨時可以調度自己角色「位置」的人，多數時候會是走在團隊前面指引方向、而當團隊面臨步伐趨緩時反而變成在後面推著團隊前進的人。很多人認為產品經理、各種 PM 們就是壞人的象徵，不過我總是會想是從誰的視角來判斷壞人感？是因為工程師們覺得開發時程被壓的很趕？設計師不理解產品經理開出的功能目的？…
很多時候可能透過敏捷環節的每一個小齒輪可以化解來自不同角色認知上的衝突。而產品經理需要具備的能力除了引導、更需要有堅毅的信念，我認為加值項目也需要有敏銳的觀察力，除了商業市場以及對人的敏感度。總歸一句，產品經理被賦予的期待與實際該做的事情太多太多了，敏捷開發的重要性更加被突顯出來，有助於減緩從微小之處就發現產品或是團隊現正面臨的真實情況。