迭代开发经验分享
2020-01-02
来源：恒生实施项目管理 伍健华
代码评审走过场。
5. 人员配置不合理，需求和设计与开发人员分离。沟通不足，理解不充分，付出很大代价。人员培养跟不上。
变革契机
16年5月27日(5月版投产)至8月12日， 7月版的周期内。借该月版本引进公司新产品模块的契机，引入公司远程资源的协助，减轻现场开发工作任务。现场组织骨干做前锋，加班加点集中攻坚业务复杂，技术难度高的需求。7月版总工作量1547人日，消化积压大小需求总21单。为后续调整版本计划，创造条件。
如果没有这次外部资源的协助，也会考虑减少某个版本的需求量，来给节奏提前和质量提升来赢得空间。
从16年9月开始，按照行方的开发周期以及项目的实际情况，采取了以下措施：
备注：日期作为周期里程碑点，每个版本中周期间隔一致。
平日收到的需求任务，马上对需求进行初步分析。评估方案，然后纳入后续《开发任务列表登记》。需求分析在9月13日之前已经着手准备，组织骨干成员集体需求分析和讨论。保证需求分析所需的时间，避免出现考虑不周的情况。确定需求方案，安排专门的同事编写需求分析文档。7月版本4周的sit测试期间，9月版本需求分析文档形成后，项目组内部组织全员进行需求评审，并登记需求评审会议纪要。内测人员也同样参与需求分析阶段，提出测试的意见和业务上的考虑。4周SIT测试与下一阶段需求分析同步进行，在纳版的时点上交付全面分析高质量的分析和设计材料。
交付SIT测试的系统，已经经过完整的内测，大部分的缺陷已经提前修复。只需要安排少部分的资源配合SIT测试。
良性循环
需求评审、设计分析阶段，骨干成员集体讨论方案，提出不同的方案论证，并且对开发同事进行讲解，然后专门的同事编写设计分析文档。分析阶段，要全员参与能带来敏捷的效果。需求的业务逻辑能第一时间传达到每一成员，设计思路能充分被理解。对经验浅的同事，不仅仅地限足在某些模块，是一次难得的学习机会，能更快的熟悉系统。扬长避短，有效避免需求人员对某些系统模块不了解造成需求分析的不合理。
需求文档和设计文档质量，每次都符合行方审计标志。业务认可度提升。
科学合理的项目过程，提供项目组骨干培养机会，骨干成员由16年的3名，增长到如今6名。
每个月度版本，工作量很大。骨干成员在内，都投入到编码开发。设计人员从当技术经理角色，在编码过程中对编码人员进行技术指导。内测人员编写测试案例，开发人员根据内测案例对开发功能联调测试。联调通过后，交付内测进行测试。
项目组配置管理，分配开发环境、内测环境、生产验证环境。上个月度版本的开发环境作为上线后的生产验证环境，开发环境与生产验证环境互换。
针对版本管理，按照轮岗制度。每个月度版本，安排不同的人对环境和版本进行管理，防止项目过于依赖单个版本配置管理员，人人熟悉项目。在月度版本里，版本管理员统一管理资源，负责将开发资源打版到内测环境，配合内测的其他需要。
轮岗承担配置管理，提高了人人的版本质量意识，未出现版本资源出错，未出现版本回退事件。承担环境配置管理后，加深熟悉系统环境，生产故障排除更迅速。
在需求、设计、编码、配置管理的过程中，项目组的每一个都参与。经验浅的同事有了锻炼的机会，也逐渐分担骨干成员的压力。压力不再由少数人承担，需求、设计、编码、内测各个过程的质量都有保障。提交SIT的项目质量明显提升，
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
