项目进入试用阶段，版本节奏也相对平缓，对于需求&开发&测试过程中的一些管理，分享一些个人体会，欢迎指正。开始正文之前，存在下面前置条件：
     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）每周周五，拟好下一周要做的任务清单。