2017年6月21日 星期三

關於LineBot(9) - 取得新加入的好友身分資訊

在知道了如何建立LineBot的WebHook之後,許多朋友開始有了另一串問題。其中我最常被問到的就是,如何在用戶加入你的bot為好友的時候,取的用戶的身分xk7。

這個問題中有兩個關鍵:

  1. 用戶加入你的bot時,你如何得知?
  2. 如何取得特定用戶的身分資訊?

這兩個動作都不難,都可以在我們的WebHook中取得。

首先,當有一個新的用戶加入你的Bot為好友時,我們可以從WebHook取得的JSON得知,透過我們的SDK,你可以很簡單的以底下的程式碼判斷:

if (ReceivedMessage.events.FirstOrDefault().type == "follow")

{

}

因為新加入好友或是被解除封鎖,都會收到type是follow的event,因此上面的程式碼很容易判斷出有新的好友來了…

而得知新好友(用戶)來了之後,我們可以透果底下這一行取得用戶資訊:
var userInfo = bot.GetUserInfo(ReceivedMessage.events.FirstOrDefault().source.userId);

得到userInfo物件之後,你可透過 displayName 輕鬆取得用戶暱稱,也因此,我們把用戶暱稱顯示出來:

bot.ReplyMessage(ReceivedMessage.events.FirstOrDefault().replyToken, $"哈,'{userInfo.displayName}' 你來了...歡迎");

得到的結果就是:

當用戶加入某個bot為好友,或是解除封鎖,都會收到follow,我們上面的程式碼抓到用戶名稱,顯示出來,結果就是上圖這樣。

很容易吧,試試看囉…

hope enjoy it…

此範例原始程式碼位於 : https://github.com/isdaviddong/LineBotExample_GetUserInfo/blob/master/LineBotExample_GetUserInfo/Controllers/LineBotController.cs

--------------------------------------------
相關課程: http://www.studyhost.tw/NewCourses/LineBot
如果需要即時取得更多相關訊息,可按這裡加入FB專頁。若這篇文章對您有所幫助,請幫我們分享出去,謝謝您的支持。 

2017年6月2日 星期五

關於asp.net framework的本質

很久沒有聊聊asp.net了,但畢竟asp.net跟我緣分不淺,或許該找個時間來談談。不過,今天我們試試看換一種方式,也讓大家自我挑戰一下,題目來囉...

  1. 我們說asp.net是一個web開發框架(framework),現在的asp.net framework提供了三種不同的方式(途徑、架構、風格)來建立網站,分別是哪三種?
  2. 這三種分別有哪些特性(或優缺點)呢?
  3. 這三種可以混用嗎?

來公布答案。

首先,千萬別執著對錯,因為我這題目本身就很爛(題意不清),其實我們應該把.net core和asp.net分開來看...這題談的不是asp.net core, 但題目沒說清楚,會讓人誤會。

因此,重點不是對錯,而是我們要藉著這題目來釐清整個asp.net的架構與觀念。

首先,題目與答案都在這邊:

ASP.NET is great for building standards-based websites with HTML5, CSS3, and JavaScript. ASP.NET supports three approaches for making web sites. ASP.NET Web Forms uses controls and an event-model for component-based development. ASP.NET MVC values separation of concerns and enables easier test-driven development. ASP.NET Web Pages prefers a single page model that mixes code and HTML markup. You can mix and match these techniques within one application depending on your needs - it's all One ASP.NET.

上面這段話的來源是:
https://www.asp.net/get-started/framework

所以,從這邊我們可以知道,先撇開.net core不談,asp.net framework (on windows),主要approaches Web Sites的方法有三,分別是 WebForms, MVC, 與 Web Pages...這三者位階相同...有趣的是…Web Pages是最常被忽略的。

而另一些常見的答案諸如 Web API,SignalR ...也是asp.net框架的一部分(但不能說它主要是用來『作網站』的,嚴格說起來它們的用途是通訊)。

接著,你繼續看上面那段英文的最後一段,這三種技術,在技術上『是可以』混用的
(David註:只要你夠熟)

而特色呢?分別是:

