發表文章

目前顯示的是有「Scrum」標籤的文章

導入敏捷最難的是什麼?

圖片
『導入敏捷最難的是什麼?』上課時同學這麼問。 『這問題,我可是很有經驗呢。』我心裡這麼想著,然後慢慢的回答… 導入敏捷最難的是…『組織總想在其他條件都不改變的狀況下,實現敏捷轉型。』 我常說:『人人擁抱敏捷,但真實狀況是…沒人想要改變。』 你說,不會啊,我們公司常常改變! 老闆總是朝令夕改…搞的大家無所適從。 我笑著說:『是啊,那是他改變你,不是改變他自己。況且,你不是也不喜歡別人常常改你的工作模式…對吧?』 總之組織從上到下,沒人喜歡『被改變』。 所以,導入敏捷當然可以…但,不能碰KPI、不能違反ISO、不能調整考績與獎金制度、不能改變合約簽訂方式、不能變更HR既定規則、不能調整休假與簽核流程、不能違反愚蠢的勞基法規法條、不能取消既有的公司會議(不管多麼無效)、不能改變組織結構、不能拆分部門與團隊…在所有外界環境都不改變的狀況下,要我們協助導入敏捷…幹的好。 這不是『難』,這根本是『為難』。 但我得說,這才是企業轉型的真實狀況。有興趣『談』轉型的老闆很多,有膽量豁出去的可算是鳳毛麟角,除非… 『除非什麼?』學生問。 除非…那公司差不多快掛了,死馬當活馬醫,這時候老闆可能會破釜沉舟,孤注一擲。但也往往能帶來最好的成效。 這也是大家常常看到,新創和小公司比較容易導入敏捷的關係。在大概超過百人左右的組織中,即便想要在一個小部門中導入敏捷,都很容易碰到與企業規範衝突的問題。 要知道,你可是在跟整個組織既有的習慣和文化對著幹,後台不夠硬,身段不夠軟,導入到最後,往往沒能改變組織,先陣亡的會是你自己。 『那怎麼辦?』另一位學員問。 『看起來很難,但也不是沒辦法。』我說『先準備好自己,別聽到台上講的精彩,一股熱血就勇往直前。也別亂找顧問,敏捷轉型不是小事。要幫企業實踐轉型,得長時間陪著企業一步步解決問題,身為顧問,你要非常清楚每一個工具、每一個activity想達成的目的,然後幫助企業選擇最適合的方式,量身訂做,趨吉避凶。』 好啦,先上課吧。先搞懂Scrum每一個角色和活動的意義,到時…才能真的幫上企業實現轉型。

Azure DevOps in Action - 從需求建立分支的開發流程

圖片
前面提過,當我們有一個新的功能(或是bug)需要開發時,可以從tasks上建立branch,這個模式是走feature branch的開發流程 [1] 。一般來說,我們可以在Azure DevOps的Boards或是Sprints來建立: 其實我自己比較喜歡在Azure DevOps的Sprint畫面中來建立: 原因很簡單,因為開立tasks與branch的這項工作,幾乎都是在Scrum的Planning Meeting Part 2中進行,Planning Meeting Part 2,是團隊在討論某一個backlogs該『 如何做? 』的會議。這個會議進行時,肯定已經進入迭代(Scrum的迭代稱為Sprints),且已經決定好哪些backlogs要放入此迭代進行開發。所以,上面這個Azure DevOps中Sprints的畫面,團隊討論時一邊開起來看最適合不過了。 至於在哪一個tasks身上開Branch? 完全無所謂。因為最後相關的tasks都應該一併納入。 例如,上圖中,團隊準備開發『計算BMI』這個backlog,在planning meeting時,為該backlog建立了三個tasks,分別是編號942, 944, 945。不管你在哪一個task身上開branch,都會出現底下這樣的畫面: 請在(上圖A)的地方,輸入branch名稱,然後把所有相關聯的tasks都加進來(上圖B),直到三個與此branch都相關tasks都被納入。 [2] 完成後,按下『Create Branch』鈕建立即可。 接著系統會自動帶你到底下畫面: 你會發現,該branch已經建立好了(上圖A)。這時候,你可以透過你的開發工具,把程式碼sync/pull到你開發端的電腦上,然後你會發現,在開發端的電腦上,已經可以看到該branch: 你可以透過Visual Studio的branch管理工具(上圖A),點選『管理分支』,然後就可以在出現的遠端分支中,找到剛才建立的分支(上圖B)。開發人員即可切換到此分支,開始撰寫程式碼。 建立PR(Pull request) 一但程式碼撰寫完成,開發人員可以透過同步(sync)的方式,把Committed在開發端的程式碼,同步到伺服器端。 一但程式碼完成同步,你會發現當你開啟Azure DevOps伺服器端的檔案檢視畫面時: Azure D...

