黑先生

【Scrum第一次Refinement meeting】 Refinement meeting(精煉會議)，通常用開車的遠光燈來形容，替前方不明路照一下，讓車子可以繼續安全往前進。 指南 中也僅僅只有幾行的簡短描述 Product Backlog items 透明性通常要經過上述精煉化活動來獲得。 先理解它要傳達的內涵 - 持續讓待辦事項關注、最新，「 模糊變明確，未知變已知 」；我們來用人、事、時、地、物劃分出原則。 人： 不必全部人參與，用最少且必要相關人進行有效討論。 事： 最新資訊持續更新，至少要讓下一次衝刺任務是清楚的，可被挑選出來拆解。 時： 視開發節奏保持彈性，但也可以固定在某一天。通常是在下一次Sprint前一個星期內。 (初期不熟流程狀況下，SM可以視情況是在哪一個Sprint才開始，不用第一次就到位。) 地： 在 使用者故事地圖 、待辦清單 看板前，隨時以全貌有系統的修正資訊。 物： 修正待辦事項的明確性，盡量讓下次的Planning meeting是有效率且可聚焦規劃。 實際情境： 如果沒有特別定出這時間來整理目前的使用者故事地圖或待辦清單，通常在Planning meeting中，人多容易失焦，又會多花一、二個小時整理後才能進行規劃。 Refine中，SM可以先與PO討論，先把目前資訊梳理到看板，問有沒有下一次想做或調整的MVP。如果有的話，目前還有缺哪些資訊須要了解，或者哪些資源須要備妥，在下一次Planning meeting前趕緊準備好，讓成員可以順利進行拆解任務。 結論： "衝刺"表示身體過程全神專注目前狀態，因此要有SM或PO如教練般旁觀，在場外觀看整體與資訊整理，再消化後轉成策略傳達給團隊，讓贏面更大。 參考： @產品待辦清單精煉會議 參考： 梳理會議(Refinement Meeting) 上一步： Scrum第十三步：第二次Planning meeting 下一步： Scrum第十五步：第二次Review meeting ------------------------------------------------------------------------- Scrum起手式第一步：團隊建立Team build

【Scrum遊戲化體驗-用戶故事地圖】 故事地圖在初期引入時候，通常成員也會比較無感，導致需求產生總是卡卡。有了地圖的雛型後，開發端也會在coding時預留彈性，間接的把風險降低，不一定要完美才呈現。持續改善才是敏捷核心精神。可以透過遊戲來體驗，強化故事地圖的存在、源頭。 大致步驟：(1.5小時) 。前置作業-準備好Persona人物誌的描述、圖像、個性 。講題目 - 寫下從早上起床到出門上班，過程中所有做過的事情 。討論5分鐘 。觀察每組討論狀況，是否呈現比較無法聚焦討論(各講各的) 。適當時機與介紹，把Persona拿出來給個組討論，讓大家容易進入相同的想像空間 。讓大家討論20分鐘，寫在便利貼上，並依照時間順序排列 。分類動作並且命名 。狀況題 - 起床後，只剩半小時可以動作，而且早上有個會議絕對不能遲到。這種情況下該怎麼做? 。把不必要的動作往下方區隔出來 。狀況題 - 出門前一刻，公司同事打電話來說會議臨時取消。時間突然多出來半小時不趕，那就再做點什麼事吧! 。把想要額外的動作往下方區隔出來 。遊戲體驗完後，再拉大家回目前專案使用的故事地圖，看看有無別的想法想做修正 額外思考訓練 - 模擬市場不確定性的想像 大致流程： 。用海龜湯題目：便利商店、水、店員、槍、謝謝 。這五個關鍵名稱，讓每個人自行想像補出細節 。每個人列出流程後，再統一合併成一個流程 練習面對不未知情境的想像!! 實際情境： 通常跑Scrum有一定前提，需求已經大部份被PO確認完畢，開發團隊要做的就是在迭代持續回饋與改善，對齊PO的產品需求。但對於開發團隊，尤其是希望這團隊未來是朝自組織狀態，把全貌描繪出來，讓所有成員都能清楚知道自己正在哪個階段做什麼事情，心裡不安定感會降至最低，最事起來也會間接影響較有效率。 就算故事地圖很粗糙也沒關係，它也是個回饋反應，讓大家理解與共識目前狀態不確定性，去做開發的彈性預留空間。 結論： 開發團隊通常是在被局限在某個視野下去做開發，很容易失焦。如果想要讓團隊擁有系統思考去做討論或開發，把地圖視覺化呈現後，會讓彼此容易共同討論也聚焦。 樹葉就像執行認務，樹枝串連凌亂的樹葉讓其有序，進而呈現整棵大樹。 它是個全貌視野，也是個系統思維，更是戰略地圖&a

