2017-09-11

Adapt or die 持續進步的力量 - 談談retrospective

趁著這次在 DevOpsDays Taipei 2017 準備這個話題
"Adapt or die 持續進步的力量"



我又再次整理了 retrospective 的一些需要注意的地方

為了準備這個題目 我在一個星期前就安排了一次實際的Meetup
讓學員實際體驗了 retrospective


每次在活動開始前 我都會問學員一個問題 :
如果有一天 專案非常忙
假設你們跑Scrum 而你必須做個抉擇
要捨棄Scrum的一個活動
你會捨棄掉哪一項活動呢?



這是在新竹 Meetup 的調查

這是在 DevOpsDays Taipei 2017 上的調查

其實不難發現 當真的很忙的時候
大家會選擇捨棄不做 retrospective
是不是很符合現實的情況呢?

不過沒關係
大家不愛 retrospective 可能是覺得浪費時間又沒有用
接下來我跟大家介紹幾個 Tips
看看這些 Tips 是否能幫助大家提升主持 retrospective 的用處
覺得有用 才真的有用

Tip 1 : Define the scope

定義清楚討論範圍

在Retrospective一開始
我通常會跟大家說明這次的範圍
如果是有Sprint概念的 就討論這個Sprint
如果是沒有跑Scrum的 (e.g. Operation Team)那就用一段期間 (e.g. 最近一個月)
如果發生了什麼重大問題
也可以針對這個問題來討論

定義清楚Scope的好處就是讓大家清楚明白接下來要討論的範圍在哪裡
才不會將所有的新仇舊恨都一起拿出來講

Tip 2 : Timboxing

每次討論我都會規定Timebox
並盡量嚴格執行
時間到了就討論下一個主題

嚴守Timebox有幾個好處 :

(1) 避免超時
      如果不控制時間 發散的討論可能會拖很長
      最棒的情況就像Daily Scrum一樣自然 每次都精準的結束 就不會造成大家的負擔

(2) 隱含排序效果
      最想講的一定要趕快拿出來講 不然就沒機會表達了 間接地就知道大家最痛的點是什麼

(3) 收斂想法
      因為有時間壓力 所以討論會慢慢收斂

上台說話時 第一輪我只讓每個人一次講一張想法就好
大家都說過一輪之後 才會進入自由討論的時間
主要是就是怕有影響力的人一次把全部想法講完 擠壓了其他人的時間

但其實每次執行時 我還是會看情況
如果討論正熱烈 大家已經進入了Zone
此時大家是很激情 很有想法的
我就會提醒他們時間已經到了 要不要再延續? 要延續多久?

Tip 3 : Play for keeps

簡單來說就是玩真的
一定要有Action Item
一定要有Owner
不然大家討論的東西又掉在地上沒人接
然後又會被質疑Retrospective沒有效果

另一方面 不要太貪心
一次先挑一件事來改善
通常大家列出的Action Item是真的會花到大家的時間的
所以套句大家最愛說的話 平常趕專案都沒時間了 哪有時間改善阿
只挑一件來改會是個比較簡單的開始

我自己是會列一項會花effort的Action Item 其餘列為Candidate Action Item (只記錄下來)
若是不須effort即能改善的Action Item (通常像政令宣導就好的那些)就直接改了
不算在Action Item裡面

Tip 4 : Play the ball, not the player

對事不對人
當討論, 抱怨或是吵架陷入了對人不對事的情況下 這個討論基本上是無效的
所以Scrum Master在引導時 一定要提醒大家 對事不對人
我們在講的是 事情 而不是
雖然我也知道很多人講出來的事情 本來就會針對背後的人
不過檯面上還是盡量讓大家客觀一點

如果已經到了劍拔弩張的時候呢?
上次看到一種作法
就是讓他們對著白板討論吧 !
讓他們對著白板上的事實來討論吧 !

Tip 5 : Run it regularly

定期舉辦
如果有跑Scrum的 開Retrospective應該不陌生(但也是最常被省略的會議)
如果沒跑Scrum 也建議要定期召開
如果久久開一次 雖然大家有新鮮感 可是心中的想法如果當下沒有記起來
事後還要回顧會非常難回想起
況且事情可能也過了 不須再追究等等

定期召開除了能夠即時收到回饋而有所調整之外
還能養成大家的自然而然的一種節奏與習慣
當這件事是很自然地發生時
團隊間也自然地塑造出一種安全的環境
而持續改進

Tip 1 ~ Tip 5 之前已經分享過了
我這邊不再詳述 請各位在去閱讀之前的文章囉
https://juggernaut-liu.blogspot.tw/2017/04/retrospective.html

Tip 6 : Visualization

視覺化
把要討論的東西 列在白板上
重點是要用粗簽字筆寫便利貼
這樣遠遠看才看得清楚再寫什麼
這樣才能引發討論


Tip 7 : Drive engagement

我一直覺得 retrospective 有個效果
就是能提升團隊 engage 的能力
所以也一直在想該如何讓團隊共同參與 覺得這是件好事 而願意一起面對
首要之務是要建立一個公平發言的機會
大家的 retrospective 不曉得是不是都是由老闆或是Team Lead率先發言呢?
然後風向就往那個方向偏了
所以 必須消除錨效應
於是 每個討論 我都會先讓大家寫自己的想法 (不彼此討論)

每一輪發言 也先暫時強迫每個人最多只能講 1 個或 2 個想法
待每個人都發言過後 (也可接受不發言) 再讓有更多想法的人補充

面對白板 圍成一圈 (越接近白板越好)
不知為何 我覺得圍成一圈有它的效果 感覺大家會開始分享

團隊自己提出 Action (非老闆提的)
自己提的solution 才有參與感 並願意去做

Tip 8 : Encourage team members

雖然 retrospective 到最後大都在檢討
但我覺得這也是個蠻棒的場合做感謝及正面鼓勵
所以每次 retrospective 無論是哪種引導的方法
我都會讓大家簡短地做個感謝或提出哪邊做的好

Tip 9 : 發散與收斂的過程

跟Brain Storming 很像
一開始要先講求發散 盡量收集想法
過程中要慢慢開始收斂
我們可以藉由 分類 或是 投票
慢慢地把想法收斂 然後專心討論某個議題

Tip 10 : Inspect the transparency

在這次 retrospective 你有多敢說真話呢? (1 ~ 5 分你給幾分?)
我建議在每次 retrospective 中都做這個調查 (匿名)
當作客觀評估團隊真話透明度的指標
因為匿名 所以姑且可以相信這是真心話
我們的期待是要越來越擴大團隊能說真話的範圍

Tip 11 : Change how we play