你只要堅持一天就好…

圖片
2019/1/26 敏捷思維、敏捷人生 之一 從敏捷的角度看這個世界是很有趣的。 年紀越大,越覺得在這個變動的時代中,計畫導向的人生原來根本不存在,小時候聽過很多傳記故事,描述某人從小立志如何如何,因為這個遠大的志向,少年時開始磨練自己,按部就班實現每一個計劃,然後一步步走向成功... 後來才發現,原來這些傳記故事大多是虛構,或是作者事後諸葛的加油添醋。真實世界中才沒那麼容易『按部就班』,意外總是比計畫來的擾亂人心。有心理學家說,成功者喜歡把事情合理化,認為自己的成就源自於規劃好有計畫的努力。然而,這世界上更努力的大有人在,常常只是運氣沒那麼好而已。 所以運氣比努力重要? 錯,千萬別誤會了。 事實是,未來很難計畫,我們沒有人知道明天會怎樣,先見之明往往只是事後諸葛。人生當中唯一能做的,就是努力過好每一天,至於其他的,交給上帝。 『被討厭的勇氣』書中描述阿德勒的價值觀,他認為過去已經消失,而未來則根本『不存在』,你真正擁有的,其實只有今天而已。為了過去懊悔沒有意義,為了未來擔憂不切實際,唯一有價值的,是拼命把你的今天過好。 『 我們唯一擁有的,就只有今天而已。 』這是多麼敏捷的思維啊。(居然出自百年前的思想家) 永遠聚焦在當下這個sprint,每一天,每一周...累積出每一個小小的Win(這不就是潛在可交付產品增量嘛!),然後,你就有機會活出一個精采的人生。 過去失敗的sprint無須留戀,每個月給自己幾小時retrospective很夠了,然後move on。太遠的未來遙不可及,過多的計畫或擔心離目標越來越遠,只是折磨自己。 唯一不可放棄的是 現在 ,還在衝刺的你,必須專注在這個Sprint,只要你能過好每一天,對得起當前這一刻的自己,未來的人生也不會對不起你。 原來真正決定你人生的,不是計畫,不是機運,是活在當下這個Sprint的自己... ------- 註1: 在Scrum軟體開發方法論中,Sprint指的是一個迭代(iteration) 註2: 潛在可交付產品增量(potentially shippable product increment) 後記: 和大家討論Scrum、Agile、DevOps時,許多人常會提到幾位作者知名的著作,像是目標系列的高...

神聖不可侵犯的規格書

