黑先生

【看板方法導入 PART 2 - 看板建置】 繼上篇 【 看板方法導入 PART 1 - 問題發現與現況連結工作坊  】讓團隊認同也發覺問題後，原本的計畫是接下來就由他們親手打造自己的看板，失敗中持續修正成符合自己的開發價值流與節奏，就如書上所說得，先求有再求好，持續回饋與改善。 果然，團隊整體上下很積極有效率的在隔天做出個看板原型，並打算在過年後馬上試用，讓人深深覺得有感受到他們的用心。不過在看完他們的看板樣貌後，眉頭深鎖一陣子，讓我深深的擔心整個過年。 經過一個過年放假思考，決定改變做法。畢竟自己是在公司內部推行敏捷，不是真的以外部講師講完看板後，交由團隊自行發展。所以就更進一步自薦當貼身教練，陪伴一起改善，更體會到，變革還真的需要一位教練在身旁，心安也會讓事情比較順利的進行，降低了變革阻礙感。 到這裡我們先來分析一下目前情境下的背景資訊， ●此團隊30人 ●各職能都有(需求與執行)， 一個BU單位 ●需求常配合市場、需求、意外做變動，開發算混亂 ●第一次接觸新概念敏捷運用 ●團隊內沒有專門負責看板導入的角色，也沒有較多此經驗的角色 ●開發很彈(怨)性(念)，具有非常大的挑戰 ●資深人員也佔一半 提醒，在公司推行時，千萬要記得去分析一下此團隊的背景，以此次經驗來說，可以的話，直接參與協助過程會是最佳解。 一來是他們的狀態需要近程勝利來自我激勵，持續變好， 二來是資深人員佔一半以上，不至於難互動，稍微點一下，後續再交由他們接手發揮就行。 當然，可以這麼做還有一個很重要的元素，我自己在公司也有一段時間，對於此團隊的開發流程和文化有一定概念，大概知道要怎起頭，要怎麼做看板價值流。畫了張看板後與主管討論，看是否需要修改，並告訴做這些的目的和接下來的步驟。 目的： ●效率提升 、 bug變少 、 系統穩定 (看板不能做什麼) ●Slack Time(盈餘時間)，最大效益、改善任務 ●資訊同步(內部、溝通、認知對齊、避免穀倉效應、優先序排序、"反應") ●自我組織 ●系統思考 到目前為止還算順利，不過在這次經驗中越來越發現到， 看板只是個誘因，利用看板來打開團隊的心房願意嘗試改變、願意展開有效的對話、願意做出真誠的互動 。 雖然說看板方法對於效率改善有幫助，但顯然不是此團隊目前焦點，反

【看板方法導入 PART 1 - 問題發現與現況連結工作坊】 在進行一場變革前，如果是對方已經有痛點而發起改變，通常大家會比較開放心態願意、也容易進行。但如果是大家都並不覺得需要改變的話，那你在強行推銷，嘴巴說破，大概也沒任何反應吧。 以此次經驗說，是主管覺得需要，所以想試試看板能不能改善，可是此心意並沒有傳達到members。也就是說，members可能覺得沒必要，說不定還覺的擾民產生反感。 如何解? 心理學中有個" 宜家效應 "「 指的是消費者對於自己投入勞動、情感而創造的物品價值產生高估的價值判斷偏差現象。 」 換句話說，就是 讓他們有"付出、投資"成本 ，可能是時間、勞力、心力、討論...等等，付出的越多，未來越是會積極參與過程，讓"他們的事"轉換成"我們的事"，心態轉變會是這次經驗很重要的起手式。 那要怎讓他們做"有效的付出"呢? 我的方法是在導入看板前，讓他們自己發現、確定真的有問題需要解決，喚起自發性想改的意願，再來講主題-看板。 手法很簡單，如同一般工作坊，例如看板體驗坊，透過遊戲化的方式，讓參與者先對看板有些概念，再來思考套入到自己的現實情境做應用。不過這種方式，也通常是主動去外面參與相關工作坊，對於自己不覺得有問題的人，此招可能不適用。但核心精神是對的，就是透過遊戲化體驗，讓參與者"付出"成本，提高未來的參與度。 如果沒有動機可能連最初的第一步都踏不出去，所以面對此案要做的是" 問題發現與連結現況工作坊 "去激發他們的動機，讓大家知道原來自己真的有問題，剛好這裡有一套看板方法可以解決，請拿去用。沒錯，這就是黃金圈的核心，先知道Why，再了解How，最後的結果What來持續修正。知道自己正在做什麼，也會讓自己的投入度提高非常多。 事情到此用看的通常都很理所當然，廢話，這還用特別說，但通常沒遇過，有時還真會忘記先這麼做。所以， 上一篇的訪談 很重要，了解目前團隊狀態做出適合的行動，也在訪談過程中，有時間去思考下一步怎做會更好。 再說個背景資訊，此團隊是30人，所有職能都有，也有Leader角色，在已經知道要讓他們發現問題的行動下，下一步會怎做呢?對全部的人做工作坊?