Randy Pausch說了以下這句話 : 
We cannot change the cards we are dealt, just how we play the hand
常常很多團隊會把過錯推到外面去
常常會說 都是 They 的錯 我們只能被動面對
可是阿 我都會引導團隊去思考
爛牌有爛牌的打法 我們要想一個辦法 讓傷害減少一點

Tip 12 : Self-Exposure


自爆
這邊自爆的意思是針對 老闆, Team Lead, 或 Scrum Master
當你們這些意見領袖勇敢提出自己做不好的地方
會讓團隊認為 
哇 老闆都敢說了 我有什麼好不敢說的

真的會慢慢形成一種氛圍
我們是真的來解決問題的

以上 12 個 Tips 希望能夠幫助大家提升 retrospective 的效率

最後我來定義一下 我個人的 retrospective
對我來說 retrospective 是一個機會
能夠讓我們學習與成長
不只是個人的成長 而是整個團隊的成長
並且是持續改進 跟團隊一起變強



大家一起變強吧 !









2017-05-10

[筆記] ICA課程 - Facilitative Agile Leadership

很高興陰錯陽差地參加了 ICA 的 Facilitative Agile Leadership課程

原本我預期是個引導的課程
希望能夠幫助我在公司導入敏捷開發時能夠順暢
但沒想到這兩天的課程反而沒有教這方面的技巧

原來這是個一系列的課程
(1) Operating in the Agile World
(2) System and Me
(3) Team Assessment and Support
(4) Leadership Frame

而第一堂課
是讓我們察覺本身的盲點及認清楚我們與公司的Mission

[Mission]
我們共同的Mission如下:
1. 用敏捷思維促成產品成功
2. 打造自主性的文化
3. 藉由快速探索以因應市場變化
4. 讓團隊與團員 win win

[Wave Analysis]
有了Mission之後 我們要討論目前導入敏捷的現況
透過 Wave Analysis 引導大家說出想法
Source :http://www.ica-associates.ca/wave-analysis-trends/

* 開始形成 (Emerging):行動逐漸確立,得到能量,學習曲線快速
* 衝刺 (Swell):正值潮流,看見正面的效果,持續的學習流
* 波鋒 (Crest) :產生最好的結果,但是僅存的創意不多,成長空間有限
* 漩渦 (Trough):運作的不順利,但是不清楚要往哪裡去,有焦慮感,感到混淆
* 暗潮 (Undertow):即便在成功當中,仍會帶來問題之深層模式,一不小心就會被吸到海底

個人覺得Wave Analysis也還蠻適合久久用在Retrospective上的


[影片引導 & ORID]
講師放了一部影片
RSA ANIMATE: Drive: The surprising truth about what motivates us

1. Autonomy - The desire to be self-directed, direct our own lives
       例子 : Atlassian 每一季的星期四會展開所謂的ShipIt Day. 工程師可以做任何它們想做的事情. 結果工程師們往往總是能提出很多很棒的Idea
2. Mastery - Our urge to get better at stuff.
    擁有熱情去做一件事情 讓我回想起學生時代不念書都在吹樂器 不為什麼就是For Fun
    但往往就是因為有熱情 才會讓你做得更好

3. Purpose
    要有明確的目標

所以有明確的目標才能確定我們的下一步
在這個session 講師就是透過ORID的方式
先讓我們講出看到了那些事實
再慢慢地帶出我們的感受及想法

[Fishbowl]
Fishbowl是一種引導討論的方式
首先區分不同角色
Manager, Scrum Master, Team, and PO
每種角色都是不同的金魚族群
每次邀請一個金魚族群進入金魚缸 (中央)
只有這批金魚可以討論 其他人都在外面觀察
外面的人唯有主持人說可以問問題時 才能問問題

沒想到各位Manager就像當兵的男生一樣
聊到不乖的同事, 不配合敏捷的同事 都能侃侃而談XD
另外 想不到 PO常常是沒被視為Team的一員的
(之後我必須注意這一點!!!)

[Autonomy vs. Self-Organization]
Autonomy 是一種可以說No ; 也可以選擇Yes的一種自由
Self-Organization 則是團隊能夠互相配合 互相調適
我認為犧牲小我 為了成就團隊
也是Self-Organization的一環喔

[Management <-> Leadership <-> Followhood]
我總是很喜歡拿NBA來比喻
其實一個球隊一定會需要球隊經理 負責行政事務
這就是屬於Management的範圍
每個球隊都會有個球星 他必須展現他的Leadership 帶領其他球員一起前進
拿下總冠軍


[Management in Mayberry]
不同管理風格影響結局
1. 一人管全部 事恭必親 累得半死

2. 一人控全場 讓部分車子自治 仍累得半死

3. 守望 等到有問題才去排解 其他時候都讓車子自己去排解

這邊想表示的是
管理上不一定要管得這麼累 

[知者 Knower vs. 學習者 Learner]
Source :http://thecuriousleader.com/
我們可能已經慢慢地傲慢起來
必須要時時刻刻提醒自己 不要當個 知者
不要隨便否定別人 用話語刺激別人


所謂的學習者
其實是Open Mind的態度 能夠包容不一樣的意見
而不是只是把話說得比較好聽一點 但骨子裡還是吃別人豆腐

[受害者 Victim vs. 參與者 Player]

不要老是把自己視為 「受害者」
老是都They的錯

反之 針對無解的外部問題
我們必須成為 「參與者」
為自己的選擇權負責

PS 以前retrospective時 我也常常提醒團隊 雖然這是別人的問題 但我們自己能做什麼? 讓我們度過這個難關!

最後 以終為始 又重新思考了
我的Mission是什麼?
跟公司的Mission是否Align?

其實這兩天的課程下來
儘管沒有預期的引導技術
比較像是先認清自己
認清自己的Mission
並提醒自己避免陷入
受害者心態及知者心態

在推廣敏捷時
我們要清楚我們的目標
我們要察覺我們的狀態

沒有認清自己 再多武器也枉然

正所謂

要推廣敏捷之前必須先誠實面對自己

持續努力吧  Go Go Go ~

2017-05-06

Daily Scrum 可以坐著開嗎?

今天聊到某個團隊坐著開站立會議
同事覺得這不敏捷

但其實我的想法是
也不見得站著開站立會議就敏捷
一切還是看會議的過程
如果坐著開會
大家仍舊可以專心地
很有效率地把站會開完 
那站不站其實也沒什麼問題

但老實說 坐著開會總是有種魔戒
容易讓人打開自己的筆電 做自己的事

不得不佩服發明站著開會的大師
這是種無形的引導啊
引導member 不得不專心開完站會

否則腳會很酸XDDDD

2017-04-23

如何主持一場有效的Retrospective


