谈研发过程管理改进(7.19)

对于研发项目管理,研发过程改进和CMMI,我在10年前的文章谈过很多,而最近几年谈的比较少,但是一进行检查发现最近内部研发项目管控,外部项目实施上,对研发过程管理,管控,标准规范流程方面的执行都出现偏差,而这些都需要在后续的研发管理中进行改善。

要做好研发项目管理,过程管理并不是一件容易的事情,我有时候就在想,就连最基本的PMS任务日志下达,日志按时反馈都无法做到位情况下,很多其它研发管理规范流程要求就更加无法落地。这一方面是研发管理中的执行力问题,一方面是每个团队成员形成的研发文化和过程意识问题。

对于目标和过程,我在原来很多文章里面也都谈过两者的关系,特别是从很早就开始强调过程往往比目标更加重要,只有过程才能够持续的让你达成目标,通往成功,而不是靠具体的经验和运气。这就好比渐修和顿悟的关系,看似六祖顿悟好像更加高明,但是没有渐修又何来顿悟?

下面重点记录下研发管理要改进的一些重点内容

对于后续系统的新增和变更功能优化更新,首先对已有的需求规范文档进行更新和版本升级,同时对增加的内容进行条目化处理,对于条目化需求不再准备Excel文档,而是直接录入到禅道。录入禅道后,在禅道中进行版本规划,并开始安排版本研发,下达PMS任务。

需求采集: 用户需求文档保留,重点是需求采集和初步需求分析和条目化拆分

原型开发: 全新模块需要,变更可直接在需求提交附图

需求提交: 直接采用禅道需求管理,不要求项目必须先有完整软件需求说明书

需求评审: 变更类和全新模块类分开,需求评审记录直接附加在条目化需求后

需求实现: 需求点对应到项目和版本规划,项目关联到具体的产品

对于研发版本规划好后,基于研发版本进行PMS研发任务下达,研发人员填写PMS日志,研发负责人对开发进度进行PMS任务跟踪管控。对于研发版本,建议采用短周期迭代模式,即2到4周为一个版本,2周的开发时间,1周的测试环境发布和验证时间,1周的正式生产环境部署时间。

产品管理: 按部门内产品线划分设置产品经理,一个产品管理可负责多个项目

项目管理: 产品经理和研发经理都可兼项目经理,不再设专门的项目经理

版本规划: 短周期迭代模式,最短周期1周,最长周期8周,运维类项目单列

任务管理: 启用任务管理和日志反馈,研发人员必须每天反馈任务和填写日志

对于测试,仍然是和具体的研发版本对应,测试提交的功能Bug要对应到具体的研发版本。前期我们采用持续集成和自动化构建,而现在本身我们研发DevOps平台后,对于我们管控平台的研发也可以迁移到DevOps平台上来实现自动化的产品构建和打包。

测试设计: 测试用例设计,新增和变更类分开,变更直接对应到需求

持续集成: 前期采用Maven和Jekin实现,当前专业到我们自研的DevOps支撑平台

缺陷管理: 采用禅道项目管理工具进行,前期已经在云团队使用

版本发布: 测试评估报告,版本发布评审必选环节,进一步规范产品发布流程

开发修改问题或Bug,修改完成后将Bug状态转为待验证(在这里没有待部署状态)。测试人员在DevOps平台触发流水线自动部署,部署完成后测试人员对Bug进行验证。在Bug全部验证完毕后对当前版本进行基线和打标签,同时将当前版本进行环境迁移,从开发测试环境迁移到SIT或UAT测试环境,转前方进一步测试。通过这种方式更好的实现异地协同和多方联动。

版本测试完成并验证通过后,测试人员出测试评估报告,准备发版申请说明书进行版本发布。同时版本发布准备好具体的部署包,准备Sql部署脚本和数据初始化脚本,以方面出现问题继续回退。

研发过程增加关键评审内容,一个就是每一个版本的需求需要进行评审和Review,一个就是要增加开发完成后的CodeReview和代码走查工作,加强代码编写的规范性。同时对于配置管理也需要加强,特别是配置分支,基线,配置审计等工作,实际上在前期做的并不好。

我来评几句
登录后评论

已发表评论数()

相关站点

热门文章