【你不需很厲害才能開始，但你必須開始才能很厲害】 前一陣子較常接觸到工作四、五年的同事，他們大多有個現象，就是不知怎跨出"邊界"。這跟舒適圈有些不一樣，他們願意踏出，但似乎有條隱形線在地上，而自己就被那條線給限制了思考，甚至會在乎那條不存在的線，莫名的區分這裡、那裡。 這些同事都有個特徵，寫產品專案的技術與能力都有一定的水準以上，很少出錯也能如期如質完成交辦任務，對於自身的事總是能處理好，團隊內的溝通、互動也不錯。一但跨出了自己這個邊界，就開始不知所措。 舉個例子，主管覺得同事A能勝任一個跨團隊任務，也該是時候成長，交辦一個與其它團隊會有一些溝通、互動與合作的任務。到這步客觀來看，主管都願意授權、嘗試讓同事A去執行，某種程度也是信任他能完成，但同事A卻自己困住了自己。 同事A開始 ●擔心自己能力不足、 ●別人會不會不信任我的專業、 ●對於沒有碰過的事感到不安、 ●自己這樣做對不對、 ●沒有經驗不知如何起手、 ●講話夠不夠力、 ●開始替自己畫框框，自我設限。 這情況還不只出現在同事A，同時也出現在同事B和C，難道是這世代的現象?因為資訊爆炸時代，停留在選擇狀態，遲遲無法決策進入行動?還是有其他因素? 醫生在下藥之前，總是要知道病症才能開藥，所以我們先試著來了解怎麼了?再來想該如何解決? 我們從二個心理學來試著解讀， 一、 定勢效應 ：「 人們因為局限於既有的信息或認識的現象。人們在一定的環境中工作和生活，久而久之就會形成一種固定的思維模式，使人們習慣於從固定的角度來觀察、思考事物，以固定的方式來接受事物。 」 似乎合理解釋，大多數人面對新的任務或挑戰，往往不加思索地慣用以前經驗來處理，卻忘記面對的是全新沒接觸過的狀況，然後碰壁了，就開始懷疑自己感到不安。 二、 詹森效應 ：「 是指人們由於受到某些因素的影響在關鍵時刻不能發揮自身水平的現象。 」有一名運動員叫丹•詹森 (Dan Jansen) ，平時訓練有素，實力雄厚，但在體育賽場上卻連連失利。人們藉此把那種平時表現良好，但由於缺乏應有的心理素質而導致競技場上失敗的現象稱為詹森效應。 有了些微不順挫折感後，心理開始影響生理，無法有進一步發揮與行動，停滯在原地，還在不知所措的狀態，也忘了求救。 既然已經知道有些這種現象，那就很好一一破解