【Scrum第二次Planning meeting】 〈 Scrum第一次Planning meeting 〉前提摘要：採用Bottom up方式，以理解Scrum元素為主，先寫出Task再補上Story。 先來回憶一下指南說的： Sprint Planning 回答以下問題：  ● 這次 Sprint 可以發佈什麼樣的 Increment？  ● 如何做才能夠達成 Increment？ 有了上一次經驗，團隊成員應該都稍微熟悉有哪些流程與內容要做，這次SM可以大膽嘗試，只做開場說明，然後交由團隊寫出這次要Sprint任務。 這次大致目的： 。SM以第三人旁觀角色，觀察與紀錄整個過程，並事後回饋修正 。了解User Story為何， 。PO寫出User Story，讓Develop Team有依據寫出Task， 。驗收標準在Planning meeting中先不寫，可以在Review meeting前在找關係人討論寫上， 。順序、估計則視狀況，通常越熟悉整體流程與資訊越完整情況下，寫的意義會比較大，但也表示付出的Plan時間成本會更多。 大原則，比上一次(只寫出Task)再多一些了解(User Story與標準驗收)與進步(由User Story寫出Task)即可。 前置作業： 。先與PO討論、溝通流程(大致會進行的方式)與內容(預計輸入、輸出物)， 。請PO準備好這次要執行的User Story。 。印列User Story表格單 。列印Scrum指南中提到Planning meeting的部分資訊、別人的Planning meeting情境參考 。開場前可以花個5分鐘講解 實際過程： 。延續上次story map與系統情境流程圖繼續衝刺 。PO白板列出可能會有哪些關係利害人(提供思考)， 。PO白板標示出User Story的描述格式，"身為Role，我希望Goal/Desire，以便於Benefit/Value。"(提供思考)， 。PO依據"系統情境流程圖" 寫出User Story提供參考， 。Development Team與PO討論User Story， 。Development Team可以在理解後，另外嘗試寫自己的User Story或者直接依據P