Web Forms : uses controls and an event-model for component-based development.
MVC : separation of concerns and enables easier test-driven development.
Web Pages : a single page model that mixes code and HTML markup.

上面Web Forms和MVC的特色說得很清楚,Web Pages可能有人會覺得有點語焉不詳,但你可以從底下這邊找到更多說明:
https://www.asp.net/get-started/websites

從上面你可以知道, Web Pages有點像是過去的ASP(Active Server Pages),提供開發人員一個最輕量級的方式來建立dynamic web content(動態網頁內容,就是從伺服器端動態抓取資訊,塞到html裡面往前端送的那種東西),和過去ASP不同的地方是,Web Pages它主要採用了Razor View。

用比較容易理解的方式來說明:
Web Pages : 最簡單,如果IT/MIS只是要臨時開發一兩個頁面,我會推薦選擇這個方式。
Web Forms : 事件驅動、主要模擬視窗物件導向開發的控制項、具有視覺化開發、快速開發(RAD)...的特性。
MVC : 主要價值就是關注點分離(SoC)、因此也最容易實現測試驅動開發。

我自己覺得MVC對於開發人員的素質要求相對比較高,如果單就一個功能點來說,透過這個方式寫出來的Code也肯定會最多。因為SoC,因此一個功能本質上應該拆成Model/View/Controller三塊來看(來思考),架構上相對複雜(因為比起單純的頁面多了Routing、Controller的概念),對於初學者進入障礙就高。

而Web Forms則是開發速度快,馬上能看到結果,容易上手,但也相對最不容易開發出職責分離的架構。

Web Pages則是最直覺容易開發,但基本上沒什麼架構可言,如果頁面一多,系統一寫大基本上難以維護,但如果只是幾個頁面,那當然就非常方便好用。

就體質上來說,Web Pages 不容易寫出有職責分離、有架構、分層負責的程式碼。但Web Forms和MVC都可以(當然前提是開發人員素養夠)。Web Forms要寫出具有架構職責分離的程式碼得靠毅力(因為容易被惡魔引誘),而MVC則是會強迫開發人員往這個方向走。

寫MVC的人如果沒能做到SoC 或 unit test/test-driven,那採用MVC的價值就大幅降低了,因為他的主要目的就是在這。而Web Forms則是為了模擬傳統的Windows 應用程式開發方式所生出來的框架,事件驅動的 event-model 和控制項是其特色,但代價就是為了去模擬狀態(State)而導致產生臃腫的ViewState。

MVC和Web Pages對於HTML Tag控制的自由度最高,而Web Forms則相對很低(特別是大量使用模擬桌面應用程式開發的Web Controls時)。

最後再順便談談 asp.net core,這個.net core,主要是為了讓系統能跨平台(例如run在Linux上),為了這個跨平台,所有與IIS和windows平台特性的相依性都必須拿掉,這意味著過去你熟悉的system.XXX之類的namespace開始無法使用,導致.net code基本其實就是整個打掉重練,跟原本的asp.net骨子裡差異很大。

但打掉重練也就沒有包袱,可以有新的開始,但當然也意味著你過去學的不一定都能延續。至於要不要使用.net core,或是跨平台時乾脆就換一種開發技術(例如node.js),這見仁見智,看你自己的選擇了。

所以簡單的幾個結論...

  1. 如果你想跨平台,可選用.net core(但我們今天上面那個題目,其實主要討論的不是這部分)。

  2. 如果你想寫較具有架構的網站或Web應用程式,你可以選擇 MVC 或 Web Forms,

  3. 如果只是想寫幾個頁面從伺服器端撈資料呈現給用戶,不是什麼大架構大系統,可以考慮 Web Pages。

MVC和Web Forms幾乎是不同的框架,使用目的基本上不同,也很難直接比較,但選用時其價值與核心精神(上面有討論)則必須掌握。否則若選了某一種開發方式卻沒有用到其特性,就很可惜了。

而真的有必要時,只要你夠熟悉,這三種寫法在技術上是可以混在一起用的。
(.net core則當然無法跟傳統的asp.net on windows混用)

---------------------------

