一些組織一年要花費 $30,000來支持計算機的原因不是因為個人計算機，而是由于對個人計算機的誤用。這些組織不是由具有資格的專業人員來安裝公共配置，而是讓用戶選擇和安裝他們自己的軟件。一旦用戶遇到了麻煩，組織的開支就飛漲。另外還有文件格式不相容的問題。若沒有公共的軟件套件，用戶得浪費大量時間在同一供應商所提供的不同軟件版本之間轉換文件，或從不同供應商所提供的不同軟件之間轉換文件�；陬愃频脑�，當用戶購買他們自己的設備時，硬件培訓和支持也變得更加困難。
在這種情況下所發生的問題是與過程相關：個人計算機軟硬件的管理不當。因而購置網絡計算機這一技術解決方案是否能夠解決問題值得懷疑。技術解決方案適用于技術問題，管理解決方案適應于管理問題，而過程解決方案則適用于過程問題。在談完了所有內容之后，我真正的意思也許僅僅是在工作中要使用正確的工具。
基于需求的規劃策略：按優先次序排序
成功的項目組認識到不能等同地創建所有的需求，因此，需要對需求進行優先次序排序并按此順序操作。
某些需求比其它需求重要得多。例如，對于聯機銀行的需求來說，對帳戶間資金轉移的支持要比銀行每月聲明的 Elbonian語言版本重要得多。成功的軟件團隊將首先集中精力構建最重要的功能，盡可能地滿足用戶需求中關鍵的功能，而那些次關鍵性功能留到以后處理。需求排序使您的團隊能夠為組織的軟件利潤作出最大貢獻。然而，要有效地對需求進行優先次序排序，必須考慮幾個因素：商業價值、交付成本、交付日期、交付復雜程度、風險（請參閱提示“控制風險：不讓風險控制您”）、與其它需求的關系、何時需要該需求。
可能的優先級別范圍
只要明確的定義了優先級并且在應用上保持一致，那么使用什么優先級別范圍是無關緊要的。一般的優先級別范圍包括：
● 高級、中等、低級
● 必需的、條件的、可選的
● 數字的（例如，1、2、3）
如何對需求按優先次序排序
您應該讓授權的個人或小組來建立并確認指派的優先權。對需求的優先級進行優先次序排序通常是一個協商的過程，它涉及到許多項目參與者，包括您的用戶、用戶管理、高級管理、開發人員、操作人員和支持部門。
大多數項目小組將組織成一個“配置控制委員會 (CCB)”——有時稱為“更改控制委員會”或“項目籌劃指導委員會” ——它由系統中關鍵的并且希望是知識淵博的參與者組成。通常由該小組定期開會決定任何新需求的優先級和指派（對于系統的發布或者對于在現有開發成果中的重復）。
為何對需求進行優先次序排序？
需求排序列表是輸入進項目定界過程中的關鍵因素。項目早期，需要認識到，最困難的事之一是不要打算能交付項目參與者要求的每個功能。項目范圍定義了項目組將要交付的范圍。這是很重要的，因為它有助于避免“超出范圍”，即，項目進展的附加的新需求。已定義的項目范圍使您能協商是否有責任交付新確定的需求，并判斷新需求對于交付日期／成本的增加的合理性以及討論是否應該在后續發行版中交付該需求。缺少確定的范圍，項目組將承擔無法交付的風險，因為經常要向正在構建的項目中添加“再多一條功能”。
規劃迭代：及時開發詳細計劃
項目不斷進行時，需要詳細規劃即將實施的迭代活動。在當今日新月異的環境中，提前幾個月甚至幾年做詳細規劃是毫無價值的，但您可以對下幾周（典型的迭代的時間跨度）進行成功地詳細規劃。
項目規劃的普遍且難以置信的有效方法是從粗略的項目規劃開始（請參閱“項目規則技巧”），即從項目開始時開發，然后在完成構成項目的各種迭代時緩慢發展形成。隨著項目不斷進展，需要更新整個粗略的項目規劃，更新它以反映近來努力的實際成果以及您的團隊將繼續從事的下一個（或兩個）迭代的規劃細節。在為單一迭代開發細致的規劃時，應該執行這些步驟。
實行真實性檢查
通過詢問并且回答一些難題來開始詳細的規劃工作：項目是否仍在按計劃進行？您的方法是否仍有意義？您的團隊是否由合適的人員組成？您是否仍有資金管理者支持？如果其中任何一個問題的答案是否，則需要解決問題，這可能意味著新（且非常短）迭代使您的團隊回到正常軌道上。對處于困境的項目進行大計劃是毫無價值的。
標識詳細的任務
在項目開始時，體系結構和轉移迭代只是列出需要實現的任務列表。然而，要規劃迭代，必須評估已為它指定的需求（請參閱“基于需求的規劃策略”）。隨著項目發展，您將對于對個別需求有更好理解。您可能會發現，現在需要更改給迭代指定的原始需求，這些需求最初是有意義的�；蛟S已經標識并添加了新的需求；或許已經擴展或縮減了需求；或許已經更改了優先級。不管什么原因，您會發現您需要重新定義打算在該迭代中實現的內容。根據需求，標識需要實現的任務。
標識任務相關性
某些任務取決于其它任務。例如，在部署源代碼之前，必須先編寫它。測試案例的開發可以在編碼之前開始。實際代碼的測試必須等待，直到已經編寫了某些代碼（盡管或許不是所有代碼）為止。問題是某些任務必須在其它任務完成之后才能開始；某些任務必須等待，直到另一個任務開始了為止，它才可以開始；某些任務不能完成，直到另一個任務完成為止；某些任務不能完成，直到另一個任務開始了為止。
均衡資源
需要緊記的重要事情是，每個人一次只可處理那么多任務，并且在工作的那一天只有那么多時間。這個概念稱為資源均衡，確保任務分派是合理的。 指定用 10% 的時間完成 10 項任務很可能無法完成任何任務， 而且指定用 50% 的時間完成 5 項任務的人員也不可能完成這些任務。確�，F實的規劃的最好方法是，讓執行計劃的人員參與計劃開發。
保持迭代短小
迭代周期應該保持比較短。應該將大于 8 周的迭代分割，以便讓您迅速將軟件交付給用戶。因為正在嘗試彌補在先前迭代中跳過的工作（如文檔編制），或者因為您的需求正在增加而沒有添加新的迭代來反映這一事實，所以當項目進展時迭代長度增長是一種趨勢。執行真實性檢查并按照它們的結果行動，將幫助您使迭代周期保持簡短。
考慮并行開發
分幾個子團隊來同時進行系統的不同部分始終是一種有效的辦法，尤其對于系統縱向片段的開發。并行開發可以大大地縮短產品的上市時間，這是當今高度市場競爭性的一個重要因素，盡管它以增加協調工作為代價。共同的體系結構、共享知識視野、共同的開發實踐、定期團隊會議及共享工作場地使并行開發成為可能。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