【看板方法導入 PART 0 - 情境體驗、資料蒐集與訪談】 當你在公司內部把敏捷開發成功應用在團隊後，自然而然產生口碑，開始吸引其他團隊來參觀借鏡，並且也躍躍欲試。這時後就是最好的行銷敏捷理念時機，通常強行推銷的效果不好，大多以自己發生痛點並想要的成功機率大，也較願意開放心態去做些改變、嘗試。 當別的團隊開始來找你協助導入時，如果剛好你手上有現成已經在跑敏捷的團隊，安排他們來參觀適合的活動，讓他們在腦中的想像和實際不致於落差太大也期待太高，也會比較有概念來做進一步討論，雙方是在相同頻道上，而非雞同鴨講。如果沒有的話，則可以透過看板工作坊體驗，來對看板先進行了解，再決定是否進一步討論。 雙方對看板有一定概念與共識後，就可以做詳細的諮詢，如同醫生看診，先好好了解病人症狀(背景)，如有需要再安排檢查，然後進行治療。千萬不要僅僅只聽到片面幾句話的描述，就把所有的情境與問題都自行腦補完，確診然後進行手術，這樣太可怕了，病人也可能因此有些不安、不信任。除非你是經驗非常多的教練，否則我們還是一步步漸進變革囉! 所以，不要輕易草率行動去導入變革，那影響的是一整個團隊成員，一但失敗，第二次要再敏捷，抗藥排斥性會很大。不管是看板方法或是Scrum，照著形式跑相對容易，因為都有清楚框架使用，但難的是背後核心精神要讓大家領會，才能長長久久，自主進行。 要去知道 黃金圈 最內層的Why，不要輕易把最外層的what帶入，那通常也是最簡單的一環 。 什麼叫輕易、草率? 實際案例上，可能會有團隊先執行站立會議，但還沒準備好看板，認為這樣至少可以先做好溝通，反而讓大家只有"罰站"的感受，不見得願意好好在站會中好好講，不真誠開放的溝通等於沒有；其次，溝通也落於抽像、空泛，比較像是被迫式的下對上報告。如果這樣有用，那何必還需要特別聚在一起講，早就發揮作用囉。 我做的前置步驟  -  資料蒐集： ●邀請參觀站立會議，讓他們知道為何而戰(站)，站只是為了之前的付出(需求規劃、討論、評估、承諾)做檢視、調整而已 ●與團隊主管安排五次的訪談，剖析原因與狀況，看是否是看板能解決的。 →給予看板概念 →什麼能解決，什麼不能解決 →五次的訪談大致的主題，每次一小時，使用ORID討論法+康乃爾筆記     ◎目前狀況討論     ◎實際案例探討  

【機會有時候比實力更重要!!但你要懂得把握】 最近有位離職的A同事面試到總監位置，對於現在的他來說，等於是直接連跳了三級，既是期待又怕受傷害。所以來找吃飯聊聊，有沒有相關經驗能建議。 這位前同事也是我曾經帶過的，很有想法、個性但總是自己來，雖然算是有潛力但沒有用對方式，職場上沒能好好發揮，有點可惜。不過秉持著助人與惜才的心，就赴約聊聊，並把過程中的談話做摘要分享給剛好有此機遇的人囉! 同事A話一開始就問我，想了解當主管的經驗。從這句話就知道，嗯，他真的還沒準備好，不過沒關係， 機會有時候比實力更重要 ，只要記住讓自己在過程中成長就行。 我做了發言權的調整，先稍微問一下他目前的背景(面試、公司、團隊、老闆、工作、期待...等等)，摘要一下情境： 公司20人團隊，老闆想請他從無到有建立出美術團隊，以往都是外包方式進行，現在想整個風格轉換。 光這個背景分析就很有趣，原本A同事想請教的是如何管理，如果就如他想要聽的主題，太多也太廣，沒親身經歷，講了也是淪於"別人的故事"，聽了就忘了。既然知道背景，那就分析二點給他，讓他好好先做好這二點再說，講太多也會忘記。 情境背後包含以下幾點需進一步了解- 公司20人團隊 ： ●老闆的產品期待?  →有賺錢的產品才會有編制，產品未來的收入發展、考量，能規劃出幾位編制、能力的團隊 從無到有建立出美術團隊：  ●老闆為何想建立自己的美術團隊?  →期待的目標(產品相關、技能專業、成本考量、未來團隊與成員發展規劃)? ●老闆對團隊期待?  →國際水準還是有一定的容忍度，可以慢慢訓練培育，或是到時取代或擴編? ●自我規劃，初期比較像專案管理，要很清楚自己要有哪些資源才能達成 以往都是外包方式進行 ： ●老闆為何想從外包變成內部?  →外包在目前配合情況是不是有困難(工作模式、期限需求、成本考量、人員配合)? 現在想整個風格轉換 ： ●期望日期，決定要多少專業、人力來支撐 ●自我定位，自己的領域上的專業如果不一樣，該扮演怎樣的角色與召募怎樣的人才做互補 ●最重要的還是 - 美術與目前工程師工作的預期的流程開發方式  →這點通常被忽略也是與日常關係最大的，建議要花時間溝通未來雙方的合作模式，工

