迭代開發需要一種不同的觀點[5]
發布: 2007-5-14 20:14 | 作者: Per Kroll | 來源: Rational Unified Process, IBM | 查看: 38次 | 進入軟件測試論壇討論
分析人員和最終用戶的交流應該貫穿于整個項目的生命周期中
傳統開發模式的另外一個缺陷是缺乏在分析人員與最終用戶之間的交流。 最終用戶被期望預先的指出需求并且對需求進行檢查，但是他們有限的參與了方案的開發。在許多情況下，和約的商定是以預先被描述的需求為基礎的，并且后來的變更需要有一個和約上的協商。
在整個開發的生命周期中維護在用戶與分析人員之間的交流是尤其有效的。雙方都應該理解他們擁有相同的目標：建立滿足質量要求的可以解決問題的方案，同時成本是可接受的。如果他們的關系是圍繞著爭論關于什么是以前達成的一致和誰應該為此付錢，而不是建立一個正確的方案的話，那么項目就陷入了麻煩之中。這并不意味著分析人員應該接受所有的需求或者最終用戶不應該作出變更的請求。相反，這意味著所有的項目相關的人員應該在提出需求和最終進入到訂單中的需求進行一個平衡以形成更好方案的開發。他們需要認可當他們過分的嚴格時，應該通過一些討論以達到一個折中的方案，并且要作積極的改變以保持項目按照計劃進行。當然，這一點做起來要比說的有難度。但是朝著有效的 團隊協作的第一步是在分析人員與最終用戶之間建立起有建設性的對話。
過度的指出預想的需求是不明智的
傳統的開發方法提倡詳細的預先需求，并且在過去的多年里很多人覺得項目失敗是因為他們的需求對啟動項目是不夠詳細的。但是增加需求說明的詳細程度將會減少的回報。在一些情況下，項目團隊需要不斷的構建方案，并假設需求在整個項目周期不斷的改進。記�。� 軟件項目的主要目標是在盡可能低成本的條件下生成可執行的能夠解決手工形式的業務問題的代碼。一旦你的需求到達了一定的細化程度，將他們定案的最廉價的方法是對系統進行部分的實現以可以向最終用戶進行演示。同時你可以一起確定你還需要提供什么樣的其他能力。 定案需求通常要經過幾次的迭代，在迭代期間你可以調整需求、設計和代碼，然后對測試進行引導。
在項目周期的后期你可以不必正式的文檔化很多的詳細的需求；代碼本身可以提供足夠的文檔，并且很少在團隊中誤解什么是需要實現方面存在 風險。這依賴于正被開發的系統自然的改變了參與的人數、系統期望的生命跨度、和約的義務和附加的質量 標準的需求。最后，也許是最重要的，你應該象驅趕技術風險一樣在項目中盡早驅趕商業上的風險。 在細化預想的需求上花費過多的時間會使你的注意偏離出降低關鍵的風險。
開發人員的新思想
迭代開發，對開發人員來說使用與迭代開發相關聯的最佳實踐和現代的工具技術，同樣需要在思想上的轉變。首先，就像我們在上一部分討論的，開發人員需要在指定需求中扮演更多積極的角色。
過去，開發人員以對辣手的問題提出聰明的解決方法為榮。他們創造唯一的方案以使系統性能最大化、內存使用最小化或者提供良好的圖形用戶界面。當然，開發人員仍然需要提出聰明的方法， 但是他們的精力需要從構建方法轉向到發現聰明的方法以盡量的將可重用的資產、開發源碼的軟件、通用的商業現貨 (COTS) 組件和 Web 服務集成成為一個可使用的方案。為了成為優秀的開發人員，你需要知道如何最好的利用交互式的開發環境（IDE）和建模環境�！斑@里沒有發明”的態度是達不到預期的目標的；作為一個開發人員，你的精力應該放在通過利用各種可重用的資產來產生可使用的方案上。今天快速并廉價的生產出高質量的產品才是應該受到褒獎的。
質量是測試團隊的職責。在傳統的開發中，在項目的最后幾周，整個系統才交付到可憐數量的測試人員手中，他們被要求盡可能多的找出軟件系統的缺陷。他們負責質量，開發人員負責修改他們發現的缺陷。迭代開發正好與之相反，迭代開發認為 質量是項目中每一個人的職責�，F在我們擁有支持這種共有職責概念的工具和過程，允許我們交付高質量的代碼。新的工具技術允許我們同步代碼和設計。他們也使我們可以在系統被完成前測試代碼產生的內存泄漏問題和性能問題，這是在過去無法達到的�，F代的 配置管理和變更管理環境支持了每日構建，不僅允許我們測試我們分離的代碼，還允許我們測試我們的代碼如何與系統的其他部分代碼的集成。
現代的最佳實踐包括測試先行的設計：首先你要指出你應該進行什么測試，然后再構建能夠通過這些測試的軟件。這樣創建高質量的代碼是我們重點要考慮的事情�，F代的工具技術也支持 設計的質量問題， 1 它使質量成為了設計過程中的主要部分。它允許你在設計過程的早期就進行質量的測量并且可以自動的從設計模型中產生測試。通過保證設計的質量增強了整個系統的質量并保證了測試代碼的完成。
總而言之，使用迭代式的開發方法，開發人員角色需要進行擴展；除了簡單的實現需求規格說明，開發人員必須在決定什么對整個系統是必要的方面承擔更多的任務。這包括幫助確保需求是正確的和在可接受的成本下創建出高質量的系統。為了作出最好的決定，開發人員需要更好的理解項目的遠景和驅動項目的業務問題。這樣開發人員才有可能創建一個滿足需求和能夠解決業務問題的方案。
測試人員的新思想