[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,才能增加公司利潤。