.NET Walker

每年到了九月，總是會把這一段時間保留下來，並且特別準備好醞釀了好一陣子的內容，和學員們度過這幾十分鐘。 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... 不過我得說，現場參與跟會後的錄影，氣氛真是差太多了 :)

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

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

    很高興能夠再一次跟大家介紹嶄新的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 如果沒有安排好時間，沒有把時間花費在重要的(注意不是緊急的)工作上，專案要如期完成，近乎不可能。 而依照 柯維對時間管理的看法 ，要妥善使用時間，關鍵之一在明確可行的目標。有了清楚的目標，團隊才知道如何優先選擇該做的事情，並且如何做好每一件事情。 這點和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 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/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想要跟...

請留意這篇文章是我配合2014年六月底的研討會所撰寫的連續幾篇關於介紹如何透過VS Online以Scrum方式帶領專案團隊進行開發的其中一篇(其餘的會陸續發表)，因此並不完整，閱讀時請務必參考相關的 VS Online 標籤以閱讀更完整的前後文。   隨著專案的kick-off，我們會正式讓整個team開始使用VS online進行所有的工作與控管。 我大致說明一下我們在kick-off的前後所進行的工作。 (請讀者再次留意，我所分享的是我們自己在實務上的經驗和處理方式，所以不要留言來問我怎麼沒有依照某本書上說的Scrum方式來進行，因為我說過了，實務上我們必須依專案依團隊因時制宜，但你可以留言問我為何選擇這麼做而非那麼做，這部分則是很有討論和交換意見的價值) 首先，PO(Product Owner)是整個專案的負責人，我讓PO選擇自己的SM(Scrum Master)，並且讓PO和SM選擇自己的team member。理由很簡單，PO負責案子的成敗，因此PO當然有人事權，PO和SM可以選擇自己喜歡的team member，身分就如同教練和領隊一樣。要打好球賽，有時候選擇的球員並非是能力高超的，而是跟我有默契的，或是配合度高的。有時候能力超強的高手，並不一定會是個好合作的team member。 因此，我讓 PO/SM決定自己要的球員是誰，而最後不論結果如何，PO都負責整個案子的成敗。畢竟，人是你選的，失敗了也不用有太多藉口。 順帶一題，有沒有一個team member太受歡迎必須同時軋很多team的情況? 有，如果是這樣，由PO自己決定接不接受，接受了，就必須承擔風險。有沒有team member找不到歸宿，沒有PO選他??? 也有...這表示...如果有天真要裁員，你大概知道可以從誰下手了。 OK，團隊成員決定後，我讓SM在VS Online開立一個Project。 如果你完全不曾使用過VS Online，你必須先建立一個VS Online站台，細節請參考 這邊 。 VS Online站台建立好之後，你可以在上面建立無數個專案，建立一個專案的動作也請參考上述的文章，請注意在選專案類型時，請選擇Scrum Template(因為我們的專案整個走Scrum架構): 可以成功進入專案首頁之後，第一步，你必須做幾...

