almost 2 years ago

我第一次接觸到敏捷開發這個詞,大約是 2008 年。本來剛入門對於這個詞是懵懵懂懂,但隨著經歷大大小小過百個專案,試過十數套專案進行方式後。在這七年當中,我逐漸累積建立自己一套系統性的心法與作法。

常有朋友問我「敏捷開發」要如何學習?

當然,最快的方式,我會推薦你來報敏捷專案管理班2015年版。這是許多專案血淚經驗以及書籍精華融會貫通的懶人包。大家最常問的一百多個問題,幾乎答案都在裡面。沒有那麼多時間自己讀書,或者衝不過鬼打牆的天險,報這個最快。

如果有時間讀書,其實我推薦大家自己研究以及實踐。

畢竟自己實踐出來的心得還是最牢靠。

回到主題,為什麼我要寫這篇「如何入門敏捷專案開發」?因為不少朋友想要掌握這門學問,卻因為網路上 google 到太多資料,不知道如何篩選。導入敏捷框架,反而沒有加速,還被團隊裡的反彈搞得鼻青臉腫。總而言之,走了很多冤枉路,所以我想寫一篇導讀,節省大家的時間。

1. 欲練神宮,必先自宮。第一件事:放棄學習專案完美規劃術。

下這個標題,我知道許多 PM 對於這件事,一定完全無法接受。

但在這裡,我也必須要告訴你一件殘酷的事實,這件事情沒得妥協。如果想要導入「敏捷專案開發」,團隊必須完全放棄由 PM 寫規格 -> 美術畫 Mockup -> RD 套版這樣的做事流程。

(如果你在這樣的架構下要導入敏捷開發,只會比當初沒導的情況下還慘,這就是為什麼有人會誤以為敏捷開發是半吊子沒用的技術。因為大家會以為不寫文件、亂寫文件,就是敏捷。)

我了解 PM 想學專案管理,進階技巧,甚至是學習敏捷專案開發。為的是「提前規劃」「巨細靡遺的不漏重點」「不讓大家浪費時間」。但是除非你做的是 repeat 性的專案(也就是你做過一次知道怎麼做了)。否則對於未知性的專案,這樣的方法只會越往反方向的結果走去(也就是越浪費團隊的時間,團隊成員對 PM 不滿的聲浪越大)。

而世界上大多數的軟體專案,處於「未知」的專案。專案成員(包括 PM)對於專案時程未知,耗用資源未知,專案難度未知。大家只明確知道一件事:「deadline」。

2. 敏捷三重點:消除浪費、過程透明、交付正確成果

當然,禁止了「走向完美規劃」這個方向,會讓很多 PM 大腦瞬間當機。因為這是一直以來大家對於「專案管理」的積極作法,甚至是終極方向。

那麼如果採用敏捷開發的方式又是怎麼做?

在談這件事之前,我想先來談談專案結束後,大家最挫敗的是哪些事?
我想應該是:

  • 在專案前期中期,錯誤的規劃方向大量的浪費團隊寶貴的時間
  • 在專案協作的時候,成員對於「規格」錯誤的「解讀」,導致不必要的「反覆大方向修改」
  • 交付成果完全錯誤。當初花了大把時間規劃出的東西,完全沒人要用,當初熬夜死線加班,好像夢一場。

也因為每次都會產生這三樣的挫敗,所以大家會一直想把原因歸咎於「當初沒有完美規劃,所以造成的災難」,所以解決方法就是「研究如何一開始就完美的規畫調查出詳細的細節以避免慘劇發生」。

PM 是專案裡面「最沒有實作專業」的人,PM 的工作是負責協調資源,而不是負責「主觀的翻譯」「主觀的下決定」

事實上這反而是錯誤的解法。「研究如何一開始就完美的規畫調查出詳細的細節以避免慘劇發生」的解法奠基於「PM 是全知全能的」。現實生活中,PM 反而可能是專案裡面「最沒有『執行實作』專業」的人。所以 PM 永遠不可能做到這件事情。

要讓專案能夠準確以及快速地前進,必須要仰賴於「有實作專業的人」,了解「正確要交付的結果」,才能辦到。

過去瀑布流的過程:『 PM 寫規格 -> 美術畫 Mockup -> RD 套版』,反而會造成了

  1. PM 花了太多時間以「PM自己」的角度,規劃了完全不接近事實的規格與進度
  2. 因為規格省略了「情境」,所以實作的 RD 以及 ART,對於規格有各自解讀的方式,以及實作的方式。在「沒有時間溝通」的情況下,交付了完全不能用的東西。或起了嚴重的爭執。
  3. 當初「規劃」的「進度」,完全是綁死在「每個里程碑皆能完美交付,並沒有意外產生」的情況下。忽略了專案進行其實有「溝通來往成本」,結果時間就不知不覺被揮霍掉了。

「消除浪費、過程透明、交付正確成果」的系統性作法

所以這些你在各敏捷領域看到的實際作法

  • Scrum 裡面提到的 User Story,其實是來解決「規格被各自解讀」的問題。
  • Kanban 的 Story Board,是解決「時間就不知不覺被揮霍掉」的問題。
  • Daily Standup 是解決「大家都不溝通,結果執行方向歪掉」的問題。
  • Integrate Early, Integrate Often 是解決「最後一個月才開始看到成果,所有人包括金主看到最後成果都大憤怒」的問題。
  • etc....