【Scrum過程總結】 ~團隊專案過程~ Scrum觀念：便利貼 Scrum第零步：團隊發展階段模型 Scrum起手式第一步：團隊建立Team building Scrum起手式第一步：團隊建立Team building - 番外篇 Scrum第二步：角色定位圖 Scrum第三步：敏捷中角色定位 Scrum第四步：任務階段索引圖 Scrum第五步：目標探索-資訊同步 Scrum第六步：故事地圖 Scrum第七步：第零次回顧會議 Scrum第八步：團隊目標共識 Scrum第九步：第一次Planning meeting Scrum第十步：第一次Daily Scrums Scrum敏捷小遊戲 - 翻硬幣 Scrum第十一步：第一次Review Scrum第十二步：第一次Retrospective meeting Scrum第十三步：第二次Planning meeting Scrum遊戲化體驗-用戶故事地圖 Scrum第十四步：第一次Refinement meeting Scrum第十五步：第二次Review meeting Scrum第十六步：第二次Retrospective meeting Scrum第十七步：第一次Relax Scrum第十八步：持續迭代衝刺 Scrum第十九步：流程聚焦討論-ORID Scrum第二十步：遊戲化體驗 - 先處理好心情，再處理事情 Scrum第二十一步：棉花糖挑戰 Scrum最後一步：年度回顧+願景圖 Scrum過程總結 - The Great ScrumMaster 上面的列表是有時間順序，也是真實在跑Scrum的過程紀錄。從列表清單來分析，使用Scrum框架並沒有太多問題，大概就是遇到，再來修正看看要如何符合自己團隊特性，讓團隊自己跑起來比較順利，也是敏捷核心精神，持續改善(一切都不是問題，只是反應。一切都是過程，不是結果)。 嚴格來說，反而是在" 人 "，花的時間多上很多。28篇文章，其中18篇是在"共識"，也是在降低變革的阻礙感。如同黃金圈，當你越清楚WHY，你就越容易進入狀況去投入參與。 個人經驗，SM越是做好僕人的角色來服務團隊，越能讓團隊成功運行。 以下歸納出幾個點 ●僕人觀看事情的角度會較"低&q

