發表文章

preparation is the key...

圖片
還記得我去年寫了一篇文章,關於『 練習 』,看看時間,剛好快一整年。 當時寫『 練習 』這篇文章時,是因為同時間看到了一些讓我挺有感觸的東西。一個是當時跟大家提過的日劇Dinner,一個是Robert C. Martin的The Clean Coder。而剛好那時候又碰到TechDays結束,忍不住把一些心情整理下來,這也是後來在 MVP Open day 當中,會和朋友們談到我自己的一些學習過程的緣起... 後來,曾經有學員(也是朋友)私下問過我,如果凡事都需要那麼多練習,那豈不是沒有生活的時間了嗎?真的每一個所謂成功的人,都那麼精實的訂定自己的『目標』,都那麼積極的過每一天的生活??? 當時我沒有回答,因為我不知道該怎麼回答。 我不知道的是,是不是只有我看到(學到)的是這樣?我無法肯定是不是一個通往夢想或實現目標的正確方程式就一定是如此;同時我也不能那麼肯定,這就是唯一正確的道路。 一年之後,我看到了一場兩年前的演講,讓我可以更肯定地跟朋友們分享:或許我在上課時提到的那些(目標、努力、練習...etc),不一定是通往夢想的標準答案,但顯然不只我一個人這樣做(或這麼想)。 或許通往成功的方向有很多條路,但更多的準備,絕對是讓你在這條路上可以走的比別人更快的方法 。 可能是因為幸運,我求學階段沒有太多參加補習班的經驗,我也沒有去過台北知名的補習街上過太多的課,所以對於補教界的老師也只是耳聞(雖然某種程度上來我,我自己搞不好也 算是補教界的一份子...),再加上前幾年風風雨雨的補教人生,可能讓很多人從新聞媒體上看到的印象是很負面的。 不過如果暫且撇開這些不談,主講者在工作上的努力,和對於目標的專注與積極的準備,是讓人相當欽佩的。 顯然在極度競爭的市場中,要擁有一席之地,倚靠的絕不會是僥倖。 本來只是假日想讓讓自己休息所以找個演講用聽的,點開youtube時不很期待,但沒想到她的演講講的很好,比我預期的要好~非常多... 整場內容時間不短(但卻一點不會沉悶),講到目標、講到夢想、講到教學、講到熱情、講到練習、講到努力、講到核心價值...etc.這些主題都是我熟悉的(甚至是我自己講過的),但能講得這樣吸引人真的很不容易,講者在演講和授課技巧上算相當不錯...推薦給當講師的朋友 或 想當講師的朋友(part 2還談到了教學技巧和怎麼準...

飛機上的27A - 談敏捷開發的成案問題

  最近看一本書,書名就是這篇文章的標題『飛機上的27A』,剛好工作上發生一些事情,頗有一些感觸。 這是一本小書,也是一本小說,我是看電子書,但看完之後我又買了紙本書(送給身邊的朋友)。書中一位成功的企業家對於選擇合作對象的想法,讓我重新省思一些幾乎快被我忘記了的原則。 書中主角是一個成功的年輕人,算是在當今這個營營汲汲的資本主義社會中的佼佼者,然而有一天,他在飛機上碰到了這位很不一樣的企業家,在企圖爭取這個企業家成為他的客戶的過程中,他所學習到的一些故事。 看完這本書後,讓我回頭思考的問題是,這個世界不知道從什麼時候開始,充斥著各種商業與管理技巧,各種tips類型的準則,讓我們目不暇給,眼花撩亂。時間管理? 談判法? 如何成交? 銷售的心法? 甚至連生活都有小技巧...然而被這些tips轟炸的同時,我們都忘記了很多最基本的原則。 其中之一,就是『誠信』。 為什麼對這個特別有感觸? 書中的企業家選擇合作的廠商,首先看重的不是獲利能力、不是資本額、不是折扣的高低、或是交易的利益。而是這家公司的誠信、道德操守、以及員工、經理人的人格特質,和公司文化。 我發現上面這一行最後幾個字,幾乎是我們現在在報章媒體上已經很少看到甚至很少被用的文字了。 最近一兩年,我們的開發團隊整個改為agile與scrum,然而碰到最大的挑戰,並非制度與工具、也不是人員或方法。坦白說,最大的問題是外部的客戶、採購與銷售。 Scrum在意團隊,也在意客戶,agile從軟體開發最原始的角度出發,我們希望建構一個客戶能用、好用的軟件。說真的,這可能是每一個軟體開發人員最原始的初衷,沒有人希望自己寫的code只能看不能用(或是不能看也不能用)。 然而,從這個角度出發,實際上會碰到最嚴重的問題,其實往往是『信任』。 依照Scrum,最合理的合約與付款方式是 time material ,也就是合約金額不固定。原因很簡單,因為我們隨時接受需求變更,如果隨時接受需求變更,那總工時當然也會跟著變更,沒有道理總工時調整了,合約金額卻不變吧? 這種合作模式,time material當然是最理想的付款選擇。 然而,這在台灣幾乎被視為不可能。 客戶總是希望固定付款金額,固定工時(遲了還要罰錢),但需求內容則在成案後還是會變更(好一點的客戶會註記變更幅度不超...

廣告:敏捷開發專案管理 與 架構設計實務(電子書搶鮮版)

圖片
這 本手冊是光岩資訊董大偉老師在『敏捷開發專案管理與架構設計實務』課程中的內部訓練教材。董老師以十多年軟體專案與產品開發經驗為基礎,採用Scrum與Visual Studio Online作為專案管理框架的實戰經驗分享,內容相當難得。與坊間的PMP專案管理、CMMI、瀑布式(waterfall)開發有所不同,本書內容為第一手的敏捷開發實戰經驗,不僅如此,這本書也並非傳統照本宣科的Agile/Scrum教材,而是結合了華人特有的專案運作模式與管理制度和文化,所凝結而成的經驗分享。         內容以Scrum為骨架,搭配Visual Studio Online為實作工具,從專案的kick-off開始,一路談到專案開發的整個Life-Cycle,內容包含工作項目的管理、Features, Backlogs, Tasks, Bugs的建立、管理、追蹤與維護,包含測試與stakeholders的反饋蒐集,也包括Scrum的周期性工作說明與經驗分享。         在本書中,董老師透過實際專案運用Scrum的經驗,以第一人稱的角度,將運用Scrum和VS Online的第一手經驗真實的呈現給學員,同時也和學員一起探討,面對在華人(特別是台灣)特殊的軟體專案氛圍下,各樣實施Scrum所發生的衝突和解決之道。更豐富的是,書中不僅僅介紹如何採用VS Online進行Scrum團隊開發,更進一步的討論到了如何透過架構與開發框架(Framework)設計,來解決專案經驗不足的團隊,採用Scrum時可能有的水土不服、品質低落的問題。透過開發框架(Framework)設計,簡化開發方法與程序,配合ALM工具和敏捷開發精神,讓您未來面對專案或產品開發更有信心。         不僅如此,這本書也集結了董老師這幾年來,在不同場合分享的Developers生存之道,是一本與資訊技術密切相關,卻又適合技術人員在茶餘飯後細細品味的書籍。 言盡於此,其餘的,就由讀者自行體會了。 此版本為搶鮮預覽版,後續會持續更新( 如何更新 ),但也可能調高價格!(越早買越便宜)...

[研討會] TechDays 2014 Taiwan

每年到了九月,總是會把這一段時間保留下來,並且特別準備好醞釀了好一陣子的內容,和學員們度過這幾十分鐘。 http://www.microsoft.com/taiwan/techdays2014/default.aspx 今年比較特別,比起往年總是分享特定的開發技術,今年則是首度和學員們分享軟體專案管理、ALM(Application LifeCycle Management)以及Scrum/Agile的導入心得,對於陪著我一起學習成長的學員來說,應該會有著不同的感觸吧... 相關的Slides可以從這邊找到: http://www.microsoftvirtualacademy.com/training-courses/techdays-taiwan-2014-breakout-sessions-dev 課程編號是DEV307... 不過我得說,現場參與跟會後的錄影,氣氛真是差太多了 :)

[影片] WP8 1 Navigation Model 簡介 - WP8.1/Win8.1 App

圖片
底下這段影片,是2014八月底在微軟7AB跟學員們介紹WP8.1的開發以及Universal App的部分Demo片段(重錄),如果對同時開發WP8.1與Win8.1 App(也就是Windows Store App)有興趣,想知道 WP8 1 Navigation Model ,可以參考底下這段影片...  

[影片] Common Xaml UI Framework, 簡介 - WP8.1/Win8.1 App 如何共用XAML UI與Code

圖片
底下這段影片,是2014八月底在微軟7AB跟學員們介紹WP8.1的開發以及Universal App的部分Demo片段(重錄),如果對同時開發WP8.1與Win8.1 App(也就是Windows Store App)有興趣,想知道如何手機和平板如何共用XAML UI/Code的開發人員,可以參考底下這段影片...

[研討會] 初探 Windows 市集 APP 開發 (Windows 8.1 / Windows Phone 8.1)

圖片
    很高興能夠再一次跟大家介紹嶄新的Windows Phone  8.1相關開發技術,這個場次相關的內容,包含投影片、範例、以及影片和書籍,將會在近期公布,請持續關注本網站或加入 FB 專頁:  https://www.facebook.com/DotNetWalker   prezi 投影片位置 : http://prezi.com/snoqghmlt9km/?utm_campaign=share&utm_medium=copy     [影片] Common Xaml UI Framework, 簡介 - WP8.1/Win8.1 App 如何共用XAML UI與Code  

PM,你必須真的在乎團隊才行

圖片
最近,我們有一個開發團隊發生了些狀況... 過去,我曾多次的研討會上,跟開發人員分享過,想要順利準時地完成專案,一個很嚴肅的重點,就是有效的時間管理(注意不是工作管理)。倘若開發人員、PM 如果沒有安排好時間,沒有把時間花費在重要的(注意不是緊急的)工作上,專案要如期完成,近乎不可能。 而依照 柯維對時間管理的看法 ,要妥善使用時間,關鍵之一在明確可行的目標。有了清楚的目標,團隊才知道如何優先選擇該做的事情,並且如何做好每一件事情。 這點和PMP式的專案管理有很大的不同,有時候我們並不會很具體的把每一個task做WBS展開,然後讓PM畫出美美的gantt chart,並且用要徑法算出時程...etc。我一直說,Scrum/Agile在意的是一個團隊,而這個團隊當中,大多數的成員都是聰明人(能夠寫程式的,大致上資質不會太差),要帶領(注意不是管理)一票有腦袋、有自己意見的聰明人,PM/PO該做的不是管理,是領導。 中間的差別在,管理一群人,是你叫他做這個、做那個、接著你去衡量產出的成效與品質如何,不及格? 再來一次,還不及格? 我們來點改善手段...再不及格? 把這個零件(人)換掉...etc。 而『領導』一群人,則是你告訴他們要實現什麼、成果該有怎樣的質量、我們有多少預算或時間、可能會有那些限制...接著,你讓大家放手去做。 感覺出這中間的差異了嗎? Scrum/Agile development 走的是團隊模式、使用的是經驗法則、在乎的是務實的成效、略過了複雜的管理手段,專注在將成品實現。 這樣,有沒有像是一個球隊? 在場上時,教練和領隊無法告訴你,這顆球往這邊跑的時候,A球員你就向左衝、B球員你就擋著,C球員你就奮力後退...如果團隊這樣打球,是不成的。 Scrum在乎的是團隊合作,而團隊中的每一個人本來就各有所長,教練和領隊的功能,是看出並善用團隊中的每一個獨特的成員,關心每一個人心裡的期望,重視團隊中每一個成員的差異,然後把這些人拉聚在一起磨合、重塑,發揮1+1>2的綜效。 這,才是一個團隊。 如果拿這個標準來量量,你會發現許多的軟體專案團隊,其實稱不上是個團隊。 也因此,PM/PO,必須給團隊一個清楚的目標,然後告訴團隊我們所碰到的限制,接著和團隊一起來衝刺、並且面對、解決每一個可能遭遇的問題。 回過頭來...

[研討會] 2014 Microsoft ALM Day

圖片
很高興有機會和大家在 2014 MS ALM Day 中分享關於 Scrum/ALM以及VS Online和Azure的使用心得,相關的的內容和影片,我會陸續整理出來,如果您沒機會來現場,可以先參考底下幾篇blog: [經驗分享]如何用VS Online及Scrum帶領兩岸三地團隊進行專案開發與管理 - (一)緣起 [經驗分享]如何用VS Online及Scrum帶領兩岸三地團隊進行專案開發與管理 - (二)讓我們來聊聊Scrum [經驗分享]如何用VS Online及Scrum帶領兩岸三地團隊進行專案開發與管理 - (三) 帶領團隊走第一步 - Scrum中的角色與做法 [經驗分享]如何用VS Online及Scrum帶領兩岸三地團隊進行專案開發與管理 - (四) 開始使用VS Online與Scrum Template [經驗分享]如何用VS Online及Scrum帶領兩岸三地團隊進行專案開發與管理 - (五) 從蒐集 Features 開始 還沒寫完,後面的我盡量努力找時間整理...(to be continued...) hope it helps.

[經驗分享]如何用VS Online及Scrum帶領兩岸三地團隊進行專案開發與管理 - (五) 從蒐集 Features 開始

圖片
VS Online/VS 2013針對Scrum的工作項目管理,是以下圖這樣的層級來區分的。從Features到Tasks是有著一對多的層級關係的,例如一項Features可能會有多個Backlogs,一個Backlogs可能會有多個Tasks這樣。跟Backlogs平行(層級)的還有Bugs,在一個Bugs底下也可以區分tasks,像是這樣: 一個軟體系統的一切從蒐集Features開始,你可以把Features看作Wish List,也就是這個系統、或是這個專案要有那些功能。 這邊有一個地方您可能需要注意。在台灣,實務上,不管在做的是一個專案(標案)或是產品,老闆(客戶)都會要你寫規格書,然後依照這個規格書來開發。這個規格書可能是SA與客戶(End-Users或IT部門專案的Internal Users)訪談後的結果,過去,我們花了很多時間在建立這個規格書上(然後再從這個規格書算出專案成本和工時)。 但我們前面說過過,在這個多變的時代,規格是一天到晚在改變的。也就是說,基本上傳統的規格書現在幾乎可以說是廢物。如果依照waterfall的開發方式,規格書應當要持續更新,要能夠隨時反應系統的現況,但這在現實情況下很多專案上幾乎不可行。 PM/SA不太會去更新規格書的內容(有的案子PM/SA根本是兼職的,分析完就閃人了),客戶對規格的變更也不會回頭寫在規格書上(甚至有時候是直接跟Developer用口頭講的、或發個mail了事),一個專案只要run了三個月下來,規格書基本上就等同於作廢了。 更荒謬的是,實務上規格變了,更但合約上的價格和時程卻不變更,專案的預計完成時間和逾時的罰則也不變,這樣的專案想不賠錢收場很難很難。 回頭談規格書,因此你會發現,不管是SOW或是SA後的Spec,在很多專案中,可以說是參考用的。坦白說,如果能參考也就罷了,很多時候是連參考都不行,有爭議時回頭翻規格書,才發現根本沒更新,或內容模糊不清太多細節沒有釐清(甚至為了成案或驗收之便,刻意保留模糊,保留空間以利各自解讀)。這樣的規格書大概只能用來在kick-off前後交差,對開發工作一點幫助都沒有。 因此,我們不寫規格書了。現在,我們只寫Features與Backlogs。(而且就儲存在VS Online中,不會另外弄個document,如果PO/PM想要跟...