.NET Walker

前陣子在上架構與框架設計的課程時候，提到幾件事情。我說... 要設計出好的架構不難，但真正能夠實施(implement)在團隊中的卻很不容易。 架構設計是一種取捨，沒有絕對完美的做法，有得，就有失，架構師除了要有足夠的技術能力，更重要的是，要有足夠的溝通能力。 架構設計只有一件事情最重要，就是能夠實施(implement)，無法實施的架構，再美也是枉然。(不能實施的因素有很多，除了設計的好壞，更多的時候是架構師是否能夠同理開發人員技術程度，以及能否在導入時突顯這個設計的優點) 架構與框架的設計與導入，不僅僅是建構開發團隊的基礎，更是一種引導或限制，讓開發人員被框在某一個規範中，在有限制的狀況下自由發揮(我甚至補充，在軟體開發和專案管理的世界中，過度的自由是一種罪惡) 。 我無法在有限的課程時間中，解釋某些事情。因此，趁著有空且記憶猶新，我想來談談我們過去一兩年做的架構設計，以及為何我要求台灣和China幾個團隊中，所有的成員(PO/PM, SD/SM, Developers)都必須採用這樣的架構。 =================================== 先講講背景... 最近這幾年，我們在Web開發上揚棄了從服務器端產生HTML的方式，而改採接近SPA(Single Page Application)的model來進行專案開發，也因此，整個ASP.NET MVC，嚴格說起來，我們只有用WebAPI，其他的部分都是透過我們自己開發的框架(Framework)來搭配與運行。 簡單的架構圖如下：   在這個架構底下，Framework 本身負責 Services Layer(中間橘色的那塊)、Client 端對服務器端 Server Components 的調用(呼叫)、以及 Cross-Cutting Components(左方豎著的那塊)。 採用此Framework 架構的開發人員，只focus 在底下2個部份的開發，而將其他部分交由這個Framework 處理，分別是： Server Components 開發   Server Components 以.NET Assembly(.dll)的形式開發，開發人員可以建立標準 的.NET 4.5.x Class Library，透...

先前我們在 這一篇 當中，曾經介紹過如何從Features展開Backlogs，但也有非常多的狀況是直接產生(建立)Backlogs，這時候我們就有可能需要重新連結(對應)Backlogs與Feature之間的關係。在這一篇當中，我們來看看這個部分。   前面說過，你可以從Features展出Backlogs，這部分實際上操作時很簡單，你只需要在Features畫面中，依照底下的方式，就可以透過『+』從Features以展開的方式來撰寫Backlogs了。   但如果你的Backlogs是獨立寫好的，或是先寫了Backlogs，後來想要讓它歸屬於某一個Features，或是調整Backlogs的Features，可以怎麼做呢?請參考下圖： 你可以先把Backlogs與Features的Mapping打開，即可拖曳特定Backlog到特定的Feature身上，以建立(或修改)兩者之間的關係。 此外，如果你觀察Product Backlogs的輸入畫面，會看到畫面右上部分，有一個forcase，可將其設為On，接著，會出現一個Forecasting Velocity讓你輸入調整（每個Sprint的工作量），設定後，即可看到如下圖的預估： 你會發現，系統已經參考了我們輸入的參考工作量，依照Backlogs的順序，計算出會大致落在哪一個Sprint ，這個功能非常的好用，能夠讓客戶一目了然的知道特定的Backlogs大約會何時開始開發。 但請留意一下這張圖，坦白說這張圖乍看之下不是很容易理解，所以我特別用藍底白字的箭頭，標註了一下Sprint。你會發現，編號1,2,3這三個Backlogs，是屬於Sprint 6進行開發的，而編號6,7,8,9則是屬於Sprint 8進行開發的。特別標註是因為，如果你把藍底白字的箭頭拿掉，你可能會以為編號3,4兩個backlog items是屬於Sprint 6，而編號5,6,7,8的backlog items是屬於Sprint 7，那可就誤會大了。 本篇收錄自 - 『 敏捷開發專案管理與架構設計實務 』

http://www.microsoft.com/taiwan/events/azure-enterprise/   在這個場次的研討會中，再一次地跟大家分享，透過VSOnline與Scrum如何讓團隊在專案管理與ALM上有個好的開始。由於時間比較長，因此這回比較完整的介紹了從kick-off開始之後，我們的專案團隊如何透過VS Online處理專案(或產品)開發的每一個Sprint，錯過的朋友，明年應該還有機會喔。   