【Scrum第一次Retrospective meeting】 先來看看 指南 如何說 框架是這樣，但身為SM更要理解背後精神與意義。 我們先來回想一下以往專案經驗，是不是大多是在功能、產品上線後，才會"特別"空出時間回頭檢視專案。而且大多還不是聚焦在"如何改善"，大多是"究責"狀態或是查Bug等等。 專案中情緒起伏較高處，"怎麼又來了、又這樣、哀、好煩......"，反應出有問題，但卻總是壓抑過了就過了，沒有正式去面對，也就一直惡性循環囉。 SM要特別觀察團隊的情緒反應，那是最真實的，也許他們不會開口說。 情緒 Scrum提供這個溝通頻道與空間，讓每個衝刺結束前，成員可以靜下心來，好好回顧熱呼呼的記憶，最重要的是，記錄下來追蹤、改善。 初期不熟情況下，每次先聚焦一個點來改善，對於SM會得到不錯的信任回饋。讓每個人都知道，任何反應與問題，都是放在心上要去解決，是玩真的，自然而然團隊向心力也會慢慢出現。所以這會議強調的是 我們變好的決心 。 1的n次方再怎樣也                          沒任何改變 1.00001的n次方會慢慢趨近           無窮大 ~ 0.99999的n次方則會慢慢趨近於  零 ~ Infinity 每次做好一點點，團隊會越來越好；千萬不要讓團隊變成小於1的狀態。 來看看指南上要改的焦點可以放在哪些事情上， 總之呢，就是有反應就改，即使是情緒發言也要探討、解讀思考背後原因，再用張紅色便利貼好好記下來，貼在最顯眼的地方，最好是每天Daily可以看的到，試著去改善，然後再次回顧檢驗，移除或畫紅色XX，放在回顧區。這也是團隊成就感來源之一，不一定要等到產品做完才能感受。 SM對於每個問題反應都要當責，即便知道做了也不會有任何改變，還是要去做一次。成員初期在意的不是真的能不能改，願意去做，失敗了也是"一個好反應"，再與團隊一起共識調整出別的方法，持續改善。持續付出，才能感受到決心。 上面提到精神與方法都具備了，感覺很容易應用，那麼實際運作下會是怎樣的情境呢? 第一次回顧會議，要嘛是反應很多問題，要嘛就是沒問題，這要完全取決於SM事前準備功夫了。

【Scrum第一次Review meeting】 先來看看 Scrum指南 如何描述 精神就是「讓利害關係者檢視我們努力的成果，做修正調整，再繼續衝」。 千萬別讓落入自嗨、當局者迷狀態，透過第三人客觀視野，有助於修正我們的盲點，也重新對齊市場需求。 身為SM掌握住精神，了解指南背後意義，就可以照你目前團隊狀態去做相對應的做法。而做法很多元，像是對內展示(只有自己人)、對外展示(有高層)、PO主講、Teams輪流講、各自主講、簡報講、操作展示...等等，都有不同效果。 為何會有對內、對外的區別? Sprint通常是固定週期Review，但利害相關人有可能忙碌無法參加。可以前一天或會議後把Review內容簡報化mail給相關人同步，再由PO另約時間親自面對面同步。 身為SM，不管是對內還是對外，都要最大化此會議目的與效益。例如，對內可以變成每個人的舞台空間，展示一下自己做的功能，驗證自我承諾帶來成就感。尤其是對內向者，更是一個練習表達的機會。 會議內容盡量做紀錄，不管是會議前，透過驗收標準(AC)詢問進度和展示內容，還是會議後，聽取團隊內容後，對於其他人的資訊同步或未來經驗傳承都非常有可貴。 既然要讓會議最大化效益，引導者身份的SM可要好好設計這溝通場域。前置作業要先做好準備與情境模擬，隨時場上應變。 「 引導學 」第三章"場域營造的技巧"，文中提到流程設計的五種基本模式，流程上，個人覺得比較像是其中的『對話→討論→對話』。利用MVP來開啟"對話"，進一步討論希望找出更好的答案，過程中若發生共識上不合，就再一次回到"對話"，讓大家重新針對會議的意義進行交談。最後可以透過對話方式對活動的意義重新思考一次，也是件非常有意義的事。 大致流程： 與PO先規劃討論Review內容與方式 初期可由SM來主導會議流程甚至於內容 透過Story、Task的AC描述，找出適合的展示方式與內容 熟悉後，可由PO或Teams輪流主導 會議中利用簡報或操作Demo來開啟"對話"、"討論" 會議後再透過"對話"整理收斂，供下次衝刺參考 團隊實際狀況： 簡報&操作機互相輔助，講到某個功能時，由製作者描述

