不再輕視軟件測試 用別樣眼光感悟軟件測試[2] 軟件測試
管理是一種控制性游戲，在游戲面前，你只有二種選擇：或者，你確信自己能蠃，于是投入足夠多的能量來蠃得一切;或者，你不進行這個游戲，放棄它。然而，作為軟件項目管理者，你也應該知道，早投入、高風險才會有高回報。逃避風險是致命的，因為這也會讓你得不到與風險同在的利益，久而久之，你就會面臨著被市場淘汰的危險。風險是"遭受損失的可能性"，由條件、結果以及周圍的環境構成。風險和問題的區別在于：風險是尚未發生的問題，而問題是業也成真的風險，昨天的風險可能會是今天的問題。風險管理主要包括下面幾個方面：
第一、風險識別：
從頭腦想像中抽取出各種風險并加以篩選，再加上在整個開發過程中，保持持續不斷的風險發現機制，以發現新的風險。
第二、風險分析：
對風險出現的可能性和潛在的危害性進行量化分析。
第三、應急計劃：
如果識別出的風險真的出現，你將采取的應急措施。
第四、風險緩解：
為了使應急計劃得以有效實施，必須在風險轉化為真之前所采取的措施。
第五、持續的監控：
跟蹤需要管理的風險，尋找風險出現的跡象。
項目面臨的某些風險可能是致命的，發生時會使項目嚴重滯后或直接廢棄。這類風險是最需要管理的，但有效的管理它們也許會使你與你的上級發生沖突(如時間上最后期限等)，對于這類風險往往超出了你的管理權限，可以先將它們列為項目假定風險，然后把它們轉交給上級來管理。風險可能出自技術、政治、經濟、資源或其它各個方面，幾乎無所不在，并且會對項目開發、市場占有率或是達到項目目標(如進度、預算、質量等)造成災難性后果。但在所有軟件項目中，通常會共存五大核心風險，分別如下：
第一、缺乏合理的進度安排
這是導致項目滯后的最主要的原因。首先、它源于開發人員們普遍存在的樂觀主義精神，我們總是期待在實現過程中不會碰到困難，然而我們的構思是有缺陷的，因此總會發現BUG。
1.它源于一種錯誤的認識。人員數量和開發時間是可以互換的，既投入兩倍的人數會在一半時間內完成開發工作。然而，這種理論卻忽略了隨著人數的增加，相應的也會增加新人培訓和人們相互交流所需的負擔,另外，還有任務重新分配所造成工作中斷帶來的負擔，正如Alistair Cockburn所說："最有效的交流方式是面對面的交流"當3、5個人的時候很容易做到這種交流方式，隨著人數的增長，再也很難做到這種交流方式。交流成本的增加與培訓新人所需時間成本的增加、以及任務重分配導致工作中斷成本的增加，直接導致一種結果：向進度落后的項目中增加人手，只會使進度更加落后。
2.源于空泛的估算。管理人員特別是高層管理人員為了滿足顧客期望的日期而造成的不合理進度安排。如果分配的時間一開始就不夠，不管高層領導威脅有多么嚇人，工作也無法按時完成，如果人們察覺到管理者可能濫用權力來懲罰自己，他們就會感覺到威脅，沒有安全感。安全感的缺乏會讓人們反對變化，而在所有成功項目中，變化是唯一不變的要素之一，除非感到安全，否則人們就不會去迎接變化，只會按部就班，這樣往往喪失了很多走捷徑的好機會，而這些機會原可以大大縮減時間進度的。第四、如果你沒有認真估算產品規模，那么你預計的進度就是空中樓閣，唯一的依據只是你的希望。在估計產品規模時，除了正常的時間計算以外，不但應該將"可能需要做"的事情所需工作時間加上，還要將某些"可能不需要做"的事情所需工作時間加上。項目的超期不應歸咎于開發者的低效率。
3.項目的滯后不是一下子造成的，而是在一天天的不知不覺中造成的，有無數種方法可以浪費一天的時間，但是沒有任何方法可以拿回一天的時間。高層管理者的不良反應肯定會對信息的完全公開造成壓制;相反，仔細區分狀態報告、毫無驚慌地接收報告、決不壓制下級，將能鼓勵誠實的進度匯報，而這會使你在第一時間掌握實際進度，把握先機，及早做出正確的修訂，從而避免了晚期才獲得這些實際信息時，那種無力挽天時的無奈。此外、也可以在項目管理中設定一個合理的進度安排和一個具有挑戰性的期望目標完成時間。期望目標和合理進度不同，期望目標完成時間，可以設為項目完成的成功率在30%左右時的日期，這樣很具有挑戰性，但不能強迫要求必須完成此期望目標。畢竟，合理進度安排才是更合理的時間安排。另外、需要指出的是現代敏捷方法論對此進行了有效改進，如XP(極限編程)中，就利用用戶素材與CRC卡，進行優先級劃分并進行快速增量迭代開發，針對原來開發的產品或第一次迭代開發后的原型完成的功能量，來計算功能點，從而估算每個CRC卡的功能點，得到總功能點來推導出比較準確的進度安排。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
