敏捷式開發，真是一個讓人又愛又恨的詞。第一次聽到這個詞的時候，大約是在30歲，還是一個職場菜鳥的階段。那時候公司正在導入敏捷式開發，還安排了許多進修的課程，其實非常感謝當時公司有投入這樣的資源，讓我早早就開始了解什麼是「敏捷式開發」，對於後來的職涯，其實幫助非常大。
而在今年，自己安排進修取得PMP認證，才發現《國際專案管理學會》在2021年的時候，進行PMBOK《專案管理知識體系指南》的改版，其中新增敏捷式開發的概念。這也就是為什麼會很感謝前公司有導入敏捷式開發，因為在準備PMP認證考試的過程中，對於敏捷式開發的內容並不陌生，重新學習不是太有困難。
反觀同學，那就不一定了。因為所處的產業，經歷背景都不相同，未必每個人都會接觸到敏捷式開發，再加上工作實務上可能無法直接套用敏捷的觀念，理解上就更加的困難。
剛好在今年3-4月的時候，有一位年輕的同事找我聊，因為這位年輕的同事想要在他的部門導入敏捷式開發。於是我就隨口問了一句：「你覺得敏捷式開發是什麼？打算怎麼做」，這位年輕同事就回答：「(沉默三秒)其實我想建立的是大家主動回報的文化。」，我就回覆：「如果是想要建立文化的話，未必要透過導入敏捷式開發，也許有其他的方式，敏捷式開發只是一種方法，並非導入敏捷式開發，就能建立你想要的文化。」
會這麼回覆，其實也曾經走過不少的坑，剛開始接觸敏捷式開發時，因為團隊內沒人懂，於是沒有任何的包袱，加上製作人也支持敏捷式開發的導入，並沒有任何抗拒，運行的過程算是相當順利。也因為如此，讓我以為這樣運作應該是沒問題的。
後來輾轉加入其他團隊，也曾經試著要導入敏捷式開發，可惜並不順利。當時的團隊進度不如預期，內部意見分歧，發生問題推來推去，還曾經因此開了好多次的會議，結果當然都是不歡而散。那時候團隊有著天真的想法，試圖導入一個專案方法，然後期望它可以解決當下的問題，而這個方法就是「敏捷式開發」。結果，當然就是狠狠的上了一課，團隊分裂、衝突不斷、規格不明、專案混亂，能多糟就有多糟。
有些朋友的團隊也嘗試導入敏捷式開發，卻總是聽到大家都在抱怨。自己後來參與的專案，很多都嘗試要導入，卻很少有順利成功導入的案例。蠻長一段時間，我就開始懷疑「敏捷開發」，真的是一個好的方法嗎？為什麼總是失敗？
然而，在接下來的幾年裡，終於有機會可以主導一些專案。過往，以一個企劃的身分在參與專案時，雖然會接觸到需求確認、規格制定、時程規劃、跨部門溝通與協調，但是專案的管理方法，都是跟著專案負責人的方式進行。直到自己能決定專案管理方法的時候，才真正「看到」，為什麼敏捷式開發的導入，總是不順利。
在正式聊敏捷式開發之前，我們要先知道「瀑布式開發」，這也是一般專案團隊最常見的開發方式。
那，什麼是「瀑布式開發」呢？
所謂的「瀑布式開發」，就是「目標明確、階段明確、分工明確」的開發方式。
瀑布式開發的概念就如同上圖所顯示的，每個階段定義的非常清楚，團隊要執行甚麼項目也是相當明確。如同瀑布一樣，一路的往下前進。實際在執行開發時，團隊成員也是非常喜歡這樣的模式，因為比較不會有模糊的地方。在專案管理上，也是相對容易，因為目標明確、過程不會有模糊地帶，就看最後的可交付成果是不是有達到專案設定的目標。
但是，專案執行的過程中，總是有非常多的意外、風險、以及市場變化，有誰會知道2019年Covid-19席捲全球，又有誰能預測當時的市場狀況？如果透過「瀑布式開發」來進行專案，對於市場的變動，應變速度過慢，專案失敗的機率是不是會大幅上升？
於是，「敏捷式開發」就是在這樣高度不確定的「環境因素」，而誕生的專案方法論。
在瀑布式開發中，強調的是「工具」與「流程」。
但是，在執行專案時，重點還是回歸到「人」與「環境」。
「人」與「環境」才是真正影響專案成敗的關鍵。
專案是因應「環境」產生，而執行專案的是「人」。
小時候常聽到一句話，「先做對的事，再把事情做對。」，但是我們要怎麼知道「做對的事」？
現在的環境，是一個成敗論英雄的世界，在結果還沒出來之前，誰能斷定「對」與「錯」？在產品還沒正式上線前，產品是否可以滿足市場需求，都是沒人知道的。
假如我們有更多次試錯的機會，而每一次的試錯都可以用較短的時間去驗證，這樣是不是有機會更貼近「做對的事」？敏捷式開發，就是這樣的概念。用「相對短」的開發週期，去進行產品的驗證、調整，讓產品可以更接近「市場需求」。
因此，
敏捷式開發，就是找到「對的事情」的方法。
瀑布式開發，就是執行「把事做對」的工具。
在敏捷式開發中，有個著名的《敏捷宣言 The Agile Manifesto》：
- 個人與互動重於流程與工具
- 可用的軟體重於詳盡的文件
- 與客戶合作重於合約協商
- 回應變化重於遵循計劃
可以從這敏捷宣言中知道，敏捷式開發著重的是「溝通、成果、合作與變化」。
敏捷式開發為了達到「相對短」的開發週期，將每一個開發週期稱之為一個「衝刺 Sprint」，而每次衝刺的周期可能會抓在2-4周，依據團隊與產品不同，周期可能也會不同。
另外，每一次衝刺的過程中，會有四個主要事件，也就是四個會議，分別如下：
- 規劃會議：決定這次的衝刺，要完成哪些項目
- 每日站立會議：每天花費15分鐘同步資訊，包含昨日完成甚麼，今日預計完成甚麼，是否遇到阻礙？
- 審查會議：展示本次衝刺的成果，並取得回饋與新的需求
- 回顧會議：回顧本次衝刺的過程，是否有需要改進調整的地方
乍看之下，導入「敏捷式開發」好像蠻不錯的，那問題到底發生在哪邊？
其實，談論敏捷式開發時，通常都只提到《敏捷宣言》及《四個會議》，還有一個很重要，卻常常被遺漏的，那就是敏捷團隊通常都是「跨職能、自組織」的團隊。
什麼又是「跨職能、自組織」的團隊？
在《Scrum指南》中有提到一段話，可以用來解釋：
Scrum Teams 是跨職能（cross-functional）的，也就是說，成員們擁有在 Sprint 內創造價值所需的所有技能。他們也是自我管理（self-managing）的，也就是說，他們在團隊內部決定誰做什麼、何時做以及如何做。
附註：Scrum為敏捷式開發中的一套方法。
有發現問題了嗎？
■跨職能與專業分工的衝突
因為敏捷團隊的成員是必須具備「在 Sprint 內創造價值所需的所有技能」，而傳統的瀑布式開發中，分工相當明確，寫規格書、產品設計、前端開發、後端開發、QA測試，各有各自的專業。若以敏捷式開發期望的2-4周一個衝刺，這樣從定規格、產品設計、程式撰寫到功能測試，每個階段可以分配到的時間就會變的非常的短暫。
所以，才會強調敏捷團隊是跨職能的，任何一位敏捷團隊成員都能執行「寫規格書、產品設計、前端開發、後端開發、QA測試」這些工作，因此，敏捷團隊的工作安排上就會相當困難。
■自組織與習慣派工的衝突
敏捷式開發中，希望的是團隊是可以自己決定「誰做什麼、何時做以及如何做」，但是，很多時候，我們習慣的工作方式卻是「派工」，PM安排工作後，再進行工作的執行，對於主動去決定「工作」這件事，往往會「怕怕的」。就跟從小父母都希望我們專心念書，不要談戀愛，可是一旦出社會後，卻一直問我們什麼時候交女友、結婚，從來都沒學過「談戀愛」這件事，卻希望我們瞬間學會「如何談戀愛」，一樣的不切實際。
■擁抱變化與規格清楚的衝突
在敏捷的精神中，希望團隊是可以「擁抱變化」的，但是在開發的世界，「變化」是我們所厭惡的，「變化」代表的是改需求、改規格，對於執行團隊來說，就是「重工」、「重做」、「浪費時間」，因此團隊希望的總是「規格不要變」，規格改變就是當時需求沒想清楚，但是又有誰可以知道現在想的需求，明天是不是還需要？
■發現阻礙與防禦心理的衝突
每日站立會議希望達到的，除了每天進行資訊同步外，另外最重要的是可以快速「發現阻礙」，進而「排除阻礙」，但是往往在說明「有沒有遇到阻礙」時，成員的防禦心就會立刻升起，接著，就是一陣「解釋大會」與抓「戰犯」，最後這個站立會議，變成每個成員都瑟瑟發抖的「顫慄會議」，每個人都很害怕自己成為別人的「阻礙」。於是，為了不要和其他人衝突，就草草帶過，相對的，也就失去「發現阻礙」的意義。
■回顧改進與避免得罪的衝突
在回顧會議中，希望達到的是團隊的經驗學習與成長，透過每一次的回顧來改善流程，然而在這樣的過程中，團隊成員常常因為不想得罪其他人，都會語帶保留，如果要討論團隊做的好的地方，那就變成「拍拍手大會」，效果往往不好，更別說「留下好的，改掉不好的」，這樣的目標了。
那怎麼辦？
其實，這些年有了新的概念，叫做「混和式開發」，說穿了就是「瀑布式開發」加上「敏捷式開發」的綜合版，後來我也才知道，原來我使用的方法就是「混和式開發」，避免掉入「瀑布式開發」和「敏捷式開發」二元選擇的陷阱。
「混和式開發」又是怎麼進行的呢？
不管導入任何的工具、流程、系統，或是一套方法，如果沒有意識到一件事，常常都會導的心力交瘁，那就是「大多數人是害怕改變的」這件事，尤其是影響到自身利益的時候，例如：我要導入一個工單系統，那第一線執行人員是不是要重新學習系統、適應流程，而「改變」對於這些人員，是一件很痛苦的事情，當然會跟你抗拒到底，加上使用新工具，效率肯定變差、出錯率肯定變高，接下來就是KPI表現一定不會太好，若是主管沒有意識到這件事，而單方面要求KPI的表現，那員工為了保護自己的KPI，不願意改變就是必然的結果。
在這邊，我們要先認識一個數位產品(軟體/網站/APP)的開發與維運，已經不像以前的方式，開發完一個版本，發布到市場後，再著手下一個版本的開發，再發布到市場。而是，發布到市場後就需要持續的營運與更新版本，於是產品的生命週期簡單來看就如下圖。當然，維運階段也是會持續進行新功能的開發。
除非是要開發一個前無古人，後無來者的創新產品，不然進行開發的項目多半都是有「明確目標」的，像是開發一個網站、一個電商平台、一個XXX APP的，都是可以預想的產品，畢竟想的到的產品，市場上應該都出現了。如果是接案公司，根據提案方的需求與規格開發就好。所以在開發階段，基本上還是以「瀑布式開發」為原則，但是，正式上線後，那就不一樣了。
為什麼這麼說？
因為，客戶的回饋總是讓人「意想不到」，因此一旦進入維運階段，專案就會處於一個較不明確的狀況，這種時候，就很適合「敏捷式開發」的方式，但是，要從「瀑布式開發」直接轉為「敏捷式開發」，實在太過於困難。
於是，在「開發階段」就要開始將「敏捷式開發」的一些精神偷偷置入。比如說，為了可以更精準的掌握專案的進度，會進行每日的進度追蹤會議，然後，請PM問問看大家「執行過程中有沒有遇到甚麼困難」，快速的理解大家的狀況後，就趕快結束這個會議，避免成員最後花太多時間在聊天，如果有成員提出困難，PM就單純記錄下來就好，後續再安排會議討論細節。
然後，在時程安排上，也會請PM跟成員說，在版本安排上，盡量是固定的時間週期，差不多抓三周，這樣之後上版和抓時間，也比較容易有個規範可以參考，需要太多時間開發的需求，就可以切割為更小的項目去執行。
每次釋出版本後，會開一個專案檢討會議，其實就是回顧會議。會議中，如果有成員的態度是抗拒、不願意配合，以及各種的冷嘲熱諷，這時候就需要有點耐心，並且塑造出輕鬆的氣氛，如果成員沒有想法，則需要適度的引導，讓成員願意發表想法，千萬不要用「找戰犯」的心態。若是可以的話，建議可以離開工作的環境進行，讓成員可以脫離「工作的氣氛」，「回顧會議」會比較容易進行。
因此，執行的流程，大致上會如下圖。
也就是在「瀑布式開發的流程」下，將「敏捷式開發的概念」偷偷加進去，用大家習慣的名詞包裝，避免大張旗鼓地說「我們要導入敏捷開發囉~」，然後讓團隊成員立刻建立防禦心理的高牆，畢竟大家對於敏捷式開發，或多或少都有一些不好的經驗。
而時程管控工具，還是一樣維持使用「甘特圖」，如果是已經習慣瀑布式開發的團隊，還是用甘特圖會比較適合，加上現在很多專案管理工具，都可以將甘特圖轉換成敏捷式開發常見的「看板」，要做的應該是「在既有的開發基礎上，逐步加入改善流程的方法」，而不是期望導入某個方法後，團隊開發就瞬間可以飛天遁地…。
不管是「瀑布式開發」、「敏捷式開發」，還是「混和式開發」，都是在當時的時空背景，為了解決當下面臨到的問題，而衍生出來的開發方式，未來環境的變化只會更快、更劇烈，需要思考的是如何應對這樣的變化，找出適合團隊的開發方式，不要被「開發方式」所綁架。
導入一套新的方法，要做的是理解自己、理解團隊、理解面對的問題，才能找出適合團隊的新方法。
《歡迎請我喝杯咖啡聊聊》
——–
大家好，我是 數位產品開發教練 – 陳俊聖/廣三/HeroMi
17年數位產品開發經驗。經手至少80個大小專案。
擅長解決與工程師的溝通問題，幫你建構工程思維。
合作邀約：info@hero-mi.com
*本站所有文章未經授權，請勿任意利用、引用、轉載，但是歡迎按讚、訂閱、分享。
留言