台中 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. 看板培訓課程筆記 - 看板遊戲玩後的感想

Agile Workspace

圖片來源：Henrik Kniberg

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

新的旅程啟航

圖片來源：pixnet blog

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

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

你的品質 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對於時程延誤的容忍度很低，也因此給了我們一個大叉叉！
　溫柏格還提到「軟體第零法則」：
如果軟體不需實際派上用場，那麼無論需求是什麼你都能符合
　經過這次的經驗，我未來對於不在乎品質的顧客其實更有信心如何去交付結案了. ^_^
謎之音：真得有不在乎品質的顧客嗎？

敏捷軟體開發宣言

藉著親自並協助他人進行軟體開發，
我們正致力於發掘更優良的軟體開發方法。
透過這樣的努力，我們已建立以下價值觀:

個人與互動 重於 流程與工具
可用的軟體 重於 詳盡的文件
與客戶合作 重於 合約協商 
    回應變化 重於 遵循計劃  

也就是說，雖然右側項目有其價值，
但我們更重視左側項目。

Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler

James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick

Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas

資料來源: http://www.agilemanifesto.org/

[轉載]研究生的學習與訓練

無意間看到交大曹孝櫟教授所寫有關研究的經驗分享─研究生的學習與訓練 ( 原文URL ) 。

和自己團隊中工程師互動的過程, 覺得文中提到的「蒐集與整理資料」、「學習思考」、「發掘問題」、「建立模型，尋求解決方法並科學化地驗證」等觀念，也是RD工程師所需修練的功夫，因此將其轉載推荐

[轉載]不管你是主管還是員工，都該好好的看這一篇文章

google 一下, 這篇文章作者有人說是: 宜蘭縣政府教育處 方德信督學
但看內文又似乎不像, 若有錯誤, 請告訴我, 我會立刻修正.


我對於以下這段話很有感觸：

「如果你上班的公司經營不善，快要倒，你會有什麼打算 ? 」從來沒有一個告訴我：『我會去告訴老闆，別擔心，我會用我的全部家當陪他拚到底。』

即使不是自己當老闆，但是身為一個帶領團隊的主管也是會有同樣的感受。以前剛當主管的時候總是會覺得member已經很努力，要把他打『待加強』、『不適任』有點不忍心。不過有些人就是皮皮的，所以我只得忍受上司的壓力以及member有時不support的無奈。但後來我也是學會一個人的考績就是要看他對於Team的實質貢獻度，應處理的就要處理。