敏捷其中一個要素是 回饋
有回饋才能有所調整

Retrospective 正是一個這樣的場合
讓團隊成員有機會對團隊給予回饋
但有些人也會反映
這沒用啦
講無效的啦
沒有想法啦
都講一樣的事啦
等等等.....

而我主持這麼多場Retrospective之後
累積了一些心得 想跟大家分享
希望幫助大家主持一場有效的Retrospective

Tip 1 : Define the scope

在Retrospective一開始
我通常會跟大家說明這次的範圍
如果是有Sprint概念的 就討論這個Sprint
如果是沒有跑Scrum的 (e.g. Operation Team)那就用一段期間 (e.g. 最近一個月)
如果發生了什麼重大問題
也可以針對這個問題來討論

定義清楚Scope的好處就是讓大家清楚明白接下來要討論的範圍在哪裡
才不會將所有的新仇舊恨都一起拿出來講

Tip 2 : Timebox

通常每次討論我都會規定Timebox
並盡量嚴格執行
時間到了就討論下一個主題

嚴守Timebox有幾個好處 :

(1) 避免超時
      如果不控制時間 發散的討論可能會拖很長
      最棒的情況就像Daily Scrum一樣自然 每次都精準的結束 就不會造成大家的負擔
(2) 隱含排序效果
      最想講的一定要趕快拿出來講 不然就沒機會表達了 間接地就知道大家最痛的點是什麼

上台說話時 第一輪我只讓每個人一次講一張想法就好
大家都說過一輪之後 才會進入自由討論的時間
主要是就是怕有影響力的人一次把全部想法講完 擠壓了其他人的時間

但其實每次執行時 我還是會看情況
如果討論正熱烈 大家已經進入了Zone
此時大家是很激情 很有想法的
我就會提醒他們時間已經到了 要不要再延續? 要延續多久?

Tip 3 : Avoid Anchor Effect

有時候說話有影響力的人(e.g. Manager, Lead) 很容易影響大家
導致心中的想法沒說出來
這個就是所謂的錨效應

所以我都是讓大家同時一起寫便利貼
有寫的就盡量上來貼
有重複也沒關係 能夠加強意見的力道
代表有人跟你有相同想法 你並不孤單

Tip 4 : Facilitation

引導的方式很重要
一開始你可以先決定這一次要用哪種方式來跑retrospective
從最簡單的
  • Good and Bad
  • Start, Stop and Continue
到複雜的
  • ORID
  • Appreciative Inquiry

每種引導的方式都有其特別的效果
對於可以用那些引導的方式來帶Retrospective
大家可以參考這個網站 (目前有129種retro的方法喔)
https://plans-for-retrospectives.com/en/?id=108-87-10-124-57

會議中隨時要注意狀況
當大家都離題時 要引導他們回來

Tip 5 : Play for keeps

簡單來說就是玩真的
一定要有Action Item 
一定要有Owner
不然大家討論的東西又掉在地上沒人接
然後又會被質疑Retrospective沒有效果

另一方面 不要太貪心
一次先挑一件事來改善
通常大家列出的Action Item是真的會花到大家的時間的
所以套句大家最愛說的話 平常趕專案都沒時間了 哪有時間改善阿
只挑一件來改會是個比較簡單的開始

我自己是會列一項會花effort的Action Item 其餘列為Candidate Action Item (只記錄下來)
若是不須effort即能改善的Action Item (通常像政令宣導就好的那些)就直接改了 
不算在Action Item裡面

Tip 6 : Play the ball, not the player

對事不對人
當討論, 抱怨或是吵架陷入了對人不對事的情況下 這個討論基本上是無效的
所以Scrum Master在引導時 一定要提醒大家 對事不對人
我們在講的是 事情 而不是 人
雖然我也知道很多人講出來的事情 本來就會針對背後的人
不過檯面上還是盡量讓大家客觀一點

如果已經到了劍拔弩張的時候呢?
上次看到一種作法
就是讓他們對著白板討論吧 ! 
讓他們對著白板上的事實來討論吧 !

Tip 7 : Run it regularly

如果有跑Scrum的 開Retrospective應該不陌生(但也是最常被省略的會議)
如果沒跑Scrum 也建議要定期召開
如果久久開一次 雖然大家有新鮮感 可是心中的想法如果當下沒有記起來
事後還要回顧會非常難回想起
況且事情可能也過了 不須再追究等等

定期召開除了能夠即時收到回饋而有所調整之外
還能養成大家的自然而然的一種節奏與習慣
當這件事是很自然地發生時
團隊間也自然地塑造出一種安全的環境
而持續改進

Safe Environment

Retrospective有沒有效
其實最關鍵的因素就是安全的環境
必須要營造出安全的環境
大家才敢把真話說出來

即使攸關利益者在場 也敢把話攤開來講
因為大家在同一艘船上
真心為團隊付出

我也相信 無論怎麼引導 現實上在這種場合還是不比匿名或私底下的的意見來的直接真實
但至少

我們要努力盡量擴大可以說真話的範圍
真誠地希望團隊變好 而一起努力

以上是我的一些心得與想法
希望能夠幫助到各位Scrum Master們

2017-04-22

來搞一個公司內部的敏捷社群

公司導入敏捷才剛跑了幾個月
輔導的團隊從無到有地開始了敏捷生活
因為沒有經驗 所以很需要顧問的協助

各團隊與我們輔導團隊的關係大致上如下:

顧問是各團隊的中心

其他團隊因為組織的關係 所以也不了解其他團隊的執行方式
而顧問輔導的時間一周可能也才一次 平常溝通的效率也不是很好

於是我就在想阿
Scrum的關鍵就在
Scrum Master是否能夠守護住Scrum精神?
自組織團隊 也是個由下而上的一種群眾力量

果我們把這批Scrum Master們聚集起來呢?
讓他們能夠即時地彼此交流 互相幫忙
是否能有效地協助各團隊跨過轉型的門檻


串聯Scrum Master們 再讓他們去影響團隊

於是就大膽建議老闆 要來搞個內部敏捷社群
並勇敢地接下這份工作

在我理想的規劃中
Scrum Master透過橫向交流及串聯
精進敏捷技巧與思維
進而再把知識帶回去影響團隊及PO

另一方面
大家都在公司裡面
或許就像Code Review一樣
說不定之後就發展出符合公司文化的敏捷

今天就舉行了第一次的公司內社群活動
搭配輕鬆的心情及幸福的下午茶
希望這個社群未來能夠持續順利地運作

2017-03-07

Retrospective - 如果再做一次

今天剛上工 就參與了團隊的retrospective
發現了一個有趣的東西

他們採用Ruddy老師的建議
在最後一個討論區塊中 放入這個議題:

