在scrum流程中,「發佈(Release)」必須是「規律且多次」的。PO要定義好每次發佈的「時間」與「範疇」。
發佈的策略有以下幾種:
前篇中我們關注了元件與元件間的連結,在本書的最後幾章,作者再把範圍擴大,談到了系統的整體規劃,以及好的RD的工作習慣。
筆者曾說過:「如果軟體工程師只能讀一本書,那你一定要看Uncle Bob的Clean Code。」然而,Clean Code一本那麼厚,要看到何時才看得完?
所謂的產品規劃,可以簡單定義為『建立前端產出物的活動』。為什麼一定要強調前端?很簡單,因為它就是一個end-to-end的需求,也就是一個完整商品。
OK,也許不那麼完整,但是它至少包含了可以組成一個商品的最小限度內容。對了,敏銳如你,一定就知道,第一次的產品規劃,就是大家來決定一下我們的『最小可行性商品』應該長什麼樣子。
有了產品規劃後,PO就該開始考慮「怎麼讓產品動起來」,亦即,「如何讓老闆買單」的問題。
首先,一個振奮人心的「願景」是必須的。PO心中有了一個最理想的產品還不夠,還得在最短時間內,讓決策者認同才行。於是,這個願景可不能太長太難懂。譬如1961年,美國總統甘迺迪說:
「10年內,我要送一個美國人上月球,並且平安送他回來。」
其實每讀更多agile的文章,就更能夠把敏捷的方法與程式的『耦合度』關聯在一起。本章看似在教你在組織內如何規劃各層級的對象,但事實上他也在教你,除了程式與函式,工作與流程也是必須要解耦合的。
Scrum的多層次規劃,從上層開始,依序講的是產品組合、產品、發布、衝刺、以及每日規劃。
Companies often have huge issues with trust:
The customer doesn’t trust the supplier
The business doesn’t trust the developers
The developers don’t trust the tests
The testers don’t trust ANYONE.
組合規劃,指的是在一間規模較大的公司,手上有超過一種產品,你要怎麼在這些產品之上,做出更高一層的規劃與構想。注意這邊說的是『之上』,而不是『之前』,因為組合規劃有…
人們總是對Scrum有個偏頗的想法:『Scrum不做規劃』。事實上這件事我在先前的文章也已經提過,這實在是很大的誤會。人們會有這種印象,應該是受了大學時軟體工程課堂那隻長得像古代貝類的圖的影響吧:
(本文中程式碼可由此下載:https://github.com/bearhsu2/building_maintainable_software)