以上,有沒有幫你更釐清asp.net的本質?
還是...你被搞得更暈了呢? :)

其實,不管你使用哪一種技術建立網站,只要能發揮其特性,避開缺點,凸顯其價值,並且在團隊中能夠對成員與老闆解釋的清楚,對企業來說,已經是很難得的人才了。

相關文章: http://studyhost.blogspot.tw/search/label/Framework
相關教育訓練: http://www.studyhost.tw/NewCourses/Architecture

2017年4月11日 星期二

the DevOps journey – 在Visual Studio版控比較多個檔案差異

這功能一點都不特別,但很重要,而且我記得我是在用了很久Visual Studio的TFVC版控之後,某一天偶然發現的。

我不知道是否每個人都跟我一樣,我自己在寫程式的時候,習慣在程式碼Check-in之前,對比一下這次修改了哪些東西? 確認無誤之後再Check-in ,會養成這習慣,是因為這小小的動作救了我很多次。

有不只一次,當我這麼做時,留意到了一些原本沒注意到的細節,諸如…在Method裡面忘了檢查參數內容是否正確? 沒有判斷空值或null是否合理? IO處理可能發生exception的地方沒有掛上try…catch…等等,太多了,只要養成review自己的code的習慣,你會發現,常常能購找到可以改善之處。

這個動作會迫使我在簽入前重新看一次剛才自己寫的code,有點自己review自己程式碼的感覺。所以,現在每當我程式寫到一個段落之後,都會習慣的在要比較的那隻程式碼檔案上,點選一下滑鼠右鍵,選擇Compare…比較一下和上一個版本的差異…

但這樣可能會漏掉了某些改過的檔案沒注意到,因此,最好的習慣是在Check-in的那一刻,在該檔案上點選Compare with …

因為版控機制幫你列出了所有修改過的檔案,如此一來,你就不會錯過哪一個檔案。

一般來說,過去在簽入程式碼到伺服器端前,我肯定會一個一個逐一比對,看看和伺服器端的檔案有何差別。(確認改了哪些東西)。

