如標題所述：
這個 blog 不再更新, 新文章將發表在新的 blog http://maxlai.cc
2018年8月31日 星期五
2016年3月29日 星期二
Agile Tour Taichung <從趨勢科技的agile之旅談改變的導入> 演講摘錄
今年 1/23 Agile Tour Taichung 我們請了志工幫忙做演講記錄，感謝Philip 的細心整理。
文/Philip Li
Joy 於趨勢科技研發總部的 Software Quality Assurance / Software Engineering Process Group 擔任 Senior Director。團隊的任務在於使公司持續成長，變得高敏捷、高品質、高生產力，且須時常注意世界的變化，並適時引進公司。簡言之，就是在幫公司做改變的團隊。
Joy 於趨勢科技研發總部的 Software Quality Assurance / Software Engineering Process Group 擔任 Senior Director。團隊的任務在於使公司持續成長，變得高敏捷、高品質、高生產力，且須時常注意世界的變化，並適時引進公司。簡言之，就是在幫公司做改變的團隊。
2016年3月15日 星期二
1980年代啟發Scrum的論文-The New New Product Development Game-重點摘要(part1)
(photo credit : www.foxsports.com.au)
2/23 參加 ASM(Advanced Scrum Master) 講義中提到這篇論文[註1]，而且Jeff Sutherland 在「SCRUM：用一半的時間做兩倍的事」這本書中也提到這篇論文啟發Scrum，因此就找來拜讀。論文中提到 80年代許多公司愈來愈著重新產品的開發，新產品所佔公司的利潤跟70年代相比成長了將近20%。因此新產品開發過程的速度(speed)及彈性(flexibility) 便關乎公司的競爭力。
乎出意料地，文中提到的都是關於硬體新產品開發的案例，其中特別提出六個案例：
2016年2月18日 星期四
專案估算還是商業目標?
通常在討論專案時程時，經理和工程師想得有點不一樣：
場景一：
麥總(業務主管)：這一個專案你需要多久才能完成？我們需要在三個月內讓系統上線以便參加明年1月的CES。而且我們没有多餘的資源，所以你必須用目前的RD團隊來完成，這邊是要參展時我們系統需要有的功能清單。
小斯(Team Lead)：讓我回去跟團隊估算一下再跟你報告。
RD會議…
小斯：我們預估這個專案必須用到5個月的時間。
麥總：５個月！？你有聽到我說的話嗎？我之前跟你說的是我們需要這個系統在３個月內完成，這樣才能去CES參展！
在二人互動後，小斯心中可能在想：「麥總的要求真是不合理，怎麼要求我們Team用三個月的時間做5個月才能做完的事，說得比做得容易！」
而麥總心中則是在想：「這小斯完全不懂商業現實！他不能了解在系統在三個月準備好去參展是一件悠關公司生存的大事嗎？」
在這個例子中，我想麥總並不是真得要小斯去做專案的時程預估(estimate)；他其實是希望小斯擬定如何完成系統並準時參展的計畫(plan for a biz target)。
大部份的業務主管並没有足夠的技術背可以區分估算(estimates)、目標(targets)、承諾(commitments)跟計畫(plans)的差別。 因此RD主管便有責任將業務主管需求轉譯成更特定的技術項目。
底下提供一個比較有效的互動方式
場景二：
麥總：這一個專案你需要多久才能完成？我們需要在三個月內讓系統上線以便參加明年1月的CES。而且我們没有多餘的資源，所以你必須用目前的RD團隊來完成，這邊是要參展時我們系統需要有的功能清單。
小斯：我想再跟您確認一下，是「所以需求都100%完成」還是「要有亮點可以參展比較重要」?
麥總：我們一定要去參展而且要有新的話題讓行銷部門可以做文章。當然如果可能，我也希望所列的需求能夠100%完成。
小斯：我們會依照您所定的優先順序全力以赴，但如果RD團隊估算之後沒有把握交付100%的需求功能，我們是否還是要將已完成的功能整合後交付，還是我們可以在CES在後再交付？
麥總：我們一定要有新功能新話題去參展，但若情況很緊急，即使不是100%完整，我們還是要將已完功能包裝好。
小斯：好的。我會擬出一個時程計畫讓RD Team在未來3個月儘可能地完成最多的功能。
—————
如果你是一個 Project Lead/Team Lead，下次當你被要求提出一個專案時程預估時，你可以注意以下幾件事
- 了解你是要做估算(estimate)還是要去達成商業目標(target)
- 儘可能跟業務主管討論需求項目的 priority
- 依照 priority 採用增量式(incremental)的開發模式，完成一個新功能之後儘量都有一個潛在可交付(potentially shippable)的產品
2016年2月16日 星期二
視覺化的好處
今年春節和家人一起去走了鳴鳯古道，這條古道難度平易近人老少咸宜，非常適合我這種很久没運動的中年大叔。
自從我學習了「敏捷」這一把錘子，眼中則是看到跟敏捷有關的事物。今天要談的主題就是「視覺化」。
鳴鳯古道全程大約3.5公里，但路程中有30~40度的石板路，中年大叔走來還是給它有點喘。還有的是這條古道在整修時便將里程數作了醒目的石碑讓旅人可以知道走了多遠，離目標還有多久。有了這種視覺化的目標，沿途走來都可以當下的進度。
更厲害的是還有好心的鄉民每隔10公尺就在地上寫了里程數
這就像是 Sprint 中 burn down chart 的作用，在很短暫的間隔就可以知道又更靠近目標了，可以讓自己保持很高的戰鬥力啊！
倘若没有這些實體的標誌，還是可以拿出手機來看距離目的地還有多遠，但當你低頭喘氣時應該還是那些直入眼裡的標誌來得快速直接，這也是我比較喜歡在辦公室要放置實體看板的理由。
若是對鳳鳴古道有興趣，可以參考：苗栗文化觀光旅遊網- 鳴鳳古道
題化話：新春期間在古道上迎面相會時，大家都會說一句「新年快樂！」心情很好啊。下次去走步道時，也應該給對面而來的朋友一句問好。
2016年2月5日 星期五
Agile Tour Taichung 2015 回顧筆記
這次的 Agile Tour Taichung 能順利完成要感謝很多人，我在FB雖然已經先發文感謝了，但還是要再說一次：
感謝鈦坦科技(林昱承)、 微程式-夢種子(薛共和)、 光明頂創育智庫(賴銘堃)在經費,場地,座椅上的協助與支持。
Joy Chen, Aska Lee, Nor Chen, Erica Liu, Tony Chang 遠從台北、台南甚至抱病前來，不計較微薄講師費，為中台灣軟體圈注入敏捷開發的新力量，感謝各位慷慨無私的分享。
還有 Cash Wu, 莊家昇, King Jk 等朋友在寒流來襲，冷風大雨中幫忙載椅子、佈置會場。
這一次超精彩的 Agile Tour Taichung 感謝有您們的寒冬送暖，外面是凜冽的，會場卻是溫馨熱情的。
Max 給各位朋友深深一鞠躬。
Agile mindset 中最重要的就是"回顧(retrospective)" ，感謝的話說完了，接下來要自省一下。
做得不錯的項目：
- 我們事先先參加 Agile Tour Taipei, Agile Tour Taichung 的活動觀摩，也跟 David Ko 請教了許多細節。謝謝他在幕後的支援。
- 活動籌備討論主要利用 FB messenger 的群組討論、搭配 Google drive。活動前全體志工只有場勘一次，對一個60人的活動算是很有效率的方式。當然前提是志工平時在 Agile.Taichung 大家都很有默契了，而活動場地—夢種子也是大家熟悉的地點。
- 有一位參加的朋友私下跟我說：這次應該是賠錢的吧？若單單以報名費的收入來看是賠的，幸運的是有贊助商的支持能讓活動的預算能比較寬裕。
- 早上演講結束到用餐、用餐結束到工作坊、工作坊結束到回顧會議，這三個 session 轉換過程因為要移動座位而讓流暢度有些受阻，也謝謝參加學員的主動幫忙，桌椅的擺設可以很快地調整好。下次辦活動應該會找有大小會議室的場地，如此可以分開辦演講及工作坊，可以讓活動進行更流暢。
- 因為每個工作坊結束的時間一定不一樣，之後的回顧會議讓比較早結束的參加者稍微等了一下。下次活動工作坊之後就可以直接結束，不用再排一個整體的session。
- 這次的主要志工連我只有4位，當天人手明顯不足，因此這類的大型活動當天需要 full time 的志工來協助場控、場地、攝影、拍照、文字記錄等工作。
再二天就是猴年了，也祝各位朋友未來的一年萬事如意、財猿廣進！
2015年12月30日 星期三
女兒的寫作業看板流程 VS 小王子中的人生計劃
我前幾天在FB貼了一張為女兒寫作業時作的看板流程相片，似乎引起不少朋友的注意，有一位令我敬重的大姐好意的提醒我要去看「小王子」
，其實這個看板和「小王子」的人生計畫是有本質上的不同的，人生計畫是
而做這個看板的起因一開始是因為女兒寫作業時總是會分心（三不五時跑去看繪本、要跟老爸哈拉...），剛好最近在看＂Personal Kanban＂這本書，書中提到看板其實也可以應用到日常生活，所以我想可以試著用看板方法引導女兒如何一次專心做一件事。
利用這個在桌上的小看板提供視覺化的回饋，讓她在寫作業的過程中知道自己的進度，並且將注意力放在進行中的項目。
中間＂進行中欄＂在她寫作業時只能放一樣功課，等她完成那樣功課之後，她把那作功課移到右邉＂完成欄＂後才能再從左邊＂待辦欄＂拉下一樣功課到＂進行中欄＂。
＂待辦欄＂的優先順序是依照女兒自己的想法而決定哪一件事要先做，在排序的過程中我會引導她＂重要性高＂的項目要先做。而這個優先序順序在還没有進入＂進行中欄＂前都可以再重排，因為計畫要因應實際狀況作調整，例如有時前面的功課寫太久，而有的作業是三天後才要交，就可以先作明天立刻要交的項目。
另外在每一樣功課進入＂進行中欄＂時，我們會記下開始的時間，進入＂完成欄＂時則記錄完成的時間，用意是想幫她統計每樣功課所花費的時間，有了每日數據後她就可以再思考自己做同一樣功課的時間如何更有效率。
這是最近開始的實驗，應該還有可以優化的地方，但這只是小學生的看板，還是給它時間慢慢演化吧！
————
若您對敏捷軟體開發、精實創業有興趣，邀請您到「Max的敏捷想想FB專頁」來交流討論。
訂閱：
文章 (Atom)