黑先生

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

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

【敏捷前，先做好一件事】 檢視 千萬別被scrum看起來簡單的框架誤導，以為scrum的活動(Planning、Daily、Review、Retro)有進行，就代表敏捷了。而是要以當初進行敏捷的痛點或改善為指標，到底有沒有被解決掉，而非活動有沒有執行為依據。 以"為何而做"為依據，最好敏捷啟動前的檢視。 ※基礎檢視 細拆scrum可以分成四個面向，執行、驗證、需求、市場。以漸近變革過程的話，一步步把四個面向依序做好，先學會把事情做好，回頭檢視下做的對不對，會比較容易切入。再以工程來檢視執行面，要先確定是否有足夠穩定的開發基礎來支撐整個敏捷活動。 ※初衷檢視 有沒有在錯誤的出發點下套用敏捷?以為痛點用敏捷就能解掉? 舉個案例， 曾經輔導過團隊，想利用scrum來解決每個人工時不準確的狀況，甚至期望多幾次Sprint後，Task單上的工時就會準確。主管把每個人每個衝刺的總工時精算後，用任務單填滿，更鼓勵工時精確度頒發獎勵。 看別人的案例總是覺得很不可思議，再回頭想想自己，有沒有犯了同樣的錯呢? 敏捷不是解藥，它只會不斷的把有問題的現象加大反應、突顯出來。 在於有沒有能力去主動解決。敏捷前的心態、能力養成，是個很重要步驟，也很容易被忽略。 ※團隊層面檢視 ●如果還沒成立團隊， 要先檢視上、下層有沒有共識、支持、資源，否則就算進行敏捷，只是換個開發方式而已，體質沒變的話，可能會讓事情變更糟糕。一般來說，成員的第一個感受絕對是會議時間變多，沒時間執行，導致慢慢排斥、參與度低然後失敗收場。 ●如果是現有團隊， 要先確定一下目前 團隊的成熟度 ，到底禁不禁的起過渡的變革時期的低潮，撐不撐的過去，或者，目前團隊適不適合。 敏捷團隊的期待是，不需要其它單位的資源或協助，就能夠在團隊內完成所交付的事。假設不是這狀態的話，請先調整後再進行。 敏捷團隊的期待是，大家都能自主完成事情。這通常也表示，團隊成員有一定的成熟度和經驗，都知道自己該做些什麼。在執行過程中，可能會和別人互相影響、配合什麼工作，大致都能提早辨識出來。 反之，假如團隊成員經驗都相當資淺，現實面來說，就要考慮是不是真的要敏捷。有可能在Planning meeting時，成員就規...

【Dual Track Development / Agile(雙軌敏捷) Part 7 - Retrospective meeting】 上一篇 Review 後，緊接著就是開回顧會議。 第一次的衝刺，絕大多數是產出不太順利。別太擔心，這很正常。團隊彼此間的磨合、對於新的開發方式的適應、準備交付的不完整、進度反退....等等，這也都是計劃內的一部份，把失敗納入計劃之中。 必要的時候，也可以刻意失敗，有時會讓團隊進步更快。就像小孩子第一次在學騎車時，摔過一次後突然間就會了。當然，第一次就有近程勝利會不錯，不過重點還是在，大膽、快速衝刺產出進行第一次驗證，這樣我們就會知道離敏捷還有多遠的距離。 別忘了，我們還是勇敢踏出第一步，這本身就是一件很值得慶祝的事。過程中，我們要時時確保、觀察的是， 團隊的氣氛是否還是在正向、投入、高效狀態 。如果有需要，適時立即的引導，會比放在回顧會議中來的有效果。 初期的會議，對於需求探索的技巧與方法都會很卡，畢竟團隊是第一次轉型成一群人一起討論需求、發想需求、最後收斂。還會有很多舊習慣和思維需要慢慢提醒，安全、信任的環境也會慢慢成型。 雙軌敏捷的回顧我分成兩種， 【固定式】 如同一般Scrum在衝刺後舉行，針對的是整個開發過程中的人員、關係、流程、工具等方法，做出改善的建議。 【立即性】 放在需求探索團隊的討論會議裡，時間短。目前經驗看來，每次的需求探索會議都是一個完整的小段落，因為下一次接著開會時，就會需要製作出原型帶入會議中再次確認。因為這個段落，也就很適合在討論結束時，提出一些剛剛討論過程所觀察到的現象，讓大家反思可以怎麼做會更好。 所以，需求探索團隊的回顧會議大多是立即回顧。會針對剛剛團隊討論的品質、狀況、流程給予建議或肯定。時間可以是會議結束前，也可以是下次會議開場時進行。 立即回顧的內容可以是， ●使用者故事、示意圖、流程圖、驗收標準搭配運用，讓整個需求更立體、明確， ●或者是剛剛的衝突反應的凸顯、討論過久沒法收斂回來， ●也有可能是觀念的建立、技巧的補充...等等。 ●大原則就是， 如何改善讓下次團隊的討論更有效 。 當然，開發團隊還是有自己的回顧會議，也會有一起的回顧會議。一起的回顧會議是請需求團隊與開發團隊的各自代表參加即可。 【結論】 ●共同的回顧 ...

