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

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

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

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

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

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

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

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

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