這個Sprint中有哪個story或task特別有感觸
如果再做一次 會需要多少時間?

這個區塊隱含的一個意思就是 Product Learning
經過這個Sprint的洗禮
你學會了什麼?
你學會了這個之後 如果讓你再做一次 你需要多久?

後來跟老師也討論了一下
老師表示除了Developer技術上的精進
也能加入事務性的學習 (感覺好像是Infrastructure)

例如:
這次導入了CI
我如果這個工作再做一次 是不是會變快

非常有趣!!!

2017-02-20

[筆記] 非型男飛行日誌 - PM的奇幻旅程

上週五有幸在趨勢聽了一場 產品經理的分享
講者Brian本身是工程師出身
他以幽默風趣的言語帶著大家進入成為產品經理的心路歷程
這場產品經理的由 0 到 1 真的太精彩了

產品經理 Product Manager, 大家熟知的PM
在趨勢並不是穿著火辣短裙的新鮮人辣妹
而是非常專業的資深同事

Brian就跟大家分享 PM其實跟大家想的不一樣

(其實在業界 聽到比較多都是PM與工程團隊的對立面)

但是PM要想的事情非常多 非常遠
負責
從無到有
從有到優
從生到死
的所有大小事

所以PM要牽涉的領域很廣 往往都需要各領域的交集
各領域都要樣樣通 (不僅僅只是略知一二)

之前小弟也有一種迷思
就是JM Project Manager ; PM Product Manager
傻傻分不清楚
後來經過Brian的分析 才了解
哇~
JM 看的是現在
以目前有限的資源 兜出資源 控制時程 把目標完成

PM 看的是未來
知道未來需要什麼 一直找尋機會並選擇對的戰場
發揮影響力帶動團隊 帶動改變

(怎麼聽起來 好像跟教練, 引導者, Lead 有87分像)

身為正確的PM 應該要有正確的態度
必須要
Positive Thinking
正面的雞婆
積極主動 樂於接受挑戰
主動找資源
聆聽與溝通

(怎麼聽起來 好像跟教練, 引導者, Lead 又有87分像)

最後
做產品 不能活在自己的世界裡

所以需要
大量的資料搜集與驗證
敏銳的觀察力
聆聽與溝通 (避免說得太多, 用詢問的方式, 延後判斷, 挖掘問題還是搜集需求)
訓練思考產生有影響力的想法 (強迫在資源不足時把事情完成)
永遠都要保持客觀 保持懷疑的態度
Start from WHY (Follow why you do it, not what you can do)

想清楚 為什麼你要這麼做 不這麼做

2017-02-15

Scrum Drawing Game 1.2 四小時豪華版


情人節的這天 我在趨勢開設了一堂四小時的Workshop課程
我都笑稱這是四小時豪華版的遊戲

Scrum Drawing Game

這個workshop我已經帶過了兩次
每一次都會再做些調整跟實驗
這次也不意外

[改變]
1. 授課方式從以往單方面傳授轉換成引導學員討論
2. Sprint個數從 4個增加為5個 但是大家總工時不變 一樣為40分鐘
3. 在Sprint中插入了Product Backlog Refinement (1分鐘)
4. 更多的需求變更 (改SPEC, 加新圖)
5. 如果PO來找User釐清問題 會提前將情報釋出給該PO (所以有來問的就能拿到情報 沒問的就沒有)
6. 團隊都有自己的Scrum Master
7. 從第3個Sprint開始 讓團隊自主管理 (總共15分鐘 自行分配每個階段時間)
8. 透過破冰遊戲(不可能的默契之Scrum篇) 找出本班級對Scrum最熟的人並成為各隊隊長
9. 透過 Token 來發言 (一顆軟質棒球)
10. 取消估算 讓遊戲單純一點
11. Retrospective 採用ORID方式 最後讓大家寫出回去之後的Action
12. 遊戲結束各組分享過程中最棒與最需要改進的事
本次課程以學員為主


[觀察]
1. 做Infra的人 往往是同一個人 這部分蠻可惜的
2. 完成Infra數獨約需要2個Sprint左右 但是效益不大 甚至還徒勞無功XD
3. 今天嘗試讓學員自己講出對Scrum的認識 但是感覺還是要有一些經驗才能說的出來
4. 自主管理時間 大家都就沒在管遊戲限制了 (沒做 retrospective, PO一直待在Team裡面講怎麼畫)
5. Scrum Master表示無力控制XD (因為大家一頭熱栽進去了)
6. 善於分工合作 這真的是Trender的優點
7. Story的粗細決定了Team的成果
8. 今天參與的學員 大部分居然沒有經歷過Scrum
9. 資源有限 有小組很快就把2張白紙用完了 只能在原地休息
做完了Infra 結果拿到什麼鬼啊XDDDD


[Retrospective]
1. 今天在遊戲後引導學員學習的方式 可以再加強連結
2. Infra的效益可以再擴大(例如 直接就給40%拼圖)
3. 今天時間控制很好
4. 繼續嘗試讓團隊自主管理
5. 應該先調查一下學員對Scrum的認識程度
    如果大部份學員都知道 Scrum 是什麼 引導討論可以多一些
    如果大部份學員不知道 Scrum 是什麼 就由遊戲過程來引導討論
6. PO在最後一個Sprint沒事做 下次塞別的任務給他們

最後的最後

哥今天不是講師 而是 SCRUM MASTER !!

2017-02-09

[筆記] 從限制理論看敏捷開發

今天參加 Agile Meetup 2017/02 聚會
主題是從限制理論看敏捷開發
講者是 William Yeh

我就來提提其中幾個點吧

[經驗主義 vs 理性主義]

敏捷的背後理論主要來自經驗主義
講求根據自身經驗去做修正
所以大神說的話 未必能套用在自己的團隊
但是經驗主義的極端就是 懷疑論
懷疑一切理論
懷疑一切教條

反觀 理性主義
用邏輯思考去推理什麼才是對的
所以理性主義的極端就是獨斷

敏捷的鼓勵失敗 從錯誤中學習 看似Open mind
但其實我也很擔心 Team或是老闆對敏捷失去信心及耐心

所以如果用理性主義去推理經驗主義的可行性
可以降低我們導入敏捷的錯誤機率

[樂高限制遊戲 workshop]

第一階段
假設有4個member 要實作6個feature
假設每個feature不可分割
如何在最短時間做完6個feature ?

這階段用排列組合就能完成了
我們直接跳到第二階段

第二階段
假設member技能不可轉移
於是工作開始出現互等的現象
這真的超符合現實情況的
QA 要等Developer 寫完程式 
Backend 要等 Frontend
Developer  要等 UX 畫出mockup

