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
本網站不放廣告、完全免費。若這篇文章對您有所幫助,請點選這裡加入FaceBook專頁按讚並追蹤,也歡迎您幫我們分享出去,謝謝您的支持。

2017年3月15日 星期三

the DevOps journey (5) - 在VSTS站台與專案中添加成員

前面我們看過了如何免費申請VSTS站台與建立專案,接著,我們要在專案中添加成員。專案的成員在VSTS當中都是以Microsoft Account來添加的(如果你有Azure AD,也可以是AAD帳號),在新增帳號前,有幾件事情你應該要知道…

  • VSTS的帳號類型有三種,分為: basic(五人以內免費), MSDN Subscriber(視為已付費), Stakeholders(免費)
  • 由於未來我們的Source code control、Work Items整個都在VSTS當中,包含bug tracking、document、unit test...等全都透過VSTS。因此,理論上所有與開發相關的人員,都必須添加進去成為專案的Member,我們可以提供這些團隊成員basic類型的帳號。Basic類型的帳號五人以內免費,如果超過五人,則需要從Azure Portal購買額外的帳號權限。
  • 如果你的團隊成員當中,已經被指派(或購買)有MSDN訂閱,則該Microsoft Account可以選用MSDN Subscriber權限,毋須占用免費的basic權限。
  • 如果並非Developer,且只是要觀看Work Items(像是Features, Backlogs, Tasks…等)的Stakeholders,也可以加入VSTS Members,毋須占用basic帳號,可選擇免費的Stakeholder身分即可。

要新增用戶,你可以先點選VSTS左上角畫面的Logo(下圖1),會進入到該站台 (Collection)的管理畫面,請找到Users(下圖2):

進入該畫面之後,你可以點選(1)的部分,會出現讓你輸入email增加用戶的介面,請於(2)的地方輸入該用戶的email(必須是Microsoft Account),Access Level請參考前面的說明,選擇三者其中之一:

請注意,我們現在新增的是整個站台(Team Site)的用戶使用權限,待會這裡新增完成之後,接著才針對專案(Team Project)來新增用戶權限。

順帶一提,也因此,VSTS的五個免費basic用戶,指的是站台,而非專案,請留意。

請依照底下的操作順序,即可把成員加入站台:

添加專案成員

當用戶被成功的加入站台之後,接著我們就可以針對專案來添加成員。

一般來說,在專案中添加人員只需要從該專案的主管理畫面上進行即可,請從站台的主畫面(點選左上角VSTS Logo)中,找到你想要設定的專案:

進入到該專案的首頁之後,請點選右上角的『+』來新增成員:

在出現的視窗中點選下圖(1)的Add:

新增時只需要輸入部分文字,如果先前該用戶有正確的添加到站台中,就會被找到:

最後按下上圖中的『Save Changes』即可。

有時候,你明明已經新增完成,卻沒有看到剛才新增進來的用戶,別急,請按一下下圖(1)的refresh鈕即可:

你要怎麼知道到底用了多少個帳號呢?

請點選左上角的VSTS Logo(下圖1),這樣會回到站台主畫面:

您會在主畫面看到 users 選項(2),點選後會進入帳戶管理畫面,您可以在這個畫面中,將每一個剛才加入的用戶配置成basic或MSDN Subscriber。

這樣,您就可以妥善的安排每一個用戶的權限,並且依照購買的數量來增減用戶以控制預算了。

至於您有多少個Basic帳號可以配置,則是看你在Azure管理站台購買的數量(更多資訊請參考這邊),一買最低就是一個月為單位,請留意。

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

2017年3月14日 星期二

the DevOps journey - 直接import Github上的Project到VSTS

我相信你一定有用Github,其實我很少用,但不知道從什麼時候開始,開發人員沒有Github帳號好像是很詭異的事情。

直到去年,我才開始比較多的把一些範例放到Github上面,當然主要原因是分享,也作為blog和書籍範例的儲存位置。

如果你有在用,你一定知道,Guthub上的專案是open的,除非你付費,否則你的原始程式碼只能選擇公開(Public)的模式。

然而,某些比較敏感的專案,你還是會希望能夠以Private的方式做版控,如果是團隊開發,那你一定得用Private的方式來管理你的原始程式碼。

