壓力管理告訴我們什么？就是一個人如果一直在一種輕松和不緊張的情況下工作，就很難持續(xù)的進行學習和創(chuàng)新，當遇到緊急情況和問題的時候也就很難在緊張起來，我們的經驗和技能水平不但會停滯不前，有可能還會不斷的下降。從這個層面來講，壓力管理就是要使我們有一種危機意思。

　　當工作了一段時間后，我們每個人都會進入到一種狀態(tài)，就是因循守舊，不愿意在接受新的事物和挑戰(zhàn)。我們喜歡接受我們已經能夠熟練完成的工作，我們認為我們的經驗已經足夠應付相應的任務。但是IT技術日新月異，如果我們不能夠迎接挑戰(zhàn)，主動承擔困難和責任，我們很難再上升到一個新高度。

　　我們有評審和測試這些過程，并不是代表允許錯誤和不負責任，評審的目的不是用來幫你發(fā)現低級錯誤和不認真。由于我們每個人愿意花在評審上的時間是一定的，如果評審的輸入物質量低，我們就去發(fā)現這些大毛病和低級錯誤；相反，如果評審輸入物質量高，我們追求的就是深入的錯誤，這樣出來的產出物自然是精雕細鑿。

　　當一個軟件項目團隊，各個崗位和角色的人員已經到位和比例固定的時候，我們采用的軟件生命周期模型一定考慮的是如何讓每個成員都能夠在每個階段都能夠較飽滿的工作。成員的投入往往很難達到分階段來投入，因此我們會更多考慮迭代模型和敏捷方法。項目里面的事情就那么多，始終都是需要做完的，不受到強制前置依賴的事情要盡量提前做；如果沒有就要考慮把任務粒度細分，去創(chuàng)造任務能夠提前并行開始的機會。我們并不是去破壞瀑布模型，每次迭代都是瀑布。

　　對于軟件項目中，開發(fā)周期和測試周期要保持一種平衡，平衡的目標就是要保證盡可能少的返工和最短的交付時間。我們有時候對于進度壓力造成的壓力過多的壓縮開發(fā)時間顯然是不合理的，造成的后果就是往往再加上兩倍的測試周期，最終的版本仍然遲遲不能交付客戶使用。我們的時間都花在了過多的返工，開發(fā)和測試的溝通中。

　　編碼人員如何檢驗和測試自己開發(fā)的功能模塊是否已經完成？如果沒有詳細設計文檔，我們的要求就是首先編碼過程是否符合編碼規(guī)范和界面規(guī)范，其次就是整個編碼是否完全實現了需求文檔中的各種業(yè)務流和業(yè)務規(guī)則，包括各種完整性和邊界的校驗。

　　4-5個開發(fā)人員可能配置一個系統分析員和一名測試人員，組建一個小型團隊。

　　對于軟件項目團隊，我們必須要考慮團隊的整個績效，而整個績效的核算正是通過我們團隊整體的人力資源和其它成本的投入創(chuàng)造了多少價值。而對于返工量，編碼生產率，缺陷密度等都必須要圍繞這個整體績效服務。簡單講，如果我們返工量少，過程做的很仔細和規(guī)范，當進度延誤了2個月，在這種情況下我們是無法滿足客戶需求的。軟件滿足客戶需求，創(chuàng)造了價值，就是績效的衡量。

　　如果你不做項目計劃，就始終無法知道你預測的準確度，也就無從談得上跟蹤和持續(xù)改進。