所以在planning時 其實不單單只是把點數相加
還要考慮各個工作的Dependency

[瓶頸處理9原則]
(4) 關鍵地方有損失 代表整個專案的損失
(5) 絕對不可以浪費瓶頸的時間
      e.g. 插件 不能讓現在處理瓶頸的人來處理
(9) 管理重點要在流量 非個別的產能
      有點像Kanban的WIP 要盡量流動

我這邊就不一一列了
但最主要就是找出 “瓶頸”
然後你就會知道 處理瓶頸是最重要的事
瓶頸才是影響專案進度的地方
其他地方就算閒置 就算delay 也不影響專案進度

[聚焦五步驟]

1. Identify 確認瓶頸
2. Exploit 決定如何充分利用瓶頸
3. Subordinate 其他一切遷就以上決定
4. Elevate 鬆綁制約因素 (學新技術或是加人)
5. Prevent inertia 避免惰性 回到步驟一 聚焦持續改進

根據William提的例子
假設瓶頸前期在UX 後期在Tester
那麼前期 其他人在閒置的時候
我們決定充分利用這個瓶頸 
於是只是調整大家的工作習慣
讓Developer 與QA提早與UX一起討論mockup
為了讓瓶頸專心處理
如果此時有插件進來 讓別人去處理
行有餘力再來思考 投資member 讓更多member學到UX 
能夠幫忙cover 瓶頸的部分

其實這個例子讓我想到之前在CM的時候
一開始我們也是在Sprint中設很嚴謹的 設計->開發->測試
原本也是有互等的情況
但後來我們在設計階段 就將Developer與QA一起來拉進來與UX一起討論SPEC
不僅釐清需求也有助於縮短開發與測試的時間

[總結]
用理性主義去推理經驗主義的可行性
來試試看 TOC 吧

2017-01-20

[筆記] 狩野分析 in Agile Tour Taichung

今天來參加 Agile Tour Taichung 的活動
下午我參加的workshop是狩野分析
講師是Nor Chen

講師先由講課開場
首先 
先從服務藍圖開始講起

服務藍圖一展開就很吸引人 我從未這樣思考過服務過程
以咖啡廳為例
打從客戶進門開始
會有哪些行為呢?

例如:
進門, 點餐 , 找座位, 喝咖啡, 離開

這一系列的行為
會有什麼樣的服務接觸點呢?

例如:
門, 櫃檯人員 , 舒服的椅子 , 好吃的餐點

前台與後台能分別提供什麼對應的服務呢?
而我們要將這些服務接觸點串接起來

服務設計就要先從服務開始
而服務一定附著在產品上
講師舉了一個可樂的例子
映入眼簾的是一罐罐裝可樂 旁邊附著裝著冰塊杯子
產品是什麼? 是 “可樂”
如同我們去餐廳 如果店家提供罐裝可樂 你可能還不屑
但是如果店家提供的是

在一個酷樂的夏天 你拿著冰鎮的玻璃杯 大口飲下冰涼舒爽的可樂
哇~ 好爽~
(服務是無形的)

再舉個例子
例如一個計程車司機
服務 : 我提供接送的服務
服務設計 : 
我提供孕婦一個效率舒適的趕醫院體驗

所以重點是將這些無形的訊息串成有感的體驗!!!
但是驅動消費的原因不在體驗 而是價值

可口可樂打造了一座非常高的販賣機
按鈕在非常高的位子
你一個人按不到 你必須找人一起幫忙
兩人一起合作 千辛萬苦才能買到一瓶可樂
可是你卻能用一瓶的價格買到兩瓶可樂
這就是 Coco-cola 2X1
圖片來源 : http://www.spotanatomy.it/2010/2-x-1-di-coca-cola-la-macchina-dellamicizia/

一瓶可樂其實也沒省幾十元
但是如果我們給人$100 要求人家給我們踩在身上
我想正常人應該都懶得鳥你
為何Coco-cola 2X1 User會買單呢???
因為 可口可樂帶給人們的價值 “跟朋友分享”

驅動消費的原因不在體驗 而是價值 !!!

接下來就進入 狩野分析的Workshop了
首先我們要釐清
滿意的相反是 非滿意
不滿意的相反是 非不滿意 (不是滿意喔)

我們這組的題目是 Line
挑了四個功能來調查
I    群組聊天
II   Line Pay
III 視訊聊天
IV 禮品小舖

[Step 1 : 正反面問法]
將你想問的題目寫成正面問法 跟 反面問法
例如
Line提供了 “群組聊天” 的功能
Line不提供 “群組聊天” 的功能

你的感覺是
喜歡
應該的
無所謂
能忍受
不喜歡 

[Step 2 : 定義需求種類]
可以參考下表 根據 Step1的問題 將答案對應至不同的需求種類




以下是我自己的一些解釋
A : 魅力型需求
      有提供很喜歡 ; 不提供至少也覺得是應該的
O : 期望
      有提供很喜歡 ; 不提供不喜歡
M : 基本需求
      有提供也還好 ; 但是不提供就不行
I : 無差異需求
      就正反都差不多 無所謂
R : 不需要
      有提供無提供都算不上喜歡
Q : 有疑問
      矛盾的答案



[Step 3 : 統計與分析資料]
每張問卷都會有個答案
我們將這些答案統計起來
你會知道 各個功能的需求種類是哪一類



[Step 4 : 找出敏感性需求]
接著我們計算每個功能的滿意與不滿意係數
先統計各需求的比例
再根據這個比例計算出係數

SI : 增加後的滿意係數
Better/SI : (A+O) / (A+O+M+I)

DSI : 消除後的不滿意係數
Worse / DSI : -1 * (O+M) / (A+O+M+I)

有了係數之後 我們可以畫出下圖


以(0.5, -0.5)為最遠距離畫出1/4圓 圓心是 (0,0)
圓內代表不敏感的需求
圓外代表很敏感的需求

距離越遠 越敏感 你越應該優先處理這個需求
如果距離相同
優先處理 DSI
為什麼呢?
因為
如果有了這個功能 User會更開心

但是如果沒有這個功能 User會更不爽 !!!

相較之下
不爽比較嚴重XD

最後講師加碼了六頂思考帽
其實六頂思考帽真的是個還不錯的思考工具
讓大家能夠換位思考一下
減少盲點

順序
白帽 -> 客觀資訊
紅帽 -> 主觀感受
黑帽 -> 不好的體驗
黃帽 -> 良好的體驗
綠帽 -> 提供更多可能性
藍帽 -> 整合以上資訊下結論

每一輪的藍帽都要下結論(依據前面各頂帽子的論述)
如果資訊不足 能再要求該帽再說一次
每一輪的藍帽也能決定題目的發展
最好讓每個人都輪流到每一頂帽子

