關於團隊使用 VSTS/TFS 原始碼控管的 - 三兩事

前言
最近接觸一些開發團隊，發現還是有許多團隊雖然已經導入 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 所以進行這些修改， 但是，因為你只有在 EXCEL 裡記錄，而每個團隊成員的表達方式又些許不同。
試想一個情境：成員B 問成員A 你 2017/5/5 簽入的程式碼是為了什麼而改？
成員A說：我看一下 EXCEL…. 好像是為了 EXCEL 的第幾 15 列問題而改，….  但過些時候，又發現，好像是為了 第 21 列問題而改…. 這來來回回就形成無形的浪費，專案怎能不 Delay？不 Delay 才有鬼……. 更糟的是，團隊還不自知… 最後就大爆炸 (如圖一) ，因此能夠讓工具代勞的，怎麼不讓工具幫我們記憶呢？這也才符合敏捷的精神之一就是「減少浪費」。

如果時間久了，人腦記憶是有限，更不要說，如果成員 A 根本忘了回填到 EXCEL 中呢？那你要花好幾倍的時間回想當時為什麼這樣改。筆者先前有許多文章探討在這個軟體日益複雜，但是工具也日益發達的年代，能透過工具來幫助記憶為什麼不使用呢？VSTS 可以將專案的工作項目與程式碼相關連，並指派工作項目給負責的團隊成員，讓版本控管並不單只是版本控管，他能控管的不是只有程式碼，也控管所有團隊成員的產出，進度、Team Build 發行是否有 issue、Task Manager 控管 UAT 回饋的 Test Case 是否被處裡、誰處裡，處裡完成沒有，這個 issue 與哪一個 Task 相關聯，VSTS 比對後即可以知道是修改哪幾行 Code 才修復此 issue，只要 VSTS 打開來就以覽無疑，團隊不再需要 EXCEL，不再需要靠腦袋去回想改了什麼，因為 VSTS 全部都可以在 History 中查詢出來。
注意：
您應該使用「原始檔控制設定」==> 「Check-In Policy 簽入原則」來要求專案團隊成員簽入程式碼時，必須關聯工作項目、撰寫註解。


該怎麼進行？
這邊假設您已經將 VSTS 或是 TFS 作為原始檔控管，並以 Scrum 作為流程範本，並且團隊已有 Coding Standard/Coding Rules 或是 團隊開發共同規範 為前提，或參考筆者先前文章「導入團隊 Project Templates 樣版設計 – (首部曲)」。

1. 在專案 Kick of 後，PM/PO/SA 已經做完初步分析完成 WBS，或者畫出甘特圖也可以，重點在於已經做工作分解、與初步分析。
2. 小組討論、個工作項目由那些成員負責 (工作項目花費時間可與團隊成員討論，或是由 PM 或 PO 先押一個時間也可，而後實際進行時，團隊成員在 Backlog 長出需要的實際 Task 並押上實際撰寫程式的工時)
3. 由 PM 或 PO將 WBS 鍵入 VSTS 中，並指派給負責的團隊成員。
4. 由 PM 或 PO 建立原始檔控制的 「Check-In Policy 簽入原則」，最少需有「工作項目」、「變更集註解原則」等。
5. 團隊成員在 Backlog 長出實際的 Tasks 的時候，也需落實回填發生的工時。
6. 簽入程式碼時，使用小組共通的語言撰寫註解 （註解不是指寫給你自己看，別人看不懂也沒有用）

另外，程式碼簽入的時候，千萬不要簽入一大包，然後才將所有有關連的工作項目都參考進來，如下：

簽入一大包，對於使用 VSTS 以及以後還要 Maintain 這個系統的你而言，這個變更集對以後的你而言完全沒有幫助 （還不如不要關連算了），因為這樣就跟沒有關連工作項目一樣，因為你三個月事後再來看這個變更集，你還是得要花許多時間來瞭解（又是個時間的浪費），哪幾行 Code 是跟哪一個工作項目有關，又要花時間看個半天，那麼跟原本的情況不也一樣？

這種情況，通常有兩種：
一、開發人員改完一個需求，總是忘記簽入，等到想到要簽入時，已經改了5-6 個 Tasks 了
二、團隊間、PM/PO 沒有要求，以致開發人員習慣不好，總是等到全部改完才簽入
有讀者會問我說，但是有時就是牽一髮才發現動全身，怎麼辦呢？可以分幾次簽入，也就是說，你可先簽入一個最小版本，不一定是可以交付的版本，只是能夠 Compile 就好，但是這邊指的是在同一個 需求 （Backlog/Task）內的狀況，不是跨 需求 （Backlog/Task）的情況，如果真的有改到一半發現改的兩個需求是同一個問題，那可能要檢討 這個「需求」 或「Bug」在「分析/瞭解問題」時，有失精準度。
在最後說明，同一個需求，是有可能修改異動到 20-50 支程式碼，這端看專案大小、架構設計、喔，對了，額外一題，如果你的專案每次小修改都要改很多支程式，那有可能是在軟體架構上「過度設計」了。

迷之音：
所以我才說，這些事情都是環環相扣阿！

後記
當然，只有這些還不夠，但是必須先有前面這幾個項目，才能再來談如何落實「Code Review」、如何搭配如：StyleCop 設計屬於團隊的 Source Analyzer Rules ，甚至與 VSTS 的 Check-In Policy 整合，因為團隊若要落實 Core Review 甚至與團隊資深人員、新進人員人數的多寡、團隊編 制的方式、工作分工的方式 都有關係。
雖然，程式碼撰寫只是軟體開發生命週期裡的一小部分，但是為專案實際的產出，如果這些工作沒有落實，沒有管理的規範把關這些產出，那越到後期，所需的成本相對提高。