黑先生

【我們該如何讓Retro.回顧會議聚焦問題產出行動方案?】 平常工作場域中，常常看到會議是以檢討為主，要求要有結論為這次的執行的過程加上註解，強調的是結果，反而沒仔細檢視過程中哪些環節造成錯誤的結果。大多是在處理症狀解而非根本解，然後無限惡性循環。 所以，回顧會議一不小心也很容易被當成"檢討會議"，一種帶著濃濃指責意味，且指向大多是對著別人，你怎樣....你如何...都是你....等等。因為這樣的回應對大腦來說最輕鬆，沒什麼成本。也因為都是指向對方，彼此不會有交集、共識，更不用說行動方案的產生，問題持續存在。 從以上來看，不難看出會議中會面臨到的問題，一般有兩個議題要去面對， ●一個是問題容易延伸出更多問題，問題發散找不到有效的解決方案 ●另一個是問題變成情緒問題，彼此都站在對立面，沒法進一步思考下一步該怎做 針對這些現象，可以在會議開始前，先訂好回顧會議準則，引導成員應該要如何描述問題的情境。敘述的方式不同，就會讓成員有不同解讀去思考、回應問題。假如用的都是"你"開頭的句子，就容易引來不同立場的對戰。 反之，只要先訂好準則，不僅會更聚焦問題，也會讓接下來的問題情境描述容易進入反饋。 而這個準則就是以" 我 "或" 我們 "開頭，並且在講完問題後，也提出自己的想法、解法，不管有沒有用都可以嘗試提一下。我們通常要的不是"答案"，而是要讓大家習慣先思考問題，而非停在問題。這樣會有助於在執行任務時，即使面對問題，也會自己先思考如何解決。 當然，可以搭配團隊當下情況，找到合適的 思考框架工具 ，讓問題自然依循架構發展出答案。這種模式通常會再經過三、四次的回顧會議後，團隊開始習慣且正面、理性思考的情況下使用。 再來說說相對難處理的情緒問題， 回顧會議中出現情緒反應大多是好現象，表示大家願意、認真的正視問題的存在，不再漠視。只要出現這狀況，通常經過好的引導後，團隊大多會有驚人的成長與轉折。如果因此解決的話，整個團隊士氣會大增，也更有凝聚力，願意投入變革，行為也會變得積極主動。 大多想要引進敏捷做變革，無非有二個因素， 想要更好 或者 正面臨痛點 。大概7.8成以上是後者，一種不得不的變革。所以，在現有團隊、組織不變的情況下進入敏捷，在初期的幾次回顧會議可能會充滿著情緒發言。至少大

【關於 使用者故事(User Story)的實際運用】 先從敏捷宣言切入，其中 個人與互動  重於  流程與工具 可用的軟體  重於  詳盡的文件 換言之，可用的軟體是互動、討論出來的，不是由企劃獨自規劃寫出。 剛接觸敏捷的人，可能會有些誤解與想像，會以為是不是就不需要規格書就可以進行開發? 當然不是，取而代之的是"溝通"，而 中間的溝通媒介就是"故事" 。 講一個故事絕對比描述一個需求來的吸引人。如果使用的故事會讓人想追問為什麼，這絕對是個好故事，而這一來一往的問答，就是溝通的開始。 故事應用在軟體開發，為了能更聚焦討論，我們會以"使用者"作為起點。 以使用者的角度出發，故事就有所依據和標準界定，描繪出更貼切、更合理的情境描述。 因為，只要不合理，一下就會被質疑，他真的會想要這功能嗎? 所以，在提出這個US前，要以這角色去蒐集更多數據來佐證，加強功能的合理性與價值。 使用者故事：我是誰___(角色)，我想要_____(功能)，因為______(利益/價值)。 在使用上有沒有種經驗，雖然格式簡單，但真的實際運用卻好像渾身不對勁?不知道要怎進行? 分享我的經驗讓大家參考，有二種使用情境， 一種是，PO/企劃   獨自準備好US、AC需求來跟團隊討論；另一種是，一群人的需求討論。 ● PO/企劃   獨自準備好US需求，準備好背景故事 可以把US當作"摘要"，拿來濃縮整個故事情境脈絡。也就是說，不能只單單寫下US，還要把上、下文表達清楚，而不是只丟一句US格式的文字，就想讓整個團隊對它非常有想法進而拆解出任務。 一句話的背後，上下文、數據、情境、流程圖、草稿圖..等，都會透過表達、呈現讓團隊知道，最後歸納出的US，會在Planning meeting時讓團隊來想像、發問、溝通、理解。 如果真的只有US一句話就給團隊，那跟 許願/隕石/命令 沒什麼差別。 ●一群人的需求討論，拿來收斂使用 團隊會先經過大量討論和探索需求，在團隊互動過程中，可能會畫出線稿，也可能會做競品蒐集、分析與討論。團隊經過一段時間發散、共識溝通，最後的收斂就會使用US來呈現與確定先前的討