【Scrum年度回顧+願景圖】 團隊跑敏捷到最後，團隊真的進入神馳狀態，每個人不僅僅對自己負責，也對他人負責，呈現自我組織狀態，團隊也進入到《Tuckman團隊發展階段模型》中的 - Performing表現期： 人際結構成為執行任務活動的工具， 團隊角色更為靈活和功能化，團隊能量積聚於一體。 ( self-organized teams work 、 自組織團體 ) 那怎麼觀察到這現象呢? 目前我的感受到的現象是，發覺SM需要出現的機會越來越少，甚至會在每個會議中，默默在團隊後面拍照紀錄，有心滿意足感覺。大多是在觀察和紀錄狀態，視狀況再給適當建議和活動。 在此分享我最後的活動! 團隊跑了半年，剛好在年底有機會做個年度回顧活動，也順便把團隊的信念強化成視覺化願景圖。 準備 ●過去團隊所有歷程照片(這表示從一開始敏捷就要做紀錄，才會有照片素材，是紀錄也是自我檢討) ●照片輸出，一張張貼在牆面上成回憶牆 ● 5步驟大膽行動願景圖 (此篇介紹的很詳細，在此就不多說明) ●年度簡報(摘要過去的重要、指標事件，並講訴核心精神，做個回憶與經驗內化的動作) 大致流程 ●用簡報稍微替團隊喚起回憶與經驗內化 ●簡報裡面會加入要引導的主題、概念，讓最後的願景被鋪陳出來，例如團隊文化、自我組織、學習型組織、需求層次理論、黃金圈、別人的願景...等等 ●簡報完後，請大家到回憶牆面前，感受一下過去發生的歷程 ●邊感受邊用便利貼寫下感想，貼在照片的附近 ●最後把所有的想法形成後，再進行願景圖討論 (簡報內容之一，關聯與鋪陳願景) 團隊長期專注專案的敏捷執行，一直衝刺真的很累，如果沒有過人的意志力，時間久了也會疲乏。為了讓他們產生源源不絕的動力，願景圖運用的時機很重要，端看目前團隊狀態，是否需要使用來強化目標信念。雖說不是Scrum範圍裡，但用"願景"適時的替團隊充滿電力，持續到產品上線，個人認為是一個很重要的策略。 (回憶牆+願景圖) 結語： 願景圖不會是在一次活動中就可以大家共識出來的。在後期的開發中，可以讓團隊有個核心價值慢慢成形，再找時間具體化就行囉! 當然，不是非得要有願景，看公司和團隊狀況囉!(我負責的成員剛好都是資深，且本身就有想法與意願，所以才有機會使用到) Sc

【Scrum遊戲化體驗 - 棉花糖挑戰】 當敏捷在團隊中跑了一陣子，大家對敏捷精神不陌生，此時來個團隊遊戲，透過遊戲的體驗，讓枯燥的專案執行期增添些活力與動力，是個不錯選擇。當然，其中對增加團隊凝聚力加分效果也很大。 玩活動前，先來"正名"一下什麼叫做「 遊戲化 」，替上班偷玩的感受找個好理由(請自行評估是否在上班時間玩囉!)。建議，當我們面對的人越是資深者，通常越要說明清楚用意與背後意義，讓對方知道為何而玩。反之，如果面對的是剛出社會或經驗不多的人時，可以斟著要不要說，讓他們好好享受的體驗也很好，有時資訊太多，不見得是件好事。 維基對 「遊戲化」的定義： 指一種在非遊戲的領域中，採用遊戲設計元素和遊戲機制，使當局者能用以解決問題並曾進當局者的貢獻力。 雖然說是遊戲化，但其實對主持人來說一點也不輕鬆。除了要先規劃目的和順暢的流程，心中更要有預期效果，好讓在遊戲結束後，觀察是否和自己想要的一致，做好每一次的調整，讓下次更好(也是敏捷精神)。 而我自己通常安排這類活動則是在" 有需要 "的時候，那什麼叫有需要呢? 就是 觀察目前團隊缺好了哪些元素、活動、精神、或疲乏了，可以讓專案或團隊進行的更順利。 以此為大原則去安排適當活動，都會有大大效果。 說明完後，就來好好的放鬆體驗下囉! 大致流程 分組：每組4人 道具：每組棉花糖一顆、90公分棉線、90公分膠帶、20根義大利麵條 時間：18分鐘 要求：在限制的道具與時間內，搭建棉花糖塔，棉花糖必須在塔的頂部，測量的高度為棉花糖到桌面的距離，最高者獲勝。 注意：棉花糖不可破壞、義大利麵可剪斷，如果不小心折斷可以換新的 每隔五分鐘提醒一次、最後三分每隔一分鐘提醒一次 ( 棉花糖挑戰 ) 以專案來說，如果真的是在跑Scrum的團隊，理論上，每次都在Sprint短跑衝次，是很緊繃累人的，適時用遊戲來充電，會讓團隊下次的衝次更有精神，就看是否在對的時機要去投資這時間成本囉!重要的是，不要忘了針對目前團隊狀況去挑選、設計遊戲符合此團隊個性，玩起來的整體感受會更好。譬如說，如果團隊溝通狀況不好，可以玩玩「 你說我畫 」的遊戲。如果要彼此認識更深，就玩玩自我介紹、心理測驗型遊戲。如果默契不夠，有許多團康遊戲都可以去玩看看。

