迭代、敏捷 與 滾動式調整

今天上課的時候，跟同學聊到，最近很流行的一個詞彙 『滾動式修正』(或 滾動式調整)。

不知道你自己對這個詞的定義是什麼? 所謂的『滾動式調整』是不是走一步算一步? 是不是朝令夕改的美化版? 是不是先做再說，後面再看著辦?

儘管很多人不明所以，但『滾動式調整』這個詞彙這幾年仍被許多團隊理所當然地使用著。為何過去從沒聽過，這幾年卻如此盛行? 我自己覺得，和敏捷(Agile)似乎脫不了關係。

敏捷(Agile)存在的意義，是因為我們認知到並承認，現今外在環境的變化實在太快了，快到我們再也沒法像過去一下，先妥善地做完計畫，然後再動手實行。如果堅持如此，將會錯失先機。

此外，更重要的是，倘若沒有先著手實施，試著得到外界真實的反饋，只在辦公室裡籌算，即便覺得計畫得再周密，一但拿到真實世界裡，很可能就會立刻破功。

這兩者都是同樣的前提 --> 這個世界變化得愈來愈快。
這也是敏捷之所以日趨主流的原因。

而敏捷的被認可，或多或少讓『滾動式修正』變得理所當然。然而，真的每一個組織，每一個單位，每一個計劃，都適合滾動式修正嗎?

今天上課談的是DevOps。
我問學員：『如今需求變化快速已不可避免。假設，持續交付 (所謂的持續交付，一般是指一天數次這樣的頻繁上版，最少也是一周數次，不會更低)是必須的，那什麼是持續交付的基礎?』『一家公司、一個團隊，一個專案，能夠毫無準備的就實施頻繁交付(CD-Continuous Delivery)嗎?』

答案是 : 『不能』。

因為，沒有良好準備的頻繁交付，將會帶來災難。

頻繁交付的前題是持續整合(CI-Continuous Integration)，持續(密集)到什麼程度? 最好應該是一天數次，至少是一周數次，將程式碼頻繁的簽入並且合併至主線(main)。同時在合併前進行程式碼品質掃描、安全性掃描、單元測試。如果這些都沒做到，那請容我這麼說，目前這個團隊(專案)恐怕還不到可以實施頻繁交付(CD-Continuous Delivery)的程度。

所以，持續交付(或謂 頻繁交付，不過這兩者其實有些許不同)的前提，是良好的基礎建設(這邊指的基礎建設是指 CI - Continuous Integration)。

同樣的，若企業想要執行『滾動式修正』，你的團隊和行政體系必須要有足夠良好的體質，這體質指的是 : 快速的執行效率、順暢的溝通管道、卓越的行政系統、高效的組織架構。不僅如此，還要有良好的防呆機制和安全性防護措施(就如同我們在CI的過程中，有著各種自動化檢查和安全性掃描一樣)。

唯有已具備良好體質的團隊，在面對快速迭代、持續修正的計畫與指令時，才能游刃有餘。

否則，我們的『滾動式修正』將帶來災難，大家看到的只會是『滾動』，而沒有『修正』。沒有辦法得到持續修正、持續改善的效果。要記得，並非所有的『滾動』都會帶來價值，就如同並非所有的『頻繁交付』都會為帶來價值一般。

我們真正想要的並不是滾動，而是修正。正如同敏捷想要的並不是迭代，而是持續改善。

唯有頻繁修正、持續改善才是價值的來源。而為客戶帶來價值，才是我們真正想要實現的成果。