ProductTank Taipei #10 筆記：敏捷開發與轉型（下）
這次的 ProductTank Taipei 主題為「敏捷開發與轉型」，由 Gogolook 負責 Whoscall 的資深產品經理 張仕杰，以及 91APP 負責 CRM 解決方案相關的資深產品經理 葉力維，分享在各企業中推動敏捷開發的心路歷程，並不藏私的分享其中的訣竅。
ProductTank Taipei #10 2018 July@Pic collage
葉力維：「我的 91 app 敏捷修羅道」
講者分享 91 app 在敏捷轉型過程經歷的六步驟，從發覺問題、引入顧問、團隊改革到最後發現主管的問題（？）的學習。
Sprint 0 91 app 的困境與變革
91 app 會開始敏捷改革，主要當時 91 app 面臨四大困境：
- 組織：團隊組織越變越大（目前公司產品研發人數達到 150 人），如何在組織轉型中，進行生存，便是個重要問題。
- 市場挑戰：市場需求多、純電商看到天花板，需要拓新戰場
- Waterfull 的極限：每個專案要 2–3 個月、每個需求變更，都要勞師動眾
- 一切都變慢了：產品與研發諜對諜（估時＆需求：大家亂估＆亂加需求）
因此進行解決，分別為三個方向：
- 團隊建立：建立跨職能團隊（9 個人是理想的數字，座位一定要在一起）
- 找有成功經驗的人：讓大家知道，是有可能成功的
- 建立團隊意識：花錢去找顧問去建立（有滿滿感動就又可以一起工作了）
Sprint 1 公開透明
接著如同上半場講者提到透明的重要性，91 App 使用 Kanban 幫助事務可視化。關於 Kanban 的使用心法如下。
- 定義明確：需定義哪些事項需要被公開透明，哪些又太細碎可以用數位工具輔助，且要有明確的 DoD (Defination of Done 完成的定義）
- 搭配數位工具，可以更有效：91 App 使用微軟的敏捷工具 VSTS
- 流動之重要：Kanban 上的便利貼（task），必須要是會動的，如果放一兩週都不會動，就不要貼出來，因為沒有意義
不過每個團隊有各種想法、對於敏捷有各自見解、發號不同行動會需要時間去做調整是很正常的。
Sprint 2 讓專業的人來
在事項可視化後，看到問題後，接著就是要找專業的來協助。關於專家的選擇，建議要找「份量夠」、「講話老闆會聽的」的人來，不然改變很難推動。
91 App 的兩位專家，分別為擁有軟體技術背景（講者表示：這個背景很重要，他的建議 RD 都會聽）的人資長周旺暾，以及業界有名的軟體開發顧問，專長敏捷開發（Agile development）的 Ruddy 老師（李智樺）來進行組織改革。一人負責與老闆溝通，一人負責主管訓練，透過不斷的授課拉齊團隊對於敏捷的知識。
Sprint 3 團隊重組
接著進入團隊的重組，91 App 採行「矩陣型組織」。
2017 年底， 91 App 將 150 人的產品研發重組成 8 個產品線以及 1 個維運團隊。每個團隊的配置約為：大 PO x1 + PO x 1–2 + Teach Leader x1 + UED x 1–2 + RD x N + QA x1-2。
在工具上面為了讓效率提升，在 91 App 每個團隊都有自己的白板，用看板的方法來做管理的工作。白板的好處除了讓一切透明外（看到一堆貼紙堆在一區，就知道有問題了），也讓大家可以吵架更方便、也更快結束。
在這變動與改革的過程中，每位夥伴可能想法都會不同，但有一點是一樣的就是「焦慮」。適時的讓夥伴說出焦慮、就算無法立即解決，説出來也可以達成某種共識（原來我們都有這個煩惱啊），進而建立起團隊夥伴的默契。
除了透過工具、溝通外，正面思考的心態更是不可缺少，也往往是能否成功的重要因素。
Sprint 4 91 app 的 agile way & Sprint 5 現場的困境
在敏捷改革中，重要的兩個關鍵「正確的心態」以及「建立自組織」。所謂正確的心態可以用四點做說明：
- 不在意用哪一種方法，只要能敏捷就可以了。（我們要用 agile 不是被 agile 受用）
- 跑敏捷也會有 deadline 迫使大家在死線前做完事情，搭配 MVP 一起執行
- 正視 agile coach 的價值，建立團隊的敏捷思維和能力，引導團隊成為一個自組織（需要有軟有硬的能力）
而在「自組織」，講者則再次強調態度的重要性，要重視目標、主動積極，且接受回饋。而自組織團隊的重點技能為「解決問題」如果不會解決問題，也要「會求助」，求助的時間點以及方式，都十分重要，提早才讓團隊可以互相協助。另外團隊的組成，十分不建議 PO 和 Agile master 一起當，絕對會人格分裂，一人沒辦法同時當黑臉和白臉的。
當然，也會遇到一些問題。像是 Domain Know How 不足，這個補足就好了。也會遇到對於做完（ DoD）想像不同，例如認為寫完 code 就是寫完了，而沒有測試等，這也簡單，只要把定義講清楚，建立共識就 ok。 而有時更會做到一半，突然不確定目標是什麼，這也很常見，此時善用 user story mapping 必要時可以使用 sprint 再次檢視。那如果切缺團隊意識要怎麼辦呢？那就找個暗樁演給他看，或是找 Agile coach 去處理。
另外也要注意，Sprint 不是短跑，而是跑馬拉松。Agile 像是教你如何呼吸，如何找到節奏。因此不建議因為專案的大小一直調整 sprint 的速度，這樣會喘不過氣的。
Sprint N 主管們的敏捷
在 sprint 方法運行漸趨成熟後，能否持續敏捷，就取決於主管們了。
下面的人都很敏捷了，但是主管的一個決策就可以全部推翻。大家都很敏捷了，但是老闆一個決策就可以全部推翻了。
為了防止主管、老闆一個決策打翻一鍋敏捷，91 App 團隊有了 One PBI （Product Backlog Item 產品任務列表）一個 PBI 原則。 One PBI 設立與應用要點如下：
- 需要一個企業等級的 PBI 老闆背書
- 不能天天換，可以換，但需要視企業面對當下的市場場景而定
- 任何開發都要以 One PBI 為依據
推薦書籍
本場演講，講者分享以下書籍供大家研讀：
如果對於上篇有興趣的話：ProductTank Taipei #10 筆記：敏捷開發與轉型（上）
如果喜歡我的文章，也歡迎給我拍手！增加我繼續寫下去的動力：）