敏捷麻瓜奇幻旅程Scrum從0~1（III）：正式開跑Scrum後，各階段我所踩的坑
Scrum團隊成員不要頻繁異動之必要，這是我所體悟的心得。原因是，Scrum團隊是很依賴「默契」這個隱性特徵上，一開始初跑Scrum會很卡沒錯，但當隨著時間紮實的進行PDCA後，Scrum團隊的效率會開始顯著的發生，對於任務拆解、估時拿捏會開始有默契。但導入Scrum要可以忍受前期可能要半年或是1年的不效率甚至是沒有高價值產出的陣痛期，才有可能看到Scrum文化的開花結果，不然，往往還沒挺過去，Scrum就陣亡了。
我對於堅持Scrum各流程都要努力嘗試走完的必要，就是來自於好的結果，都是來自於上一階段、上上一階段、上上上階段的付出，這些階段都是環環相扣的。當完全熟悉正式的流程與方法論後，才是開始可以依據團隊的調性，來排除不必要的階段，又或是去創造/調整屬於團隊的方法論。當走到這個程度，Scrum的內功，某種程度才是真正的開始要在公司發揮效用。
【Product Explore】
產品探索&發想會議，基本上沒有在Scrum的框架中，但我認為適時的把這個階段放入團隊中，對於凝聚開發共識是有效果的，往往有些想不到的產品發想，都是出現在這樣胡說八道的會議裡，以及團隊可以一起走過從點子生成到落地的整體過程，無形之中可以達到為什麼而做、為誰而做的共識。如何衡量導入的時機點，可以是在產品主要的項目都衝刺到一個階段，即將要開始去發想下一個階段的產品開發方向時，或是在規劃年度產品地圖的時候，可以帶領Scrum團隊一起進行產品初期的腦力激盪會議。以下有幾個坑需要避免：
‧團隊文化：在進行產品探索&發想會議，團隊文化會是影響做的好與不好的重要因素。如果團隊的成員相對被動(組Scrum團隊的特質)，或是在會議中持續用自已的筆電做自已的事……等，這就會變成PO自High的發想會議，這將會影響點子產出的品質。如何，主持一個好的產品探索&發想會議，除了PO本身的心理素質要有外(對產品的熱情；你不尷尬，大家就不會尷尬。)，還需要會議前的準備，例如如何先協助團隊破冰、放下戒心、鼓勵參與、場域環境的設計……等。可以參考這本書《Facilitation引導學：創造場域、高效溝通、討論架構化、形成共識，21世紀最重要的專業能力！》
‧高階管理者：建議一開始不要有高階管理者加入發想會議，除非大家真的可以100%對參與會議的高階管理者沒有「需要謹慎發言」的心態。老實說，以目前的觀察，當高階管理者一進入會議室，氣氛整個就乾尬了起來(這目前我也無解)。
‧產品PO：PO在主持這樣發想會議，前期引導非常重要。要如何讓大家可以進入狀況，或是進去那樣的心情，都是在會議前期的準備所需要考量到的。對於會議後的點子產出，產品經理的職責就是要將這些想法進入到所為的「產品開發優先順序的框架中」。產品經理要如何評估產品開發的價值與產品這是非常重要的，以及要如何扣緊公司的營運目標，或是利害關係人的目標。如果，這一階段，產品經理無法衡量產品的產出價值，將會是非常非常的失職（這個手感我也持續在學習與練習中）。
【Refinement meeting】
在進入Refinement meeting階段，已經不是在發散的腦力激盪，或是相對空泛的討論產品規格。這個階段，基本就是在非常～非常具體的討論團隊接下來要做的項目，再一次的聚焦以及排解各種可能在Sprint發生的問題。例如：在Refinement的時候，RD就可以先反應那個Story的規格可能會需要單獨一個Sprint，又或是這個Story會需要跨Scrum team的協助(高耦合度)，又或是在Refinement的時候，就可以先確認產品規格是否有符合「利害關係人的預期」、「公司的策略目標」。在這個階段做的好，其實在Planning meeting的產品規格就會相對落地，RD估時有就會相對準確，估時準確，產品順利上線，團隊的信心就會持續上升。以下有幾個坑需要避免：
‧利害關係人管理：在這個階段強烈建議一定要找利害關係人加入會議達成產品開發共識。原因是，在Sprint的週期，我們很常碰到來自「利害關係人的對於產品規格的關心」，這樣會導致，團隊必須時常的停下來討論是否需要調整規格。又或是，我們會以目前是Sprint的週期，無法去調整規格(當然很嚴重的問題PO當然要喊停)，讓利害關係人與團隊之間得關係緊張。利害關係人的視野其實很不一樣，確實可以提出團隊沒有想到的好建議。如果可以在這個階段，就讓利害關係人加入，然後將利害關係人所提出的建議納入考慮，又或是放入產品開發規格中，某種程度，間接的利害關係人也成了隊友的感覺。
‧產品規格：在開始出初跑Scrum的時候，這個階段產品規格的產品真的是零零落落，導致討論規格的狀況非常的不好。因此在Refinement meeting時，對於需要討論到的Story，建議就需要有具體的產品規格書，這能夠讓整體會議可以有非常好的聚焦，RD在這階段也可以開始反應開發的困難度，並也可以提出更好的解法。
‧PO需要再次確認大家的共識：這裡很有趣的一個現象：我們很常發現，會議大家都說沒問題，都說知道了，但仔細一問大家其實想的都不一樣。所以，就算是已有高擬真畫面，還是會發生這一個問題。因此，當會議聽到大家或是誰說：喔，我知道，或是沒問題。PO內心一定要響起警鈴，再問一次「你確定你知道嗎？你想的真的跟我一樣嗎？ 不如，你說一次你知道的？」
【Planning meeting】
Planning meeting順不順利，取決於在Refinement的時候討論出的結果夠不夠完整。這個階段基本上的大坑會是「選擇任務」、「拆解任務」、「估時」(這部份我目前都沒有做的很好)。Scrum團隊成員不要異動之必要，這是我在Planning meeting所體悟的心得。原因是，Scrum團隊我發現是很依賴「默契」這個隱性特徵上，一開始初跑Scrum會很卡沒錯，但當隨著時間紮實的PDCA後，Scrum團隊的效率會開始顯著的發生，對於任務拆解、估時的拿捏會非常的有默契。但管理高層要可以受得住前期可能要半年或是1年的不效率，甚至是沒有高價值產出的陣痛期，才有可能看到Scrum文化的開花。不然，往往還沒挺過去，就陣亡了。以下幾點心得：
‧利害關係人只要參加brief階段：可以在衝刺期前，可以再次接收到來自第一線同事對於產品的回饋，這部分的建議是真的非常的重要。
‧拆解任務只需要開發團隊留下：拆解任務，僅需要實際開發人員的參與即可。原因是，讓整體的開發進程可以相對落地，另一方面Planning Meeting的priority已經由PO掌握著方向(PO的責任)。因此，此階段僅對開發任務進行討論，不在進行發散的討論。
‧選擇任務：這裡依據不同的地方都會長的不太一樣。我分享一下目前我覺得還不錯的方式。首先：PO要先把預計上日期先押出來，讓大家有共識。並以利RD接下來的選題與估時。方法：
a.我們是採用蓋牌方式：先讓各RD自行就PO排出的Product backlog優序來排個人開發優序。
b.RD亮牌：RD亮牌後各自說明彼此排序的理由，然後由PO來排解爭議點，或是找出共同的交集點，最後確認開發項目。
‧「拆解任務」、「估時」：這個部份我一直沒有做的很好。目前的心得就是RD團隊要非常熟悉產品架構、產品開發團隊低耦合度(不需要依賴其他團隊)、需要有資深的RD，這對整個拆解任務與估時會順很多。
【Daily meeting】
站立會議是不是流水帳，這會是在跑Scrum通常大家會感受到的。我自已的想法是，站立會議不是流水帳，也不是RD對PO交辦進度的會議。PO會需要在每日的站會去觀察整體的開發進度、排除未預期的產品開發問題、進行各種小決策讓衝刺可以繼續。以下幾點心法：
‧讓開發團隊專心：強烈建議不要有突然的需求插件到Sprint週期中，這會打亂整體開發前期的準備與節奏感。除非是PO等級的票發生，需要現在馬上hot fix處理。
‧每一位夥伴是對團隊負責而不是為PO負責：站會會很容易不自覺變成，都是RD在對PO報告完進度。其實，站會的意義是在，每一位夥伴是在對團隊報告進度，以及彼此互相確認是否有互相Cover到彼此的任務，而沒有掉球。
‧說說乾話也是必須的：站立會議可以培養團隊的默契與情感，不要覺得每天都是在講一樣的事就不需要開站會。
【Product Review】
在這個階段就是展示產品並與利害關係人確認是否有符合產品期待。這裡可能會跟產業的不同而有所不同。例如，我當時是2C的產業，所以我們利害關係人的像會是高階階理者、需求部門；而2B的產業，利害關係人會是客戶、業務這樣的角色(這一階段我也不確定其他的行業是如何)。以下幾點心法：
‧產品上線後就要做：產品上線後，就需要開始進行Product Review，除了要確保是否有符合利害關係人的期待外，對後續的Retro幫助也很大。
‧直接面對利害關係人：雖然很血淋淋，但這是對整個團隊是重要的，團隊可以直接看到、聽到利害關係人的想法與感受，讓產品可以更符合現實層面。
‧要準備產品DEMO：Product Review一定要DEMO產品，而不是用口頭說說這次我們上線了什麼balabala，這很容易讓與會人產生不必要的產品誤解。
【Retrospective】
Retro階段非常的重要，但也是非常難的階段，很容易就變成互相感謝的罐頭會議。這需要到團隊彼此的信任感到了一個程度，以及場域是否讓大家覺得安全(不論是有形或是無形）。除了大家提出很正向的地方外，PO會需要引導大家說出負向的部份，然後最重要的是在每一次Retro會議，都需要Pick up一個下次要優化的項目。如此，團隊才能在每次的Sprint持續迭代成長。以下幾點心法：
PO的心態就是不要尷尬：PO的引導非常的重要，這會去影響這個團隊的Retro文化。通常講到負面的事情，基本都會很保守，這可以理解。我自已的方式就是先提出自已的失誤或是疏忽的地方，來去引導出團隊信任感。
Pick up要優化的項目：在每次一次Retro，團隊都要選出一個在下一次Sprin可以更好的項目來優化，不論是開發方式，或是團隊合作的方式……等，讓團隊的開發效能可以持續成長。