[結論]
透過服務設計找到驅動消費的價值
狩野分析是個很強大的分析工具
六頂思考帽是個很棒的思考工具

2017-01-16

Scrum Drawing Game 1.1



今天來到新竹Agile Meetup來帶大家玩個workshop
Scrum Drawing Game

上次在公司已經帶過一次了
所以這次就提一下做了哪些改變

[改變]
  1. 破冰 - 有節奏的自我介紹 
  2. SPEC是會改變的 (我先讓PO看一半的圖 在第二個Sprint進行到一半時 再給PO看完整的圖) 
  3. User的觀點僅僅只注重某幾點 
  4. Team在工作時 PO要離開團隊 
  5. PO只能在planning時講解SPEC 
  6. 強制大家一定得做planning跟retrospective (不做就休息 不能偷工作) 
  7. 允許Team客製化自己的流程 (例如 retro後 提出planning要縮短 那就縮短) 
  8. 限制資源 (白紙一開始只給兩張) 
  9. 要求Team Review時是要搭配便利貼 所有的工作都必須有便利貼 
  10. 該角色如果有賺到錢 則要在便利貼上註記 (以免重複計算) 



[觀察]
  1. 第一個Sprint 大家都拿不到錢 因為都是半成品 
  2. 第一個Sprint時間到時 大家都還來不及把作品貼到麻將紙 我有偷放水讓他們貼完 但是從下個Sprint開始他們就知道 要在麻將紙上的才算是部署完畢 所以剩下一分鐘會知道要趕緊急急忙忙貼上去 
  3. PO風格不一樣 有的PO SPEC開得很粗 但是Team能力很強 像swarm一樣 嗡嗡嗡嗡地把所有工作完成(用猜的?) ;另一組的PO把SPEC寫得超詳細 Team就照做 
  4. PO表示無力感~ Review時才發現大家畫成這樣~ 原來PO不好當XD 
  5. 有一個Team的成員是從Titansoft來的 所以很有敏捷的mindset 知道什麼時間該做什麼事 
  6. 這次數獨都幾乎沒人完成 我最後放水讓他們體會一下有Infrastructure的好處 
  7. 有一組就算做了Infrastructure 也徒勞無功XD (現實上也是啊 做了也不一定有效XD) 
  8. Planning的時候 大家自己去搶工作來做 感覺不錯喔 希望在現實職場上也是這樣 
  9. Review完開始有member發現User的喜好 PO馬上更改Priority 
  10. 第四個Sprint 有兩組幾乎都把事情做完了 所以沒事做 


[Retrospective]
  1. 有節奏的自我介紹 好像還不錯 繼續這樣玩 
  2. 我這次演講也沒有準備好 身體也晃來晃去的 下次要強迫自己先站定一個點 不要回頭看投影片 
  3. 前面介紹(Scrum + 規則)還是太久了 下次會把部分遊戲規則說明拿掉 大家邊做邊體驗吧 
  4. Scrum的介紹可以拿掉 改由最後讓大家去思考 可能還比較有效果 
  5. 考慮縮短遊戲長度 
  6. 數獨太難 可以先幫忙填些數字 讓大家容易一點完成 
  7. Task的Effort 太複雜了 大家在忙 可能也不會考慮這個 下次拿掉 
  8. 這次讓PO離開團隊 效果不錯 繼續保持 
  9. 不能心軟XD SPEC該變就變 Timebox到了就到了 要符合現實 
  10. Business Value 不夠差異化 應該變化要大一點 才會有效果



也感謝 David 的推廣筆記文


2017-01-03

用Appreciative Inquiry來正面能量一下retrospective吧

今天是2017開工第一天
我則是讓兩個團隊嘗試了

Appreciative Inquiry


來說說今天的心得吧


[時間點]
我覺得年底或是年初都是個適合做 Appreciative Inquiry的時間
一來可以趁這個機會 感謝團隊成員並以正面的態度肯定2016年的工作
二來可以畫出新年度的夢想大餅

[動機]
我們團隊是cross-site的團隊
所以平常大家都是靠IM在溝通
鮮少有機會見到大家的廬山真面目
上一次Global meeting時 就有一位南京的同事說想要看看我們的長相
所以我靈機一動 這是個很好的機會來辦一場 cross-site的 retrospective
順便開啟雙方的視訊 讓大家都看看彼此的真面目XD



[破冰]
由於南京那邊還沒有retrospective的習慣
所以我一開場 先讓大家做一句話的自我介紹
例如
我是Juggernaut
我是個 無可救藥愛上敏捷的大叔
先讓大家破破冰 笑一笑 然後才開始今天的討論

[問題]
今天則是準備了三個問題讓大家討論
Q1 : 在2016年 你覺得團隊做得最棒的事情是? 或著你最想感謝的人是?
Q2 : 你認爲的理想團隊 應該有什麼特質?
Q3 : 如果要滿足這些特質 應該要做什麼?

[觀察]
男生跟女生就是不一樣
另一個純爺們的團隊 實在很難把感謝說出口 倒是夢想大餅卻能夠侃侃而談
女生們總是比較感性 我覺得能懂的欣賞別人 真的很棒

另一方面 我的主管一開始有先打預防針
他提到南京那邊的團隊可能比較悶喔 沒有意見喔
但是今天卻能講出不少東西
可見 只要有場合 其實是能讓大家講出心底話的

[引導]
在純爺們的團隊裡 由於我不屬於這個團隊 所以更能體會純引導的力量
以往我往往都是很有意見的人 但是在這個團隊中 我不能影響他們
我盡力地練習擔任純引導的角色
而他們最後能自己討論出個Action Item 我覺得是個很大的進步

[自省]
今天原本就預計想要先讓南京的同事體驗一下retrospective
加上remote team 沒有坐在一起 實在不好討論
所以本來就設計成開放式的結局
不過後來確實是有點發散 大家也各講各的 少了一點討論的味道
我下次應該要設計一個實際的主題
例如 如何打造一個理想的 cross-site team
人太多 應該也要換個方式 別讓大家習慣輪流發言

[理想團隊的特質]
以下是我們團隊提出的理想團隊特質:

熱情 , 互相幫助, 同理心 , 高效能 , 持續學習

希望大家能夠一起努力 共同打造這個理想團隊!!!

2016-12-21

[筆記] User Story Mapping in Agile Tour Taipei 2016



這場session的講師是Erica 

Erica一開始先玩個有趣的破冰遊戲
給每個人四格的紙
每個人先在第一格寫上你想做的事
接著將紙傳給左邊的人
左邊的人要看著第一格 “你想做的事”

將 它 畫 出 來 !!!

