最近發現，還是有許多公司、開發團隊連最基本的原始檔管控、Work Item 、工作管理等都沒有做的完善，而原始檔管控又算是軟體專案開發最基本功的部分，如果連基本功都無法落實的話，那麼，後續的 Agile/Scrum... 其實都不用談了。
前言
最近接觸一些開發團隊，發現還是有許多團隊雖然已經導入 TFS 或 VSTS (以下都簡稱為 VSTS)，但是仍然只是將 VSTS 當作 Source Control 使用而已，不要說 PM 或 PO 沒有將 WBS 或是 Tasks 鍵入 VSTS 中的 Work Items 外，就算有鍵入 Work Items ，也沒有強制要求團隊成員 Check-In Policy (簽入原則)，將完成的程式碼簽入 VSTS 的時候，關聯相關的工作項目 Task (後面都簡稱為 Task)。
引發的問題、隱憂
筆者先前，有許多文章在探討團隊開發、個人工作管理與共同規範的關係與問題，這也是筆者先探討 問題、隱憂的原因，因為撇開團隊所使用的開發方法、合作模式 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 樣版設計 – (首部曲)」。
- 在專案 Kick of 後，PM/PO/SA 已經做完初步分析完成 WBS，或者畫出甘特圖也可以，重點在於已經做工作分解、與初步分析。
- 小組討論、個工作項目由那些成員負責 (工作項目花費時間可與團隊成員討論，或是由 PM 或 PO 先押一個時間也可，而後實際進行時，團隊成員在 Backlog 長出需要的實際 Task 並押上實際撰寫程式的工時)
- 由 PM 或 PO將 WBS 鍵入 VSTS 中，並指派給負責的團隊成員。
- 由 PM 或 PO 建立原始檔控制的 「Check-In Policy 簽入原則」，最少需有「工作項目」、「變更集註解原則」等。
- 團隊成員在 Backlog 長出實際的 Tasks 的時候，也需落實回填發生的工時。
- 簽入程式碼時，使用小組共通的語言撰寫註解 （註解不是只寫給你自己看，別人看不懂也沒有用）
另外，程式碼簽入的時候，千萬不要簽入一大包，然後才將所有有關連的工作項目都參考進來，如下：
簽入一大包，對於使用 VSTS 以及以後還要 Maintain 這個系統的你而言，這個變更集對以後的你而言完全沒有幫助 （還不如不要關連算了），因為這樣就跟沒有關連工作項目一樣，因為你三個月事後再來看這個變更集，你還是得要花許多時間來瞭解（又是個時間的浪費），哪幾行 Code 是跟哪一個工作項目有關，又要花時間看個半天，那麼跟原本的情況不也一樣？
這種情況，通常有兩種：
一、開發人員改完一個需求，總是忘記簽入，等到想到要簽入時，已經改了5-6 個 Tasks 了
二、團隊間、PM/PO 沒有要求，以致開發人員習慣不好，總是等到全部改完才簽入
有讀者會問我說，但是有時就是牽一髮才發現動全身，怎麼辦呢？可以分幾次簽入，也就是說，你可先簽入一個最小版本，不一定是可以交付的版本，只是能夠 Compile 就好，但是這邊指的是在同一個 需求 （Backlog/Task）內的狀況，不是跨 需求 （Backlog/Task）的情況，如果真的有改到一半發現改的兩個需求是同一個問題，那可能要檢討 這個「需求」 或「Bug」在「分析/瞭解問題」時，有失精準度。
在最後說明，同一個需求，是有可能修改異動到 20-50 支程式碼，這端看專案大小、架構設計、喔，對了，額外一提，如果你的專案每次很小的修改都要改很多支程式(8-9支、甚至10多支)，那有可能是在專案的軟體架構設計上有「過度設計」的現象，可能需要審視目前的架構設計 與 分工的方式是否恰當。
迷之音：
所以我才說，這些事情都是環環相扣阿！更何況，原始檔管控又是最基本的工作管理，基本的工作管理都做不好，後續的 Agile/Scrum.. 流程的導入那都不用談了。
後記
當然，光只有原始檔管控的基本功還不夠，但是必須先有這幾個項目，才能再來談如何落實「Code Review」、如何搭配如：StyleCop 設計屬於團隊的 Source Analyzer Rules ，甚至與 VSTS 的 Check-In Policy 整合，因為團隊若要落實 Core Review 甚至與團隊資深人員、新進人員人數的多寡、團隊編 制的方式、工作分工的方式 都有關係。
雖然，程式碼撰寫只是軟體開發生命週期裡的一小部分，但是程式碼又為專案實際的產出，如果沒有有效的管理規範來管理這些產出，甚至這些工作沒有落實，那越到後期，我想所需的維護成本相對呈現倍數提高。
簽名：
學習是一趟奇妙的旅程
這當中，有辛苦、有心酸、也有成果。有時也會有瓶頸。要能夠繼續勇往直前就必須保有一顆最熱誠的心。
軟體開發之路（FB 社團）：https://www.facebook.com/groups/361804473860062/
Gelis 程式設計訓練營（粉絲團）：https://www.facebook.com/gelis.dev.learning/
如果文章對您有用，幫我點一下讚，或是點一下『我要推薦』，這會讓我更有動力的為各位讀者撰寫下一篇文章。
非常謝謝各位的支持與愛護，小弟在此位各位說聲謝謝!!! ^_^
