敏捷的判準

今年暑假，我第一次去台中的國美館，參觀 2018 年全國美術展。

這年度盛會，分成油畫、水彩、版畫、水墨等十大類。大開眼界之餘，也不禁有個奇想：為什麼要分這麼多類別來競賽？為什麼不選出一個跨十大類別的首獎，就像武林盟主一樣？

很外行吧！畢竟，油畫的美感判準，與版畫的美感判準、攝影的美感判準，本來就有很大不同，不能草率化約在同一把尺來衡量高下境界。

把照片拍得像油畫，就能夠贏過油畫嗎？

我們有選擇美術媒材的自由。一旦擇定媒材，就要正視及尊重該媒材的運用手法、該媒材營造的世界觀，以及該媒材表現境界的判準。

軟體開發，亦然。

前一篇文章初步提到方法論與判準之間的關係，這一篇文章，就來繼續探討幾種常見軟體研發方法的判準。

「多元典範的軟體開發取向」認為：我們可以視問題的性質，採取瀑布或敏捷軟體開發典範。

然而，採取某種典範，不但要說明自己的方法論立場，而且要採用該一典範的方法論判準。

瀑布方法的判準

敏捷三叔公 David Ko 在〈原來瀑布老祖是想做敏捷啊〉考古文章中指出，瀑布式開發始祖 Winston W. Royce 在 1970 年發表的會議論文中，總共提出兩種想法，一種是後來被世人普遍稱為萬惡的 waterfall 的版本，另一種則是帶些更務實風格的修正版。

兩種想法，背後的核心觀念，其實都是 phase gate 或 stage gate 的 “gate” 機制：

以上圖來說，圓圈圈的部分，就是在各個階段 (phase/stage) 負責把關的守門員：

1. PSR: Preliminary Software Review
2. CSR: Critical Software Review
3. FSAR: Final Software Acceptance Review

這就是瀑布方法論的判準。

合乎現實嗎？

要走 waterfall 路線，就要弄清楚 waterfall 的判準，並致力於判準的實踐品質，這是將方法論落地實施的重要關鍵。

問題是：這個判準，合乎現實嗎？更進一步的問題是：是怎樣的世界觀，才會催生如此的判準？

Waterfall 的世界觀就是，萬事萬物，都有一個自然的、可預測的線性執行順序。在這些自然的線性順序當中，會有一些關鍵的控制點，或者像《利潤的故事》所用的「地景的控制點」妙喻：「有些地方，就是比其他地方重要」。

這些「地景的控制點」，就是瀑布方法 phase gate 判準之所在。

不可否認，的確有人在這種方法論、世界觀、判準底下活得很好。認清這個判準，以及這個判準背後代表的方法論及世界觀，有助於你和這類人種互動。

或許更重要的是，你不同意這種方法論，卻又得與這類人種合作，你就應該在這些判準的層次上，挑戰關心對方對這些判準的認知與實踐品質。

在判準的層次動工，比各自表述的爭辯更有力。

Scrum 的判準

儘管 Scrum 是很精簡的框架，但真正核心的判準，未必都被清楚地認知。

我個人認為，Scrum 的判準，就在於 increment，或者更具體一點講：PSPI (potentially shippable product increment)。

The Scrum Guide (2017 版) 說：

Scrum 使用疊代和逐步 increment 的方式，來最大化可預測性和控制風險。

在 Sprint 結束時，increment 是一種可檢視，完成的工作實體，並可支持經驗主義。

簡言之，Scrum 是以 increment 作為載具、「地景的控制點」，藉以反映出透明性、檢視性、調適性這三大主張，藉以最大化可預測性及控制風險。

並不是隨隨便便任何一個軟體中間狀態都夠資格稱為 “increment”，而是有標準的。Scrum 是很精簡的框架，將這標準交由團隊來定義 (DoD; definition of done)，但能否嚴守這個承諾共識，決定了 Scrum 實踐的成敗：

Scrum Teams 用疊代和逐步 increment 的方式交付產品，將回饋的機會最大化。用逐步 increment 的方式交付「完成」的產品，可以確保一直提供一個潛在可用的產品版本。

真正執行的人員和檢視 increment 成果的人員，需要對「完成」之定義，有一個共同的認知。

在 Sprint 的最後，新的 increment 必須是「完成」的，這意味著它必須是可用的狀態，並符合 Scrum Team 對於「完成」之定義。

在 Sprint 過程中，對於品質的目標不可以降低。

簡言之，Scrum 的判準，就在於 increment 的定義，以及能否在各個疊代過程中，捍衛並精進這個 increment 的整全狀態。

合乎現實嗎？

要走 Scrum 路線，就要弄清楚 Scrum 的判準，並致力於判準的實踐品質，這是將方法論落地實施的重要關鍵。

問題是：這個判準，合乎現實嗎？更進一步的問題是：是怎樣的世界觀，才會催生如此的判準？

Scrum 的世界觀就是，萬事萬物，都有一個自然的生物成長順序。或嬰兒，或幼童，或成年，在每一個當下，必然都是整全的生命個體。

認清這個判準，以及這個判準背後代表的方法論及世界觀，有助於你與其他物種分別為聖。

或許更重要的是，你支持這種方法論，卻又得與反對者合作，你就應該在這些判準的層次上，盡一切努力守護這些判準的認知與實踐品質，並最大化這些判準的價值能見度。

在判準的層次動工，比各自表述的爭辯更有力。

Kanban 的判準

Kanban 是極度精簡的框架，甚至連「框架」都不太能夠稱得上。因此，他的判準很容易辨識，也很容易衡量，那就是 Kanban 的核心規則：拉動系統 (pull)、WIP 限制。

問題是：這個判準，合乎現實嗎？更進一步的問題是：是怎樣的世界觀，才會催生如此的判準？

Kanban 的世界觀就是，萬事萬物，都有一個自然的流動順序。我們所該做的，就是讓這流動，以小批量的方式，毫無阻礙地順流而下。

認清這個判準，以及這個判準背後代表的方法論及世界觀，有助於你掌握這個「入門毒藥」(gateway drug) ¹ 的殊勝之處，以及⋯⋯潛在的問題。 ²

或許更重要的是，你支持這種方法論，卻又得與反對者或不可知論者合作，你就應該在這些判準的層次上，盡一切努力守護這些判準的認知與實踐品質，並最大化這些判準的價值能見度。

在判準的層次動工，比各自表述的爭辯更有力。

善用判準作為施力點

判準，是將方法論落地實施的重要關鍵，也是方法論歧見的槓桿解。

畢竟，方法論，甚至背後的世界觀，不是那麼容易就撼動得了。

試問：你對自己採用的軟體開發方法論，了解它的判準嗎？

試問：你對其他人採用的不一樣的軟體開發方法論，也了解它的判準嗎？

理解別人的判準，善用判準作為施力點，在判準的層次動工，比起辯論不同方法論之間的優劣，更有建設性，也更能推動事情的前進。