[Essential Scrum] Scrum的多層次規劃

其實每讀更多agile的文章，就更能夠把敏捷的方法與程式的『耦合度』關聯在一起。本章看似在教你在組織內如何規劃各層級的對象，但事實上他也在教你，除了程式與函式，工作與流程也是必須要解耦合的。

Scrum的多層次規劃，從上層開始，依序講的是產品組合、產品、發布、衝刺、以及每日規劃。

一般的工程師，包括scrum master，最熟悉的大概就是衝刺規劃與每日規畫了，因為那實作起來其實就是每兩週一次的Planning meeting與每天一次的Daily scrum。然而，其實一間公司的開發流程是否能夠『順暢地敏捷』，其實應該要從最上層的『產品組合規劃』開始才對。

『產品組合』這個概念說來抽象，但其實說穿了，你就想，『我手上的這些git專案，要怎麼包裝出去成為一個服務，來賣給客戶。』一個產品組合的規劃，週期可以是一整年。譬如，我在一年的開始，就決定好今年每一季我要推出什麼產品，才能最大化我的利潤，這些產品彼此有沒有相依性，各自大約需要花費多久，我是不是可能就這些產品，而推出不同組合，來賣給不同客戶…等。這很大程度是經營團隊、CTO、與架構師的課題。

一旦決定了這一年的產品組合，我們就可以來針對各『產品』做出規劃。這時候，產品負責人(PO)對於此產品為來會發展成什麼樣子，會有一個藍圖，或是願景。這個願景可以具象化成為表格，或是圖表，這沒有一定，只要能表先你的『願景』就可以了。而其後，就可以細分為Epic等級的Product Backlog，到這裡，聰明如你就知道接下來會發生什麼事了。

有了產品組合與產品的規劃後，我們會開始著手『發布規劃』，這是相當重要的一件事。我認為，『發布規劃』做得好不好，就看的出你的公司是成熟發展，還是停留在草創期。

怎麼說呢？如果我能在腦中有一個『目標產品』，或是我們常聽到的『最小可行性商品(MVP)』，那麼我們可以概略估算出，大約需要幾個衝刺，才能把這個MVP上市，那麼，相關的宣傳、客戶聯絡、市場調查、安全性驗證等，都可以提前準備。

草創期的公司就不是如此了，我『今天趕出一個功能，明天就要上』，客戶『今天跟業務許願，我下禮拜就要滿足他』。在愈來愈成為主流的Continuous Delivery原則裡面，這樣『趕快做完趕快上』的心態，在草創期是非常OK的，為什麼？當然啊！你要生存啊！你系統就這麼點大，僅有的那兩三個客戶就是神，當然他要什麼明天就生給他啊！

但等你商業模式穩定了，code base也越來越大了，還要繼續保持這種心態，那就危險了。這會造成系統不穩定，以及商業策略紊亂。為什麼？很簡單，因為前面提到的，你的產品是以一整個組合的方式呈現給客戶，而不是一個一個的『功能』。客戶要的是具有功能的商品，不是這些零散又臨時趕出來的功能。不好好進行發布規劃，長期下來，可以想像，對公司的商譽反而會造成毀滅性的影響。

『做好什麼上什麼，今天做完明天上』，實在是猶如嗎啡般，偶爾為了止痛可以拿來用，但不適合天天施打的致命處方藥。

注意到了嗎？我們這兩篇講的都是『規劃』，可是，Scrum不是不規劃嗎？就跟你說你誤會了齁！Scrum不是不規劃，他是只做『必要的規劃』，而且只有在得到足夠資訊時，才會動手規劃，而在那之前，則是努力想辦法去取得資訊。為什麼？老話一句：

未實現的規劃成果，也是WIP，唯有減少WIP，才能增加公司利潤。