Max的敏捷想想(Thinking in Agile)

2015年1月2日星期五

2014年度回顧

2014年我做了一個人生的重要決定，離開任職十多年的法人機構加入一家國內網通業者的內部創業團隊。我很高興也很感恩新老闆能讓我在台中成立一個Agile Team。簡單回顧下半年換新工作後自覺做得不錯的事

6/14 跟朝陽科大唐教授等人辦了第一場 Python Taichung Meetup
9月底台中辦公室啟用，是一個 Agile friendly workspace
12月辦了一場 Kanban 桌遊工作坊, 因而促成 Agile Taichung Meetup 的成立(2015 每月會辦一次)
逐步落實團隊的 Agile practice，讓member (包含 designer & engineer) 可以快速的協同工作

之前在台中遇到資訊領域的朋友都會說台中在地 meetup 很少，其實當我有想辦 meetup 時代表有其它人也是有同樣想法的，所以大家一談就立刻有一群熱血的朋友跳出來，所以201４下半年台中就有了Python Taichung（反而我後來只是參加而已 XD)；而2015年還會有Agile Taichung。

另外「連辦公室都是從無到有建立一個RD團隊」的經驗是人生第一次，過程中也學到了不少以前從没有想過的細節，其中感受最深的還是人與人之間的溝通。

第三個感受是團隊的人對了，敏捷實務的推動就自然順利了，在之前單位想做而無法順利推行的實務，在現在的團隊中卻是很快的落實。

對於2015年，自己的新計畫是：

每月舉辦一次 Agile Taichung Meetup，今年下半年希望可以挑戰辦一次 Agile Tour Taichung
團隊的Kanban流程可以落實到量化的管理
第一季以前要讓MVP上線到Google Play，儘快取得end user 的 feedback
努力做好自己的GTD
安排時間做運動

新年快樂，大家加油

讓Agile社團在台中落地

圖片來源: techdistrict.kirkk.com

把12/23發佈的FB的網誌，匯整到這個blog
----------------------
11/28 David 在 FB Scrum Community in Taiwan 提出 "Agile Tour 落地生根" 的想法，文中提到有一位台中的朋友說： "真心希望往後台中的軟體業可以更加成長而成為另一個聚落，讓我可以下定決心回鄉發展”，我心中著實也很期待讓台中軟體圈熱起來．

我是在台北長大，卻剛好在台中落地．之前在台北幾乎每天都可以找meetup去參加．來到台中，遇到同行大家常常感歎在地很少有跟軟體開發相關主題聚會可以參加，但這一年來陸續看到或參與 "享實作樂","台中前端社群", "Python.Taichung", "光明頂創育智庫"...等社群主辦的活動，感受到台中軟體圈似乎漸漸動起來了．

12/6在台中辦完看板桌遊後，David 找了幾位表達有興趣參與Agile Tour Taichung 志工的網友，大家討論要如何開始，我給自己挖了個坑來當主辦人．第一次的聚會先決定在我的辦公室跟台北 Agile meetup 直播連線．

昨天晚上氣溫頗低，本來還在想是否會降低參加者的意願，但是到了７點原本說好的網友都來了，心中真是感動．

昨晚除了學習到台北Hugo分享如何利用看板流程精進自己的看書計畫(感謝 Tony 支援 Adobe Connect 連線直播)，大家也很熱血地決定了2015 年度目標：年度活動大略規劃為：

CodingDojo x 2
Kanban/Scrum Game Workshop x 2
Agile Tour Taichung 2015 x 1

活動時間：以每個月第三個禮拜一晚上7:00開始為原則，需長時間活動選擇禮拜六
第一季度活動規劃:

一月: CodingDojo by using Python,
二月: 停辦,
三月: Scrum實踐分享

在討論中我聽到台中的軟體開發團隊其實比想像中的多，期待明年大家都來Agile一下．

2014年11月28日星期五

台中 Kanban 桌遊工作坊

圖片來源: meetup

今年11月8日參加了 Agile Tour Taipei 2014，當天下午是參加“看板桌遊工作坊”。