請留意這篇文章是我配合2014年六月底的研討會所撰寫的連續幾篇關於介紹如何透過VS Online以Scrum方式帶領專案團隊進行開發的其中一篇(其餘的會陸續發表)，因此並不完整，閱讀時請務必參考相關的 VS Online 標籤以閱讀更完整的前後文。   坊間已經有不少介紹Scrum的相關書籍，其中也不乏很完整介紹整個Scrum的本土書籍，而讀者們也可以在網上找到不少介紹的資訊，因此，我並不打算很詳細的討論整個Scrum的每一個環節，而是希望在這篇文章中，著重在Scrum的實際執行經驗分享，以及如何搭配我們所採用的工具，也就是 Visual Studio Online。   這邊也稍微說明，讀者必須了解，要說Scrum是一個進行軟體專案方法(methodology)，不如說是軟體開發與專案管理的風格(Style)或框架(framework)，有趣的是，如果你用這幾個關鍵字上網google, 你會發現不少blog在說明Scrum到底是什麼? 有人說是方法、有人說是流程、有人認為不該說是流程，有人則認為是一個框架...然後又有一堆文章在討論敏捷開發(Agile)與Scrum的關係云云...   坦白說，我看了很久，但最後覺得，這些對我來說都不太重要，因為 我在乎的只有一個，就是如何讓專案有好的結果 ，我只需要知道Scrum可以幫助我就可以了，至於其他的，等我開始實作了再說...   (所以我誠心建議，當你照著我或其他Scrum傳教士的介紹，準備開始在自己的團隊中實施某個動作時，請務必務必，要知道為何要這麼做...)   也因此，這篇文章就不討論Agile, Scrum之間的關係, 他們和CMMI以及waterfall開發方式之間的差異，以及到底是方法還是框架之類的話題...   我們直接來看, 採用Scrum的時候，會有那些程序(有別於傳統專案進行的SA, SD, Programming...階段...etc)。討論這個，用的當然就是底下這個比較動感圖:           由於Agile的精神之一，在於將一個較長的開發週期，細分切割為多個iteration, 在Scrum我們稱之為 Spr...

請留意這篇文章是我配合2014年六月底的研討會所撰寫的連續幾篇關於介紹如何透過VS Online以Scrum方式帶領專案團隊進行開發的其中一篇(其餘的會陸續發表)，因此並不完整，閱讀時請務必參考相關的 VS Online 標籤以閱讀更完整的前後文。 Scrum和敏捷開發，在這幾年幾乎變成顯學。這很有趣，如果你深入觀察，會發現Scrum和過去的專案運行模式，有著 "根本上" 的差異。 而且確實，我對Scrum有些 "自己的" 看法。 在討論這些之前，首先，我必須先強調一件事情。我在團隊中導入Scrum，並不是為了要研究或驗證Scrum，也不是為了要遵循大師的腳蹤，更不是為了要體驗一下新的專案運行方式或是新的工具...都不是。 執行Scrum的理由只有一個，而且非常簡單，就是我們(專案團隊)希望讓案子成功。 會這樣說，是因為過去這十多年，在台灣，我們參與、執行、聽聞大大小小的案子，失敗不勝枚舉，幾乎沒有多少案子是在客戶和開發團隊都滿意的狀況下收尾的。專案不是延遲、就是超過預定的人天成本、再不然就是數不盡的客戶需求變更、或是解不完的Bugs和無法預測的未來、再加上客戶的預算和我們的成本看來永遠無法達到平衡。 經歷的案子越多，就越來越覺得這不是一個辦法。 客戶對於專案預算壓低又壓低、要我們提供報價卻不知道專案的範圍與具體內容、每一個案子的能見度都非常低，PM、開發人員、沒有人知道案子將會怎麼收場... 說真的，我們受夠了這樣的生活。 敏捷開發和Scrum的出現，讓我們『聽說』有一個更好的方式，讓客戶和專案團隊都過的開開心心。並且大家認真扎實的面對專案中的每一個問題，用合作與信任替代稽查、用溝通協調替代文件、用最簡單的工具和方法，讓整個專案回歸基本面。 由於我們是認真的開發團隊、有著相當資深的開發人員，我們不希望用哄抬的方式膨脹案子的預算，然後再打折來成交。我們的開發團隊真心喜歡編程，我們一點都不希望我們熱愛的工作在專案裡卻變成痛苦的來源。(真心話) 我們相信客戶想要一個真正能夠使用的軟體產品，而不只是想要結案交差，我們相信軟體可以有效的幫助企業實現利潤，而不只是畫一個美好卻遙不可及的大餅去騙客戶的錢。我們希望客戶真的使用我們所開發的軟體，讓我們的軟體創作與建設真正幫上客戶的忙。 所以...