2022年5月26日 星期四

迭代、敏捷 與 滾動式調整

enter image description here

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

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

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

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

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

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

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

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

答案是 : 『不能』。

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

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

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

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

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

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

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

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

沒有留言:

熱門文章