前言

為什麼選在這個時候切入「敏捷」呢？在這之前我們談論了「溝通」、「當責」與「透明」，這些都是展現敏捷的重要關鍵。

敏捷

談到敏捷，著名的「敏捷軟體開發宣言」鐵定少不了，也因為它的篇幅很短，容我在此再引用一次。

個人與互動 重於 流程與工具
可用的軟體 重於 詳盡的文件
與客戶合作 重於 合約協商 
 回應變化 重於 遵循計劃

在 A Behind The Scenes Look At The Writing Of The Agile Manifesto 一文當中，我們可以看整個宣言是如何誕生的，並且從 Andy Hunt (即宣言作者之一，當時署名為 Andrew Hunt) 的手稿上看出一件有趣的事，無論其他三個的順序如何變動，Individuals and interactions over processes and tools 始終位居第一，顯示「個人與互動」是整個敏捷當中的重中之重。

而在宣言背後還有 12 條「敏捷原則」，也非常值得一讀，這邊就請讀者前往查看了。讀完之後，自然可以從中摘錄幾個關鍵字，例如：交付價值、面對改變、頻繁交付、緊密合作、保持溝通、自組織、自省。

那又是什麼可以支持這些原則呢？前幾天提過的「溝通」、「當責」與「透明」就是很好的實踐指引。

為什麼要敏捷

我們團隊執行 Scrum，這邊就以它來說明。Scrum 作為一種敏捷框架 (Framework)，擁有易學難精的特性，難精我們先不要看，不然文章不好接 (喂！)。

在我們要跑 Scrum 前，我是這樣向團隊說明的：「Scrum 提示我們事情本該如何做」，我們只是借著 Scrum 定義的角色與活動，來幫助我們發揮本能，讓我們充分知道我們正在做什麼，讓我們可以從容應對變化、可以流暢的交付價值，一旦展現這樣的精神，那麼敏捷與 Scrum 這些名詞都不再重要了。

也就是這樣，沒有為什麼需要敏捷，而是這樣做是自然的、是符合常理的，我們本來就擁有應對變化的能力，反到是在工作上僵化了。當我們駕車「衝刺」時，不會緊踩著油門不放，而是注意車況並隨時調整，不是嗎？

如果多多觀察，會發現生活上充滿各種變化，又急又快，甚至還在加速著。 “VUCA” 一詞就傳達了這個概念，這也早就體現在工作中，在你感嘆「隕石又砸下來」的時候。關於這個主題我安排在更後面的文章，現在我們先專注在敏捷身上。

同時，我認為敏捷也沒有什麼好失敗的，差別只是面對變化時有多麼優雅罷了。有了這個認知，再回頭閱讀敏捷宣言與原則，你可能會更有共鳴。假若你的團隊運作一點問題也沒有，那要不要敏捷也不是那麼重要了，又或者說本身已經敏捷了，所以學習、討論敏捷時，不要過度糾結在「敏捷」這個詞，它不是旗號，而是個實際。

至於「難精」呢？做了才知道，隨著各方面的問題被暴露出來，團隊必須拿出行動力來解決。

敏捷也要敏捷

有一個值得反思的現象，在導入敏捷時通常會有反彈，這是人之常情，而運作一段時間更可能會有人產生質疑，質疑我們是不是導入失敗了呢？

正如文章前面提到，我認為敏捷沒有失不失敗的問題，同時也要提醒：敏捷導入的過程本身也是一種「敏捷」。

若有人感到「是不是失敗了」，本身就是個機會，一個已經被看到的問題 (現象)，接下來就是去應對它了，千萬不要看到一個失敗，就斷了後面的所有機會。反過來說，如果一切都很順利，如同工程師不知道自己的程式為什麼可以執行，那這樣的「敏捷」不是令人發毛嗎？

會有這種現象，也許是過度執著在「敏捷」兩字上面，而忽略了它的本質。

我要開始敏捷了

「交付價值、面對改變、頻繁溝通、追求卓越、反思修正」，容我再次壓縮敏捷原則，在看到這些原則，不知道各位有沒有問過自己：「我敏捷嗎？」。

讓我們從生活上來思考：

1. 塞車了，我是想改變路線，還是繼續等待？
2. 我想改變路線，那我真的能夠改變嗎？
3. 請導航機算條替代路線，啊！導航機沒有即時路況
4. 問問某家的地圖，它有即時路況
5. 太好了，有條替代路線可以走，前方路口就是突破的機會，等下右轉。

請問，我們可以從 1 走到 5 嗎？還是在第 1 步就放棄了呢？

6. 這條路真是暢通，果然之前改變路線是對的。
7. 孩子：「我要上廁所」。

那現在呢？是不是先抱怨為什麼忽然要上廁所，這樣會打亂原有的計畫。不行不行，這樣是不行的，聽說「敏捷」可以應對變化，那我也要學。

希望這個小劇場能夠讓我們反思「導入敏捷」這回事，思考這位開車的父/母，究竟要學什麼呢？