【先處理好心情，再處理事情】 在工作或生活上，多多少少會遇到不如意的事，而產生出相關的情緒表現，心理抽像層-心情，也很難用口語文字表達清楚，更不用想要去好好處理事情了。 在此提供一個有趣的視覺化溝通方式，讓大家能好好表達心情，也能好好處理事情，更可以進一步做出決策產出行動方案。這方法屬於我自己誤打誤撞玩出來的，目前實際帶過三個團隊使用，效果都還不錯，但還是請自行真對團隊狀況，調整使用喔! 說明活動前，先講個很重要的前提觀念，引導學:「 所謂的問題，就是理想與現實間的落差。 」 心情某種程度就是自己的"理想"，自己心中的美好預想狀態為何沒有實現。慶幸的是，大多數人很擅長描述自己心情過程，可以講很多但可能都不是重點，也不容易自我察覺到底哪裡出了問題。所以呢，可以透過別人的傾聽，替自己的描述加入客觀觀點，讓自己能發現可能有問題的地方在哪裡，這樣才有機會進一步去修正。 而這個方法就是利用ORID焦點討論法，來替自己心情拆解，用有效的思考框架，替抽象的心情具體化。 好了，現在就讓我們來用「心情」+「ORID焦點討論法」來抓問題! 文具準備 ●每人一張A4白紙、一支黑筆 ●ORID海報 ●O(黃便利貼)、R(紅便利貼)、I(藍便利貼)、D(綠便利貼) 大致流程(以專案開發為主題例子) ●每位畫出屬於自己的心情圖，可以是曲線或是任何圖形，能夠代表你在整個專案過程的心情 ●每位針對自己的圖形做描述說明，並貼到ORID海報附近 ●其他聽眾則根據聽到的描述，一半的人寫下O，一半的人寫下R，並貼到ORID海報底下 ●輪流分享描述，也輪流寫O或R ●分享完後，請大家針對所有的O與R，各自靜默或者是分組討論解讀出I ●I有了後，相同的方式進行D(如果是各自的方式解讀出D，則需要再投票或討論做最後收斂) ●D有了後，則看看要如何執行 觀點1 對於初次介紹或認識ORID的人來說，一次要會運用四種不同的角度來思考事情，還真有點難入手。透過主題活動，大家可以一邊練習傾聽，一邊用一個觀點(ORID的其中一項)專心感受，並寫在便利貼視覺化，讓當事者了解。透過這樣的"分享回饋"知道彼此的觀點，原來別人是這樣看自己的事情，通常會產生出更多想法。 觀點2 心情比較適合用圖形來表達，不用太擔心畫不畫的出