【Scrum敏捷小遊戲 - 翻硬幣】 透過「 體驗式學習 」除了讓團隊更理解為何要敏捷，背後邏輯為何，更是Team Building的好時機。及便是簡單小小的遊戲，只要設計好，把要傳達的精神與概念融入，成員們越來越知道why(黃金圈)，會更有向心力。 來介紹初期跑敏捷小遊戲，簡單易帶，所需的準備材料也不多 - 翻硬幣。 透過硬幣價值流動，感受快速迭代回饋的。 步驟： 一、列出此遊戲提到的觀念，如迭代、價值、週期、回應變化....等等，可自行體驗後，再去翻閱敏捷宣言和指南，看看符合其中哪些項目，利用遊戲過程停頓，傳達要表達的敏捷精神。 二、分組 -> 每人代表不同部門 -> 解說規則、競賽、賞罰 -> 練習一次 -> 開始玩 1~7：已知價值玩法，錢幣攤開可見 8：未知價值玩法，錢幣裝在不可見的袋子中，等待開始後才進行。預期大家會分工合作一起數錢。 三、規則 單手，批量 所有硬幣 單手，批量10個硬幣(1.2過程，體驗 瀑布、敏捷差異，會發現，上市完成時間大大提升) 單手，批量5個硬幣(開發波動變小，逐漸形成"流"動開發) 雙手，批量5個硬幣(提高生產力、工作能力、效率) 雙手，批量1個硬幣(局部的優化並部會對全局的優化影響甚至降低)      (1.2.3.4.5 應該關注的是生產週期而不是每個員工的生產力 或利用率，回顧檢視瓶頸 並改善) 雙手，批量1個硬幣，限制30秒，比價值(第15秒時，塞進100元當作 變化，看是否回應，敏捷宣言:回應變化 重於 遵循計畫) 雙手，批量1個硬幣，限制40秒，比價值(硬幣裝不可見袋中，直到開始時才能拿出，並要確認正確金額後才能開始) 硬幣掉落不算。 硬幣要在桌面上，不能直接放在手上翻轉。 結論： 身為SM ，除了敏捷導入，還需察覺團隊所欠缺的活動，讓過程內部阻礙變少、順暢 。引用引導學一書，什麼叫做「問題」? 所謂問題就是「理想」與「現實」之間的落差 。 找出團隊中的理想、期待，並檢視目前現況，中間的落差可以好好思考，該用何種方式來補足，而「方式」可別自我限制囉! 參考： https://blog.51cto.com/zhoujg/518062 Scrum過程總結 Scrum過程總結 -

【Scrum第一次Daily Scrums】 執行 Daily Scrums 框架很簡單卻難精通，大家說好後就花個固定時間，來彼此同步下資訊，看似美好實則怎難做到。原因為何? 因為無所依據，尤其是在沒有建置看板任務的情況，更容易流於形式，然後變成"罰站"，然後就不知所云，最後無疾而終。 「 為何而戰(站) 」是身為SM必須帶給團隊的觀念、信念，"為(WHY)何(HOW)"更要先在Sprint 0備好才進行。 何(how)： 現在我們產生了代辦清單也列出Task任務要做，那要如何讓這貼便利貼的價值更凸顯出來? 就是"每天親近它"，一直重複地看著它的變化、流動，親手送走它，「 認同來自於親自動手 」越是從你手中付出越多，賦予這張便利貼的價值就越高，當責的觀念也就慢慢形成。 每張便利貼(TASK)就是你的焦點，我們要奮戰完成、解決它。 信念(why)： 團隊越認同TASK價值，會更加相信自己做的每件事屬於團隊，勇敢朝目標方向前進。所以知道任務意義，不僅用來提高價值，也知道為何而做。當有了信念，通常不會輕易放棄任務，使命必達。如同你現在上班工作，其中之一原因是讓家庭過快樂的生活，形成驅動力。 如 Scrum指南 提到：「 當 Scrum Team 體現和活化承擔，勇氣，專注，開放和尊重這五種價值觀時，Scrum 的三 根支柱：透明性，檢視性，調適性就會出現並幫助大家建立信任。 」，這些精神，其實都被落實在每個活動中。 「 這是一個用來做為檢視和調適的重要關鍵會議。 」，沒錯， Scrum指南 中提到，實際運用也是，更多人用"照妖鏡"來形容。很重要、很重要、很重要，所以千萬別在還沒準備好前，就貿然開始Daily Scrums，否則整個敏捷容易失焦而被摧毀。 Daily Scrums中提到的回答問題範本：昨天、今天、障礙，是一個很好的起始點，但不是絕對只能這樣講，要注意的反而是這三個問句的意涵，SM必須看運行後的狀況，適時替團隊找出最舒適語言來進行團隊溝通、任務檢視。 如果大家一開始講不順暢或講了也跟現實不符，SM就要開始檢討該如何改進。譬如說，漸進式的先講一個重點，只先講做了些什麼。再則引導提問彼此的任務的關聯影響，昨天、今天的任務跟誰有相關，會後再

