新的旅程啟航

圖片來源：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的實質貢獻度，應處理的就要處理。

EzScrum團隊合作筆記

　　很高興今年有一個機會認識ezScrum團隊鄭教授, 經過數次的互動後決定更進一步合作--進行軟體研發團隊執行Scrum的研究.

　　本週一召開了第一個spring的spring planning meeting. 對照以前所做spring planning meeting, 覺得我們Team以前很多地方没有落實. 在此將心得整理一下.

這次我自己是Product owner, 找了一位member 作Scrum master

• 說明User story之how to demo的過程, 就是一個跟developer很好的雙向溝通的機會
• 針對story point的估算, 有member反應是要用什麼標準來估算story point? ezScrum團隊說story point是該story 的複雜度, 但它是實作的時間嗎? 倘若對實作story 的技術及domain knowledge不熟悉一定是估不準, 該member反應竟然估不準那就不要表示意見, 聽別人的就好了. ezScrum團隊卻堅持這個story point 是全體成員要一致同意的. Agile estimation 是我一直没有認真study的部份, 所以我決定先follow ezScrum建議的作法.
• 針對一個user story, 我(PO)先assign biz value, developer 再估 story point, 之後我要參考biz value & story point去 assign importance value (優先順序). 身為PO, 有了 story point 我似乎多了一些資訊可以再思考 importance point, 這又是一個溝通的機會.
• User story 要再切割成一個以上的task, 一個task 不能超過13hr. 這個規則讓大家可以認真地將 user story切割成更清楚&有 time-bound 的task.

除了白板之外, 我們也使用了 ezScrum , 做為管理user story 的工具. 有興趣的朋友可以下載來玩看看

數位電視實驗室推出HbbTV測試包(新聞收集)

出處：依馬獅廣電網 作者： 責任編輯：本刊編輯部 日期：2011-5-3 10:55:44 所屬期刊：
--------------------------------------------------------------------------------
數位電視實驗室推出了一個新HbbTV（混合廣播寬帶電視）測試包，它旨在於全面的HbbTV標準遵循環境出現前，爲製造商提供核心的一致性和互操作性測試。該公司還推出了專業測試服務。

此新Ligada iSuite包括Ligada測試伺服器（管理和提供HbbTV應用）以及Ligada iSuite（爲測試在目前互操作性乃HbbTV最大問題的那些方面專門設計）。測試專案包括音頻和視頻流式傳輸、網路恢復性和終端能力測試。

數位電視實驗室的HbbTV專業測試服務採用Ligada iSuite以及運行中和記錄應用的增值測試。