從好一陣子以前(忘了有多久),提供團隊開發(五人以下)免費使用的VSTS,就徹頭徹尾的支援了Git版控機制,也因此,你可以直接申請一個VSTS站台,在上面建立Private的專案,並且讓多位程式設計師一起透過VSTS上提供的Git repository進行版控。你毋須自行架立Git伺服器,和所有的Git服務一樣,他也提供SSH或簡單的帳號密碼身分驗證,如果你還不知道,可以參考這篇建立一個VSTS站台試試看:

當你在VSTS上建立好一個Team Project之後,立馬會看到一個很有趣的功能,VSTS的Git版控可以直接從某一個現有的Github Repository把source code給Import過來(下圖),你建立好自己的VSTS Team Project之後可以試試看,請不用客氣,直接用我分享在Github上的範例即可:
https://github.com/isdaviddong/isRockWebFxBasicSample
(順帶一提,如果你不知道上面這個專案在幹嘛,可以參考這邊)

按下Import鈕之後,會跑一下底下這個畫面:

完成之後,該repository上的source code就都複製到VSTS的Team Project中囉:

從此之後,你就享有自己團隊非公開的Git repository,五人以下免費,空間無限,非常方便吧。

基本上,目前我只有需要刻意公開的專案,才會使用Github,除此以外全部都在VSTS上了,你也要試試看嗎?

------------------------------
本系列文章索引位於 http://studyhost.blogspot.tw/2017/02/the-devops-journey-index.html

the DevOps journey (4) - 建立VSTS站台與專案(2017年Q1版)

在開始使用VSTS管理你的專案之前,你需要知道一個概念。首先VSTS基本上可以視為TFS(Team Foundation Server)的雲端版本,最遠古的時代,微軟是以TFS作為程式碼版控與軟體生命週期管理(ALM)的工具。

隨著雲端SaaS服務的盛行,TFS被改成了雲端版本,過去的名稱曾經是VSO(Visual Studio Online),後來改名為VSTS(Visual Studio Team Services)。

因此,一個VSTS站台,其實可以視為一台TFS伺服器,因此,一個VSTS站台上,你可以建立與管理多個軟體專案,以往TFS的概念是以Collection為單位,而Collection底下再建立多個Project(這裡指的Project是Team Project,也就是一整個項目專案,而非Visual Studio裡面的某一個Project)。

好,所以重點在於…

  1. 你待會建立的VSTS站台,是一個雲端服務,你將會把所有的程式碼版控、工作項目(WorkItems)、Bugs清單…等資訊存放在微軟的雲端。
  2. 你建立的一個VSTS站台,上面可以建立無數多個專案,每一個專案當中可以有一個或多個Project Solutions(.sln)。
  3. 權限的控管是透過Microsoft Account,也就是過去你熟悉的Hotmail/Outlook帳號。

好,知道基本概念之後,我們就來建立第一個Team Project Site。

首先,請進入 https://www.visualstudio.com/ 網站,接著點選最下方的VSTS(Get Started for free):

接著,你應當會被導引到Microsoft Account登入畫面,登入完成後,會看到底下畫面,這邊就是讓您建立VSTS Team Site:

還記得前面提到過的? 一個Team Site可以有多個專案,因此,原則上一家公司或是一個團隊,其實只需要一個Team Site即可,毋須人人建立一個,當你建立好一個Team Site之後、開好專案之後,再把團隊成員加入即可。

上圖中(1)的位置就是讓您選擇您的Team Site的網址,形式是:

https://xxx.visualstudio.com
(您可以替換掉前面的xxx成為你公司或團隊名稱)

(2)的部分可以選擇預設的版控採用Git或是TFVC,最近這幾年,大家都流行採用Git這種分散式版控,和TFVC集中式版控有所不同,各有利弊。不過這邊也並非選定了之後就不能改,只需要選擇你習慣的即可。

一般來說,目前我的選擇方式是,如果團隊成員中有大量的設計師(Designer),由於他們也需要將UI/UX source code納入版控,但MAC上目前沒有很好的支援TFVC,只有Git Client稍稍好用,因此我會屈就於Designer選擇Git版控。

(3) 的部分是選擇你要把整個Site放在哪一個資料中心,原則上不需要調整。

