不再輕視軟件測試 用別樣眼光感悟軟件測試[3]

　　不再輕視軟件測試 用別樣眼光感悟軟件測試[3]   軟件測試

　　第二、需求的變化

　　從項目的角度來說，需求總是向著膨脹的方向在變化。就連去掉某些已經做好的東西，也是一種膨脹，因為它增加了工作量。開發人員交付的是用戶滿意程度，而不僅僅是實際的產品，用戶的實際需要會隨著程序的構建和使用而變化。要知道，一個活著的軟件必須面對變化，只有死掉的軟件才不會有需求變化(沒人用了)，我們應該盡早面對現實，而不是逃避，事先為它們做好思想準備。變化是好事不是什么壞事。同樣，現代敏捷方法論強調對需求變化的快速響應，如XP(極限編程)就采用快速增量迭代開發，來在短時間內開發出功能不斷增強的原型軟件提交給用戶使用的方法，來快速響應需求的變化。

　　第三、人員的變更

　　在我們有些管理者中，總是假設開發者都是可以隨便替換的，新員工馬上可以取代離去的老員工，多么愚蠢的假設。解雇員工或高的員工替換率最大的影響，是使軟件項目失去了連續性。這是在抱著這種假設的團隊文化中，大量員工會在項目進行到一半時離開，新來員工往往需要1到3個月的上道時間，在這段時間內，他們做不了什么，還經常需要其它老員工的幫助，從而浪費了其它老員工很多不必要時間，導致項目進展更加緩慢，最終造成項目的很大損失。

　　另外、還有一種現象在中國軟件事業中普遍存在，當正在進行一個項目時，另一個項目由于進度落后或最后期限等原因所致，高層管理者就會從你的團隊中抽掉一些人去到另一個項目中補墻。這種拆東墻補西墻的作法，往往導致的結果是兩個項目都會落后，因為它不僅十分錯誤作了團隊人員可以隨意替換的假設，而且還作了將開發人數與開發所需時間可以互換的錯誤假設。盲目的認為，投入大量人數后，新人馬上會投入新的工作，這樣項目開發所需時間就會成倍縮短。在這種組織文化中，是不會形成一支穩定的團隊的，成員整天只會忙碌著補自已的墻或為別人補墻，充當著類似消防員的角色，那兒有火那兒就有我們的身影。

　　同樣，現代敏捷方法論非常注重人的能力，如XP中通過權力下放、教練角色、將團隊緊密圍在一起并結對編程、小團隊組成等方式，來組成一個強有力的團隊，由于有凝聚力，所以很少有大的人員變動，他們往往可以完成兩倍于他們人數所能完成的任務。非常小的團隊能夠產生非常大的物質生產力，有時候，小團隊可以在很短時間內創造奇跡，而大型團隊極少能做到。但是，小團隊卻往往得不到足夠的政策支持，從而導致任由團隊超編，這是一種病態組織文化所致。作為管理者必須明確知道，擁有一支穩定的、有凝聚力的開發團隊是組織最大的財富，而不是障礙。

　　第四、規約崩潰

　　這種情況只有兩種結果：要么發生，要么不發生，不會有不同程度的影響。但它真的發生時，它會直接毀滅你的整個項目。在項目啟動之初，項目各方需要通過一系列商談來確定需求的范圍，規約崩潰就是指這個談判過程的崩潰。在商談期間，很多時候當遇到嚴重沖突時，由于雙方都不愿意讓步，但又不想放棄這個項目，從而導致這些沖突被掩蓋起來。最終項目便朝著一個帶著缺陷的、含混不清的目標前進了，被掩蓋的問題暫時不會打擾你，但不是永遠。盡管你可以含混說明一個產品，但不能含混構造一個產品，所以，最終在項目晚期這些問題將發生，在大半甚至所有預算時間和金錢都已付出的時候，此時，任何一方不再全力支持，都將使項目被取消。任何規格文檔中的含糊標志著不同的系統參與者之間存在著未解決的沖突。只要在開發過程中有多個參與者，就一定會有沖突存在。談判困難而調解容易，如果兩個人的利益是完全或部分相斥的，預先做好安排，準備好請雙方通過調解來解決沖突。同樣，現代敏捷方法論通過客戶的積極參與勝過合同談判的方試，來盡早發現和避免規約崩潰。

　　第五、低效率

　　對于項目成功而言，項目人員的素質、人員的組織和管理是比使用的工具或采用的技術方法更重要的因素。團隊質量是項目成功最大的決定因素，對人的關注、激勵和培養勝過一切。項目管理人員的職責不是要人們去工作，而是給人們創造工作的可能。創造力來自于個人，而不是組織架構和流程，項目管理者面臨的中心問題就是如何設計架構和流程，來提高而不是壓制人們的主動性和創造力。通過權力的向下委派，從而產生了改進的質量、提高的生產率、高漲的士氣，進而使中心的權威實際上得到了加強。就整體而言，組織機構會更加融洽和繁榮。增加加班時間只會降低生產力，壓力之下的人們無法更快地思考既也會降低生產力。使用壓力和加班的真正原因是為了在項目失敗時讓人們看上去能好受一些。

　　正式的過程改進程序需要花錢、花時間，特定的過程改進工作還會延緩項目進度，盡管最終會體現生產力上的收獲，它們也不可能抵消花在過程改進上的時間。多種技術的改進程序(如CMM提級)很可能讓項目比不實施這些程序完成得更晚，對于人員超編的項目，標準過程會為多余的人們制造出足夠的工作，讓所有人都忙個不停，盡管很多是無用的，這也導致生產率低下。人員超編的團隊往往生產率低下，因為它們團隊內部耦合度提高，會議時間、重復勞動和無效工作都會增加。理想的人員安排是在項目的大部分時間里由小型核心團隊來做設計工作，在開發的最后階段再逐漸加入大量人手。如果不大幅度減少調試的時間，就沒辦法讓項目大幅度提前完成，而要成比例減少調試時間，就需要成比例增加設計所需時間，因為絕大多數的錯誤源于接口缺陷，編碼前進行的正規而完善的設計，可以大幅度減少錯誤。同樣，現代敏捷方法論通過注重人、快速迭代開發、自組織的團隊和提倡可持續的開發速度，來避免跑的過快導致團隊精力耗盡、出現短期行為而導致崩潰的問題，從而保持了穩定的生產率。

　　精兵簡政是失敗公司使用的辦法，它讓員工負擔失敗的責任。成功公司的目標應該正好相反：興旺、發達、而人性化。

　　企業的最大風險則與價值相關：在低價值的項目上浪費資源，付出高價值的機會成本，就這是企業最大風險。勇于承擔風險是好事，但必須由收益來導航，愿意承擔多少風險，必須取決于能獲得多少收益。真正的項目評估不是傾向于不斷削減成本，來提高價值，而是在風險與價值之間取得平衡點。通過不確定的價值和不確定風險組合效果的凈收益圖，來指導你把資本投入到最適當的地方。我們每個軟件從業人員都必須明白：顧客真正需要的，是我們能夠給他的、某種他想得到的利益。

原文轉自：http://www.anti-gravitydesign.com