每一個Backlog都有可能因著PO或Team Member的調整，而改變了狀態或內容，這個改變可能來自於團隊成員，也可能是擁有權限的任何人。但你不需要擔心，work item的每一個調整，哪怕只是上傳了一個檔案，或是在description中增加或減少了一個字，你都可以透過History看的一清二楚，因此不僅不用擔心被異動，也不會有資料經過修改後遺失了的問題。 要看到Backlog的History，可以開啟Backlog，接著點選 History：       進入到History之後，你可以更清楚的看到，該Backlog狀態的改變、以及Backlog的所有異動： Backlog和專案中的每一個工作項目(不管是Task/Features/Bugs…etc)都是開發團隊相當關注的部分。也因此，每當這些Work Items有異動的時候，老闆們(或是PO)可能都會想要知道。 因此，VS Online除了讓你可以從Backlogs/Task的History中看到變更之外，還可以透過訂閱的方式，來隨時掌握這些Work Items的異動。 你可以進入Project的首頁，在右上方有個『工具』的圖示： 點選該圖示後，會進入到管理畫面(請留意，必須具有管理權限才可以進入)。進入後請按下Alerts頁標籤，接著會看到底下畫面: 你可以從左方的選單處看到該專案所有的Alert，而右半部則可讓你建立或修改Alert。 當你點選New來新增Alert之後，會看到底下視窗：   你可以選擇Alert的範圍和類型，按下OK後即可新增。在底下的新增畫面中你可以看的出來，是依照剛才選擇的Alert範圍和類型所建立的。當然您也可以自行客製化調整，增加判斷條件，或是這個通知的發送對象。   按下OK鈕之後，這個Alert就建立好了，也同時間生效。此後，一旦Work Item有所變更，訂閱者將會收到類似底下這樣的email:   對於開發團隊來說，是相當好用的機制。   本篇收錄自 - 『 敏捷開發專案管理與架構設計實務 』

在實務上，專案可以不寫Features，但不可能跳過Backlogs。 由於蒐集好Features之後，基本上Features只是客戶的Wish List，談不上是什麼規格，基本上只是針對系統需求的期待而已。因此，我們會讓PO稍微排一下優先順序(當然是參考客戶的意見)，接著，開始把Features展開成為Backlogs。實務上，你也可以把Features視為Backlogs的大項分類。如果系統不是很大，那只寫Backlogs不寫Features(或是用後面會提到的階層式Backlogs取代Features)也並無不可。 如果參考微軟MSDN網站上的翻譯，微軟把Backlogs稱為『待處理項目 』，類型上還分為三種。 不過我倒是覺得，我們可以從比較扼要的角度來看Backlogs(簡化可以降低工具和開發方法導入的困難度)。 在這邊，我們先簡單定義一下。我們將一開始建立好尚未放入Sprint中)的Backlogs，統稱之為Product Backlogs，至於進入Sprint之後，被放入特定Sprint中的Backlogs，我們稱之為Sprint Backlogs。因此，剛寫好的Backlogs，全都是Product Backlogs。 至於何時要將Product Backlogs放入特定Sprint(成為Sprint Backlogs)? 則是Planning Meeting要決定的事情了。(會在後面Planning Meeting中介紹) 此外，剛才前面有提到過，多個backlogs之間，也是可以有階層關係的，例如:   這個階層也可以視為Backlogs的分類，有點像是Features的意味。   Backlogs 的來源其實有很多種可能性，原則上大多是從 Features( 或是上一層的 Backlog) 展開，或是直接從系統分析後的規格書謄過來。   ===================================== 備註：         這邊要做一些說明，一般來說，我並不會希望團隊在run scrum的過程中，額外多一個撰寫系統分析說明書這一段。因此，我們一般是直接針對end-user做系統需求訪...