但有時候,Visual Studio會把附屬性質的檔案(例如.aspx.cs, .aspx.designer.cs,當作已修改,但其實它並沒有被改到,真正改到的只有.aspx而已。這時候,一個一個比對很煩人。(浪費時間)

不知道從哪一天開始,我突發奇想,難道Visual Studio不能一次比對多個檔案,先幫我確認哪些檔案有改過,讓我只review有改過的檔案嗎? 有了這個想法,當場嘗試看看能不能用滑鼠Mark多選幾個要簽入的檔案,發現,居然可以耶…

但,卻不能比較(Compare選單disable了)

不死心,又突然想到,那如果選擇資料夾呢?

咦? 可以耶,快來試試看。
你會發現,點選Compare後,會出現底畫面:

Visual Studio真的去幫我對比整理出了所有該資料夾下的檔案,僅列出有修改差異的部分,你還可以在該檔案上double-click,看到細部的差異比較:

這節省了我很多時間,我只需要把程式改完,在check-in前面,一次比對所有檔案的差異,不僅讓我安心check-in,對提升程式碼品質也有助益。

Visual Studio,地表最強開發工具,你當之無愧。
------------------------------
本系列文章索引位於 http://studyhost.blogspot.tw/2017/02/the-devops-journey-index.html
本網站不放廣告、完全免費。若這篇文章對您有所幫助,請點選這裡加入FaceBook專頁按讚並追蹤,也歡迎您幫我們分享出去,謝謝您的支持。

2017年3月23日 星期四

the DevOps journey (9) – 在TFS/VSTS中使用Git版控

接著,我們來看如何在TFS/VSTS中使用Git形式的版控。

同樣的,請先建立一個支援Git版控的Team Project,與TFVC版控的Team Project不同,建立好該專案之後首先納入眼簾的是底下的畫面:

你可以透過SSH連線的方式來連接,也可以點選上圖(2)的地方,產生連線所需的帳號密碼。

如果你用開發工具是Visual Studio,那你可以很大方的按下上圖(3)的位置,即可直接Clone該專案並且設定Mapping的用戶端資料夾位置,如果你用的開發工具並非Visual Studio,但也是知名的開發工具,則可點上圖(4)的下拉清單,看看是否也支援直接Clone:

從VS2017連接TFS/VSTS上的Git版控伺服器

當然,你也可以用類似我們開啟TFVC版控專案的方式,直接從Visual Studio當中建立連線,請注意一樣是選擇Connect to Project,在出現的畫面中找到要連結的專案與repository:

接著,成功的連上之後,在Team Explorer中一樣會出現讓我們選擇用戶端Mapping版控檔案的儲存位置,也就是你要把雲端的原始程式碼Clone到用戶端的哪個資料夾。

請選定資料夾後(下圖A),按下Clone鈕即可:

如果伺服器端已經有其它開發人員先前push上去的程式碼,會被一起下載下來,但由於我們是建立一個新的專案,因此目前還沒有任何檔案被Clone下來。

我們可以點選下圖A的New,建立一個新專案:

你會發現預設的資料夾,應該也是先前我們Clone時設定的資料夾,你可以直接按下OK,建立該專案。完成後,切換到Solutions Explorer視窗後,會看到類似底下這樣的畫面,這時請留意,和TFVC版控有些許不同:

你會發現,在上圖A的位置,標示出了有12個檔案已變更(或新增),你可以點選該數字,會出現Commit程式碼的畫面。

將程式碼Commit並Push到伺服器端

你會發現,在下圖A的地方,和TFVC版控類似,也會讓你輸入此次Commit的Comment,而B的地方有三個選項,分別是Commit All, Commit All & Push, Commit All & Sync:

所謂的Commit,和TFVC的Check-in不同,Commit並沒有將程式碼上傳到伺服器端,你需要手動Push,或直接選擇Commit All & Push,才會把程式碼確實的簽入到伺服器端。(如果你選擇Commit All & Sync,則會順便把其他人簽入到伺服器端的程式碼一起下載下來)。

Push之後,你同樣也可以在TFS/VSTS的站台上,透過Code → History看到程式碼版本出現了:

同樣上圖A的地方一樣有你Commit時候寫入的Comment,我們試著新增一個index.html,並修改Global.asax.cs檔案:

然後再Commit & Push一次,觀察伺服器端的結果,你會發現同樣的,在Code→History當中,可以看到這次Push上去的Commit,點選後也可以看到修改的時間並且對照出修改了哪些內容:

同樣的你也可以在Team Explorer選單中,透過Home按鈕,找到Sync或Branch指令,Visual Studio很貼心的讓大多數的功能都可以透過GUI來使用:

不管你用TFVC或是Git版控形式,在Visual Studio中都可以非常方便的使用,而TFS與VSTS也都同時支援TFVC和Git,到這個地步,開發人員的每一個專案再不上版控應該就說不過去了…

同場加映

 

------------------------------
本系列文章索引位於 http://studyhost.blogspot.tw/2017/02/the-devops-journey-index.html
相關教育訓練: http://www.studyhost.tw/NewCourses/ALM 
若這篇文章對您有所幫助,請點選這裡加入FaceBook專頁按讚並追蹤,也歡迎您幫我們分享出去,謝謝您的支持。

the DevOps journey (8) – 使用TFVC程式碼版控

我們先看採用TFVC的部分,請先建立一個以TFVC為版控的Team Project:

當你在VSTS/TFS中把專案建立好之後,首要工作就是從用戶端的Visual Studio連上伺服器,請開啟Visual Studio,找出Team Explorer視窗:

在Team Explorer視窗中,最上方(上圖1)的位置,有一個連線按鈕,點選後接著會出現Manage Connections選項,理論上會有兩個,一個是上圖2的『Connect to Project』,另一個是『Connect to Github』。

上面的Project指的就是VSTS/TFS的TFVC或Git Repository,而Connect to Github指的當然就是網路上那個Guthub。

請注意,不管你在team project建立時,選擇的是TFVC或Git版控,都是點選上圖2那個『Connect to Project』

接著會出現底下這樣的畫面,這是VS2017的UI,你會看到所有你的登入帳號可以連上的TFS Server或VSTS站台:

留意上圖,其中(1)的部分是你的連線帳號,由於該帳號可以連上我建立於區域網路的TFS以及internet上的VSTS,因此上圖(2)和(3)分別就是TFS伺服器以及VSTS站台,而展開的項目當然就是Team Project(上圖6),而(4)和(5)所指的分別是位於VSTS站台上的Team Project裡面的Git版控的repository和TFVC repository。

新版VS2017的連線UI設計的很完整,一次把所有需要連線的對象全列了出來,你只需要點選後,按下Connect鈕即可。

Mapping工作區並下載檔案

當你連上了伺服器端之後,會看到類似下圖的畫面,由於範例是剛建立的Team Project,因此下圖中你會看到還沒有其他開發人員先前已經簽入(Check-in)的source code,只有一個預設的資料夾:

由於第一次連上,你必須先Mapping你的Workspace,你會發現上圖(2)的地方,可以設定你的用戶端工作區位置,一但設定,未來該位置就可與伺服器端做同步,設定後按下『Map & Get』,如果先前有其它開發人員已經簽入程式碼,也會被下載下來。

你也可以點選下圖(1)的地方,也可以快速的設定工作區Mapping:

加入新的程式碼

Map工作區之後,你也可以點選下圖『New…』的Link,新增一個新的方案(Solution),你會發現,點選後跳出一個新增專案的視窗,而預設的資料夾位置,應該就是你Mapping的工作區目錄:

您可以建立一個Web應用程式專案試試看,建立時請記得勾選『Add to Source Control』(上圖1)。

建立完成之後,請切換到Solution Explorer,你可以在該專案上按下滑鼠右鍵,選擇Check In程式碼:

接著會看到底下的畫面,該畫面列出所有正準備簽入到伺服器端的檔案。你可以在下圖(1)的地方輸入一些Comment,一般來說會填入此次簽入程式碼時做哪些修改或目的,(2)的部分則是關聯的工作項,(3)則是準備被簽入的檔案,(4)則是已排除不簽入的檔案。

為何有些檔案會不簽入呢? 因為版控系統只是為了幫我們管理程式碼的版本,毋須將所有的檔案都簽入,例如.dll就是典型被排除在外不該簽入的檔案,因為它只需要用被版控的source code重新Build過就可以再次產生,本身毋須存放到伺服器端一起版控:

輸入Comment和確定要納入控管的檔案之後,你可以按下上圖(5)的位置,即可把所有程式碼簽入到伺服器端。成功簽入之後,回到Team Project站台網頁,點選CodeàFiles後,會呈現出結果如下:

你會發現程式碼都已經簽入了。

簽入修改後的程式碼

你可以嘗試在專案中新增一個檔案,或是修改程式碼,會發現新增的檔案在Solution Explorer顯示時,檔案前會有一個『+』符號(下圖2),而修改過的檔案則是紅色的打勾(下圖1):

同樣的,你可以嘗試將上圖的程式碼簽入TFS/VSTS當中,再去Portal上看,這時,會發現版控的威力出現了:

從CodeàChangeset選單中可以看到每一次的修改紀錄清單,點選進去會看到每一個檔案的修改紀錄,不管是檔案的新增、或是修改,都可以很清楚地呈現出對比狀況。

一但有了程式碼版控,你在Visual Studio當中,也可以一目了然的看到程式碼的修改歷程,你可以在Solutions Explorer中,選擇Compare:

將會出現類底下這樣的差異紀錄,綠色表示新增的部分,而紅色表示被刪除的部分:

哪一位開發人員,在什麼時間,做了什麼調整…都將無所遁形。

好啦,TFVC我們暫且先看到這邊,後面來看看Git版控

------------------------------
本系列文章索引位於 http://studyhost.blogspot.tw/2017/02/the-devops-journey-index.html
相關教育訓練: http://www.studyhost.tw/NewCourses/ALM 
若這篇文章對您有所幫助,請點選這裡加入FaceBook專頁按讚並追蹤,也歡迎您幫我們分享出去,謝謝您的支持。

the DevOps journey (7) – 你的source code還沒上版控嗎?

原始程式碼對於軟體公司來說是一種資產,Source Code被納入版控不足為奇(沒有才奇怪),但我常常看到企業內的MIS/IT,認為自己開發的專案只是小型專案,或是開發人員只有『一個』,所以要控管什麼版本呢? 因為一切都在自己的腦袋裡啊。

不,千萬別這樣想。

在這個時代,任何專案,那怕從頭到尾都只是一個人開發的,都應該要簽入到版控系統當中。不管是任何一種專案,不管是因為任何目的原因所撰寫的,不管它能夠在企業中活多長,只要有需求,有程式碼,需要維護,就一律必須納入版控。

如果非要我在兩者中選擇其一,我會說,軟體專案成敗的關鍵常常不在開發,而在維護。在這個時代,幾乎沒有寫完程式碼後可以不用維護的專案,也沒有你可以大聲喊『Close!』結案之後就再也不管它的程式碼,幾乎所有的Projects都會持續衍生、修改Bugs、調整需求。如今想要很快的生出一個可以動的網站太容易了,但隨著需求的變更,對程式碼的修改常常才是軟體開發真正內涵的開始。況且廣義的說,專案還沒有交付前所作的任何需求變更或修改,也都得算是維護的一部分。

如果你敢在寫好程式碼編譯成.dll之後,立馬把source code丟掉,我就承認這世界上有不需要維護的專案,但我們從來不敢這麼做,對吧?不管一個專案再混亂、或是你開發的是根本是拋棄式的應用程式(用一次就不會再用),原始程式碼都至少還要留上一段時間,甚至永久保存下去。

而如今這些需要無限期永久保存的程式碼,慢慢的逐漸移動到了雲端環境上,我們到了一個版控雲端化的時代。當然,保存原始程式碼不是為了安全感,TFS/VSTS的版控可以幫助我們解決那些實質問題?

版本控管的價值

有沒有發生過底下這些事情?

  • 某位團隊中的程式設計師改了某一個bug,結果另一個原本好的功能卻壞掉了? 沒改過的地方怎麼會錯呢?
  • 客戶突然告訴你,你剛才改好的某個功能他不要了,他要回到上上上個版本的那個狀態!
  • 團隊成員結婚去度蜜月了,但不幸的是,他手上負責的某個案子,客戶發現了一個安全性的漏洞,嚴厲指責這估計是他結婚前一個月的某次修改時造成的,但...那段程式碼在哪呢?
  • 你同時是三個軟體開發專案、兩個維護案的程式碼設計師,面對客戶和專案經理天馬行空的需求,你的大腦常常必須在2-3個案子之間切換,剛剛才改完維護案的bug,下午要開發另一個專案的新功能,但是…昨天…我程式碼寫到哪裡了呢???

我們在真實案例中天天面對上面這樣的問題,現在的VSTS/TFS,不僅僅能夠為開發人員保存每一次的版本變更,能夠比較程式碼版本(changesets)之間的差異,配合Scrum的Backlogs,TFS/VSTS可以把每一個work items與changesets連結在一起。不僅如此,程式設計師與程式碼、work items之間的關係也一目了然。每一位程式設計師、因為每一個bugs/feedbacks/requirements,對程式碼所做的調整,都可以在TFS/VSTS的版控系統中一覽無遺。

前面說過,即便你的專案只有一位開發人員,程式碼的版本控管也能夠在每一個關鍵時候發揮他的價值與效果。

如今,我們透過Scrum與敏捷開發來駕馭整個專案,更不能沒有版控機制在其中穿針引線。

不管你對於版控是否熟悉,接著,我們會以最扼要的方式,帶領讀者對TFS/VSTS的版控有最基本的掌握與應用。

TFS/VSTS的程式碼版控支援

VSTS/TFS裡面同時支援了TFVC和Git這兩種版控形式,不論選擇哪一種, source code都會以Private repository的方式儲存。

先有一個概念,一個Team Project同時可以擁有多個repository(一個TFVC和多個Git),因此,不管你在建立Team Project的時候,預設選擇了TFVC或Git,後面都可以在同一個專案中建立另一種形式的Repository。

要建立多個Repository,可以在Team Project的Code選單中,選擇Manage repositories:

TFVC是傳統的集中式版控,開發人員每一個Check-in,都是把程式碼往伺服器端送,會形成一個變更(changeset),而Git源於open source社群,一開始用於開放原始碼的共同開發,因此設計上更為鬆散靈活,當開發人員把Git版控的source code複製(Clone)下來到本機之後,開發人員的每一個Commit都是發生於本機用戶端(這與TFVC不同),直到Push才真的把程式碼往伺服器端送。

你可以依照你的專案性質選擇不同類型的版控,後面我們兩者都會討論。

先來看如何使用TFVC的版控Git版控看這邊

------------------------------
本系列文章索引位於 http://studyhost.blogspot.tw/2017/02/the-devops-journey-index.html
相關教育訓練: http://www.studyhost.tw/NewCourses/ALM 
若這篇文章對您有所幫助,請點選這裡加入FaceBook專頁按讚並追蹤,也歡迎您幫我們分享出去,謝謝您的支持。

2017年3月19日 星期日

the DevOps journey (6) - 安排與設定專案的迭代

當專案啟動後,我們會用VSTS來管理專案中的每一個Features/work items,以及source code。

Source code管理的部分我猜大多數的開發人員比較熟悉,畢竟版控這幾乎是開發人員吃飯的工具,我們就暫且先不說了,主要是因為有用過TFS的開發人員肯定知道怎麼用,而VSTS在版控上的操作完全相同,因此不需贅言。

但由於最近幾次的改版之後,VSTS除了過去支援的TFVC,現在還支援GIT,因此似乎也必須稍微整理一下,如果以後有機會我再補齊,讀者可參考後面的篇幅。

因此,這一個部份我們先focus在work items在iterations中的處理。

回顧先前所提過的,敏捷開發的核心精神之一,就是把開發周期縮短成多個iterations,在Scrum中我們叫做Sprint。(其實想一想,我覺得不管是不是敏捷開發,只是要面對需求快速變更的近代軟體開發專案,都應該盡可能的切分出iterations)

前面曾經說過,這個Sprint可能是 1-4 周,一般來說我自己喜歡用2周。但這個長度完全取決於你希望專案有多透明,衝刺有多密集。

經驗上來說,2周是一個比較舒服愉快的周期,1周多半意味著Team Members和PO/PO, Stakeholders都得要上緊發條;但 3 or 4周我自己覺得有些鬆散了,比較適合人數比較多、或是整個專案時程預估會超過一年以上的開發團隊,或是長期抗戰永無休止日的軟體產品開發團隊。

要在VSTS當中設置iterations相當容易,你會發現當一個新的專案被建立起來之後,就已經建立好了預設的迭代了,只是系統還沒有幫你安上迭代的時間日期:

當你點選專案主選單的『Work』選項(上圖1)之後,會發現初始建立的專案已經有預設的Sprint1-6(上圖2)。但每一個Sprint的日期則還沒設定(上圖3),而中央黃色區域的地方則是輸入工作項目的位置(上圖5)。

這別請特別留意,上面的『Sprint 1』這個名稱,是依照你選的流程版型Scrum而定,如果一開始你選的是Agile或CMMI,則Sprint會變成Iteration

原則上每一個迭代(Sprint)的週期應該一樣長當專案建立好之後,你其實可以直接修改預設已經存在的迭代名稱和日期區間:

動作很簡單,請依照上圖的操作順序,最後點選(1)的Set dates,即可出現底下畫面:

在上圖中你也可以修改迭代的名稱,但重點其實是迭代的起始日期和結束日期。

如果你的迭代是兩周,開始日期可以設定周一,結束日期則設定為下周五,如上圖一般。最後按下儲存即可。

你可以點選每一個迭代,透過同樣的方式,逐一設定其日期區間:

如果你想增加迭代,或是一次性的設定多個迭代,也可以直接進入專案的管理畫面。

請在專案(注意,不是整個站台,因為一個站台可以建立多個專案)畫面的右上角,找到設定的圖示:

請點選Work頁標籤,你會發現這個畫面可以讓用戶設置每一個Sprint的週期,如同我們前面說的,可以是1-4周,而VSTS也很聰明,你設置完第一個之後,後面的Sprint在設置時,只需要設置開始時間就會幫你算出結束時間。

設置好了之後,可以點選專案名稱旁的Work選單,你會發現我們規劃好的Sprint已經出現在畫面當中了,後面接著我們就可以新增Backlog囉。

嘗試新增第一個backlogs

我們後面會再詳細一點的說明Backlogs的概念,不過我們剛建立好迭代,可以先試著建立一個Backlogs玩玩看,你會很清楚的看到迭代的價值。

想像你要做一個健康管理的醫療系統,其中有一些基本的功能,例如…透過身高體重計算BMI值、允許用戶登入、申請帳號…等。

你可以把蒐集到的需求,填寫到系統當中作為Product Backlog items,類似底下這樣:

先點選上圖中的(1),Product Backlog Items意指開發團隊所有要進行的開發工項,接著,在上圖的(2)的位置,輸入你蒐集到的工項(需求)名稱,按下Add你即可新增,完成後類似上圖(4)。

我們前面說過,之所以要切分迭代,有很多的意義,目前我們輸入的Product Backlogs,屬於準備要做的需求,待PO/PM與客戶把優先序排定,並且梳理過每一個Backlog items的粒度大小之後,我們就可以把最優先的items用拖曳的方式放入第一個Sprint :

雖然你可能很疑惑,一個Product backlog應該要切到多細? 如何估算開發時程? Backlogs裡面要怎麼寫具體的需求? 先別急,這些我們稍後再說明,我們先來看Product Backlogs與迭代會帶來的效果。

當你把某一個Product Backlog拖曳到某一個迭代中之後,這代表著該Backlog已經交派給團隊,準備在這個迭代中進行實際的開發。這時,團隊可以在進入該迭代後,於Planning Meeting中,把該需求做工作項目(Task)的細分:

可以點選上圖(1)的地方進入某一個迭代,系統會列出屬於該迭代中的Backlogs,你可以點選上圖(2)的+符號,會跳出底下的視窗,可將該Backlog切分為更具體的工作項目(Task):

在跳出的對話視窗中,(1)的部分是輸入該Task的名稱,(2)的部分可輸入該Task的預估工時(日後可作為燃盡圖繪製的資料來源),(3)的部分則可以視需要填寫該工項的說明。

有趣的部分來了。

將每一個工項填寫完畢之後,我們可以將這些工項(tasks)指派給開發人員(或由開發人員認領),在指派前,請先設定該Sprint開發人員的Capacity:

可點選上圖中(1)的位置,即可進入設定Capacity的畫面,在該畫面中,您可以設定這個迭代中,您的Team Member在這個專案每天可用的開發時數(上圖2),我們設定的是實際可用的開發時數(而非每天的工時),因此,一般來說應該介於4-6小時之間。

一但您設定的工時,就會出現上圖(3)Work Details的長條圖,明確的顯示出了整個團隊本迭代還有多少可用時數,以及本迭代中所有預計的開發時數(也就是您剛才設置的Tasks的Hours)。

接著,請回到Backlogs的畫面,這時你可以用拖曳的方式,把tasks拖曳指派給特定的開發人員,你會發現,當你進行指派之後,不僅tasks的owner會被設定,也會看到每一位team member以集團對整體的工時狀況:

如果預估工作時數太高,團隊成員或團隊無法負荷,也會以紅色的長條圖來顯示:

是不是很吸引人?

一目了然的看到此迭代中整體專案的狀況,是一件相當賞心悅目的事情。

------------------------------
本系列文章索引位於 http://studyhost.blogspot.tw/2017/02/the-devops-journey-index.html
相關教育訓練: http://www.studyhost.tw/NewCourses/ALM 
若這篇文章對您有所幫助,請點選這裡加入FaceBook專頁按讚並追蹤,也歡迎您幫我們分享出去,謝謝您的支持。