圖片
身為開發人員,我猜你也和我一樣曾有這種經驗… 你拿到一份規格書,依照內容進行開發,程式寫著寫著,過了一陣子之後,發現… 不對啊,這規格書本身很矛盾!? 如果依照前面說的XXX這樣做,那後面的OOO可能會做不下去,如果依照OOO的做法,那用戶顯然以後會很難用唷,反覆來回看了幾次,細細思考之後,你肯定了這份規格書確實有問題。 OK,這時候的你,會怎麼做? 一般我們會有底下三個選項: A: 管它的,依照規格書先做完再說。 B: 找客戶或PM/SA溝通。 C: 用自己的方式直接做出更好的版本。 如果規格書真的是錯的(當然開發人員也可能自己理解錯),那走A顯然是會造成浪費,你非常有可能做出一個看起來十分符合規格但實際上沒法用的軟體,這狀況我們都碰過,而且很常見,所以這邊暫且先不討論。 選C,則在大部份公司是不受歡迎的(你誰啊?竟敢動SA/客戶的規格? 你第一天來的唷?是剛來看不懂規格書嗎? 驗收是照規格書還是照你自己發明的寫法啊? ) 一般來說,你身為Developer擅自改規格是要讓SA/SD/PM怎麼拉下臉去承認自己的規格書有寫錯呢? 況且,規格書若經過了客戶的認可,那你這麼做就是一竿子打翻一條船上的所有人,要一票人去承認自己的思慮不周,而這不周還只有你一個人看的出來!? 如果你選的是B,其實是一件挺累人的事情,你可能會碰到很多挫折,過程中,發現沒甚麼人願意理你,並非所有人都跟你一樣在乎規格的正確性。你慢慢發現,似乎大家都各自幻想著一個完美的最終產出的成品,卻期待著這成品能透過一個千瘡百孔的設計圖來實現。 就算真的能夠開始溝通,你可能也會慢慢認知到,原來溝通一條規格的成本和時間比你想像的高很多很多(但又收不到錢),隨著時程越來越緊,你逐漸開始妥協,在規格書中『刻意保留模糊』,以作為日後驗收時各自表述、各自解讀的籌碼。(搞半天,原來先前規格書中的矛盾就是這麼來的…) 當然,如果規格書不出問題,那上面這些故事場景當然也都不成立,不過…我想你也做過專案,你來告訴我,碰到完美的規格書的機率有多少? 0% 不誇張,就是0%,我從來沒碰過沒寫錯的規格書。 既然規格書那麼不堪用,不如乾脆丟了吧。 所以,曾經有敏捷開發的支持者告訴你,如果想要建構出一個真的可用的軟體產品,與其讓開發人員 只看 規格書,不如多一些和客戶、需求單位之間的 直接頻繁的溝通 。 這就是你會在 敏捷開發價值觀 中看...

真正的需求訪談,是談價值、而非只談功能。

圖片
前幾天聊到價值(Value),給我點時間,讓我細說從頭。 這幾年做案子下來,發現大多數的SA/PM/PO在需求訪談時跟客戶談功能很在行,談價值卻很吃力。你可能覺得疑惑,需求訪談不就是談需求嗎? 為何會扯到價值? 回答這問題前,先幫我想想,一個軟體的需求是為了什麼? 沒錯,需求是為了實現價值,功能則是需求的具體表現。 舉例來說,一個電子商務網站可以有各式各樣的功能,但核心價值要嘛是銷售、要嘛是服務,OK,這個你一定懂。 但大多數的SA或技術人員,受過了多年的技術訓練,談功能很拿手,各種工具、圖表、道具順手捻來毫不手軟,客戶看的眼花撩亂但也很開心,因為看到這麼多功能(工項)被列出來,腦袋裡自然而然幻想著,當這些功能實現,需求『自然』就滿足了,而需求被滿足,價值『自然』就實現了。 但真的是這樣嗎? 做那麼多年的軟體之後,你肯定知道,不是的。擁有一堆功能跟這個 軟體/網站 能不能滿足客戶需求乃至於實現某種價值,根本可以是兩回事。 然而很多客戶(和廠商)死不信邪,以為價值沒實現是因為功能不夠多(天殺的!!!這是我碰過最可怕的思維...) 然後試圖用無止盡的增加功能來滿足可能根本不存在的想像出的需求,然後在心裡期望價值能發生。(天佑PM/天佑SA/天佑客戶...) 每當我們要求跟客戶談需求時,試圖把焦點拉回價值(而不是一直停留在談功能上),一開始客戶都很不習慣,因為這仿佛很抽象,廠商自己也擔心,因為哪有一個網站可以保證上線後就財源滾滾而來? 就好比你賣一個ERP軟體要保障客戶使用後利潤增加一成,這...似乎有點難? 對,但就是因為這很難,所以久而久之,我們把價值放一邊,銷售時就拼命暗示客戶你有某種需求等著被滿足,而要滿足這些需求,則要做出這些功能,只要你買了這些功能,一切就搞定了。 然後,最初期待實現的價值呢? 恩...沒實現嗎? 不要緊,下一套軟體我們再來談... ------------------ 相關課程: http://www.studyhost.tw/NewCourses/ALM 電子書: http://studyhost.blogspot.tw/2014/10/blog-post_1.html 如果需要即時取得更多相關訊息,可按 這裡 加入FB專頁。若這篇文章對您有所幫助,請幫我們分享出去,謝謝您的支持。

