Gelis 技術隨筆-部落格

前言 最近接觸一些開發團隊，發現還是有許多團隊雖然已經導入 TFS 或 VSTS (以下都簡稱為 VSTS)，但是仍然只是將 VSTS 當作 Source Control 使用而已，不要說 PM 或 PO 沒有將 WBS 或是 Task(後面都簡稱為 Task) 鍵入 VSTS 中的 Work Items 外，就算有鍵入 Work Items ，也沒有強制要求團隊成員 Check-In Policy (簽入原則)，將完成的程式碼簽入 VSTS 的時候，關聯相關的工作項目 Task 。 如果開發團隊連最基本的原始檔管控、Work Item 、工作管理等都沒有做的完善，而原始檔管控又算是軟體專案開發最基本功的部分，如果連基本功都無法落實的話，那麼，後續的 Agile/Scrum... 其實都不用談了。 引發的問題、隱憂 筆者先前，有許多文章在探討團隊開發、個人工作管理與共同規範的關係與問題，這也是筆者先探討 問題、隱憂的原因，因為撇開團隊所使用的開發方法、合作模式 Agile/Scrum/CMMI 等方式不談，因為流程在這邊並不是重點，但是工作若沒有被有效管理，你如何掌握每一個工作項目所花的工時、無法掌握每一個工作項目的工時，更不要說你想要掌控團隊成員中，每一個人手上有哪些工作，有那些已經完成、那些正在進行中、哪一些還未開始，以及哪一些工作由哪一位成員進行 (工作分派狀況)。 在以前，大約十多年前，2005 年左右，當時 TFS 還未盛行，當時筆者的公司、訪間的軟體開發團隊會使用 EXCEL 來控管團隊的工作進度，當時，一樣控管得很好，只是會有幾個缺點， 團隊成員要另外開啟 EXCEL 與其他成員共享 Sheet，每天Update工作 主管要引導團隊成員 Update EXCEL 內容 主管對團隊成員間，要花比較多的溝通成本 團隊成員之間，要花比較多的溝通成本，討論程式碼 (因為 EXCEL 內的說明無法直接與程式碼相關連) 使用 EXCEL 管理專案當然不是不好，以前的開發人員這樣管理專案，不也管理得很好，相信很多讀者心裡是這樣想著，沒有錯，但是 (有但書)，開始有使用者回饋 (進入 UAT) 階段， 團隊成員 A 簽入的程式碼究竟是為了某個 Task 而修改、或是因為從某個原始 WBS 展開的 工作項目，User 測過後有 Bug 所...

前言 有在看小編部落格的朋友應該都知道，我有許多關於 Project Templates 相關的教學、投影片、分享部落格文章等，本次小編進行另一個客戶的的 C# Project Templates 專案時，卻發生一個詭異問題。 就是如上這個錯誤訊息，每當建立安裝好的這個新的 C# Project Template 時，專案建立過程中就會出現這個錯誤，這….. 是什麼詭異訊息？我從來就沒遇過啊？從以前建置 Visual Studio 2015 的 Project Templates 就從沒遇過這種情形，為一的差別只是目前使用的是 Visual Studio 2017，難道我踩到了 Visual Studio 2017 Extensibility SDK 的坑？  喔~ 不會吧，馬上搜尋一下 Google ，結果是，從沒有人遇過跟我相同的問題，一度還認為是專案目錄名稱太長，也許 VSIX 執行環境命令列長度限制，於是將整個專案複製到 D:\ 磁碟機下面還是一樣的狀況。 就在案情陷入膠著時，於是我將編譯完成的 VSIX 安裝檔直接解壓，查看其內容時有了驚人的發現… 這麼發現倒不是 Visual Studio Extensibility SDK 2017 有什麼 Bug，而是我發現了我驚人的失誤…. 什麼失誤呢？@@ 答案是，字打錯，什麼字打錯呢？看看下面的圖就知道了…… 在 C# Project Templates 裡，編輯 ProjectTemplate.csproj 檔案時，不管是需要編譯、不需要編譯的檔案均放置在 <ItemGroup> 節點下面，只是，在習慣上，我們會將不需要編譯的 Content 內容 (也就是<None>的項目)，放在另外的 <ItemGroup> 下，只是代表包含檔案的 Include 我不小心敲成了 Incluse 以至於引發這個作業失敗的錯誤訊息。   結語 這次問題的起因在於，我們若是編輯 .csproj 或是 .vstemplate 等原本由工具產生的檔案，對於 Visual Studio 而言，因為 Visual Studio 工具自行在 Maintain ，Visual Studio 工具不會料想到有人會去修改、甚至改錯了 Visual Studio 工具不...