項目進入試用階段，版本節奏也相對平緩，對于需求&開發&測試過程中的一些管理，分享一些個人體會，歡迎指正。開始正文之前，存在下面前置條件：
     1.本輪版本要交付的功能及時間已已評估并與客戶達成一致，是以交付時間倒推來管理《需求規劃》和《研發計劃表》的方式。
     2.團隊資源：有測試組長，開發組長是臨時支持（同時兼顧其他項目）。
     3.開發4人、測試2人、需求1人，迭代周期1～2周。
     4.需求、開發和測試在一起辦公。

（1）對需求的管理，個人認為需要維護好《需求規劃》和《需求規格說明書》這兩份文檔。
      1、《需求規劃》用于管理規劃中的用戶需求，需求狀態含：待需求分析、需求分析中、待開發、開發中、待系統測試、系統測試中、系統測試關閉、待業務測試、業務測試中、業務測試關閉，需求的時間含‘客戶提出時間、交付時間’。
      2、《需求規格說明書》用于管理已明確的軟件需求。
      3、《需求規劃-歸檔》用于管理《需求規劃》中需求狀態為“業務測試關閉”的條目。
  操作過程：
      1）每天下班前：
           需求人員將《需求規劃》中當天和開發、測試評審確定的本輪新需求更新到《需求規格說明書》。
           需求人員將當天在研產生的變更需求，不影響交付時間的情況下，需求&開發&測試三方達成一致意見后，更新到《需求規格說明書》。影響到交付時間，需求負責人與客戶溝通或開發測試溝通，要么延遲交付、要么加快進度。 
           需求人員將當天用戶提的新增需求登記到《需求規劃》。
           其中：
               1.《需求規劃》和《需求規格說明書》之間是用戶需求和軟件需求的對應關系。
               2.需求人員之間對本輪新需求、用戶新增需求相互溝通，對目前的所有需求有整體、一致認識。
               3.需求人員對所負責的需求質量負責，項目負責人對需求的客戶匯報負責。
               4.本輪在研過程中，客戶提的新增需求統一放入下輪規劃，否則走變更流程。（除非重要、緊急且工作量允許的功能或UI需求）。
       2）每周周末前：
            需求人員針對《需求規劃》和《需求規格說明書》中新增的內容做溝通、核對。
            需求人員之間針對客戶提的新增需求做溝通，對目前的所有需求有整體、一致認識。
            項目負責人將《需求規劃》中狀態為“業務測試關閉”的需求統一歸檔。
           
（2）對開發過程的管理，個人認為需要維護好《研發計劃表》這份文檔。
       《研發計劃表》用于管理“研發中”的任務時間計劃，任務狀態含：待開發、開發中、待系統測試、系統測試中、系統測試關閉。
  操作過程：
          1）每周周一如有新任務要安排，非緊急任務，可以下午開展需求溝通、時間評估，上午讓開發、測試人員對新需求進行預審。
          2）根據《研發計劃表》以天為單位列出本周要完成的任務清單（含每天日期、每天的任務、開發人員、測試人員、提交測試時間、測試關閉時間），發給測試負責人和開發人員。
          3）開發過程中，對于關鍵路徑上（本輪版本中開發測試時間最長的功能）的開發進展（提交測試和測試關閉兩個時間點）要重點跟蹤，其余過程由成員自行把握。
          4）每輪升級前，請測試負責人更新《研發計劃表》的狀態，掌握本輪版本的系統測試情況（哪些關閉和哪些還沒關閉）。
          5）測試人員升級完成后，請其更新《研發計劃表》的備注欄（標記每個任務是哪天完成的增量升級），以開展業務測試。業務測試完成后對還仍然存在的問題（系統測試是關閉的），分析是升級包制作問題還是測試故障泄漏還是開發代碼沒提交，另一方面下次增量升級時，測試人員也對功能點做增量升級的代碼文件日期選擇有所依據。
          6）對于個別小功能但影響用戶使用，在走正式增量升級之前，可以讓測試將開發人員開發的代碼單獨拎出來制作成升級包（經過系統測試的），走非正式升級流程，但必須記得讓開發人員將代碼提交到受控庫。
          7）階段性的客戶匯報前，擬定好工作清單（含：已完成的功能開發、已完成缺陷修正和界面優化、已完成的其他問題、當前正在開發和暫時還沒做的）。
          8）每周周五，擬好下一周要做的任務清單。