選定之後,請按下(4)繼續,接著系統會幫您建立您的專屬網站,完成後會看到類似底下的畫面:

VSTS站台建立好之後,你可以在上面建立無數個專案。VSTS會預設先幫你建立一個名稱為MyFirstProject的專案,如上圖(1),很討厭,一般來說我都直接刪掉。

如果你選用的是Git版控方式,會看到上圖(2)的畫面,主要是告知你的用戶端Visual Studio(或其他開發工具)如何連上這個Git版控[1]。而(3)的位置則是讓你加入其他專案成員,例如開發人員,設計師,或其他閒雜人等(stakeholders),上圖(4)的地方是這個專案的主選單,包含了數位儀表板、程式碼檢視、工作項目檢視、自動化建置(CI/CD)的管理…等,我們後面再慢慢介紹。

請先點選上圖(5)的部分,我們來嘗試建立一個新的專案。

當你點選專案左上角的VisualStudio圖式之後,會到整個Team Site的首頁,這時,你可以點選New Project在這個Team Site中開啟一個新的專案:

點選後會出現底下畫面:

其中(1)的部分你可以自由的輸入專案名稱,(2)則是選擇版控(一樣是Git或TFVC),而(3)則是工作項目的管理要採哪一種形式,分別是Scrum、Agile、CMMI,建議新手可選擇Scrum。

完成後按下『Create』鈕,完成後依舊出現底下畫面,這樣新的專案就建立好了。

可以成功進入專案首頁之後,第一步,你必須做幾件事情,分別是:

  • 添加專案的成員(Developers、PM/PO、SM...etc)
  • 安排與設定專案的Iterations
  • 安排與設定專案的Team或Area

上述的每一個動作都有著各自的重要意義。後面我們接著要繼續看,如何添加專案的成員、以及建立迭代(iteration)…

------------------------------
本系列文章索引位於 http://studyhost.blogspot.tw/2017/02/the-devops-journey-index.html

2017年3月9日 星期四

The DevOps Journey – Index

去年(2016)關於DevOps的討論很多,但內容大多相對抽象,對於從來沒有接觸過軟體開發生命週期管理(ALM)的技術人員來說,不是很容易掌握DevOps的精神。

不過,隨著工具的成熟以及敏捷開發概念的盛行,我們越來越能夠看到DdevOps在各行各業的具體實例與應用。同時,不管是專案或軟體產品,在各類的軟體開發的情境中,ALM/DevOps/Agile幾乎已經是近代軟體開發方式與專案管理的主流。

過去這幾年筆者有幸參與各種不同類型的開發團隊,包含軟體產品開發、也有客製化專案軟體開發,同時偶而也協助企業導入ALM/DevOps/Scrum。因此,這一系列的文章中,如果可以,我希望能夠把我們這幾年面對軟體開發方法,以及使用ALM/DevOps/Agile的一些經驗,有條理一點的整理出來,如果你有興趣,不妨嘗試慢慢的看看,如果實在已經不習慣看長篇文章,也可以挑有興趣的重點來讀。

我先定義一下我們的範圍:

  • 採用的開發技術包含.NET傳統桌面應用程式和網站、iOS和Android開發,使用的DevOps/ALM工具主要是VSTS/TFS(版控包含Git和TFVC),從需求、設計、開發、測試、CI、CD、線上監控、客戶反饋…大致上都有涉及。
  • 開發團隊包含設計人員(Designer)、前端開發人員、後端開發人員,當然還有PM(PO)、客戶服務(或Sales)

底下是系列文:

相關文章

希望這些經驗對大家有幫助。

2017年3月8日 星期三

the DevOps journey (3) - 為何需要開發流程『自動化』…

對我來說,從傳統Waterfall專案管理方式移轉到敏捷開發,兩個最主要的關鍵就是『透明度』與『自動化』,我們前面談過了透明度,這一篇我要聊聊自動化。

我在課堂上曾說,如果你不確定要怎麼改善你的團隊,那設法提高整個專案(各項事情)的透明度,以及讓開發流程盡可能的自動化,幾乎可以確定對專案成果將帶來顯著的正面影響。

為何我們該在意『自動化』

