變化才是常態

一路敏捷至此的各位，應該對於敏捷強調的「面對變化」已有所體悟。

有個縮寫詞彙 VUCA 表達了現況，維基百科的條目是這麼說明的：

vuca 是 volatility（易變性）、uncertainty（不確定性）、complexity（複雜性）、ambiguity（模糊性）的縮寫。VUCA這個術語源於軍事用語並在20世紀90年代開始被普遍使用。隨後被用於從盈利性公司到教育事業的各種組織的戰略這種新興思想中去。

我們可以知道 VUCA 源於軍事，在戰場上的變化可想而之，而商場如戰場… 不用了，不需要再對比與延伸了，我們直接看看周遭、看看手機、看看最近裝了哪些 Apps 又移除了哪些、最近又有什麼新產品發表了、市場上又冒出哪一隻獨角獸了。

或是，又有什麼隕石掉下來了？

(註：這邊的隕石概念來自紅極一時的「メテオフォール型開発」。好啦，現在也很紅)

面對變化的心態

在對團隊內訓時，我強調這種變動與不確定性，是充斥在整個大環境中，希望一個需求不發生變動，或一個需求不會衍生其他需求，都是不太理智的。這就像是一個理想的衝刺，從 PBI 定義、拆解、實作，整個過程如果 Product Owner 與 Scrum Master 努力的維繫世界和平，那麼團隊應該可以專注完成，但這也不保證在 Review 時我們會得到一致的認同，也許客戶看到一個動起來的東西就會產生各種新想法，這幾乎是肯定的。

客戶或市場的改變，縱使 Product Owner 進行協調，仍然有推翻前局的可能性。當我們站在敏捷的角度來看，這其實是幸運的，我們在整個期程還沒走完就得到了回饋，有了應對的機會。不過推翻之前做的東西，在重視效率與自我實現的團隊當中可能心生不滿，必竟這些都是心血，也是眾人智慧的產物，但是要記得，正在交付的是客戶(或市場)想要的價值，不是交付自己的理想，當然我們期待這兩者的重疊。

那麼，不斷被拿來揶揄需求變動的「隕石開發法」，我們用什麼心態來面對它？

這得看這顆隕石是何許人也了，如果它大到一個程度，連 Product Owner 與 Scrum Master 都無法化解，在 Scrum 當中最慘烈的情況是，PO 有權停止當下的衝刺，這是考量到市場 (或客戶) 發生劇烈變化的時候，團隊很可能失去繼續發展手邊工作的理由，理智的切斷衝刺也是個合理考量。

面對變化的應對

那麼，團隊呢？看起來深受隕石所害一群人，可以做點什麼？

這就得發揮工程人員最擅長的部分了，設計具有彈性的架構，使它具備可抽換與可擴充的能力，句話可以解讀得很廣大，感覺要用上各種精妙的設計模式。能適時引入模式是值得讚許的，但還有一些更簡單的方案，可以減緩變動帶來的痛苦，例如：可以抽換的設定檔機制、DRY 與 SOLID 原則的實踐、共用的 CSS 定義等，有不少工程人員容易掌握的技術可以減少變動帶來的影響，我們要在開發的時候，意識到可能會發生變動，並思考「如果要未來要改變，我現在應該要…？」。

如果有人說「但這邊就是當初覺得不會改，所以沒預留彈性啊！」，這樣就認了吧，這種事總不會一直發生的，假若一直發生，除了客戶可能有獨特的喜好之外，或許我們自己的經驗資料庫也需要更新一下。

與期害怕或抱怨變化的發生，不如先準備好迎接變化，不是嗎？