MVP(最小可行性產品)的重點不是雛形、不是迭代、不是探索需求、而是實現價值!!!

圖片
最近網路上有幾篇文章, 這篇 文章中談到的MVP(最小可行性產品)那個圖,我在上課時也常用,也常被問到一樣的問題,而我的回答也總是很簡單... 在下圖中第一和第二個路線的例子裡,我們從來都不是說要做『一台汽車(太具體了)』,而是說要做一個運輸或交通工具(相對抽象),因為一開始你根本不會知道具體需求是甚麼,下圖中的『汽車』只是運輸器具的一種呈現方式,但根本不是一開始的目標... (如果你做過產品,就會知道,開始時需求根本不可能是具體的,更不用說有什麼『清楚的規格』這種事情了,再清楚的規格,其實都是你自己的想像,只要碰到市場都會幻滅) (講到這裡你應該知道我認為下圖是對是錯了,但重點在於,這些根本不是重點!!!) 這幾篇文章討論到最小可行性產品這個議題時,都少了一個我們做軟體專案時非常重要的概念,就是:『MVP的每個迭代(或交付)都必須要對用戶產生出價值(Value)』。 因此我在談MVP時的重點,從來都不是雛形(prototype)、也不是邊做邊改去符合(或探索)用戶需求,甚至不是其實我認為也很重要的快速反饋,而是『時刻產生價值』。 沒有帶來價值的產出,不管是滑板、腳踏車還是機車、汽車,對我(客戶)來說,都叫做『浪費』。 當客戶的預算有限、需求常常變、一切彷彿都捉摸不定時,你很有可能永遠都不知道客戶(或市場)到底最終要的是戰車還是超跑,但,不管你產出的是什麼,只要能在當下立即為客戶帶來『價值』,那就是好東西,否則不管你做出什麼曠世巨作或太空梭,只要沒能帶給客戶價值,我們都稱之為『浪費』。 敏捷專案管理中所追求的,是每一個迭代、每一次交付都要能為客戶帶來『價值(Value)』。這很不容易,但這才是我在乎的重點... 後記:關於價值,為何我們那麼看重? 後續我又做了一些補充,請參考 這裡 。 ------------------ 相關課程: http://www.studyhost.tw/NewCourses/ALM 電子書: http://studyhost.blogspot.tw/2014/10/blog-post_1.html 如果需要即時取得更多相關訊息,可按 這裡 加入FB專頁。若這篇文章對您有所幫助,請幫我們分享出去,謝謝您的支持。

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

圖片
對我來說,從傳統Waterfall專案管理方式移轉到敏捷開發,兩個最主要的關鍵就是『透明度』與『自動化』,我們前面談過了 透明度 ,這一篇我要聊聊自動化。 我在課堂上曾說,如果你不確定要怎麼改善你的團隊,那設法提高整個專案(各項事情)的透明度,以及讓開發流程盡可能的自動化,幾乎可以確定對專案成果將帶來顯著的正面影響。 為何我們該在意『自動化』 有幾個顯而易見的理由: 回應真實世界所需的速度        面對瞬息萬變的市場,你幾乎不可能像過去一樣,累積所有的bugs每三個月或半年固定上版更新一次。如今,所有已知的bugs,在一周內更新完畢應該算是最差的狀況了。對一些線上服務或是網站,如果是跟交易金額有關的bugs,沒有人會接受已知的bugs被放任不管。        如今在技術上,我們絕對可以在程式設計師撰寫完程式碼(不管是修復bugs或是增加新功能)之後,自動進行伺服器端建置,建置完成後隨即進行非人工的自動化測試(用以確保這個更新不會改壞了其他原本是好的的功能),如果自動化測試一切正常,則自動上版到測試機或是正式機。整個過程在技術上可以完全自動,並且在從開發人員Check-in code之後一小時內自動完成。 強迫品質提升        為了讓上述的自動化可以實現,你必須建置自動測試流程,把過去系統從開發到上版之間,所有原先倚賴人力進行的流程,改為由電腦自動進行。在這個調整的過程當中,你的專案品質自然而然會被迫自動提升。         因為你過去沒有自動化測試把關、過去沒有伺服器端自動建置、過去沒有上線後的錯誤警示…改為自動化之後這些全都要實現,如此一來,你的專案品質自然和過去以往不同檔次,將會有顯著的改善。 減少人為錯誤以及倚靠人力的SOP        過去,在一個沒有自動化的開發流程當中,單一程式設計師把改過的程式碼在自己的電腦上撰寫完成,經過自己初步的測試,他就認為這段程式碼 寫完了 。然而真的是嗎?    ...

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有多少。 上...

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訊息。如果你還不知道該怎麼設計,我們特別幫你做了一個,讓你可以嘗嘗鮮玩一玩。(其實是我們團隊自己要用的啦…) 請先保留上面這個畫面,別關閉。然後開啟另一個瀏覽器,輸入底下網址: htt...