畫在第二格
再傳給左邊的人

第三個人 是看著第二格的圖
在第三格 寫下圖的描述
再傳給下一個人

第四個人 是看著第三格的描述
在第四格 畫出來



大家可以猜到這在玩什麼嗎???


藉由有趣的破冰遊戲
也稍微帶到了今日的主題

如果只是靠文件 沒有溝通
那大家還是會誤解原意

重點是 有沒有對話


接著就開始帶著大家來體驗User Story Mapping了
一樣藉著活動
將有共同興趣 或是 共同目標的人分組
接著 這群有共識的人 一起討論

如果你是出國旅遊
當你 決定出發出境
會有什麼步驟 ?


這些步驟 必須透過 動詞名詞 的方式呈現
每個步驟都寫在便利貼上

1st Round大家先把手裡寫的 手忙腳亂地貼在白報紙上
因為題目很明顯是時間軸
所以我們從左邊開始 按照時間順序 依序往右貼
這過程中也充斥著團員們的衝突
例如 我習慣先決定機票 再決定日期
但是大部分的人是先決定日期 再決定機票
不過最後達成共識就好啦


歸類

亂亂的順序當中 總有幾項是可以Group起來的
所以我們大概分類了
1. 預約事項
2. 調查資料
3. 準備行李
4. 動身出發

而這些分類 (Activity) 就是整個故事的骨幹
而這些骨幹下的小故事 
就是 
整個故事的細節

2nd Round
假想 過程中 如果有某個環節出問題 你會增加或減少哪些故事呢?

3rd Round
假想 如果你是某種身份的話 你會增加或減少哪些故事呢?
我們這組就是假想我們是美食部落客
所以我們在
(1)預約事項中增加了 “敲定餐廳合約”

(3)準備行李中增加了 “攜帶胃腸藥品”

4th Round
假想 如果你是當天來回 你會增加或減少哪些故事呢?
把最少故事能滿足當天來回的需求的故事留在第一水道


於是我們就假想我們是出差客 一切簡便
省去一堆預約行程跟行李

有點像是 內褲版本的產品 你可以把它想成 MVP
其他故事當然不是拿掉 而是下移到第二水道
在User Story Mapping中 就把多餘的故事往下移
這第二水道則是稍微充裕之後可以滿足的需求

經過這個 User Story Mapping Workshop
我學到了 初期我們必須盡量把想法拋出來
然後 歸類
這個類別就是骨幹
骨幹是AND的概念
我做完 類別A 會做 類別B Then C
而骨幹下的細節
是 OR 的概念
為了完成類別A
我可以做 x or y or z

接下來的發現 其實不會脫離這個骨幹
然後盡量以不同角度 去發想 是否還有故事
最後找到最小執行Effort的MVP -> See it work
以及行有餘力還能完成的其他故事 -> Make it better
最後再補強 -> Make it releasable

User Story Mapping 畫完之後
它的價值在於
透過故事 開啟對話

整張地圖 要放在可視的地方
視覺化的方式 讓團員一目瞭然目前的Roadmap

不過 對於時間軸這個概念
其實我還有些疑惑
如果有些需求 其實沒有時間的概念呢?
先做什麼其實無所謂 那軸線將會是用什麼方式呈現呢?

另外 Erica 有提到
User Story Mapping 的缺點是 主題已經事先定好了
所以如何補強這一點呢?
可以考慮 
Design Thinking 跟 Thinking Impact

[補充]
建立User Story Mapping的六個步驟

2016-12-18

[筆記] ScrumMaster 的吃飯傢伙 – 引導出個夢幻團隊 in Agile Tour Taipei 2016

這個Session是在講

引導

講師是Yves
好的引導 應該是引導流程
讓參與者在無形之中被引導了

而Scrum Master 不應該時時刻刻跟大家說要做什麼
而是要引導活動
透過活動 引出團員的想法或行動
所以Scrum Master 必須夠中立 以第三者的角度切入

[jug] 我也深感這種中立的角色 引導Member講出自己的結論 會比以往直接由上而下的Command來得有效

[jug] 深深記得在Daniel在CSM的課說過 Scrum Master就像牧羊犬 對團隊守望

評估團隊目前的問題
可以使用 CDE Model

C : Container
D : Difference
E : Exchange

Container : 容器 可以想像成範圍, 物理空間, 定義的問題等等

然後準備繪出四個象限

Difference : 水平軸線 最左邊代表差異大 最右邊代表差異小

Exchange : 垂直軸線 最上面代表交流多 最下面代表交流小

想像容器的問題 會位於四個象限中的哪裡

你就知道目前團隊的問題位於



左上方 D+E+ : 討論半天 雞同鴨講

左下方 D+E- : 開會沒意見 會後講不停

右上方 D-E+ : 人人都贊成 執行很難成

右下方 D-E- : 你說你的 我滑我的

接著各組討論 依各個目的
大家可以看看每組的討論內容

不過對我來說
最感興趣的是 如何增加交流 

把問題丟給member
好好的引導
member自然就討論出一堆Action Item了

你看講師 什麼也沒教我們
我們自己就討論出Solution了 XD

補充
引導的技巧

其中我最喜歡的兩張圖
對稱的溝通 = 高生產力

頻繁跨團隊溝通 = 高創造力


我們目前的團隊非常需要這兩種特性
Cross-site, Cross-project, 甚至是Dev & Ops Team
希望未來能夠高生產力 & 高創造力

講師的slide

[筆記] 乘著Agile的風 往CD的方向 in Agile Tour Taipei 2016





這個Session描述著一個沒有Agile實踐的團隊 怎麼一步一步地邁向CD之路
講師是 Edward
首先講者準備了一組 成熟度模型
用來評估目前團隊的成熟度
幫助組織了解目前團隊的開發流程距離CD這條路還有多遠

[五大指標]
(1) CI
(2) Automated Deployment to env
(3) Test Automation
(4) Version Control
(5) Agile CD
[判斷準則]
(1) 流程無法重複使用
(2) 有流程可參考 部分自動化
(3) Agile 開發流程中有自動化
(4) 流程可視並趨勢追蹤
(5) 流程最佳化處理

而以下是講者一步一步地讓團隊走向CD的步驟
我個人覺得超有感 因為我們現在也是很不DevOps 手活還是很多
阻塞了整體的速度

Step 1 : Local的 automation script 
(要先有script 再上CI 才有意義)
(後來 Open Space跟朋友聊這塊 也有人分享說 先上Local 對Member心理上是安全的)

Step 2 : CI
透過Jenkins來跑Step 1產生的 Local Script

Step 3 : Version control
[jug] 這點我覺得怪怪的 Version Control 不是應該是Step1嗎

