孫子兵法：夫未戰而廟算勝者，得算多也；未戰而廟算不勝者，得算少也。多算勝，少算不勝，而況無算乎！
任何軟體開發專案的基礎都是「程式碼」。即使，專案經理不需要親身撰寫程式碼，但是必然要能夠透過程式碼，取得專案關鍵資訊，作為專案領導管理的最佳參考。(關於專案進度，請參見這篇。)
版本控制系統(git, cvs, p4, svn等等)，則是有效控制程式碼的基礎，開發過程大部分的事情會發生在這裡，也應該發生在這裡。
如果你的軟體開發專案，沒有使用版本控制系統！！？？...呃....請參考註1。
版本控制系統「至少」可以提供以下這些重要而且基本的訊息給專案管理者：
(1) 截至目前為止，有多少人實質參與專案
(2) 截至目前為止，專案的實質規模(程式碼檔案數量 行數等等)
(3) 一段時間內，此專案程式碼品質的推測
(4) 一段時間內，例如過去48小時，軟體團隊的實質產出
(5) 一段時間內，例如過去7天，有沒有人在非上班時間內工作
專案管理者(或者Scrum Master)應該自己取得這些訊息。為什麼？？
"Доверяй, но проверяй"
- 俄羅斯名言，意思是 Trust, but verify
冷戰期間美國總統雷根特別愛用此名言，根據wiki說明，雷根是受到一個作家的影響
因為，過去專案管理者常見兩種極端：
(1) 極端放任自由：在Scrum的精神下，雖然每天站立會議和燃燼圖，都可以揭露專案最確切的進展，完全相信成員的口頭回報
(2) 極端間接的繁複審閱：在沒有技術背景的情況下，透過頻繁而起瑣碎的會議，加上各式各樣文件追蹤，試圖了解目前進展。
這兩者都有明顯的問題，Trust, but verify才是正確做法。以Scrum的精神取得每日進展，並且，專案管理者應該「自己」想辦法檢查。專案管理者，如果沒辦法自己檢查，表示對此專案的本職學能不足。(註2)
專案管理者能夠做的程式碼基本分析有很多。好的專案管理者，至少需要能自己「動手」，利用工具或者程式，透過事實，了解下面三件事情：
(a) 基本專案狀態分析：哪些人寫了哪些程式碼
(b) 哪些程式碼檔案很重要：某些程式碼就是常有問題
(c) 哪些人需要額外關注：某些人工作壓力大常加班
以下以git為例，其他版本控制系統也能做到類似的事情。
基本專案狀態分析
靜態程式碼分析工具有很多。例如，gitinspector可以揭露整個專案的大致情況。gitinspector的安裝使用請參考這裡。
以github上的serverless.com為例，在github上clone這個專案，並且執行#gitinspector的結果如下：
首先會大致列出作者和過去的產出摘要，例如Aaron在這個專案一共commit了8次，包含170行程式碼跟刪除87行。這個表當然不能作為績效考核用途，但是可作為參與度的重要參考。很明顯的Austen鐵定比Chris的參與度高很多。
接下來隨即會列出還存在的程式碼行數。以Austen來說，他還有2713行的程式碼存在。和他的總新增行數與刪除行數有很大的差別。這很有可能是他參與了開發初期，而開發後期的版本沒參與。
哪些程式可能容易有問題？
程式設計師每天辛勤的工作，自然會知道哪些程式常出問題。而專案管理者必須要由技術面來獲取正確的資訊。版本控制系統會記錄每次程式修改的原因(如果commit的備註正確的話)。最簡單列出「要注意的哪些程式碼檔案」
git log指令，可以加上 --grep=<string> 來濾出字串，以下例子只用fix當作過濾條件，並且配合linux其他指令：sort, uniq 就做出簡單的報表：
~/serverless# git --no-pager log --name-only \
--grep=fix --pretty="%s" | sort | uniq -c | sort -n
19 lib/ServerlessState.js
19 tests/tests/actions/ResourcesDeploy.js
20 lib/ServerlessProject.js
23 lib/actions/EndpointDeploy.js
23 lib/actions/ProjectInit.js
23 lib/actions/RegionCreate.js
23 lib/SerializerFileSystem.js
24 lib/Serverless.js
25 lib/actions/ResourcesDeploy.js
25 lib/actions/StageCreate.js
25 tests/test_utils.js
27 package.json
27 README.md
28 lib/actions/FunctionRun.js
34 lib/actions/FunctionDeploy.js
38 lib/actions/FunctionCreate.js
55 lib/utils/index.js
101 tests/all.js
當然，以上報表只是列出有fix字串的commit中，哪些檔案出現次數最多。 tests/all.js 明顯是最多的，但也很明顯這檔案本來就是會被一直修改。此外，README.md也是一樣，大概也不是真正有問題。不過其餘的檔案倒是可以額外關注一下。
程式有問題的的判斷方式有很多，除了在commit的紀錄中說明是[fix]或[bug fix]之類。但也可以考慮總行數，刪除的行數，增加的行數，並且配合QA/bug tracking系統，才較為完整。
哪些人需要額外關注？
「人的問題」，永遠是最難解決的問題。然而，卻也是要優先解決的問題。組織中必然有需要「被關心」的人。
專案組織中，最要被關心的人是「表現好且有潛在壓力大」，以及「表現不好且對團隊有負面影響」這兩種。其中，表現好的人更是要優先處理。
除了每天例行工作接觸之外，專案管理者應該要有確切的「數字」。假設，我們想知道在此專案中，哪些人常常「晚上」工作。最簡單的方式是分兩步驟，先用git列出作者時間，然在寫個簡單的統計程式，列出所有人的「晚上」工作時間和「平常」工作時間次數。
* 步驟一：先取得所有的branch, 然後, 以下git log指令可以列出作者和時間，並且輸出到檔案author_time_log
# for BRANCH in $(git branch -a | grep remotes | grep -v HEAD | grep -v master); do git checkout --track "${BRANCH}"; done
# git --no-pager log --all --pretty="%an,%ai" > author_time_log
檔案內容大概如下
....
Austen Collins,2015-08-05 18:28:18 -0700
Austen Collins,2015-08-05 17:26:26 -0700
ryanp,2015-08-05 17:04:37 -0500
Derek van Vliet,2015-08-05 09:31:56 -0400
Michael Friis,2015-08-04 18:54:03 -0700
Austen Collins,2015-08-04 15:04:46 -0700
Colin Ramsay,2015-08-04 22:03:48 +0100
Chas Warner,2015-08-04 14:53:59 -0600
Austen Collins,2015-08-04 11:19:31 -0700
Austen Collins,2015-08-04 11:15:44 -0700
Austen Collins,2015-08-04 11:11:06 -0700
Austen Collins,2015-08-04 11:09:24 -0700
....
* 步驟二：撰寫簡單的分析程式，設定正常時間是早上7點到晚上8點，其餘都算不正常時間。用人名為單位加總之後，就可以產出簡單的報表。簡單的統計程式原始碼請參考這裡。
此表中，Eslam幾乎有一半的commit都是在晚上產生，而Kamil則是標準完全正常時間工作。
Joe Turgeon [1, 0]
Erik Erikson [15, 7]
Ian Serlin [1, 0]
David Hérault [1, 0]
Peyton Zhou [2, 0]
Kazato Sugimoto [2, 0]
Nick den Engelsman [1, 0]
Kiryl Yermakou [0, 1]
Austen Collins [575, 267]
Kamil Burzynski [101, 0]
Frank Schmid [9, 2]
Jacob Evans [13, 1]
Michael McManus [1, 0]
Eslam A. Hefnawy [158, 132]
Dave Newman [0, 1]
Ryan S. Brown [35, 6]
doapp-ryanp [129, 48]
Michael Friis [1, 0]
Matthew Chase Whittemore [2, 0]
當然這並不代表Eslam的表現好而且壓力大，這只是提供給管理者參考的事實。專案管理者，必須要事實層面，檢查軟體專案的狀況，因為很多時候「會吵的小孩有糖吃」，只單純被煩就會給糖的專案主管，其實對團隊是沒有價值的。
小心統計陷阱
統計數字都可能會有陷阱，程式碼的基本分析也是統計的一種，自然要小心陷阱的存在。專案管理者應該要善用統計數字，切勿被統計數字所左右。請參考統計與謠言。
註1：軟體開發專案不使用版本控制系統，會讓專案本身暴露在極端的風險中。如果你是專案管理者，讓專案暴露在風險中就是你的責任。如果你只是個開發人員，儘早離開高風險的環境才是上策。
註2：某種情況是，專案規模過於龐大，例如參與開發者超過100人，某些技術確實不見得能完全掌握，但專案管理者，仍然要保有部分自行檢查的能力。