the DevOps journey (1) - 敏捷開發不相信時程預測?

圖片
這一篇,我們來討論敏捷開發中怎麼看待時程預估,以及迭代開發的重要性… 到底專案時程能不能預測? 這是一個常常困擾初踏入敏捷開發領域的新手的問題。 你一定聽到過有人說(甚至,其實 上一篇 推薦的Martin Fowler的文章中也提到過),敏捷開發不太相信可以進行準確的時程預測,我特別用『預測』這個字,而非預估。中文很有意思,這兩個字很接近,但有那麼一點點的不同。 前面 提到過,既然真實世界裡面的 需求根本不可能固定 ,開發人員的素質(每個人每天的產出)也不太可能統一,那我們幾乎已經宣告無法掌握軟體開發專案中,最重要的兩個變因,那這樣怎麼可能精準的預測出開發時程呢? Martin Fowler在早期的文章中,幾乎是直接告訴你,預測是不可能的。 但這件事情非常弔詭,大概所有開發人員都明白,在需求不確定的狀況下,要精準的預測專案時程、計算出人天數,是幾近不可能的事情。但 好笑 有趣的地方就在於,幾乎所有的軟體專案的業務或PM,都會要求你在專案起始前,在一切模糊的前提下,估出人天數以便於 報價 。 壓在合約裡面的驗收日期和報價耶!? 難到不需要更詳細的資訊以便於精細計算嗎? 這是繼 上一篇 提到的軟體開發迷思之後,另一個超級經典、行之有年、卻嚴重違反常識/常理的軟體開發迷思。同樣的問題又來了,難道從來沒有人覺得哪裡怪怪的嗎? 我相信有,但你會碰到各種壓力,告訴你整個業界都是這樣幹的,你區區一個程式設計師想改變這個慣例? 不可能。 因此,開發人員只能習慣性的在時程預估裡面保留一些buffer,業務/PM報價時再加一些Buffer,然後客戶的採購砍一些作為折扣,done,成交。後面就看彼此的運氣了… 不能預估,怎麼辦? 這篇文章一開始的 那張圖 很貼切,它描繪出了理想狀況與真實世界之間的差異, 上一篇 說過,兩個軟體專案的需求不可能完全一樣,因為 完全一樣 你就根本不需要新的專案,買個套裝軟體或直接copy一份即可。因此,我們知道每一個軟體專案都是新的開始,既然是新的開始, 沒做過的事情要預估時間,這本來就是一種賭博 。 這也是軟體開發和工程專案差異很大的地方,傳統的工程專案施工較容易預估人天,因為施工方法固定,需求固定,常常只是在可以控制變因的狀況下,重新做一次而已,但軟體開發不是,每一個專案都是一場新的冒險。 我常開玩笑的跟業務說,你真要我這樣報...

the DevOps journey (0) - 敏捷開發真和每個開發人員有關?