【Scrum流程聚焦討論-ORID】 當團隊已經執行過2~3個Sprint後，應該開始累積不少困惑和問題，但可能無法很具體說明清楚，那就有點浪費之前努力了。這時後，最好把腦中抽象問題概念化後，用紅色便利貼貼到回顧改善的海報欄位，讓事情持續變好。 也許你會有些疑問，不是有回顧會議在做持續改善了嗎?難道這樣還不夠? 據經驗來說，還真的不夠，原因是回顧會議初期在跑的時候，焦點容易放在"任務執行過程"的檢視，屬於局部。再來是群體討論，容易發散討論不出結果。如果在會議中，又加入全局流程思考，那可真要有十足的功力才能做好相關的引導。所以個人比較傾向一次一個焦點來討論、發現問題，不要全擠在同一場會議，最後會容易失焦，流於無效想法，產出無效行動。 所以呢，獨立再拉一場流程聚焦討論會議，讓大家當下討論的焦點放在全局，用較系統思考方式去想想，我們到底發生了哪些卡卡反應與問題，需要如何解決? 這樣，會議的引導與設計會相對單純，團隊也容易進入 參與式合作討論場域，大家一起來想辦法解決問題。 該如何做呢? 「 ORID焦點討論法 」會是很好用的方法，以下寫出大概的步驟 目的:     針對大型複雜的項目作聚焦討論，並進一步產生行動方案 過程:     開發流程通常是很抽象複雜的項目，如果要大家討論其中哪個環節需要改善，通常會無法聚焦思考 。透過流程圖海報 。由主持人描述流程階段，並稍做停頓讓大家思考與動筆寫下描述 。請大家先用 O(客觀、事情)，每個人寫下看到的客觀的事情 。流程全部描述完後，便利貼也全貼到O欄位 。在請大家根據O，去寫下有共鳴的R(情緒、反應) 。R寫完後，在請大家根據O.R寫下詮釋內容 。最後根據ORI寫下行動方案D (O分類前) (O分類後，讓事實更聚焦) 好了，現在讓問題浮現出來，也產生解決方案了，但另一個問題是，能不能解決或改善，又是另一項挑戰。所以不要忘了還可以去" 找大神 "來協助喔，不一定要自己花很多時間與精力摸通，也造成團隊變成白老鼠，讓大神來縮短團隊的不適應、痛苦期，也是SM的責任。 SM有時候千萬不要太糾結於「 沉沒成本 」(人們在決定是否去做一件事情的時候，不僅是看這件事對自己有沒有好處，而且也看過去是不是已經在這件事情上有過投入。)

【Scrum持續迭代衝刺】 先來回憶摘要前面幾篇講的內容， ●團隊Team building ●相關輔助資訊     角色定位圖     便利貼     角色定位     發展階段模型     故事地圖     團隊共識與啟動會議 ●團隊活動     翻硬幣     用戶故事地圖     Relax ●Scrum     Planning     Daily     Review     Retrospective     Refinement 雖然團隊是自願要跑敏捷，但對於變革過程還是多少有些不適應，既然已經知道變革過程- 薩提亞變格模式 會有哪些反應，那就先做好相關準備再進行，混亂階段會縮短很多。如同醫病關係一樣，當醫生有告訴你接下來會有哪些症狀、做哪些治療，我們都會較容能接受後續考驗，甚至正向面對。 後面迭代就差異不大，我就抓幾個重點來說。 我們是採用「 由下而上 」 的方式，慢慢了解與演進成Scrum，把握這大原則，讓大家了解Scrum每個元素的意涵後，再「由上而下」正式的整合所有元素進行Scrum。 提供一開始的計劃給大家參考囉! Sprint 0:觀察與準備 Sprint 1: 了解Scrum會有哪些產出、角色、會議 Sprint 2: Task更新同步狀況熟悉、AC驗收標準、DoD(養成習慣為主) Sprint 3: Task準確性(由下而上寫出 Story、Feature)，同理心角色的切換、換位思考、商業價值、Burndown精確 Sprint 4: 由Feature > story >Task 列出，精確 Refinement 。Planning進行前，先與PO確定，是否有足夠的資訊可以進行規劃，有的話，再討論預計Planning的流程 。檢視與調整 使用者故事地圖(排序與挑選出Planning中要執行的需求) 。轉換成User Story的開放思考描述句(視團隊狀況，越成熟的團隊越適合。不過倒也不是絕對，初期以熟悉的方式為主) Planning 。過程中，先請PO講解這次衝刺需求單，大家討論理解後，開始進行拆解出Task 。如果是沒做過的產品或技術，初期可以進行預估點數，否則大多是以"信心點"(依個人過往經驗來推算)來做估計