2013.6.12
聯調有3個目的：
1、將項目組的代碼整合起來，這點在好的專案管理中編碼階段已經完成了大部分的整合工作。2、保證系統的品質，避免後期的大改動，之後轉整合階段3、進行品質評定以調整測試策略
按專案管理的五要素分解如下：
1、干係人期望-目標 編碼階段干係人的影響已經很小，先不討論。
2、沙盤-思路
1） 程式碼涵蓋範圍 只有被跑過的代碼才是安全的，之前的任何假設只有通過驗證才能得到結果。程式碼涵蓋範圍是保證品質的一個基本指標，通常這個指標在85%左右。而更加嚴厲的指標是代碼的分支覆蓋率。當我們發現程式碼涵蓋範圍不夠時，可以使用調試逐步執行，新的單元測試案例，新的測試案例來增加覆蓋率。
2） 執行BVT BVT是指系統、模組的準系統案例，在聯調階段執行通過這些案例的意義在於：控制整合測試階段的改動並防止測試阻塞。正常情況下，轉測試後，每次bug的修複改動代碼應在100行以內，改動太大會導致迴歸測試成本增大。
3） 效能測試達標 如果一個系統的效能指標不達標，那麼及有可能會導致整合測試階段的代碼/方案改動不可控，因此效能測試達標應是系統進入整合測試的一道關卡。
4）冒煙自動化測試 聯調階段正是合適的時機準備和啟動冒煙自動化測試，冒煙自動化的案例至少包含系統主要的BVT案例，當冒煙環境搭建成功後，每次重新打包後，這些自動化案例將自動執行。這樣能夠保證每次新包的基本品質，且能很快發現問題，而問題引入通常是當前包的改動導致，所以也縮小了代碼的排查範圍。
3、計劃制定
1） 聯調計劃 根據編碼階段的情況，我們有可能需要適時調整聯調計劃，例如：模組案例執行的先後，個別模組要晚點整合到系統裡等。
4、風險管理
1） 核心/基礎模組阻塞 聯調時當出現核心或基礎模組完成進度延期，會導致其他很多關聯模組無法繼續調整，這時要立刻安排介面樁（介面可返回固定值），以便其他受阻塞的模組能夠按計劃聯調。 2） 倉促轉測試 項目當前的品質和進度是需要平衡的，專案經理對此要做到心中有數。這時候項目有兩個因素需要考慮： a、已經準備好的測試案例要執行一遍，如果風險可控，可以在這個過程中控制品質 b、bug的修複成本越到後期，修複越高。如果有大的品質問題導致返工，那麼迴歸測試的工作量更大 新的版本經理往往迫於進度壓力，會選擇忽略當前品質風險，進入測試階段，如此項目組將在測試階段將承擔很大的風險壓力。而過于謹慎的專案經理計劃在聯調階段消除所有的品質風險，這樣會導致後期的案例執行壓力很大。此時合適的做法是分析出高風險的地方，進行品質加強，例如：做專項審核，走讀，加大測試力度等，將風險控制在可控範圍則進入測試階段。 3） 識別出風險模組 雖然管理上我們盡量消除所有風險， 但當精力受到制約時，我們也只能關注高風險區。世界不是完美的，項目中我們總是有機會遇到風險模組，在聯調階段要將他們識別出來，並制定改進方法，並輔以測試策略進行改善和控制。
5、團隊管理
1） 項目組階段總結 聯調階段是項目組的一個重要裡程碑，意味著項目組已經完成初品，此時項目的品質、進度情況已經比較明朗。同時這個階段也是一個轉折點，聯調之前的工作計劃以開發計劃為主，測試輔以缺陷預防，之後的工作將以測試計劃為主，開發要進行積極配合。此時總結應分為兩部分： a、項目組總結 這部分通常由專案經理講述，包括但不限於：項目整體的進度、品質情況、之前階段的沙盤落實情況、下一步的計劃與工作思路。 b、個人總結 個人總結的目的在於：總結之前的經驗，聽取其他人的經驗教訓，整理出下一階段的具體工作思路。好的經驗總結的內容應該包括但不限於以下點： 1、總結需求階段，設計階段，編碼階段，好的經驗，壞的教訓。 2、羅列出當前自己工作的風險，並給出措施，包括測試建議 3、整理出自己可以提高的地方 4、給項目組提出改進意見
雖然願望是好的，但是程式員很多時候不擅長總結此類經驗，或是有總結習慣的不擅長表達出來，這裡是執行的難題，後續會有章節專門分享如何讓此措施更有效果
。
2） 裡程碑慶祝點 如上第一點所說聯調是個非常重要的裡程碑，那麼裡程碑時進行慶祝及頒獎就是很必要的了。一個不會慶祝的團隊是不會有戰鬥力的，這是激勵的作用。在此時落實之前的對團隊的各種獎項約定就是非常合適的，同時在頒獎之後可以設定後續階段的獎項。至於團隊慶祝方法可以選擇喝酒，吃飯等，依照公司及部門文化而定。
關於團隊的獎項，很多時候專案經理苦於經費有限，無法開展此活動，因此放過了大好的團隊建設機會。後面的章節計劃分享下”如何以手頭的有限資源極大化的激勵組員“這個話題。