雖然我們團隊目前是採用Kanban在進行專案管理，但除了我之外團隊成員對於Kanban的WIP以及度量方法(CFD)還没有很深的體會。當天在2個小時的過程中，透過getKanban ( http://getkanban.com/ ) 這個桌遊很快地讓我體會到
1. Kanban 工作流程運作
2. 如何在開發中進行工作項目限制(WIP)
3. 如何處理不同類型的工作(例如緊急任務)
4. 如何度量: CFD, control chart, cycle time
5. 如何自backlog挑選user story

在當天的 Retrospective session 我自己設定一個action item：要在台中公司辦一場Kanban桌遊工作坊。也非常感謝 David Ko 熱心贊助，願意在12月6日來台中帶這個工作坊，目前這個工作坊已經有盟創雲應用中心及台中另一友人的公司同仁共14人參加。但我覺得David 難得來台中，跟他討論之後應該還可以再開放6個名額，如果你對Kanban有興趣、想要在最短時間內對Kanban有簡單的認識，這套遊戲應該是最有效、最模擬、最互動、最好玩的方式。
有興趣的朋友請到報名網頁(http://mitracloud.kktix.cc/events/kabangame-taichung-2014)報名。

Kanban桌遊工作坊
日期:2014/12/6
報到時間: 13:30~14:00
工作坊時間:14:00~17:00
議程:
Kanban 簡介 (10 min)
getKanban 遊戲說明 (20 min)
play getKanban game ( 策略說明:討論為什麼會贏; 分享心得:討論 swarm, WIP, 以及分析圖表)

PS:這一次的費用由盟創贊助，下一次的話則會酌收費用。

參考資料
1. 看板遊戲操作心得
2. 看板培訓課程筆記 - 看板遊戲玩後的感想

2014年7月18日星期五

Agile Workspace

圖片來源：Henrik Kniberg

最近終於把台中辦公室的地點確定下來，並且著手規劃敏捷團隊的工作環境。
Mike Cohn 曾寫過一篇blog “The Ideal Agile Workspace”，文中提到一些元素。依此列表來自我檢查一下

2014年5月16日星期五

新的旅程啟航

圖片來源：pixnet blog

　　我在本週離開了工作十幾年的法人機構，進到業界開始投入一項新的計畫。有些朋友問我在法人做的好好的為什麼想出來到業界？也有些朋友關心：這一出去似乎有很多的不確定性！其實一開始在考慮是否離開前公司時，也確實對未來的不確定性猶豫了一陣子，但在綜合考量了自己對工作的期待、業界現況以及家庭因素後，決定把握這次的機會試看看。
　　今天想來分享其中的二點思考面向。
　　其一是去年看了「人生是永遠的測試版：新創企業家改寫生涯的方程式」，書中提到了ABZ計畫：

A：你現在正在做的事。
B：你需要改變目標或方法時所採取的應變對策（轉用B計畫的時間點：當某件事行不通了/有更好的機會，就是轉為執行B計畫的時候。而最好的B計畫，就是和你目前做的事情不一樣，但密切相關。）
Z：你的救生艇計畫，當轉換到B計畫失敗了你是否有救援方案？

2012年11月21日星期三

你的品質 vs 我的品質

Image by shutterstock

最近得知一位的客戶A對我們Team的產出的品質不太滿意(是由另外一個單位所作的滿意度調查)！但和另一位客戶B相比，我們Team的成員普遍認為交付給客戶A的產品品質遠高於交付給客戶B的產品，而客戶B對我們Team的滿意度卻高於客戶A所給的分數。
(註：這兩個客戶的產品需求是很相似的)
　溫柏格在「溫柏格的軟體管理學：第一級評量」中有一個例子，有一家軟體公司的經理人員認為延誤交期對小型專案無妨。但公司用問卷調查方法去評量顧客滿意度，用1到7的數字代表專案的好壞，並將之轉換為臉型。(最燦爛的笑臉是最高滿意度，而黑色的骷髏頭加兩根骨頭則是最低滿意度)，以下是分別是顧客滿意度及開發人員滿意度的結果：

圖1：顧客滿意度

圖2：開發人員滿意度

讓資訊部門經理大感驚訝的是，顧客對於大型專案没有那麼不滿意，即使這些專案在時程的延說超過原訂時間的25%到125%。(有一個專案得到骷髏頭和兩二根骨頭，是因為能否準時交貨攸關到顧客的生意) 其它專案的顧客在使用新軟體前需要有許多準備工作，因為顧客本身在守住時程上遇到許多問題，其實他們大體上反而很高興軟體有延誤。
　但針對開發人員滿意度的結果顯示：顧客和開發人員對於何謂專案品質所採用的標準是不一樣的。顧客所關心的是對於他們商機會有怎樣的影響，而開發人員最在意的是對於自己工作的成果是否滿意。
　對開發人員來說，專案做得愈久表示要花好久時間test & debug，對此他們會感到壓倦。規模較小的專案雖然也有延誤，但開發人員不會因花幾週的時間test & debug 而厭倦。
　然而小型系統大多需要很快就能派上用場，若有延誤做生意的機會已完全消失，這是顧客最不滿意的情況。
　以上書中的說明正是我們Team的客戶A情形，我們交付的產品是客戶A要立刻拿去做生意的；相對於客戶B，我們交付的產品比較像是公司內的POC還要整合到既有產品中才會開始銷售，所以客戶A對於時程延誤的容忍度很低，也因此給了我們一個大叉叉！
　溫柏格還提到「軟體第零法則」：
如果軟體不需實際派上用場，那麼無論需求是什麼你都能符合
　經過這次的經驗，我未來對於不在乎品質的顧客其實更有信心如何去交付結案了. ^_^
謎之音：真得有不在乎品質的顧客嗎？