鼓勵良好的編碼實踐
由於代碼是構建活動最主要的產出，因此，管理構建中的一個關鍵問題就是“如何鼓勵良好的編碼實踐？”一般而言，從管理的角度出發，強制採用一套嚴格的技術標準並不是個好主意。程序員傾向於將管理者視爲技術進化的低級層次。如果項目中要制定標準，那麼應該有一位收人尊敬的架構師來做，而不應該由管理者來做。在軟件項目中，“專家層”騎得作於至少與“管理層”相同。即應該找非常瞭解編碼活動的人來製作標準，而不是什麼也不懂的人來制定。
鼓勵良好的編碼實踐技術
1、給項目的每一部分分派兩個人：如果每行代碼都是由兩個人共同完成，那麼可以保證至少有兩個人認爲這段代碼是能工作的，而且是可讀的。
2、逐行復查代碼：代碼複查通常包括程序員本人和至少兩名評審員。
3、要求代碼簽名：這樣一方面可以提醒在程序員在編寫程序過程中應確保程序的正確性，簽字之後就認定程序能夠爭產工作。
4、安排一些好的代碼示例供人蔘考
5、強調代碼是共有財產
6、獎勵好代碼：所給予的獎勵應該是程序員想要的；只有非常出色的代碼才應該得到獎勵。
7、一份簡單的標準：必須能夠閱讀並理解這個項目裏的所有代碼這一簡單的規範。
配置管理
什麼是配置管理
配置管理是“系統化地定義項目工作和處理變化，以使項目一直保持其完整性”的實踐活動。也即“變更控制”。其中的技術包括評估所提交的更改、追蹤更改、保留系統在不同時間點的各歷史版本。
1.如果不對需求變更加以控制，那麼就會爲系統中某些最終會被取出的補教案編寫代碼，也會去寫出一些坑能與系統中新的部件不兼容的代碼。可能直到集成時才發現不兼容的問題，這會導致手忙腳亂的局面，沒人能知道將會發生什麼。
2.如果不對代碼變更加以控制，這有可能會修改某個人也正在修改的子程序；想把兩個人的改動成功地合併到一起將成爲問題。
3.如果沒有系統地對變更加以控制，就相當於在迷霧中隨意遊走，而不是直接向着一個清晰的目標邁進。
需求變更和設計變更
在開發過程中，一定會有很多關於如何改善系統的想法。如果每產生一個想法就實施相應的變更，就會發現自己走上了軟件開發的永不完結的工作。
一些相應的建議：
1、遵循某種系統化的變更控制手續。
2、成組地處理變更請求：記下所有的想法和建議，不管它實現起來有多容易，把它們記錄下來，知道有時間去處理他們。到那時，把它當做整體看待，從中選中最有益的一些變更來加以實施。
3、評估每項變更的成本：每當客戶、老闆或者自己想要修改系統的時候，請評估做這些修改所需要花費的時間，包括對修改的代碼做複查以及重新測試整個系統的時間。
4、提防大量的變更請求：儘管變更在一定程度上是不可避免的，變更請求的數量太大任然是一個很關機俺的警報信號，它表明需求、架構或者上層設計做得不夠好，從而無法有效地支持構建活動。
5、成立變更控制委員會或者類似機構：作用->設定需求變更的優先級，以及控制需求變更
6、警惕官僚主義，但也不要因爲害怕官僚主義而排斥有效的變更控制：缺乏規範的變更控制是當今軟件行業主要管理難題之一。有相當大的一部分進度落後的項目本來是可以按時完成的，如果他們原來就考慮了那些“未做跟蹤但卻同意執行的變更”的話。變更控制的實質就是確定什麼最重要，所以不要害怕因爲官僚主義就不去享受變更控制的諸多益處。
軟件代碼變更
配置管理另一項內容是源代碼控制。如果在修改後產生一個新的錯誤，並且看上去與所做的更改無關，那麼在尋找問題的根源的時候，很可能希望拿代碼的新版本與老版本做對比。如果是用了辦本控制工具，那麼這種辦本回溯的操作就會是小菜一碟。
機器配置：創建公司統一的開發測試環境。
備份計劃：定期備份自己的工作，做完一個項目，要對該項目進行歸檔。把所有的東西都保存下來：源代碼，編譯器、工具、需求、設計、文檔——重新創建該產品所需的一切事物。要把它們放到一個安全的地方。
評估構建進度表
1、建立目標：爲什麼需要評估？評估些什麼？只評估構建活動還是評估所有的開發活動？只評估項目需要的工作量，還是把休假、節假日、培訓和其他非項目的活動也算進去？
2、爲評估留出時間，並且做出計劃：應該仔仔細細的進行評估工作
3、清楚地說明軟件需求，要做的事情還沒有確定下來的時候，無論是誰想讓這些事情所需要的工作量做出評估的都是不切實際的。在評估之前要先定義需求，或者計劃出一個預估過程。
4、在底層細節層面進行評估：一般而言，考察的越細，評估就會越準確。如果分成50個小塊再估計，某些塊的估計會偏高，某些塊的估計會偏低，而這些誤差趨向於相互抵消。
5、使用若干不同的評估方法，並且比較其結果
6、定期做重新評估：軟件項目的一些因素會在最初評估後有所變化，因此要計劃好定期進行重新評估。
評估與控制
爲了按時完成軟件項目而做的“計劃”中，評估是很重要的組成部分。一旦確定了交付日期和產品規格書，剩下的主要問題就是如何控制人員和技術資源的開銷，以便能按時交付產品。從這個角度上說，最初評估的準確度的重要性遠遠比不上“隨後爲了完成進度而成功地控制資源”的重要性。
如果落後了該怎麼辦
如果落後的時候，增加時間通常並不可行。如果可行的話，那麼就做。否則可以採取以下的一種或幾種解決方案：
1、希望自己能趕上：當項目落後於進度安排時，人們通常的反應是對此抱有樂觀態度，但實際上，越接近項目後期，延誤和超值的現象就越嚴重，項目不能在後期把時間補回來；而是越來越落後。
2、擴充團隊：往一個已經落後的軟件項目里加入人手只會使得它更加落後。這無異於火上澆油：因爲新手需要先花費時間熟悉項目，然後才能發揮出生產效率。培訓他們就要佔用已受訓人員的時間。而且，僅僅增加人員數量，會導致項目交流的複雜度和數量也增加。一個婦女可以懷胎10月產下一子，並不意味着10位婦女能只用一個月時間生下一個孩子。當然這種拖延效應的前提條件是，項目中的任務不可分割、不能個個擊破，那麼增加人手是無濟於事的。但如果項目中的任務可以分割，那麼就可以吧它進一步細分，然後分配給不同的人來做，甚至可以分配給項目後期才加入進來的人。
3、縮減項目範圍：縮減項目範圍這一強大的技術通常會爲人們所忽視。如果去掉了一項特性，就除去了響應的設計、編碼、調試、測試盒編寫文檔工作。這樣也就刪除了該特性和其他特性之間的接口。
把程序猿當人看
程序員怎麼花費時間
研究發現，一個程序員大約有30%的時間花費在“對項目沒有直接好處”的非技術活動上：步行、個人事務等。
性能差異與質量差異
不同程序猿在天分和努力程度方面的差異十分巨大，在編寫程序的質量、編寫的程序的大小以及程序員生產率等方面，都有着一個數量級別的差異。其體現的差異可以分爲個體差異和團隊差異。
環境的影響
好的編碼工作環境可以提高程序員一定的效率