圖片
#不想看廢話,直接按這裡跳到重點 這年頭大多數人已經沒有耐心,已經很難看完一整篇長篇大論,因為這樣,這幾年我們寫blog的時候,幾乎都零零碎碎,這使得許多學員面對知識的掌握,也變得片片斷斷。 如果可以,我希望能夠把我們這幾年面對軟體開發方法,以及ALM/DevOps的一些經驗,有條理一點的整理出來,如果你有興趣,不妨嘗試慢慢的看看,如果實在已經不習慣看長篇文章,也可以挑有興趣的重點來讀。 開始一段新的旅程 這一系列的標題中有個字眼『journey』,第一次看到這個字…是在一場研討會,我忘了是TechEd還是Build,印象中研討會的主題是Metro Style App(現在應該不多人還記得這個名字了吧?),主講人用journey這個字眼來描述學習一種技術的過程,我覺得真TxD的太貼切了… 不知道你有沒有發現,最近五年,軟體開發的潮流根本就是一場journey,而且非常像是我最愛的影集Star Trek Voyager中的旅程。你該怎麼形容這段旅程呢? 圖乎其來? 充滿意外? 不僅如此,大夥摸著石頭過河…似乎根本沒人能告訴你往哪個方向才是對的,你也不知道怎麼走才會到終點…這差不多就是這部影集當中的旅程。 若用來描述最近五年軟體開發技術的發展,根本是整個貼切到不行,而且從Web、前端、行動裝置、開發方法、框架…幾乎都逃不過這場journey魔咒,所有的技術都是 在途(on the road) ,一點都沒有發展成熟的跡象… 當然,如果旅程總是只為了看到終點倒也世俗了些,旅程的過程中還是有很多意外的小驚喜,以及足以令人回味的點滴,不管是你早已遺忘的Metro Style Application,或是充斥各種消耗型框架的所謂前端開發技術,又或者是我們要討論的這個主題 – ALM/DevOps。 關於開發方法的重要性 身為一個以寫程式起家的開發人員,就一個軟體開發人員的生命週期來看,我算是到了很老的時候,才願意承認軟體專案/產品的開發過程中,最重要的可能不是開發技術,而是開發方法。 技術能力的強度,是進入軟體(專案/產品)開發領域的入場券,它就是一塊敲門磚,技術能力的強度,決定了你敲門的力道。然而一但當門打開,你開始了一個專案,進入了一個團隊,參與了一個產品的研發,技術能力對成果的影響力,可能就開始慢慢式微了。請注意, 個人技術能力可能會影響開發團隊產出的...

VSTS的新功能 - 數位儀表板

圖片
2015/11月底,微軟在Connect();大會,正式公布了大幅度改版的線上TFS,也就是變了新名字的VSTS(Visual Studio Team Services,從前叫VSO)。 VSTS可視為線上版的TFS,讓開發人員可以對軟體的生命週期做非常良好的管理,是一套ALM軟體服務。翻成白話一點,就是軟體專案的統籌管理軟體。 更新後的VSTS,除了原本的版控、自動化建置、測試,以及工作項目管理之外,加上了眾人期待已久的數位儀表板功能: 這個討喜的功能,讓團隊以及PM/PO可以一目了然的看到整個專案的整體狀況,當然,這個儀表板是可以客製化的,有各式各樣的組件,可供專案管理人員選擇應用,您也可以為專案建立多組儀表板,分門別類的以視覺化方式來呈現所有資訊。 我們接著就來看,如何客製化這個數位儀表板。 (等等,你竟然還沒申請免費的VSTS專案管理服務? 請參考 這裡 。) 如果你有管理員權限,現在,進入VSTS專案之後,你會看到overview頁面上,右下角有一個『+』符號: 按下上圖右下角的按鈕,會出現一堆的Widget供你選擇,你可以隨意用滑鼠選擇一個或多個,佈置在預設的數位儀表板上: 類似像上圖這樣,可以點選幾個widget(被點選的會打勾),按下新增(add)之後,即可加入: 這很簡單,但重點是,這些圖表有何用途? 如果熟悉TFS/VSTS使用或和我們一樣採用Scrum開發框架的朋友們,應該很熟悉了,你可以在畫面上看到底下這些: 這些都是從library直接抓取出來的Widget,當然,你也可自行建立不同的查詢(Query),以呈現想要的結果。 例如,我們可以在work底下的Queries中,建立一個Query: 我們查詢專案中所有的Backlogs,儲存完成後,移入Shared Queries: 接著,建立一個新的Chart: 有各種圖表可以選擇,我們選擇Pie圖,並設定Group by “state” 欄位: 我們設計好圖表之後,可以透過圖表右上角的選單,把圖表釘選到數位儀表板上: 我們看看: 成功的在數位儀表板上,把Backlogs的狀態顯示出來囉。如此一來,一目了然的呈現出整個專案的狀況,老闆、客戶和PM還能說專案不夠透明嗎? 不僅如此,還有個好玩的功能,Query Tile讓你可以針對某一個數字設定紅綠燈警示看板,你可以點選Q...