此为历史版本和 IPFS 入口查阅区,回到作品页
Tin
IPFS 指纹 这是什么

作品指纹

ProductTank Taipei #10 筆記:敏捷開發與轉型(下)

Tin
·
·
由 Gogolook 負責 Whoscall 的資深產品經理 張仕杰,以及 91APP 負責 CRM 解決方案相關的資深產品經理 葉力維,分享在各企業中推動敏捷開發的心路歷程,並不藏私的分享其中的訣竅。

這次的 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 面臨四大困境:

  1. 組織:團隊組織越變越大(目前公司產品研發人數達到 150 人),如何在組織轉型中,進行生存,便是個重要問題。
  2. 市場挑戰:市場需求多、純電商看到天花板,需要拓新戰場
  3. Waterfull 的極限:每個專案要 2–3 個月、每個需求變更,都要勞師動眾
  4. 一切都變慢了:產品與研發諜對諜(估時&需求:大家亂估&亂加需求)

因此進行解決,分別為三個方向:

  • 團隊建立:建立跨職能團隊(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 筆記:敏捷開發與轉型(上)

如果喜歡我的文章,也歡迎給我拍手!增加我繼續寫下去的動力:)

CC BY-NC-ND 2.0 授权