Mystic Pieces

今天參加了曉梅老師的分享活動—「Agile Taipei 海盜年會：聊一聊『隱藏的質量』問題」，似懂非懂的，到了後半場才有些融會貫通的感覺，好像有些收穫，特別記錄下來。如果有什麼錯誤的認知，歡迎大家給我提點指教，謝謝～。

若兩年後你的團隊還在 run Scrum，這說明了你們的 Scrum 不 Scrum。

-- Daniel Teng

Scrum Master 在前期或許偏重 Scrum 引導，後期就要嘗試引入一些有趣的變革。變革適不適用根本不是重點，重點是嘗試過，有問題再來修正就好～。而我發現自己最常引入變革的是 Retrospective Meeting 的部份，往往需要增添更多滋味，才能引發出更多的反思及反饋。但這次要談的是 Review Meeting 的新滋味！

今天分享的是在《敏捷回顧：團隊從優秀到卓越之道》之中學到的「三個五」的活動。書中歸類在「收集數據」的章節，也就是 ORID 之中的 O（Objective ），但我覺得也很適合用在 brainstorming 的情境。

前一陣子閱讀了 Ed Catmull 的《創意電力公司 ― 我如何打造皮克斯動畫》，這本書讓我非常有共鳴，特別撰寫這篇文章，記錄並梳理我的心得，也同時分享給各位。

整本書裡頭，壓根沒有提到任何「敏捷（Agile）」的概念或字眼，但完全就是敏捷文化的形狀。這就是我內心敏捷的最高境界，叫什麼名字、跑什麼框架並不重要，重要的是團隊一同實現的文化內涵。除此之外，我們也熟悉迪士尼和皮克斯的一些作品，所以閱讀中就像穿插了一些小彩蛋一般，比起一般的商業管理書籍，又多增添了點趣味。

敏捷開發講求團隊合作，往往有很多事情需要大家共同決議，最常見的不外乎圓點貼紙（dot voting），用投票的方式快速找出共識。然而，在我閱讀《失控的多數決》後，對於簡單多數決，有了些微不同的看法。彙整記錄，提醒自己別輕易把多數決與共識劃上等號。

身為一枚 Scrum Master，我明白自己的角色職掌，也努力學習了不少 SM 的相關知識；現在的我也參與開發，所以也略懂身為 member 該有的技能與姿態，唯獨 PO 這個角色，我僅僅明白該承擔什麼責任、扮演著什麼樣的角色，對於 PO 的工作該怎麼進行，絲毫沒有頭緒。

所以我希望自己不僅明白 PO 的角色職掌，還能給予 PO 更棒的協助，甚至是引導。所以我報名了 David 大的「敏捷需求探索工作坊」，希望能夠有所助益。這天的 workshop 真的很有收穫，記錄一下我滿滿的心得！先說結論，這門課完完全全符合我的需求與期待，讓我在需求探索這塊領域讓我有了一個非常棒的入門，期望自己真的能夠給予 PO 足夠的協助。

老實說，在參加課程前，這幾個字分開大略是什麼意思都知道，但無論哪兩個合在一起我都沒聽過。XD 就這樣懵懵懂懂的去參加了這個體驗 workshop。這邊記錄一下我自己的感想與心得，Workshop 細節就等著大家有機會自行體驗才會更有感覺～

今天讓整個軟硬團隊練習需求切割的過程中，感受到一些有趣的現象，記錄下來與各位分享。這是一個真實存在的需求，但不是實際的時程，藉由這個需求讓團隊練習，也或者說趁此機會同步一下大家的想法。

又到了一年的尾聲，來做個自己 2017 年的 Retrospective 吧～

今年是自己職涯中最突飛猛進的一年，進步的不是薪資，更不是職稱，也沒有換工作。卻是我學習成長最豐碩的一個年頭。

從三月左右開始，覺得需要一些方法來管理團隊工作，對於敏捷開發還似懂非懂，只翻了幾本書查了一些文章，感覺相當時尚，決定先做了再說，就這樣跌跌撞撞的導入了 SCRUM，而我擔任了 Scrum Master 這個角色，一切就從這個看似辦家家酒的故事開始。

實行敏捷開發以來，慢慢體悟到很多文化、思維與傳統模式（瀑布）上的差異。逐漸感受到這不只是一種方法論，而是一種文化及信仰的力量。一個失敗的產品，可能的原因很多。先不論外在資源、環境等因素，單單就團隊內部能量是否能夠完全展現，就是一個很值得討論的問題。

最近突然靈光一閃，運用 LEGO® SERIOUS PLAY® （LSP）引導了一場團隊的 Retrospective 會議。我們使用的是探索包（Window Exploration Bag），每包的組合都相同，含有 52 塊各式各樣的 LEGO® 積木。運用這樣的工具，展開了這次的 Retrospective～

（圖片來源：https://shop.lego.com/en-US/LEGO-SERIOUS-PLAY-Window-Exploration-Bag-2000409）

此篇是將我自己的心得感想做一次簡單的整理。如果你之後想要參加 Daniel 的 CSM 課程，建議別閱讀這篇文章，這不是預告片阿～多少會有一咪咪微劇透，會減少您個人透過身體得到的感動。預告片請見另一篇：[CSM] Certified ScrumMaster® (CSM) 課程。

當我接觸到 Agile、XP (eXtreme Programming) 時

也常常聽見 TDD 這個名詞，在學習這門課前

僅約略知曉就是開發前先撰寫測試，以確保產品品質

心中不免晃過一絲絲「這只是測試人員推卸責任而已吧～」的念頭
（真的只有一絲絲喔～XD）

上完了第三天課，不只是顛覆既定的刻板思考

而是紮實有一種醍醐灌頂的感動。

在敏捷的團隊中，理論上至多只能擁有團隊績效，沒有個人成績

敏捷團隊重視的團體大過於個人，鼓勵所有成員能夠相互幫助、相互支援

將一切都透明化，一起成長、一起進步。

但現實生活中卻不是這樣，多數的公司的文化制度，仍保有個人 KPI 的規範

那基於敏捷模式下的團隊，該如何去訂定個人 KPI 呢？