標籤：
這篇文章寫的比較雜亂，思路不是很清晰。這本書的內容大多數講怎麼計算程式員的表現，和體育比賽的運動員記錄相比較。個人感覺這個書如果給專案經理讀或者人事讀會有更多的感想。我僅僅是大概領略下裡面的方法，並且把自己認為比較有用的知識摘錄出來。
一簡單的成功團隊模式
模式1有一個無怨無悔的做瑣事的人
模式2一到兩個牛人提高了整個團隊的水平，雖然牛人並沒有相應的頭銜
模式3常在創業小團隊出現，項目在80%的時候撞牆。能生存下來的團隊裡面總有個人能夠鼓舞士氣。
二
作者的一個團隊，軟體從版本1到本部1.1用了6個月。並且沒有加入任何新的功能。從1.1到2.0隻用了9個月，期間還有很多功能增強。團隊的主要變化是原來團隊離開了兩個特別依賴別人的程式員，新加入的程式員可以自己工作，自己找出軟體的bug所在。所以作者認為一個團隊要有各種能力的人，才能成功。
三
評價資料統計的離群點和異常點，都表現為不在正常的範圍內，如工作量迅速下降。也可能是不可解釋的點,如某人學曆背景不好，但是工作效率奇高。
異常點可能是偶然事件導致如身體不適。可以忽視。
離群點則可能表面上市異類，是打破常規的人。忽視離群點會限制我們對成功模型的理解，如黑天鵝效應。
四
峰值和穀值代表著周期
五在學則統計項目的時候要意識到
1統計的項目有局限性，很多有用的項目沒有被統計。
2統計的值與預期不一樣。比如作者發現這樣一個現象。團隊裡的人經常被售後，支援人員的人打擾項目品質反而提高，這與普通認為的程式員不該被打擾相反。
六統計項目選擇的標準
1資料容易獲得
2容易讓非程式員理解。這樣便於管理，人力等交流
七如何評價程式員。這裡我們可以看做是如何培養自己的能力
1核心職責表現
2代碼測試品質
3能覆蓋多少領域
4主動解決自己的問題。主動指出他人的問題
5創新
6處理壓力
7逆境
8與他人互動
9領導力，支援隊友，指導他人的能力
10對項目的理解和接受團隊角色的能力
八團隊的評價標準
1使用者對新版本的反應。如新版本的採用率
2與競爭者軟體比較如何
3品質
4新版本交付率
九作者在講團隊的時候舉了一個例子。
兩個團隊，一個團隊組建的時候成員背景都很好，並且互相認識。二另一個團隊的背景不是十分優秀，人也是臨時組建的。但是後一個團隊取得了成功，前一個團隊失敗了。作者有幾點收穫
1成功的團隊複雜任務集中在少量人手裡。其他程式員承擔數量多但是不難的工作。失敗的團隊差不多每個人工作負載類似，平均複雜度高。
2成功團隊每個人工作在多個領域。失敗團隊每個人工作在很小的領域
3成功團隊的人創新，也主動。
《程式員的度量，改善軟體團隊的分析學》讀書筆記