這是一篇我很早就想寫的文章。 我常常把標題列著，放在Blog的文章清單裡，但放著放著，半年就過去了，可能只是因為我一直找不到好的例子，把我想解釋的想法或概念，有條理地跟大家分享。這一篇，就是最典型的狀況。 我一放，就放了半年。直到今天和Team Member剛好討論起相關的議題，才讓我重新把這篇整理出來。 想說的很多，但題目卻很簡單，就是『專人專用』。 自己做專案很多年，不僅接觸過很多公司，也接觸很多接案的外包的單位。我可以說，幾乎沒有任何一個開發團隊，團隊中負責Coding的開發人員，是100%的專人專用。幾乎每一個所謂的『團隊』，開發成員身上都是兼著2-3個案子。也就是說，絕大部分的開發團隊成員，身上都不只一個案子。如果是PM，那就更慘，大多數的PM肯定都身兼多個案子。這還不包含不需要談規格和需求的維護案。 其實對我來說，這是一件很弔詭的事情。但，在這業界似乎卻是常態。 年輕時，不只一次，我曾在專案裡要求我的team member是100%投入，不得兼任其他案子的任何角色，然而，過去幾乎每一家公司的老闆，都曾跟我說過：不可能。 不管我擔任甲方或乙方，這種結果幾乎如宿命般的相同：就是開發人員『總是』身兼多職，同時也身兼多案。在比較具有規模的接案團隊中，『搶資源』有時候還變成某些PM的強項咧。 但有趣的是，任何腦袋清楚的Developer，都會告訴你，只要身兼兩三個案子後，自己的工作效率就會開始變糟、程式碼的bug數也開始變多。事實上最理想的狀況，其實是讓Developer同一個時間，只參與一個案子。但任何老闆都會跟你說：我知道，我也希望這樣，但這是理想狀況，現在實際上....(後面的就不用多說了) (我甚至聽過有公司應徵developer的時候，其中的問題是...你的『抗壓性』如何? 你可不可以身兼多案? 能不能在專案中快速的轉換? 碰到這種公司，我勸Developer好自為之。) 因此，只消幾年業界經驗之後，Developer就知道，這是一個不用抗爭的事情，幾乎在任何公司、任何老闆、都會讓你身兼多案，屢試不爽，毫無討論的空間。 但有趣的是，任何客戶都不希望這樣，如果是賣人力的time material合約，大部分的買方，即便沒有要求on site，也會要求人力不能兼任其他客戶的案子。當然，沒有on site就不好控制，...

『薛西弗斯是希臘神話中的一個人物，他因為卓爾不凡的智慧惹惱了眾神。作為懲罰，他雙目失明並被判永久的將一塊大石頭推上山頂，但最終都不可避免地要承受著大石頭滾進山谷的結局。』-- wiki 第一眼看到 這篇 ，吸引我注意的，當然是照片中推著石頭的薛西弗斯。從某種角度來說，薛西弗斯絕對是一個悲劇人物，而這篇出現在『 猴子靈藥Blog 』上的 文章 ，也真的道盡了創業者所要面對的辛酸，以及不為人知的心路歷程。 文中有一段，引了『梁宁』寫下的… 『在创业的真空里，没有人告诉你，该做什么，停止什么，该往那里去。你再也不能通过迎合某人的要求而换得晋级。』 上面這段話，我感觸尤其強烈。 因為種種的因緣巧合，我在約莫10多年前，離開了穩定的園區工程師生涯，後來從事寫作、顧問、教育訓練…等工作，一直到後來參與成立自己的公司，雖然這些確實都是我的興趣(何其有幸)，但這也確實並不是一開始我人生規劃中曾經考慮的路徑。 不少朋友以為，這樣的『講師』生活肯定多麼愜意。事實上是，離開了所謂上班族的生活之後，要不了多久，你確實就會開始感受到生活的的確確、明顯的和上班時有所不同。 首先，準時早起上班開始變成工作中的非必要條件，但換來的則是忽高忽低的不穩定的收入，以及強烈的不安全感。 我曾經多次跟身邊的朋友說，當你開始變成所謂的SOHO，只消幾個月的時間，你就會發現你無可避免的，會幫自己接下超過你原本上班時所能接受的工作量還來的多很多的工作(所以比起上班時更不自由、時間更少)。為什麼? 很簡單，因為你再也不會有固定的薪資在每個月固定的那一天匯到你的帳戶(我得說，回頭想，每個月能夠固定領到錢，就是一種幸福)。你開始必須自己估計每一筆款項可能進來的時間，並且，預先為客戶可能發生的延遲匯款自己事先做好準備。 在你上班時，你理所當然的認為從來不需要擔心的問題，在你變成SOHO之後，開始變的得要自己小心管理。不過這還算OK，只要謹慎一點、量入為出，積極一點、拼命工作，再加上你的產品(也就是你自己)還賣得出去，那大致上不會出什麼大問題。 只不過，你再也沒有上班時的那種…生了病可以請假、下了班可以暫時把工作丟在一邊、國定假日可以自在地休息…的日子了。當自己要為自己的收入負上100%的責任時，你的人生觀會立刻開始有所不同。 因為你清楚地知道，你得為自己的工作績效與成敗負上完...

如果你有購買PubU平台上的電子書，像是『 敏捷開發專案管理 與 架構設計實務 』。 我們不時會更新電子書，更新時會在我們的FB專頁上通知，當您看到通知，即可試著更新您的電子書。底下以ipad為例，您進入系統後，可以嘗試點選右上角的更新鈕： 接著你會看底下的更新畫面： 完成後您即可閱讀新版的電子書囉。