顯示具有 統計 標籤的文章。 顯示所有文章
顯示具有 統計 標籤的文章。 顯示所有文章

11/16/2017

軟體專案管理 - 版本控制系統內的程式碼基本分析


孫子兵法:夫未戰而廟算勝者,得算多也;未戰而廟算不勝者,得算少也。多算勝,少算不勝,而況無算乎!

任何軟體開發專案的基礎都是「程式碼」。即使,專案經理不需要親身撰寫程式碼,但是必然要能夠透過程式碼,取得專案關鍵資訊,作為專案領導管理的最佳參考。(關於專案進度,請參見這篇。)

版本控制系統(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人,某些技術確實不見得能完全掌握,但專案管理者,仍然要保有部分自行檢查的能力。




4/20/2017

數據分析 - 獵人頭如何從Github尋找人才?


前陣子遇到某特殊的獵人頭hunter公司(參考:這裡),竟然是透過分析統計在github, gitbucket的程式庫,來找到軟體人才。

目前,github使用者數量仍屬商業機密,但估計約在2千萬左右(參考:這裡)。當然,使用者大部分從事軟體相關的行業。

資訊科技,特別是軟體的實際成果,容易在網路上展示。因此,如果要找到「軟體開發人才」,github是一個很好切入的地方。一般獵人頭可能會人工搜尋,但身為工程師,當然是寫程式找到大量資料。

從github找人,這做法有一些顯而意見的好處:

1. 有可能看到此人實際上寫的程式碼
2. 有可能了解最近此人的工作範圍
3. 很快找到此人的聯絡方式(email)部落格或其他技術相關資訊
4. 有可能找到此人合作對象
5. 有可能看出此人的英文語言能力

當然也有些顯而易見的缺點:

1. 當然找不到那些不在把專案程式擺道github的人
2. 此人可能只是擺放玩樂性質的程式
3. 只能有機會看得出技術能力,非技術能力仍然需要其他佐證
4. 資料範圍過大,很難逐一肉眼看完

雖然我不是獵人頭,但基於工程師的精神,就嘗試一下解決「資料範圍過大,很難逐一肉眼看完」的問題。看是否能透過程式取得並處理gitbub資料,找到潛在挖角對象清單。

實際上做的步驟如下:

1. 了解gitbub資料如何取得:


github提供api可供程式使用。和許多Web Service一樣,也有完整的文件,請參考這裡


2. 以程式取得少量測試資料

github的web api測試起來很簡單。舉例來說,如果你已經登入github,用以下這個URL request就可以找到,以javascript與nodejs為關鍵字的所有程式庫:

https://api.github.com/search/repositories?q=topic:javascript+topic:nodejs

當然,他的回應是json格式,需要簡單地用程式轉換。例如下圖,乃是搜尋和javascript相關,並且其位置在台灣的使用者:



測試資料回傳乃是json,調整格式成為csv,以便於日後在excel做簡單分析。


3. 了解測試資料內容


如果已經有在使用github,那麼對於回傳的資料應該很清楚其內容意義。

如果不太了解github,就需要找對軟體版本控制系統有些認識的人幫助瞭解其含意。

這上述的範例:「搜尋和javascript相關,並且其位置在台灣的使用者」來說,程式會刻意收集following(有多少人在跟隨這個人的更新),follower(這個人跟隨了多少其他人)。此外,程式會額外計算push和javascript相關的程式庫的次數,取名為work,表示和javascript的相關工作在過去一段時間的次數。


4. 撰寫簡單統計程式,大量取得資料


當然,這個程式就放在github上。請參考這裡

程式本身是python撰寫,需要有github帳號密碼才能使用。


5. 結果


以上述範例:「搜尋和javascript相關,並且其位置在台灣的使用者」大量取得資料並且「過濾可取得公開email」的人數一共是661筆。並且取最前面的199筆,給熟識的headhunter (獵人頭) 鑑定看看是否有效果。

目前的回應都是此資料非常有用。

1/11/2017

企業巫醫 - 統計與謠言



In god we trust all others bring data 

  -  W. Edwards Deming (全面品質管理TQM之父)


網路讓資訊傳播成本降到極端的低,同時也讓資訊品質降的極端的低。

謠言的成因有非常多。有些僅只是美麗的誤會,例如:十幾年前開始流傳的泰戈爾的詩。有些則是恐嚇類型的無風起浪,例如:誠品可怕迷魂盜泰國罐頭。有些只是試圖吸引人目光的搞笑惡作劇,例如:裝翅膀飛起來

最糟糕的類型,莫過於以「統計數字」造出看似符合邏輯的謠言。並且,從這樣的謠言中獲得利益。


許多時候,數據本身難以查詢正確性。而且由數字導引出的邏輯,更容易因人而異,因地制宜。從數字所引導的偏誤,有時候甚至比單純的謠言還可怕,因為它可能會在網路上留存多年,難以辯證。如果只是單純搞笑也就罷了,如果個人或者組織,以這類型的資料來作為決策的判斷依據,那下場可能非常慘。錯誤的資料,比沒有資料更糟。


不過,只要稍微留意,加上合理的好奇心,統計謠言是有機會判斷其可能性:


(1) 不解釋的數字


在各類文章或研究報告中,為求精簡,只會根據重要數字做衍生推論。然而,數字背後通常還有「未解釋」的數字,而這個數字可能更為重要。

企業僅21%的需要大學以上學歷為例。這篇文章,簡單說明勞動部的調查,僅有21%的企業需要大學以上的學歷。然而,這個數字有很大的問題。

也許,該調查隨機抽了100個企業主,其中只有21個企業主宣稱需要大學以上學歷的員工。

也許,該調查抽樣了企業主的「100個正在招募工作職缺總數」,這100個職缺中,只有21個是需要大學學歷。

這兩者有極大的差距。前者,可能這21個企業主,所需要員工數量高達2萬人,而另外79個企業主,所需員工只要79個人也說不定。而後者,正在招募的職缺,和「已經在職」的學歷也並未顯示。而單就此推論,僅21%企業需要大學學歷基本上過於簡化。

所有經過簡化,而沒有附上數據的真實來源的推測,其解釋很容易被扭曲。然而,被扭曲的解釋,當然比較有戲劇性,比較容易被注意。

勞動部網站根本也找不到這份調查。

此外,很多政治性民調也是屬於此類,涵蓋許多不解釋的數字。



(2) 接近完美的不可能


網路上流傳一份超過十幾年的Dr Ephrem Cheng研究顯示,越早退休壽命越長。(參考這裡這裡這裡)  

這份數據流傳非常之廣,被引用次數非常多,每隔數年也會在通訊軟體上流來流去。最近當然就是LINE上流傳的長輩文。

上面提供了一份數字,是退休年齡跟「壽命」的對照表如下。


retirelife
49.986
51.285.3
52.584.6
53.883.9
55.183.2
56.482.5
57.281.4
58.380
59.278.5
60.176.8
6174.5
62.171.8
63.169.3
64.167.9
65.266.8

不會統計的人也可以看出,在這個表中,越早退休,壽命越長。如果49.9歲就退休,那麼可以活到86歲。65.2歲才退休,就只能活到66.8歲。

以相關係數簡單計算,他的相關程度高達-0.96,換言之,這是一份極為完美的負相關數字。

這種過度完美個數字,應該要看研究論文的細節加以瞭解。例如他的樣本有多大?是什麼時候做的研究。就可取得的事實來看,他的樣本很小,並且研究的時間幾乎可以肯定在1990年以前。由於上述的年紀追蹤到80歲,所以研究對象大概是1930-1950嬰兒潮時代的人。

最重要的是,這些數字並非真實研究論文,卻在很多人的轉貼中,莫名其妙的被冠名「美國權威學者」。


這份研究數字會流傳很久的原因,是他剛好契合 (1) 這看起來是個學術研究 (2) 可以被直銷,財務規劃,人生規劃等等產業拿來利用 (3) 可以有趣的解釋它

除此之外,別無他因。雖然已經有些人發現不對勁,例如這裡。但是許多第一次看到此研究的人,仍然不明究理的轉貼。

如果想知道實際的退休年齡和生存年齡的相關性研究:請參考這篇研究。該篇的結論就交由各位判斷,但至少它的研究方式,數字細節,都解釋得十分清晰。

我已經透過管道寫信給該研究者Dr Cheng,懇請取得確實的研究資料以及統計方式等細節(說不定他也是受害者?)。至今2017/Jan/11尚未收到回覆。


(3) 邏輯上的不可能


邏輯上不可能,或者簡單的說「數字兜不攏」。

中國的2010的地方GDP就是邏輯上的懷疑問題。因為 中國31個省份的GDP加總起來,竟然遠超過全國GDP,而且高過很多。這在邏輯上是不可能的事情,因此自然就有合理的統計造假懷疑。

類似的事情也容易發生在沒檢查,而且其實也不打算認真做統計的相關文章上,例如這裡。因為在許多時候,謠言只是想要造成吸引人的目的,其真實性不重要,當然就也不特別檢查數據。所以自己造成自己數據兜不攏,邏輯上不可能的情況並不少見。

這和前兩者不同,邏輯上的不可能,可以單就資訊本身的內容加以探索,或者是再加上一些事實根據來檢視。因此,比較容易看出謠言的真實性。




最後,稍微提醒一下:廣告的統計宣稱,其實難以查證。例如高露潔的「大部分牙醫師推薦」如果不是公平會主動進行查證,一般市井小民根本無法查證屬實與否。