【Dual Track Development / Agile(雙軌敏捷) Part 6 - Review meeting】 上一篇 Planning meeting 後，探索團隊和開發團隊就回到各自的衝刺節奏，由共同的Daily來確保交付項目，有沒有什麼意外需要即時調整。畢竟是遠端協作，當初交付的需求可能不盡完整，多少會有遺漏掉的。 【會議前】 Review也是共同會議，除了所有成員以外，還要包含產品的利害關係人也要參與，除了解進度外，更重要的是回饋與調整。所以不要忘記在Review前一天，以Mail或其它方式通知相關人到場，附上此次的Review內容和順序資訊，有助於加速理解目前產品狀況。 為了讓演示過程順暢，會請開發團隊事前檢視確認一下目前的版本與環境，把所需要的畫面、帳號、服務都先開啟。更進一步，可以安排演示的順序。因為有些User Story接著演會具有連貫性，對於利害關係人來說是更容易進入狀況理解。 遠端演示有些小細節做了會更好，譬如說， - 投影共享操作手機畫面時，開啟點擊觸控的回應功能，讓遠端的人知道剛剛的操作是點了哪個地方才切換畫面。 - 演示人員的講話速度慢些和停頓點多一些，讓遠端的利害關係人容易理解。 - 麥克風是共用放在桌子中間就可聽清楚，比需要靠近拿來拿去更好溝通。 - 座位的安排 【會議中】 Review過程中，探索團隊會指定主持人與紀錄者，主持人先做開場，然後由開發團隊操作、展示。利害關係人的討論與意見回饋，當下會做適當但不深入的討論，最後摘要記錄下來，於會後由探索團隊深度討論是否要做調整。最後的決定權還是以探索團隊為主。 初期會議裡，如果有個像教練或SM的角色會更好。會議過程中，SM以客觀的角度去發現需要改進的地方，帶進雙方的Retro.中，會加快進步、改善的速度。 【會議後】 Review會議後，探索團隊和開發團隊有各自的Retro.，其中，探索團隊的Retro.會先行討論剛剛Review中紀錄的回饋，確定是否進一步討論或取捨，納入到待辦清單中。回饋討論完後才進入Retro.。 【大致上的流程】 ●事前通知，附上Review內容與此次Sprint燃燼圖 ●演示內容的流程安排 ●測試機與相關展示設備的準備(Zoom、手機投影、視訊...

【Dual Track Development / Agile(雙軌敏捷) Part 5 - Planning meeting】 在 上一篇 準備好下一個Sprint所需要的相關資料(User Story,Acceptance Criteria,圖)，並且輸入到自己的專案管理系統，就可以開始Planning meeting囉! 由於我們雙軌的二個團隊一個在台灣(需求探索)，一個在大陸(產品發行)，非常倚賴電子專案系統(Azure DevOps)，有些事前準備要先做，像是把User Story的順序做個排序(讓情境是完整或連續的)，降低當下遠端溝通成本。否則，可能在會議當中又再次過度發散討論或者聽不太懂需求描述，更可怕的是聽錯意思，導致最後產出歪很多的產品功能。 【使用者故事、驗收標準】 經驗來說，User Story是比較開放性的需求描述，非常適合用來說明需求的情境和發想需要的功能。但在雙軌敏捷的話，對於開發團隊來說，就不是主要文件。 我們會盡量以"圖"為主，示意圖、流程圖、草圖、分鏡圖、結構圖、Mockup、影片、競品....等等，當作主要說明文件，能用圖就用圖說明。 - User Story在過程中用情境帶入( 用圖說故事 ) - AC則在關鍵點時說明 團隊越是有文化差異，就盡量用圖為主，文字為輔。 以登入驗證來舉例說明， - 出張示意圖把可以登入的方式標示出來(FB、LINE、官方帳號的按鈕) - 看圖說故事，三顆按鈕的故事 - 分別說明FB、LIN、官方登入的AC - 同樣的，如果過於複雜，最好也用流程圖來說明AC 【規格書】 也許大家會懷疑，這不就是規格書?不就是瀑布嗎? 因為需求探索已經把開發團隊要列的AC列完了，他們只要照著做就好。 雙軌敏捷如同 之前的前言 所說，視團隊和專案的狀況調整交付的精確度，如果開發團隊都有設計的思維、專案上線壓力不大、需求探索團隊的專業組成能產出較高較正確的價值，那也許由需求探索團隊把AC寫清楚會較合適。 不過呢，真的在用AC描述的時候，其實正常狀況下，應該也寫不出像規格書那樣細。反之，當發現交付過程中，連一點討論的聲音都沒有，可能就表示你的User Story或AC格式、寫法錯了，應該都還有2-3成...

【Dual Track Development / Agile(雙軌敏捷) Part 4 - 需求探索衝刺】 雙軌敏捷中，負責需求探索的團隊也如同Scrum一樣，有著固定的週期和節奏，也和開發團隊有著共同的會議(Review.Retro)，負責同一個產品目標。 需求探索團隊可能不是一個專職團隊，是一個約七人的虛擬團隊，來自各方的代表，人員角色也必須多元(PO.營運.RD.企劃.QA.UI/UX)，參與的人員大多是固定的，但會依不同主題找必要人員，譬如說客服.財務人員。 需求探索團隊主要職責是 「運用設計思考的思維創造或發現"對的事"(Build the right things)」 ，通常需要時間來發酵，如果能善用引導或方法(思考框架)可以提高效率。 雖然需求是由探索團隊討論&確定下來，很重要的一點是，最後交付出去的絕對不是封閉式規格書，而是開放式的使用者故事(User Story)、驗收標準(AC)、示意圖or流程圖，會跟開發團隊做Planning meeting，最後還是要交由做事的人決定方法。 需求探索五步驟 ●發散思考 有很多方式可以做，如果需要搶點時間的話，先前可以準備好相關競品資料、最新趨勢參考，或是先設計好一版的原型後，大家再來一起發想討論。 當然，視主題而定，如果遇到殺手級的功能，也許可以安排一下Design Sprint來決定。 到後期熟悉時候，大多時候帶著Design Thinking的思維來寫下"使用者故事"就足以解決了。 ●收斂成 示意圖/流程圖 發散思考討論會有很多的建議、想法，所以，最好在有足夠大的白板旁邊進行，這樣就可以隨時把大家腦中畫面視覺化。很多時候似乎嘴巴講的都對，實際畫出來後卻問號連連，怎完全不一樣，尤其是面對複雜流程、功能更明顯。 流程圖可以用畫的，也可以事前準備分鏡圖，讓大家排出最有共識的流程。 ●寫上US.AC 經過前二步驟，其實大家腦中已經累積大量資訊，要趁熱把腦中資訊和眼前畫面連結。 有二個方式，有不同的效果 - 邊畫圖的過程邊寫上US.AC - 事後補上 事後補上是讓每個人對剛剛所有資訊進行轉換，以US.AC的方式記錄，重疊也沒關係，有時會出現剛剛沒想到的想法，36...