Step 4 : 自動化部署
參考一下 : ios-deploy, facelane, fabric(remote deployment)

Step 5 : 開始跑 Non-functional test
定義 Monkey Test

Step 6 : 可視化
讓大家都知道 目前的狀態
    (1) Slack (透過slack 通知大家狀態)
    (2) Pipeline (Jenkins PipeLine 一目瞭然)
    (3) JIRA (issue tracking)

如果大家都裝死不看?(狼來了效應)
可以用聲音通知大家

Step 7 : 團隊快速溝通
(1) 快速開發
(2) 快速調整整合需求
(3) 快速測試 => [3A] Anyone, Anytime, Anywhere
(4) 快速改進 不要放棄 => Retrospective

講師有句話說得真好 我非常認同
*** Retrospective 做得好 開發沒煩惱 ***


補充3A測試的部分
可以透過 Slack bot 跟 Jenkins整合
讓人人(非QA) 能夠自己呼叫 slack bot 去做測試 不用再麻煩QA
Slack bot的好處 就是隨時隨地任何人 透過Slack Bot下指令去工作
能自動化的地方就自動化 手工的部分還是越少越好
這也是我的目標

*** Test as a Service (3A + 2A) 3A + AnyDevice + AnyAutomate ***

講者最後提到了 Test as a Service
跟我最近跟一些團隊接觸的經驗頗像

另一方面 由於講者是出自於StartUp Team
所以工具都是找免費的資源
這點可以好好參考

參考資料:
The Continuous Delivery Maturity Model
上面這串是CD的成熟度模型評測 可以拿來評評看自己的團隊喔

PS. 講師的投影片 如果有放出來 我再補上

2016-12-09

Scrum Drawing Game 1.0

[前言]
事情是這樣的 約莫11月初的時候 我的老闆找我談了一下
在年度盛會ETS Global Meeting上是否能準備一個Workshop ?

原本手頭上有兩個已經帶過的workshop 但是都太專門太技術
不太適合ETS 所有的Member

所以我想了又想 想了又想 想了又想
終於在有一天的夜裡

想到了一個很棒的Idea

Scrum Drawing Game 



[設計思維]
在設計遊戲的時候
我站在User的角度去思考
經由這個Workshop 我能學到了什麼

於是我把可能可以學到的項目都列出來:
1. 悶著頭做 可能到最後方向錯誤 不是客戶要的
2. 什麼叫做可以出門的產品
3. Business Value 的重要性
4. 基礎建設的重要性
5. 及早交付的重要性
6. 隨時調整PBI優先順序
7. 隨時整理Product Backlog
8. Retrospective 的重要性
9. 如何達成共識
10. PBI的描述越清楚 越能幫助Team完成任務

所以我設計了以下幾種規則 讓學員能夠體認到上述能學到的觀念
1. 每個Sprint都要Review 隨時檢視
2. 垂直性功能而非水平性功能, 一個角色的完成 一定要有基本的外型,姿勢, 顏色, 位置才能出貨
3. 每個圖畫中的角色都有不同的Business Value
4. 如果完成的基礎建設 可以加快開發速度
5. 越早完成部署 越早拿到好處 賺到的錢會加倍
6. 根據Business Value 調整優先順序
7. 一定要隨時調整Product Backlog 不然你會跟不上
8. 如果能停下來 做個自省 找到改善方法 會比不自省來得好
9. 面對面 隨時討論 隨時也能找PO Sync
10. 訓練PO的邏輯與描述能力

[遊戲流程]
== 產出 ==
一張圖畫


== 隊員分配 ==
每組一個 Product Owner
其他人皆為 Team

== 這個遊戲總共 4 個Sprint ==
每個Sprint 約莫30 分鐘
15 分鐘 做 Plan & Run
10 分鐘 Sprint Revew (all groups)
 5  分鐘 Sprint Retrospective

== Sprint 0 ==
在Sprint 0 , Team 要先準備一張紙版的JIRA
要分成這四個欄位 : Product Backlog, To Do, In Progress, Done

PO 這時要去理解 User想要的圖案是什麼
然後將需求轉化到 Product Backlog

PS. 此時Team可以先幫忙PO把PBI建立起來

== Sprint Start ==
== In the Sprint Planning ==
大家一起討論 要先做什麼
PO 要盡量釐清需求 也要考慮Business Value 也要考慮是否要實作基礎建設

估算出來的Sprint Backlog 要將這些Story貼到 Todo欄位


== Run Scrum ==
PO 這段期間內 要隨時refine PBI 隨時調整優先順序
Team 就按照Story 工作 (new feature or infrastructure)

基礎建設完成之後 隨時可以得到一把剪刀 跟 20%Sample的拼圖

PS. 我安排的基礎建設是 "數獨" 正常會吃掉1~2 Sprint的時間 就看團隊願不願意投資


== Sprint Review ==
1. Demo這個Sprint的產出
2. User 根據產出 不同角色有不同價值 圖案只要超過某個條件 就能拿到價值
2. 其他組可以趁機來觀察一下別組靠什麼賺錢

PS. Feedback要整合進Product Backlog


== Sprint Retrospective ==
檢討 找出改善方案

== Repeat the process ==
重複這個循環直到第四個Sprint結束







[發現]
1. 一開始有幾組先把所有的角色的草圖畫出來 但是沒能得到分數 因為這東西不能出門 (MVP)
2. 由於越早交付 價值的倍數越大 所以應該要先拼提早交付的
3. 狂做基礎建設的組別 得到很多拼圖 交付的產品馬上就趕上來了
4. 目前沒有一組有觀察到User喜好 而隨時更改Story 有點可惜
5. 果然面對面溝通是最有效率的
6. 如果有Member卡住 換人畫畫看


[自省]
1. PO到最後都是在Sprint期間 邊看sample邊描述 提醒member哪邊做錯了
    [S] 1. PO待planning結束得先暫時離開group
           2. PO只有在planning時才能說話

2. 重複計分的問題
    [S] 做分數條 打過得分數就貼在上面

3. 剪刀功用不大
    [S] 其實原本的設計是希望學員把圖給剪下來 再貼到白報紙 這樣才會造成預期的塞車

4. 資源太充足
    [S] 1. 隨機抽走一個人
           2. 一開始白紙太多 或許只需要3,4張 其他用數獨去換

5. 大家都沒在看別人畫了什麼 得了幾分
    [S] TBD

6. 大家都沒做planning或是retrospective 直接繼續埋頭做事
    [S] 強制設下 planning跟retro時間 不做的人就發呆

7. 這個題目的需求是死的 一開始PO看到的sample 是什麼就是什麼 下次可以模擬需求是會變的
    [S] TBD


[看看大家的作品吧]