都是為了朝向:「消除浪費、過程透明、交付正確成果」的目標前進。

3. 引入專案管理工具是為了讓「進度透明、時限內交付、可追溯決策」

很多團隊引入專案管理工具,失敗的原因在於:這些團隊只把「專案管理工具」當作是派票(順便可以 email)的工具。

(所以很多執行者,只會在票的內容裡面寫 done)

而忽略了專案管理工具的目的是為了讓「進度透明、時限內交付、可追溯決策」。

反而不小心把專案管理工具將「原先要達到的目標切得支離破碎」,最後人人只 focus 在單項工作的完成,而忽略大局所要完成的「有效成果」。

專案管理工具的發明是為了要在龐大的專案待辦事項(幾百項)中,能夠讓專案成員繼續

  • 保持時間感
  • 階段性交付、階段性驗收
  • 緊密溝通
  • 決策回溯

所以在使用專案管理工具時,通常我還是建議要有自己的一套「切票工作方法」,配合這套工作方法,去對應相對的專案管理工具。

大中小團隊的管理方式以及拆分

專案管理工具有百百種。我會建議依照要完成的事的規模以及團隊 size 去選擇。

  • 小團隊,小事:Trello
  • 中團隊,中事:Brightpod
  • 大團隊,大事:Redmine、Jira

主要的心法在於

  • 小團隊只要用 Kanban 的方式去管。狀態:待辦、正在實作、完成。
  • 大團隊、大項目,則要用 Milestone 與 User Story Mapping 去切分。

4. 框架不是仙丹,專案加速不夠快不是你做的不夠徹底

敏捷世界裡面最有名最熱門的一套框架是 Scrum。這套框架讓許多團隊又愛又恨。愛的是裡面的確很多方法的確是有用的,很多方法卻是詭異到你根本不敢引入團隊的,而且引入以後也發現的確沒用的。

但是你卻不知道,哪一些招術是可用可以不用的,哪一些招術是你執行錯誤還是 Scrum 原先就設計錯誤。甚至是有些 Scrum 培訓老師還會說如果你引入 Scrum 無法加速,一定是你用的方式錯誤或「沒有全用」,需要再進修或者是整個團隊需要繳錢全部來上課。

更討厭的是,Scrum 裡面很多「規則」,團隊實際執行起來非常綁手綁腳,結果 Scrum 書籍出了一大堆「Exception」去解釋例外的狀況以及處理方法。

( 我個人的想法是正確的道理一定有一套心法說得通,如果這一套道理出了一堆 exception 集,一定是有一個核心前置設定錯誤了)

我在半年前寫的一篇文章如何同時執行 Growth 戰術以及 Project Management 裡面其實就有談到 Scrum 以 Product Owner 為 User Story 的主導角色造成的嚴重問題。

我的看法是你應該取敏捷框架裡面可以『消除浪費、過程透明、交付正確成果、驅動全體成員關心執行成效』的招數,而非所有招數照搬使用。

我建議取用的概念是

  • Standup
  • Sprint Planning
  • Scrum Retrospective Meeting

不建議取用的概念是

  • Planning Poker
  • Velocity
  • Burndown Chart
  • Product Owner

5. Deadline-Driven 與 MoSCoW method

以上講的四段,偏向原則。我真正用於實務最有效的主軸執行方法,其實是 Deadline-Driven 與 MoSCoW method。

Deadline-Driven

為什麼是 Deadline-Driven 呢?因為對於幾乎絕大多數的專案來說,幾乎只有 Deadline 是明確的,其他結構全部不明確。所以用 Deadline 去「倒序排定要完成哪些事」是最準確的,而非「順序去規劃」(只會嚴重超時)。

我在 三年前得到世界首獎的 Hackathon 就是用這樣的方式去管理七小時內的可用資源的。

MoSCoW method

MosCow Method 是把所有的需求照

  • Must have
  • Should have
  • Could have
  • Won't have

的方式區分。

這配合時間倒序的專案管理方式特別有效,在有限的時間內,會迫使人們去決定重要順序。如果是用正向順序進行專案管理,人們往往會將需求通通定義為「Must Have」。

推薦書籍

當然,以上談的通通是心法與關鍵字。如果真的進行深度研究,每一個主題領域都至少好幾本書專門深入探討該題目。我推薦有幾本「淺顯的聖經」是可以去翻翻的:

這三本都是 Mike Cohn 寫的,本本是經典。

至於如何與軟體開發搭配,有兩本心法書我是建議用來搭配:

兩本都是 Kent Beck 寫的。都是老書了。一本 2000 年一本 2004 。(所以敏捷不是新把戲了)

至於如何將產品主導權從 PM 交還到團隊成員,我推薦兩本書給你方向:

推薦課程

如果你沒有那麼多美國時間看完,我有一堂專案管理課:

建議有「現在就有打仗需求的人」直接來上 XD!我想你不會真的想真的去花幾萬在買書錢,以及花上三年慢慢把這些東西都練完。肝都先被操到爆掉了。

← Deliver Project on Time 敏捷專案管理實務班的設計理念 [Growth Hack] 如何系統性的救回半死不活的 MVP 產品? →
 
comments powered by Disqus