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