June 12 21:15~22:19
▲Teddy認為的PDCA循環與Scrum的關係
有一次上Scrum企業內訓的時候，有學員問了一個問題：「Scrum與戴明的PDCA（Plan、Do、Check、Act）循環有何不同？」在看到這個問題之前Teddy並沒有想過這個問題，依據直覺來講，Plan就是sprint planning meeting，Do就是sprint execution，Check就是sprint review與retrospective，Act則是sprint review與retrospective的回饋結果，反應在具體的需求與流程改善活動上。
後來在《SCRUM：用一半的時間做兩倍的事》書中看到另一種講法，Plan和Do與Teddy的看法一樣，不過關於Check書中只提到在retrospective中討論團隊工作方法有哪些可改善之處，而Act則是改變工作方法，等於是Check結果的實際行動。
▼每個PDCA循環好比一個Sprint，隨著時間演進，透過持續改善，團隊的品質不斷提升。
***
Teddy覺得如果只把PDCA循環放在「改善品質」上面，無法完全對應到Scrum的雙重回饋路徑（請參考〈Scrum 是什麼（1）：雙重回饋機制〉）。也許可以擴大解釋，讓Check包含工作方法與需求的查核，這樣的改善威力會更加強大。
***
友藏內心獨白：扯上PDCA，管理出身的人是否比較容易理解呢？
June 12 10:35~12:10
Teddy經常會被問到「要怎麼找force？」雖然在〈Force是什麼？〉、〈了解Force讓你做出好設計（1）：自然界與設計界的Force〉、〈了解Force讓你做出好設計（2）：一個軟體設計範例〉談過幾次有關force的內容，但似乎還是沒說清楚。上禮拜天（6/7）在上「Design Patterns這樣學就會了–入門實作班」，進行到pattern寫作的活動，Erica突然告訴Teddy：「是不是可以從問五個為什麼來找force？」
因為不少人在找force的時候，找出來的都是眼前看到的表象，而不是表象背後的原因，所以也許透過針對表象問為什麼，可以探索出背後的原因，也就是造成這個表象的force。
***
6/11日Teddy在北科上課的時候，剛好有學生問到force的問題，Teddy就套用問為什麼的方法，來幫助學生尋找force。問問題的是做「北科報馬仔App」的這一組學生（請參考〈看到才有感覺〉）…
學生：我們找到一個force：「PO文的人不希望暴露自己的身份」，這樣算是一個force嗎？
Teddy：我記得「PO文的人不希望暴露自己的身份」是sprint 2 review的時候其他同學提出來的建議，感覺比較像是一個現象或是需求。為什麼不希望暴露自己的身份？
學生：因為隱私權。
Teddy：為什麼隱私權很重要？
學生：嗯……
Teddy：以我為例子，假設我在校門口看到一個正妹，如果我PO了她的照片，可能被人家說我是色狼，和我平日維持的形象不符，所以我想要匿名PO文。
學生：對。
Teddy：所以這個force會不會比較像是：「因為不需要顧慮旁人眼光，人在私底下比較容易表達出真實的一面」或是「如果所有訊息都可以追蹤到發文者，可能會導致有些人因為顧慮太多而減少PO文的機會」。
***
問「為什麼」是一種尋找表象背後原因的好方法，也許不用問到5個為什麼，就可以找出force。鄉民們也可以自己練習一下。
***
友藏內心獨白：你媽媽知道你在PO廢文嗎XD。
June 12 14:13~14:54
▲日蝕。
如何登陸太陽
甲：聽說有人提出一項偉大的計畫，打算登陸太陽。
乙：那麼厲害，要怎麼做到？
甲：很簡單啊，就是利用晚上太陽睡覺的時候登陸，這樣就不會被燙傷了。
乙：這個主意不錯喔，我還有另一個建議，可以利用日全蝕的時候登陸太陽。
甲：耶，這個方法也不錯喔，這樣就不用等到晚上了。
丙：拜託，你們兩個不要在那邊耍白癡好不好。不管是晚上還是日全蝕，太陽都一樣會發光發熱。
甲、乙：真的嗎？！
丙：是真的，你們說的這兩種方法都不可行。要登陸太陽，不可以跟它硬碰硬，只能偷偷繞到太陽背面避開它的光芒，這樣才可以成功登陸太陽。
來人啊，將這三個人鞭數十，驅之別院。
***
評估績效
皇上：針對此次改革，朝廷要如何評估軍人訓練的成效？
兵部尚書：在改革之前我們先測量每個人射箭的距離，平均為500公尺。改革之後採用碳纖維弓箭加上每天加班工作16小時的魔鬼式體能訓練，射箭距離長達1000公尺，足足進步一倍。
皇上：如此成效，甚好、甚好。
小兵：報~~~700里加急，軍情急報。
皇上：宣。
小兵：啟奏皇上，豐台大營在八里橋與洋鬼子對戰，全軍覆沒。
皇上：什麼！兵部尚書，這是為何？
兵部尚書：我軍戰力甚強，這是臣親眼所見。為何一敗塗地，臣也不明白啊。
小兵：啟奏皇上，我軍雖可拉弓射箭1000公尺，但洋鬼子的大砲可遠射5公里。我們還沒見到敵人蹤影，就已經被砲火給轟滅了。
***
友藏內心獨白：改革前還是先安排時間出洋考察，看看世界都變成什麼樣子。
June 12 16:20~18:10
Scrum團隊有三個特性，分別是self-organizing（自我組織、自組織，或稱為自我管理）、cross-functional（跨職能）與continuous product development model（持續產品開發模式）。這三者之前都談過（請參考〈Scrum團隊之持續產品開發模式〉、〈Feature Team or Component Team?〉、〈自我管理〉）。最近讀了《群的智慧》這本書，對自我組織有著不同的體會，今天來談一下這個話題。
Teddy曾經提過在《Scrum Shortcuts》看到一段改寫自《Essential Scrum》的敘述，用來描述自我組織：
Self-organization is a bottom-up emergent property of a complex adaptive system. In such systems, many entities interact with each other in various ways, and these interactions are governed by simple, localized rules operating in a context of constant feedback. These types of systems exhibit interesting characteristics, such as being remarkably robust and producing amazing novelty.
從這個定義裡面，可以找出幾個重點：
***
試想一下，你的Scrum團隊具有以上特點嗎？如果沒有，有沒有什麼方式可以協助團隊成唯一個比較好的自我組織團隊？讓我們逐一來檢視一下：
Teddy覺得，「根據簡單基本的原則來處理問題」這一點在Scrum團隊中應該要被加強說明，因為如果團隊成員沒有一個共同的合作準則，很難培養默契，最後變成「分工而不合作」。例如，對於團隊成員認領的工作，如果一天以上沒有解決，其他團隊成員會有什麼反應？PO帶來sprint planning meeting的story應該滿足什麼條件，以免大家花費不必要的時間在釐清問題上？當看到寫得不好的程式碼，是不是每個人都願意且敢於去修改？
***
自我組織的團隊能夠穩定、可靠、有創意的解決問題。養成這樣的團隊很難，但值得持續努力。
***
友藏內心獨白：可以跟大自然學習。
June 12 09:28~10:25
圖片來源在此。
在部落格寫了這麼多Scrum文章，好像從來都沒解釋Scrum這個字，今天來說明一下。這個名詞來自於橄欖球中爭球的動作。為了爭球，團隊必須：
在爭球的過程中，雙方角力，環境變化很快。如果團隊沒有共同目標與方向，力量分散，很難搶到球。當搶到球之後，團隊必須合作把球往後場傳遞以便得分，這又是需要高度的默契與高超的技巧才辦得到。最後，球場如戰場，環境瞬息萬變。球的位置、隊友的位置、敵對人員的位置、觀眾的 吵鬧 加油聲、團隊士氣與人員狀況、天候與球場狀況、裁判表現、教練戰術等，都會影響比賽結果。團隊必須隨時檢驗與調適（inspect and adapt），以適應外在環境變化。
***
鄉民們的Scrum團隊是否符合上述要求：團隊成員有共同目標？是否開誠布公的緊密合作（transparency）？是否經常檢驗與調適？還是每個人各發一顆球（各做各的story），各自努力往後場衝刺以爭取個人績效？如果你的Scrum團隊遭遇困難，可以思考如何向優秀的球隊學習，也許會是一個突破困境的機會。
***
友藏內心獨白：名字不是隨便亂取的。