【Scrum第一次Planning meeting】 第一次的敏捷新嘗試不用太期待會有多完美，抱持敏捷精神"先有目的做、再調整方法修、持續改善"，調整到符合這團隊的特性、節奏。依此專案經驗，大概也是花了半年，團隊才買單，也開始進行自主管理。 前八步的準備作業，團隊開始有共識、目標，且資訊要足夠能想像出第一個MVP樣貌，這兩項備妥後，就可以來做第一次Planning meeting囉! 大致步驟如下 1. 移動" 任務階段索引圖 " 2. MVP流程圖 3. 拆解任務 任務階段索引圖： 與大家宣告，我們要從"探索發現"進入下一階段"概念設計"，並再次確認大家對於自己的項目是否已經有一定的了解，都沒問題後，就把箭頭移到下一階段囉!也是個宣告開始。 MVP流程圖： 搭配 Story Map 討論與分析，並畫出系統流程圖或分鏡圖，利用視覺化畫在Scrum Board旁，讓開發成員的想像一致，才不會寫任務時，方向又跑掉。 為了讓大家接觸到新嘗試"敏捷"不這麼反感，所有的時間和細節最好有所設計與掌控。譬如說，第一次的Planning meeting聚焦在，熟悉拆解、看板、便利貼Task，並設計好該如何讓團隊成員想像去拆解任務，控制在1.2小時內最好，良好的體驗才能讓活動持續下去。 Task便利貼描述，也是用最容易上手理解方式就好，時間也暫時用經驗導向去估計。大原則，焦點放在體驗、理解、吸收，而非一次到位。在則，如果要使用故事點數去做，花費的時間成本與效益也是要考慮。如果專案完成時間本身就不是要100%精確，那大可放低"估計"行為，專注在回顧會議再來檢視，為何預估的時間比預期的多或少，修正下一次更好。 到此時，並沒有特別導入User Story，反而是讓團隊成員漸進了解敏捷框架內涵。此次就先依團隊成員最熟悉的方式，直覺地用自己的文字描述寫下任務、預估時間就好，讓看板和價值流先呈現出來，再視未來情況調整。 結論： Scrum指南 「Scrum Master 依照 Scrum 指南中的遊戲規則來負責推廣和支持 Scrum。Scrum Master 幫助每個人了解 Scrum 的理論，實務，規則和價值觀，來

