前陣子，在 Facebook 上分享了《Agile is Dead》的中文翻譯版，分享時人在公車上，不喜歡用手機打字的我，沒有下任何註解就分享出去了，但後續的發酵倒是令我有點意外。我個人沒有推崇任何方法，就如同我討厭有人跟我推銷宗教一樣。只是在進入職場前跟著老師很早就接觸 RUP 和 agile software development，在職場中也待在 scrum 團隊多年，甚至後來也擔任 scrum master，希望給團隊最大的空間能夠自我組織與成長，也以這目標在努力，因此，若真要問我對這篇文章的感想是什麼？
事實上跟文章的內容大致相同，只是標題很聳動，我應該會說 Agile 是個已經被過度炒作的商業名詞，注意，我用大寫開頭，因此常被誤解是銀子彈能解決所有軟體開發中會遇到的問題，但事實上它並不是，要視 context 才能知道哪種方法 (不論是不是 agile 方法) 適合您的團隊。
在沒有內化《Manifesto for Agile Software Development》核心精神前就導入任何方法，就好像練武功只練外功沒練內功會走火入魔一樣，會有很多副作用，因此覺得這方法很 OOXX。至於為什麼導入時總是會先從方法開始而不是先從了解精神開始？我想這跟為什麼練武功都是先從練基本功與招式開始相同，因為要把一個概念內化是很難的，方法是最容易讓人上手可以開始的地方，但練武到後期，若在一個好的師父帶領下，不會讓他的徒弟只練外功不練內功，相同地，如果有好的 agile coach，是會讓團隊慢慢內化宣言背後的精神，只可惜，在商業炒作下，有太多拿著 XXX 證照的講師，說是幫助團隊導入 agile 開發方法，方法教完了就離開，團隊也就照著方法做了，短期可能有些成效，但講師一不在團隊內，團隊無法用內化的思維自己解決問題，也就停滯甚至退步。若我們用理解 pattern 的方式來理解這些方法，也許應該先從當初這些方法推出時的 context，以及所面對的 forces 有哪些，了解這些方法如何平衡這些 forces，然後才能判斷是否適合用在您的 context 中。不過可惜的是，我沒參與過那場討論出《Manifesto for Agile Software Development》會議，我無法明確知道 context 與 forces，但我在學軟體工程與專案管理時，有個漫畫倒是常常被引用，即便到現在依然是如此：
在那個年代…這說法好像我也很老了，需求常常是軟體開發商與客戶之間永遠的痛，軟體開發者覺得客戶不知道自己在說什麼，客戶覺得軟體開發商總是誤解他們的需求，又或者是，軟體開發商受不了客戶對需求一變再變，但客戶覺得不是他們變更需求，而是軟體開發商根本就做錯了。在這樣的 context 下，有一些方法被提出來，想平衡需求無法明確與變動的 forces，像是 Rational Unified Process (RUP) 或是對我來說惡名昭彰的 CMMI，某種程度上，我認為 use cases 搭配 iterative development 的 RUP，確實是比根本不該用來開發軟體的 waterfall process 要好很多。
只是，當商業業務本身變動越來越快的情況下，對開發中的軟體需求自然也就跟著變動，若不跟著變動，即使做對了做完了，對客戶來說也沒有用處，因為當初的需求現在已經不是需求了。以下是我的猜測，軟體開發商完成了合約中的項目，卻無法幫助客戶；為了確保做對合約中的項目，即使是用 RUP，也做了大量的big up front design，因此對於變更有一定的排斥；因為 RUP 有一定的規範和文件，讓不少人覺得 RUP 很笨重；因為 RUP 通常伴隨著 UML，變成設計師或分析師與工程師之間，只有 diagram 而沒有溝通。所以在現實中需求是易變動的 context 下，為了平衡上述的 forces，宣言誕生了，以及後來的幾種方法 (就我的印象，有些方法誕生其實比宣言要早)。
《Manifesto for Agile Software Development》就這四條 (還包含一段關於如何解釋 over 的描述)，看似簡單，但卻是很難達到的目標：
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
即便使用 Scrum 或 Kanban 等方法，都不保證能達到上述的目標。
當軟體開發不再只是工程師的事，需要各種角色 (像是美術與企劃) 的參與，individuals and interactions 就需要考量到不同領域做事方式的不同，取得一個多方都能快樂工作的平衡點，這就很難。
當使用者對軟體的要求不再只是一個不會出錯的 working software 時，如何在設計的過程中考慮並溝通各式各樣的 non-functional requirements，以及如何在時程與完整性之間取得平衡，這就很難。
當開發的產品，其使用者是一般消費者，但需求的決定權是握在一個不在團隊中且很難約時間與他討論需求的老闆時，customer collaboration 就很難。
在有單元測試、持續整合的協助下，responding to change 對軟體工程師來說，確實比過去要輕鬆不少，但成本依舊是有的，但無法用單元測試和持續整合協助的部分呢？像是體驗、動畫、轉場、UI 風格等非功能性需求的變動，對於軟體工程師或非軟體工程師來說，有時候一個變更對他們來說卻可能是地獄般的加班，或是 product owner 得理解需要好幾個 sprints 來處理變更，此時 scrum master 能笑著臉對他們說：Responding to change over following a plan 嗎？很難。
既然很難，那就是這方法不好啊？何需要用？我一開頭說過，我不是個 agile software development 的推崇者，所以也不會推別人入教，更不會見人就說 XXX 方法好棒棒，用了之後專案絕對不延誤，開發人員一定很開心，準時上下班，因為根本沒這種東西。我也認為要做到上述宣言確實很難，要花費很多的心力，才能將核心的精神內化到團隊中。因為專案的屬性，當初團隊組成時，認為 Scrum 方法能幫助團隊順利開發產品，所以用 Scrum 方法一路走自今日。當初在接觸 Scrum 時看了《Agile Software Development with Scrum》這本書，書中用一張圖介紹 agile 方法適合的專案，我依稀還有點印象 (手上沒這本書，感謝 Teddy 贊助圖片)，下面是自己的解讀 (沒書可以抄 XD)：
- 若需求不明確且所需技術也不明確，即圖中右上角 chaos 那一塊，不論用什麼方式，風險都很高，只是 agile 方法能更早暴露風險。
- 若專案需求明確，彼此共識高，所需技術也明確，也就是圖中屬於 simple 的那一塊，用 agile 方法、RUP、CMMI 或 waterfall 都不會差太多，大致都會成功，差在有沒有機制能讓團隊在專案進行中跟著進步。
- 若專案需求明確，彼此共識高，所需技術不太明確，一般俗稱 R&D，屬於圖中間下方的 complicated 那一塊，waterfall 是不太合適的，因為在做計畫時，很難處理技術上的不明確，較合適的是能容納試誤的方法。
- 若專案需求沒這麼明確，或是會變動，但所需技術明確，屬於圖中左側中間的 complicated 那一塊，那能盡早讓客戶見到產品，並隨著調整的方法比較合適。
- 不過實際上的專案，大都會在兩個軸上遊走，也就是灰色的 complex 那一塊，因此能容納試誤與快速應變的方法比較合適。
有人看到這可能就會說：你就是在推銷 agile 方法啊，我可以很肯定說不是，事實上，只要團隊現行的制度能滿足上述的描述，就能在所屬的專案上進行的較順利 (只是比較順利，成不成功還要看很多因素)，不用刻意導入什麼特定的 agile 方法，採取 agile 方法可能會對公司現有制度和文化造成衝擊，越是有阻力時硬推行一種方法其實都不太容易成功。重點是能適應所屬的專案生態，讓團隊成員開心積極地去完成專案，並讓客戶滿意，agile 方法只是眾多方法中，不少團隊使用後認為確實幫助他們解決問題的方法。上面那張圖還只是其中一個面向，要不要導入一種方法還要考慮到時程、成本和品質等面向。所以與其說，某方法已死，較合適的說法也許是視情境決定適不適合您的團隊。
2013 年，我在團隊的 release planning 中安排了幾個影片給團隊成員看，第一個是 Spotify Engineering Culture ，我個人很喜歡這分成上下兩集的短片，裡面有許多可以引起思考的東西：
第二個是 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr，因為產品已經進入準營運階段，我希望透過這影片讓團隊思考未來該如何順暢地營運產品。
本來，我還想安排第三部影片，就是 Dave Thomas (若不知道他是誰，你可以在剛剛的 Manifesto for Agile Software Development 網頁上看到他的名字) 的演講，題目就是《Agile is Dead》，但後來我決定不放進去，就自己的觀察，我們是有幾年 scrum 經驗的團隊，但在團隊成員增加與變動下，整體以『守、破、離』三個階段來看，還在等待破繭而出進入破的狀態，擔心這影片讓團隊往不預期的方向走。
看完影片後的問卷，可以發現團隊從影片中吸收了很多東西，也思考了很多東西。最近，接近 release 周期的尾聲，在我的建議下，團隊使用 Spotify 分享的《How we do large scale retrospectives》的方式，針對未來營運需求，討論團隊組成與制度的調整，會議中，我盡可能保持低調並讓參與的成員發言與討論，也很高興看到成員認真地思考問題並提出見解，幾次來回，與各自小組的成員討論 (在上個 release 週期，決定將一整個約 20 人的團隊拆成 2 個 feature team 與 1 個 OP team)，並慢慢整理出一個結論，這過程中，一些《Manifesto for Agile Software Development》的核心精神真正內化到他們的心中。
像是會去思考，這樣的調整會不會只是開發 feature 的成員很開心，但營運的成員很痛苦，會不會只有寫程式的成員很開心，美術成員很辛苦？或是固定 iteration 的週期是不是真的適合不同類型成員的工作模式？一個 story 因固定週期與既有人力被切開後，在某些因素下，後續一些雖然不影響功能性卻影響體驗的小 story 在 priority 上被排到很後面或是被忽略 (我建議過 PO 試試 User Story Mapping 進行追蹤)，導致產品雖是個 working software 卻不是一個團隊心目中 high quality 的產品。
可惜的是，新的團隊組成與運行機制，我不會參與到，因為一些因素我決定轉換跑道到別的團隊發展，但我覺得現在的團隊已經算是到『破』的狀態，已經是能 inspect 與 adapt (這是我認為很重要的核心精神) 的團隊，尊重彼此、思考與真心地自我檢討，雖然說還有很多地方能改進，我想這團隊在另一位 agile coach 的相互引導下，應該能順利繼續往下走下去。
最後，要給在考慮是否導入 agile 方法的人建議的話，先熟悉自己的 context 與要面對的 forces，思考後再決定是否導入，不需要為了那個名字而導入。如果想導入 agile，建議初期要找到對的 agile coach 或顧問，並在團隊內培養一位 agile coach，這位 agile coach 需要不斷地吸收內化精神並散播給團隊，讓團隊最後能自己解決問題，不然就很容易進入覺得練功無用，抱怨 XXX 已死的狀態。
其實某某方法已死，這種標題很多，像是 Continuous Integration is Dead 或是 Is DevOps Dead? LogicMonitor Suggests So But I’m Not So Sure，在讀這類文章時，我都建議先釐清作者所處的 context 及想平衡的 forces 有哪些？與他們做過哪些努力和遭遇的困難，再來判斷是否可以套用在自己的 context 中。
參考閱讀