有幾個顯而易見的理由:

  1. 回應真實世界所需的速度
           面對瞬息萬變的市場,你幾乎不可能像過去一樣,累積所有的bugs每三個月或半年固定上版更新一次。如今,所有已知的bugs,在一周內更新完畢應該算是最差的狀況了。對一些線上服務或是網站,如果是跟交易金額有關的bugs,沒有人會接受已知的bugs被放任不管。
           如今在技術上,我們絕對可以在程式設計師撰寫完程式碼(不管是修復bugs或是增加新功能)之後,自動進行伺服器端建置,建置完成後隨即進行非人工的自動化測試(用以確保這個更新不會改壞了其他原本是好的的功能),如果自動化測試一切正常,則自動上版到測試機或是正式機。整個過程在技術上可以完全自動,並且在從開發人員Check-in code之後一小時內自動完成。
  2. 強迫品質提升
           為了讓上述的自動化可以實現,你必須建置自動測試流程,把過去系統從開發到上版之間,所有原先倚賴人力進行的流程,改為由電腦自動進行。在這個調整的過程當中,你的專案品質自然而然會被迫自動提升。
            因為你過去沒有自動化測試把關、過去沒有伺服器端自動建置、過去沒有上線後的錯誤警示…改為自動化之後這些全都要實現,如此一來,你的專案品質自然和過去以往不同檔次,將會有顯著的改善。
  3. 減少人為錯誤以及倚靠人力的SOP
           過去,在一個沒有自動化的開發流程當中,單一程式設計師把改過的程式碼在自己的電腦上撰寫完成,經過自己初步的測試,他就認為這段程式碼寫完了。然而真的是嗎?
           這段程式碼並沒有和其他人撰寫的程式碼一起運行過,沒有經過單元測試或整合測試,沒有經過壓力測試,沒有正式佈署到某一台網站上,因此你無法得知,改過的程式與正式機資料庫連線後是否可能發生問題(例如正式機的table schema沒有調整),也無法得知上了正式環境之後,網路和硬體環境是否依舊能支撐這段改過的程式碼。
           在過去,這一整段After-Coding後的流程,都是透過人力(例如維運工程師)手動完成,但只要有人力介入,就有可能會出錯。哪怕企業明確訂定了上版SOP,只要有人,就會有錯。而這個流程的自動化,將會把可能發生人為錯誤的機率減到最低,並且讓機器來進行枯燥重複的procedure,我們也可以把人力使用在更有創意(例如設計、開發)的領域。

上面這幾個理由,還不足以讓你改變心意? 讓團隊的開發流程從手動改為自動化?

要如何進行自動化

我們看看底下幾張圖:

上面這張圖從需求的蒐集開始,我們透過VSTS/TFS來管理每一個requirement,並且勾稽串聯到開發人員的工項(Wotrk Items),從開發人員將程式碼撰寫完Check In到Repository之後,一系列的自動化流程就被觸發。

下圖是程式碼Check-In之後的流程,如果導入CI,每一位開發人員的每一次程式碼的Check-In,在伺服器端都會有整合性的自動建置,並且透過自動化運行的code review/unit test來確保程式碼的品質:

如果建置成功,自動化測試也都通過,接下來可以進行自動佈署:

我們可以自動將最新的Build佈署到Release Candidate(RC)主機上,上版到RC的新版系統,可由Power User或tester進行人工測試,測試無誤之後,將系統切換到UAT或Production主機上,直接上版(這部分也可以整合簽核流程變成自動進行)

簡單的說,從開發人員Check-In程式碼開始,後續一連串的動作直到把最新版的系統上架,我們都可以自動化的方式來實現。

如果初期開發團隊擔心太自動,會不小心上錯不該上的code,也可以慢慢的、逐步的實現自動化,但不管如何,將這整個流程實現,所帶來的好處遠遠高於傳統倚賴人工進行的建置與上版流程,而這一切,我們只需要使用一套VSTS/TFS就可以實現。更別說這整個過程當中,每一個段落你都可以收到即時的信件或訊息通知,自動化流程搭配透明度的提升,將會讓你的開發團隊換骨脫胎。

好了,知道概念之後,我們後面就要具體的進入整個DevOps的自動化/透明度提升之旅了…

------------------------------
本系列文章索引位於 http://studyhost.blogspot.tw/2017/02/the-devops-journey-index.html

2017年3月6日 星期一

the DevOps journey (2) - 如果時程難預估,不如追求透明度…


