.NET Walker

A> B> C> D>

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

前面提過，當我們有一個新的功能(或是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...

今天在改一個以前自己寫的系統。 愈改愈覺得，當初怎麼會這樣設計的? 很多寫法實在看不下去，只好重構一番，把過去的一些設計和架構做些調整和改善。我猜，只要你是職業(不需要是專業)的開發者，肯定也曾有過這樣的經驗。 我們常常覺得過去的東西似乎還有可以改善的空間，所以，系統就這樣在修修補補之中度日。 曾經我覺得這樣子不行，所以花了一些時間認真學習各種pattern、架構設計、框架開發...等知識技能，想說從此之後，應該能高枕無憂，在開發時做出比較能夠長治久安的設計。 結果呢? 跟你猜的一樣，並沒有。系統還是在修修補補中度日。這到底是為什麼? 幾年之後我知道，原因很簡單，因為環境在變，技術在變，需求在變，我們活在一個多變的真實世界，然而我們能控制、能掌握的變數實在太少，少到所有的預先規劃和設計最後看起來都變得可笑。 所以，敏捷(Agile)不相信計畫(Plan)，甚至誇張一點說，敏捷不相信有完美的預先設計(Design)。 但注意，這不是完全不要設計，而是，不管當時看起來怎麼完美的設計，你都要有這個心理認知--『 日後它一定會變得不完美 』。不管你做了什麼樣精細的計畫(Plan)你都要知道，這計畫未來一定會走歪，只要你是活在一個充滿變數與未知的真實世界中。 你不相信? 或許你會問，那為何過去的年代，計畫似乎是有用的，甚至有人手上可以有好幾套劇本，事情的走向總是被掌握在足智多謀、細心計畫的智者手中? 那是因為過去的時代沒有現今的科技與技術，資訊的傳遞也不像現在這麼迅速，當時的世界給了人們一個假象，讓人誤以為自己可以掌握些什麼，能夠控制些什麼，能夠讓事情的走向依照計畫，或是運籌在股掌之間。 也確實，當你手上的資源越多、運算能力越強大，面對的問題越簡單、變數越少、時間越短，那預測和掌握未來的可能性不是不存在。 反之，當你手上的資源越少、變數越多、你就會發現對未來的掌握度趨近於零，事事依照計畫走的可能性根本不存在。 所以我們乾脆不要計劃了? 開發時也不用做任何架構設計? 對，也不對。 對的是這個想法，預先計畫和預先設計並不可靠，這意味著你不能完全倚賴它。 不對的是這個行為，你不能完全不做任何計劃或設計，你只是不該再像是以前那樣鉅細靡遺地去設計，並要求所有人照著劇本走，期待規劃好了就不會再改變。 會不會很矛盾? 對我來說完全不會，因為這就是人生。 ...

一個下午，以前公司的同事跑來，哭訴著在新工作中推動敏捷發生的種種慘況。 我盡可能的耐心聽完，跟大家知道的一樣，不外乎是一些常碰到的現象，長官們不支持，團隊成員後期的配合度也越來越低，數個月後看不到任何果效，反而被客戶抱怨開發品質變差，一直要配合測試『半成品』…凡此種種，導致了一個很顯而易見的結果：半年後團隊回到了原本習慣的開發方式，他則是離職謝罪，業界再添一個失敗的敏捷案例。 他說：『我不後悔，如果再來一次，我依舊會堅持推動敏捷！』 我笑笑地看著他，問道：『我以前說要怎麼推動敏捷，記得嗎？』 他看了看我，想了一會，回答：『你好像沒說過，你說的是…不要推動！』 『是啊，我以前說了，敏捷「 不要推動! 」，我不是開玩笑的！』我笑著說。 『特別是當你的主管腦袋裡面根本沒有敏捷時，推動是沒用的』我喝了一口咖啡『反過來說，當你的團隊腦袋裡充滿敏捷時，根本不用推動，屆時你想攔都攔不住。』   『那不推動能怎麼辦呢？專案狀況很糟，難道放著不理嗎?』他有點不服氣。 『不是的，平常的時候，你得要帶風向。』 『 帶風向?』他看著我，一幅不可置信的樣子。『這些人的腦袋跟ＸＸ(消音處理)做的一樣，我怎麼可能帶得了風向? 』他又補了一句『別開玩笑了。』 『你有沒有想過』我問他：『如果你連風向都帶不了，又怎麼可能推動呢?』話說完，他傻了。 『所以，關於推動，你首先要做的是其實是擴張影響力。』我接著補充道：『帶出影響的方法有很多種，除了你自己以身作則的示範之外，推薦好的書、適合的研討會、有預算的話外請講師上課、在企業內安排敏捷成功案例分享...有很多事情可以做。基本上就是，洗腦。』    『我認識某家公司的CIO，這幾年舉凡公司會議，開口必提microservices、docker，即便他不確切知道這些term到底是什麼，或許跟他心裡想的有所差異，但不論如何，這些名詞朗朗上口，這也是洗腦成功的案例…』我說道。   他打斷我：『但是…如果主管們的腦袋裡沒有敏捷，那到底塞了些甚麼XX(再次消音處理)?』   我回答：『每一個層級的主管，在意的往往有所不同，很多人以為主管愛打高空，但原則上愈高層的主管，關切的事情卻總是愈務實(現實)，你必須知道他們在想什麼，然後用他們的語言去和他們對話...』我接著說...

身為開發人員，我猜你也和我一樣曾有這種經驗… 你拿到一份規格書，依照內容進行開發，程式寫著寫著，過了一陣子之後，發現… 不對啊，這規格書本身很矛盾!? 如果依照前面說的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的每個迭代(或交付)都必須要對用戶產生出價值(Value)』。 因此我在談MVP時的重點，從來都不是雛形(prototype)、也不是邊做邊改去符合(或探索)用戶需求，甚至不是其實我認為也很重要的快速反饋，而是『時刻產生價值』。 沒有帶來價值的產出，不管是滑板、腳踏車還是機車、汽車，對我(客戶)來說，都叫做『浪費』。 當客戶的預算有限、需求常常變、一切彷彿都捉摸不定時，你很有可能永遠都不知道客戶(或市場)到底最終要的是戰車還是超跑，但，不管你產出的是什麼，只要能在當下立即為客戶帶來『價值』，那就是好東西，否則不管你做出什麼曠世巨作或太空梭，只要沒能帶給客戶價值，我們都稱之為『浪費』。 敏捷專案管理中所追求的，是每一個迭代、每一次交付都要能為客戶帶來『價值(Value)』。這很不容易，但這才是我在乎的重點... 後記：關於價值，為何我們那麼看重? 後續我又做了一些補充，請參考 這裡 。 ------------------ 相關課程： http://www.studyhost.tw/NewCourses/ALM 電子書： http://studyhost.blogspot.tw/2014/10/blog-post_1.html 如果需要即時取得更多相關訊息，可按 這裡 加入FB專頁。若這篇文章對您有所幫助，請幫我們分享出去，謝謝您的支持。

接著，我們來看如何在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並...

原始程式碼對於軟體公司來說是一種資產，Source Code被納入版控不足為奇(沒有才奇怪)，但我常常看到企業內的MIS/IT，認為自己開發的專案只是小型專案，或是開發人員只有『一個』，所以要控管什麼版本呢? 因為一切都在自己的腦袋裡啊。 不，千萬別這樣想。 在這個時代，任何專案，那怕從頭到尾都只是一個人開發的，都應該要簽入到版控系統當中。不管是任何一種專案，不管是因為任何目的原因所撰寫的，不管它能夠在企業中活多長，只要有需求，有程式碼，需要維護，就一律必須納入版控。 如果非要我在兩者中選擇其一，我會說，軟體專案成敗的關鍵常常不在開發，而在維護。在這個時代，幾乎沒有寫完程式碼後可以不用維護的專案，也沒有你可以大聲喊『Close!』結案之後就再也不管它的程式碼，幾乎所有的Projects都會持續衍生、修改Bugs、調整需求。如今想要很快的生出一個可以動的網站太容易了，但隨著需求的變更，對程式碼的修改常常才是軟體開發真正內涵的開始。況且廣義的說，專案還沒有交付前所作的任何需求變更或修改，也都得算是維護的一部分。 如果你敢在寫好程式碼編譯成.dll之後，立馬把source code丟掉，我就承認這世界上有不需要維護的專案，但我們從來不敢這麼做，對吧? 不管一個專案再混亂、或是你開發的是根本是拋棄式的應用程式(用一次就不會再用)，原始程式碼都至少還要留上一段時間，甚至永久保存下去。 而如今這些需要無限期永久保存的程式碼，慢慢的逐漸移動到了雲端環境上，我們到了一個版控雲端化的時代。當然，保存原始程式碼不是為了安全感，TFS/VSTS的版控可以幫助我們解決那些實質問題？ 版本控管的價值 有沒有發生過底下這些事情? 某位團隊中的程式設計師改了某一個bug，結果另一個原本好的功能卻壞掉了? 沒改過的地方怎麼會錯呢? 客戶突然告訴你，你剛才改好的某個功能他不要了，他要回到上上上個版本的那個狀態! 團隊成員結婚去度蜜月了，但不幸的是，他手上負責的某個案子，客戶發現了一個安全性的漏洞，嚴厲指責這估計是他結婚前一個月的某次修改時造成的，但...那段程式碼在哪呢? 你同時是三個軟體開發專案、兩個維護案的程式碼設計師，面對客戶和專案經理天馬行空的需求，你的大腦常常必須在2-3個案子之間切換，剛剛才改完維護案的bug，下午要開發另一個專案的新功能，但是…昨天…我程式碼寫到...

在開始使用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)。 好，所以重點在於… 你待會建立的VSTS站台，是一個雲端服務，你將會把所有的程式碼版控、工作項目(WorkItems)、Bugs清單…等資訊存放在微軟的雲端。 你建立的一個VSTS站台，上面可以建立無數多個專案，每一個專案當中可以有一個或多個Project Solutions(.sln)。 權限的控管是透過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)的部分可...

去年(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) 底下是系列文: the DevOps journey (0) - 敏捷開發真和每個開發人員有關? the DevOps journey (1) - 敏捷開發不相信時程預測? the DevOps journey (2) - 如果時程難預估，不如追求透明度… the DevOps journey (3) - 『透明度』與『自動化』… the DevOps journey (4) - 建立VSTS站台與專案(2017年Q1版) the DevOps journey (5) - 在VSTS站台與專案中添加成員 the DevOps journey (6) - 安排與設定專案的迭代 the DevOps journey (7) – 你的source code還沒上版控嗎? the DevOps journey (8) – 使用TFVC程式碼版控 the DevOps journ...

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

前面 說了，在近代專案管理當中，大家已經慢慢能夠理解，死板的去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有多少。 上...