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 的推廣筆記文
http://kojenchieh.pixnet.net/blog/post/456818921-scrum-drawing-game:-agile-meetup-新竹聚會筆記


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


[看看大家的作品吧]





2016-11-15

Relative Estimation - Bathing Animal Workshop

今天則是受邀向tool team介紹 Relative Estimation
如何讓成員快速理解這種新估算模式呢？
最好的方式就是workshop了
於是我把專業的動物洗澡團隊又搬了出來
假設我們是個動物園團隊
今天要評估幫動物們洗澡的Effort

今天的動物共10隻




每個動物都有不同的需求
例如 ：
石虎是個動物園明星 全台僅剩一隻 要小心呵護
銀背大猩猩是全動物園最兇猛動物之一 要剪指甲
等等

Product Owner 今天就是負責將這些需求天馬行空地描述出來
其他Member 則是依據這些需求 來做估算



估算的步驟 :


Step 1 : 比較大小
  • 排序 
Step 2 : 校正基準
  • 定義最小的動物 
  • 插入歷史評估參考 
Step 3 : 評量程度
  • Planning Poker 


遊戲規則 :
  • 一次一個人說話
  • 一次一個動作
  • 輪流

其實過程中花最多時間的是排序
這次大家在爭論的地方在於
石虎是極為珍貴重要但是處理不複雜
換言之是 Business Value高 但是Effort相對沒這麼高
兇猛動物雖然兇猛 處理的Effort高 但由於Business Value低於石虎 所以排石虎前面

不管怎麼排 一但完成排序
後面評估點數的速度就快多了!!!

這是最後的結果:




黑熊由於會自己洗澡 所以Member覺得他是最簡單的Story
而石虎由於太珍貴了 需要特別地呵護 所以給予100點

儘管結果跟PO想得不太一樣
PO覺得：
石虎有這麼困難嗎？？？

Member回一句 ：
我們才是做事的人啊 !!!


超霸氣的啊 完全無法回嘴XD
不過下一句 PO 應該要問的是
那 石虎可以再細分Story嗎？


不管如何 這就是團隊的一個共識
先GO下去再說吧

2016-09-18

解決 為什麼無法在VS Code上 Debug

前一陣子我碰到一個Issue
我的Visual Studio Code 突然無法debug了

Error Message 如下
ERROR: CLRDBG exited unexpectedly with exit code 133 (0x85).

Google了一下 應該是我後來更新.NET Core版本之後 VSCode裡面的設定沒有跟著換
可以看一下 我電腦目前有兩個版本


project.json 仍是指到舊版本的RC2


所以手動更改Version成正確的版本即可


參考來源 ： https://github.com/OmniSharp/omnisharp-vscode/issues/541