前面說了,在近代專案管理當中,大家已經慢慢能夠理解,死板的去stick to the plan,追求計畫導向的專案管理,在外在環境瞬息萬變的今天,這恐怕是不可行的。

但是,如果我們不去追求計畫實施(implementation)的準確度,不去要求執行計畫的每一個步驟一如開始的計畫一般,那我們該用什麼標準去定義何謂一個『好的軟體專案』呢? 對企業來說,如果PM不是依照著既定計畫、時程把成果交出來,那到底什麼可以被叫做『執行了一個好專案』?

在DevOps課堂中,對於這個問題,我的回答是: 我們與其去要求專案100%按照計畫進行,不如追求軟體專案的高「透明度」、以及開發流程與維運的「自動化」。

有注意到這一篇的標題嗎? 請把它記起來…

如果時程難預估,不如追求透明度

什麼是透明度?

底下有幾個問題…不管你是PM、Team Leader、還是專案團隊的成員,你都應該要自問自答一下…

  • 你知道每位開發人員今天正在開發哪些功能項目嗎?
  • 你能知道最近一次Check-in上去的Code,是改了哪些程式碼嗎? 這個修改是因為哪一項需求或Bugs呢? 
  • 專案的程式碼Check-in是否有觸發Build? Build是否成功?  
  • CI Build的過程中執行的Unit Test是否都有通過? (還是你根本沒建立Unit Test? Check-in還不會觸發Unit Test?)
  • 這個迭代每一個開發人員手上的工項(WorkItem)是否都與MVP(或潛在可交付產品增量)有關? 整體需求目前完成的比例是多少? 已經有多少完成的 item通過測試? 客戶實際驗收過的Item又有多少呢?
  • 到今天為止,你還有多少已知的Bug尚未解決?
  • 這個Sprint要達成的目標為何? 要交付出哪些成果(潛在可交付產品增量)? 當前進行的Sprint是否有任何風險? (導致無法交付出成果?)
  • 已經上線的系統每天有多少人登入? 每天發生幾個Exception?

只要你確實參與在團隊當中,你自己一定很清楚,上面這些問題你能夠回答出來的比例有多少…

別急,我們再來看看幾張圖表:

上面這張圖表呈現出了專案中所有的需求數總共有多少、有多少比例的工作項目正在開發中、有多少需求已經開發完成等待測試、還有客戶已經驗收過(認定完成)的Item有多少。

上面這幾張圖,則呈現出了每一個迭代(Sprint),開發團隊的工項完成度(此為燃盡圖,具體來說是Sprint中每一天的剩餘工作時數)。左上與右上兩張圖呈現出了團隊的預定進度狀況良好,而中間上下兩張圖以及左下的圖則是清楚呈現出專案團隊的問題(你看的出來是什麼問題嗎?) 以及進度狀況(一看就知道這個Sprint將會延遲,無法達成預定進度)。

上面這張圖,則呈現出每一個迭代(Sprint)當中正在進行的工項(展開後會有具體的工作item、原始需求、驗收條件…etc.)、以及每一個工項的狀態、負責人…等資訊。而這些工項,也可以透過看板(kanban)的方式來呈現,請看下圖:

底下這張圖則是程式碼版本控管機制當中,某次異動的紀錄,包含異動者、異動原因、關聯的工項、以及異動前後的內容…

底下則是典型的數位儀表板:

OK,看完了?
那底下這是一個可以問問PM的好問題:

你所參與的開發團隊,有沒有這樣的專案管理圖表? 在軟體專案管理上是否也能夠呈現出類似的透明度?

你得要知道,這些可是我們現在專案管理的標配喔...

專案中所有的利益關係人、技術與非技術負責人、團隊成員…etc.,對專案現況的掌握度,以及圖表呈現的清晰程度,就是我們後面接著要談的『透明度』。

所以,什麼叫做『執行了一個成功的專案』?

好,看完上面那些圖表之後,讓我們回到最初,請重新幫我思考這個問題,現在,在你的認知當中,你認為什麼叫做『執行了一個成功的專案』?

