迭代开发经验分享

我们是一个驻场在客户现场滚动开发的项目组，项目组由9名开发，2名测试组成。客户两个月一个版本，一般有十几单需求，工作量平均1200人日。银行单个版本计划如下： 

1. 1周需求分析和概要设计时间。限期完成并提交纳版准备材料。

2. 1周内完成概设评审以及详细设计。

3. 4周编码开发以及内测时间。在规定的日期，提交第三方SIT测试。

4. 3周时间，第三方SIT和行方UAT测试。严重缺陷必须1天内修复，普通缺陷必须2天内修复。

5.  版本质量要求，缺陷数量要求在1000工作人天不超过60个C级缺陷。重大A/B级缺陷单个罚款5000/3000。每个里程碑的交付物纳入考核！无法按时提交SIT测试或者SIT测试冒烟不通过，扣罚该月度版本工作量50%。

我是2016年3月开始担任X银行Y项目经理。2016年5月版仍然保持传统的进度模式。

一周时间，与业务部门商讨需求清单，最终确定12单需求任务。各个项目阶段仅能按时交付。3月13日之前，项目组未能确认5月版需求清单。前一版本未结，又开始下一版本。为准时交付，需求分析质量付出巨大代价。许多一句话的需求，业务规则模糊不清，关联分析不到位，产品分析遗漏。前一版本质量不理想，骨干成员也都全心投入缺陷修复。概设文档实际上仅把需求文档进行格式转换。这种现状从系统14年上线至16年5月，延续多年。在极短的时间里，完成需求和概设编写工作。为满足纳版规定，需求和设计只能做得很粗糙，严重的后果是需求模糊，设计不清晰，对后续的开发工作带来很大的不稳定因素。版本重叠，顾此失彼，项目组的需求评审工作或有或无，也不够重视业务评审。编码阶段，开发人员面对“概设”模糊不清。应付而生的需求，几乎无法用于开发和设计。开发人员更多的时候需要重新分析需求，改变设计。老同事曾经多次经历由于需求分析错误，导致一个版本里编码被推翻重做。大概20工作日的开发时间，现场资源紧张，为追赶进度，带来代码质量和项目质量的下降。前期需求不确定，又给编码阶段带来频繁的变更，造成项目的进度严重滞后。进而导致交给内测的时间不充分。项目各个过程没有计划，更没有应急变更措施，骨干成员频频救火，项目已经失控。提交SIT冒烟的时候，交付的质量差强人意，严重的甚至无法通过冒烟测试。SIT中测出大量的缺陷，不得不组织资源加班修复大量的缺陷。

5月版缺陷情况，SIT缺陷 100 个，UAT缺陷81个。在定版的最后时间，好不容易的完成修复各种缺陷，这个月度版本总算死里逃生的度过了。4周时间开发编码，结果花4周时间疲于修复缺陷。5月13日，投产定版。此时，离7月版纳版时间仅剩1周。定版的结束，似乎又是噩梦的开端。大概说这样的项目是无间地狱，也没有太差异的。

如果按照过去开发的模式，项目组就一直处于精神绷紧状态，项目已经失控。之前，项目就是处于这个状态。在各个项目过程中，项目组处于被动。

1.  需求分析不够清晰，需求评审不到位。当初，项目组完整熟悉系统的仅有3人。由于时间不充分，需求难以做到考虑每个细节。

2.  忽视设计分析的重要性。不重视设计分析，往往在编码过程中，开发人员才了解设计，降低编码效率。开发人员联调工作不充分，存在编译即交付。

3.  版本管理缺位。开发环境同时作为内测环境和版本库环境，造成版本混乱。经常出现打版出错，影响交付质量。版本配置管理员不足。

4.