【Scrum團隊目標共識】 在進行 Sprint 1 前，SM必須確定已經有足夠資訊(不用完整)，至少可以讓每個人規劃出第一次Sprint的Task。而環境上，也可以先把最基本款的Scrum Board貼上，讓一切看起來蓄勢待發，就差一個宣示來點燃起點。 (不要怕看起來空空，即使是個形，視覺上會讓心理產生預期反應) 從剛接任務到蒐集資訊過程，團隊應該都在忙於摸索階段，還沒真正的共識過"我們要一起做什麼"，都還在各自大腦的想像內。此時身為SM需要把這抽象的命令與想法具體化，團隊才會朝向同一方向邁進目標，不會走歪。 如同運動競賽，需要靠一聲響亮哨音，大家聽到了，才會在同一個瞬間一起反應，奮力向前衝刺，而 身為SM 可以靠一份簡報來鳴槍，告訴團隊準備啟動囉!! 第一張可以小小的調皮一下，放一下大家的心情寫照，緩和一下嚴肅的內容!! 簡報內容大致如下 1. 目標 2. 使命 3. 步驟(接下來會面臨的階段) 4. 成員 5. 時間 6. 影響 步驟： 為了讓大家對於陌生的敏捷流程有所依據，會在此先簡介一下未來會有的"動作"，例如MVP、User Story Map、Review、Burndown Chart、Planning....等等，先讓大家有個概念就好，不用花太多時間講細節，焦點還是要在"鳴槍"，也可以稍微談到一下未來可能有的規劃。 其中"執行發展"可以提一下Scrum的會議週期和方式 每個會議時間照團隊目前狀態去調整，例如，通常越有明確資訊可以細談拆分到規格的話，時間會花得越長；有限資訊下，就先放個大概的短時間。記住，重點是要先了解體驗再修正，而不是要一次到位，Planning meeting就得跑好跑滿>3小時，跑過一次後，任誰都不想再來第二次。 其次，如果團隊時間允許話，可以在回顧會議之後，放個Relax，我稱為3R。目的是讓大家有短暫的"自我消化、修復"時間，也以透過活動來增進大家凝聚力，如桌遊、電競....等，效過很好，尤其是真的在這次Sprint用盡全力在衝的人。注意一點，不用每次都一定要Relax，視團隊情況，有點犒賞、激勵意味。 成員： 就是前幾

【Scrum第零次回顧會議】 承上篇"故事地圖"建立後，並沒有馬上開始進入Planning meeting跑看板，而是刻意漸近讓企劃人員(PO)先熟悉與了解觀念，SM再視團隊情況調整作法。 當然前提下，還是要有時間允許一步步導入，最好安排在專案開始前一個月(Sprint0)，先不要進入專案執行狀態。在Sprint0的狀態，讓團隊先依照現有技術與資訊做研究與開發，不要輕易貼上便利貼，讓要 便利貼呈現價值感 ! Sprint 0的狀態主軸是放在PO身上，其他團隊成員抓到機會時就講些觀念。譬如PO在同步資料的會議、技術討論、議題討論時，很多機會可以引進觀念，讓團隊在淺移默化的環境中敏捷，倒也不必刻意一直強調!! 既然有Sprint 0就會有Retro. meeting 0，焦點也是放在PO身上，因為PO與需求一不對勁， 長鞭效應 就會開始出現，尤其是不確定感和不信任感越會被放大，到時團隊也只是坐在一起的一群人而已。 「 只有先規畫可預測的部份，未來才更有能力去處理不可預測的部份 。」 針對第零次回顧會議重點以下 1. 解除企劃(PO)的疑慮，如上層無法加入討論 2. 解除企劃(PO)對敏捷的想像，如一起討論出規格.... 3. 敏捷觀念、框架的解說 4. 聚焦在 故事地圖 ，目前資訊是否足夠與修正調整內容 5. 還缺少哪些資訊需要先同步才能開始Planning meeting 在這裡所謂的足夠，並不是指完整，而是檢視 故事地圖 的整體內容，PO覺得心安的狀態下，且目前也沒進一步要蒐集的資料後，SM判斷可以開始進入Sprint 1，即可結束Sprint 0。 來看看 Scrum指南 中SM對PO的服務 結論： PO在上篇簡報同步現有資訊後，團隊依據資訊做研究與開發，這也是團隊第一次接觸到"故事地圖"，但沒有拿來做Task拆解，正式的第一次Planning meeting則放在1~3個星期後，一來是讓資訊足夠，二來是下一篇的"團隊使命"共識完後再開動，畢竟這專案是長期專案，基礎打好再上，團隊會更紮實應付每件任務。 其實，SM心中有敏捷信仰，自然會找到對應的方法做，例如鼓勵討論、互動、共識出可用軟體的想像(資訊同步會議)、刻意不用電子訊息溝通、親自過去或抓人一