過去,當碰到這個問題,一般人腦袋裡立即閃過的字眼會是『on schedule』…是的,用我們先前很愛拿出來講的那個字眼,就叫做stick to the plan。過去,計畫導向的專案管理認為,on schedule的專案就是好專案,一位PM若能夠依照既定計畫,精確的執行一個專案,那他就算是一個好PM(哪怕這個專案的原始計畫再怎麼爛也無所謂,因為PM照著執行完了啊)。

但我們前面已經花了兩個篇幅告訴各位,僅僅只是stick to the plan,在這個時代是不可行的。既然我們確定它不可行,那就衍生出一個問題,若我們不照著計劃走,軟體專案管理豈不就失去了方向? 不追求照著計劃,那我們該追求什麼呢? 答案就是這兩個關鍵字,分別是 『透明度』和『自動化』。

『透明度』和『自動化』

如今,我對開發團隊在專案管理當中所要求的,也就是『透明度』和『自動化』。而這兩個關鍵字,將會帶出我們這一系列文章的主題 -- ALM與DevOps。

為什麼我們應該在意透明度? 請回憶上一篇的一些關鍵字,像是: 『迭代開發』、『潛在可交付產品增量』、『持續修正』、『持續改善』…,你會發現一件事情,當我們採用迭代開發並且企圖持續改善時,有一個非常非常重要的關鍵,那就是『專案現況到底是如何?』。

如果你壓根不知道專案的實際現況,那你要怎麼持續改善呢?要修正什麼?有什麼好調整的?只要你想要讓團隊可以持續改善,那你的現況必須是可量測的、可估量(可評估)的,說白話一點,就是你的專案現況要夠清楚,你專案中的問題要能夠真的被凸顯出來(而不是被掩蓋起來,所有人都不知道,又或者是,所有成員都知道,但只有PM和老闆不知道)

你想要能夠持續修正、持續改善,那你的首要任務就是讓整體專案的透明度提升,否則你無法知道該怎麼改善? 無法知道該讓專案團隊往哪個方向走。

因此,對我來說,透明度提升是敏捷開發要追求的第一個首要目標,它將會貫穿我們專案管理的每一個層面。

拿我們一開始隨手舉的幾個問題當例子,你知道你的專案當中,目前有多少個bug尚未解決? 每天完成哪幾個功能點? 整體需求的完成度比例是多少? 每天程式碼改了哪些? 每一次修改是為了哪些功能或bugs? 開發人員正在開發哪個功能? 每一次Build是否都正確無誤的? 今天(或這周)開發人員Check in / Push 了哪些Code? 開發人員測試過了哪些功能? 客戶驗收過哪些功能? 已經上線的系統每天發生幾個Exception?

不管你是專案的PM、Team Leader、還是Team Member,上面這些問題我們能掌握多少? 你知道坐在你隔壁的開發人員現在手上正在開發哪一個功能嗎?

這幾年下來,我可以武斷地說: 專案的透明度,幾乎表現出(等同於)專案管理的成熟度。

那該怎麼做?

好,當你同意專案的透明度是一個重點之後,接著我們就得要來看如何提升它? 答案依舊是透過迭代開發與敏捷流程,例如我們團隊採用的開發法是Scrum。而工具(我們用的是VSTS/TFS)當然也是一個很大的關鍵,不過別忘了敏捷開發的核心精神才是一切的重點…

到目前為止,這一篇,我們提出了現代軟體專案管理所追求的兩個重要指標 --『透明度』與『自動化』,而這恰恰就是ALM與DevOps可幫助我們實現的目標。我們後面會接著利用幾個篇幅,慢慢來介紹如何透過導入敏捷的開發流程、建立團隊的開發準則與習慣、以及妥善的使用VSTS/TFS等工具的協助,來實現專案透明度。

但別急,我們下一篇還要談談剛才提過的另一個重點,就是『自動化』。

------------------------------
本系列文章索引位於 http://studyhost.blogspot.tw/2017/02/the-devops-journey-index.html

2017年3月3日 星期五

the DevOps journey - 在VSTS CI(Continuous Integration)中發送Line通知

需求很簡單,我們希望在VSTS的程式碼Code Check In(Code pushed)、Build Success/Fail、或是Work item發生了改變時,透過Line發送通知給特定人員(專案成員、PM…etc.)

會有這個需求很單純,我們希望通知(notification)更加即時,每當任何團隊成員簽入程式碼,或伺服器端的建置(Build)完成有結果之後,相關人員都能夠立即得到通知。過去,我們是用email,隨著各種IM肆無忌憚的入侵我們的生活,現在用推送訊息來通知也是很合理的…

在台灣,你不可能不用Line,幾乎沒有人能跟朋友說自己沒有Line帳號,因此,在VSTS CI (Continuous Integration)當中整入Line通知也是理所當然的。

怎麼做呢?

首先你可以在VSTS的Team Project的管理畫面中,找到Service Hooks,這是一個好用的功能,他可以幫你在該專案特定事件發生時,連結到外部系統並觸發某個動作:

如果你按下上圖的新增鈕,會發現其實已經很多外部系統可以連結了,例如大家很熟悉的Slack、Trello…,很不幸的,我們要發訊息的Line不在裡面:

但不要緊,你會發現我們可以透過Web Hook觸發一個http post,我們只要在該http post裡面來發送Line訊息即可。因此,我們在上圖中的畫面選擇Web Hook,接著按下Next,會出現下圖中的畫面,在該畫面上你可以選定Trigger,也就是,當哪一個事件發生時,要觸發http post來發送通知:

你會看到,選項中有Code Checked in(支援git版控的專案則會出現code pushed),以及Build completed、WorkItem Created/Updated/Deleted…等觸發事件,請選擇你要的。

然後按下Next,接下來出現的Action畫面,你只需要輸入 URL即可,也就是您選定的事件發生時,要以Http post通知哪一個URL?

你可以自行設計一個可接受http post的WebAPI,並在其中發送Line訊息。如果你還不知道該怎麼設計,我們特別幫你做了一個,讓你可以嘗嘗鮮玩一玩。(其實是我們團隊自己要用的啦…)

請先保留上面這個畫面,別關閉。然後開啟另一個瀏覽器,輸入底下網址:
http://isbaas.azurewebsites.net/VSTSWebHook/default.aspx
將會出現底下畫面,這是一個VSTS WebHook URL產生器:

請依照上圖中的步驟,填妥上面該WebHook URL的用途,按下產生鈕,接著會看到上面產生出一串GUID(WebHook URL),產生出GUID之後,請接著按下上圖(3)的按鈕,將會出現底下的Line登入畫面(這是Line的網頁,而非我們開發的網頁):

如果你還記得,我們前面曾介紹過的Line Notify機制,大概就知道我們準備在該WebHook中透過Line Notify來發訊息(而非用Line Bot),上面的這個登入畫面,就是Line的OAuth機制,用來取得可透過Line Notify發訊息給用戶的Token。

請用您想要接收到訊息的Line帳號登入,按下Login之後會出現底下畫面,讓你確定你要用哪一個帳號(或群組)來接收通知:

請選定後按下Agree and connect,如果一切順利,接著會出現底下畫面:

請牢記上圖中藍色的URL,並將其複製到剛才我們做到一半的WebHook URL輸入畫面中貼上:

按下Finish之後就大功告成囉,你會發現,未來當您的Team Project剛才選定的Trigger發生時,你的Line就會收到來自Line Notify的通知:

你可以把剛才上面的藍色URL貼到多個WebHook Trigger中,這樣當相對的Trigger被觸發時,你剛才綁定的Line帳號都會以Line Notify收到VSTS傳來的通知。

如果除了你自己以外,你也想讓其他團隊成員也收到這些通知,你也可以把剛才的藍色URL分享給團隊成員,請他將該URL貼到瀏覽器上,會出現底下畫面,同樣的按下『訂閱上述WebHook』,並且綁定Line帳號,即可讓您的team member和您一樣,在事件觸發時收到Line Notify的通知訊息:

透過這個簡單的設定,你的VSTS CI Build/Check In(或WorkItem更新)都會即時的以Line通知您,如果有興趣的話就玩玩看囉。以後找時間,我再來介紹這是怎麼實現的…

免責聲明: 以上VSTS WebHook服務網址是我們為內部團隊自用所開發的服務,我們不對此服務進行任何瑕疵擔保。您的VSTS Action JSON資料將會經過此WebHook以及微軟Azure Web App雲端服務,並透過Line Notify機制傳送給予綁定該WebHook的Line帳號,但我們並不會收集和使用您的Action JSON資料。