CODING DevOps 跨项目管理实践
原创CODING DevOps 跨项目管理实践
原创
本文通过介绍 CODING 内部实践常使用的两种项目管理模式，为用户提供 Decvops-项目管理过程中的跨项目管理时遇到的卡点问题和解决方案，使项目中各个环节进度与风险透明，各个岗位职责分工明确，整个流程尽可能的自动化运作。
-------------------------------------------------------------------------------------------
在与客户交流的过程中，我们发现用户团队会遇到的跨项目管理问题，比如：
- 项目经理 ：每天有很多项目要同时跟进并关注风险，不想进入不同项目中来回切换查看进度，如何统一高效的管理发布流程与进度？
- 客户成功：每天有很多业务需求提过来，要分类管理业务需求不遗漏，如何保证需求被产研关注并如期解决？
- 产品经理：面对产品Roadmap与大量业务需求，怎么有效平衡并有序纳入迭代开发最合理呢？
这些问题应该如何解决，我们推荐以下两种模式供参考。
【模式一】跨项目需求统一管理发布（版本火车）
适用于跨项目需求统一版本发布的团队，交付标准统一，按月及以上的发布周期。
1. 版本火车整体流程
版本火车在大规模敏捷架构SAFe以及集成产品开发流程（IPD）中均有涉及，综合以上两种流程，结合实际情况设计版本火车流程如下：
2. 运作方案
- 项目层级
版本火车整体在CODING内部运作，涉及到的项目分如下三类：
客户项目（1+N个）：由客户成功维护，可在CODING创建通用客户需求项目以及定制客户需求项目，由各客户服务人员进行提交和维护，客户项目集中的需求可以关联到产品项目；
产品项目 (N个）：由各子产品经理创建并维护，来源为客户需求或各子产品团队的Roadmap，可通过史诗-需求-子任务的形式录入到项目中；
以上两种类型的项目中的需求列表也就是Team Backlogs，由于包含比较多的未澄清与去重的客户需求，因此需要对全量需求池中的需求进行澄清与去重后进入ART项目；
ART项目（1个）（ART指 CODING内部使用的统一发布项目名称）：由PM维护，按照此版本火车的方式进行运作。
- ART Backlog
ART Backlog是一个待发布上线的产品特性清单，由产品管理团队进行审核和维护，进入版本规划后，可以使用KANBAN进行管理，以描述待上车的特性当前处于那些阶段，以确保向客户持续交付价值流，ART Backlog的主要输入源为已经进行澄清、去重、排序且整理过后确认可向客户交付的清单。
3. 业务需求管理
- 业务需求来源
业务需求来源于客户成功提出的客户诉求，会在客户项目中进行需求单创建；
- 需求创建
在上述项目中选择“创建事项-->客户需求”（可在项目设置中创建此类自定义需求）
- 产研更新需求状态
所有更新到规划版本的业务需求在ART中需要有对应的特性/故事，与之通过产品需求关联
接受此需求且近期有版本规划 | 不接受此需求 |
|---|---|
规划版本：如果近期有版本规划，则根据下拉选择选择合适的版本（添加自定义属性）状态更新：更新状态从“待版本”到“已规划” | 状态字段：更新状态到”已拒绝“ |
- 产研进行需求关联
1) 需求关联-产品需求关联到业务需求
产研更新到已规划的需求，需要将产品项目中创建的产品需求关联到业务需求，并将产品需求关联到ART中的特性：
使用引用资源功能，操作路径为：引用资源->更多资源->项目资源->选择合适的项目->选择合适的需求->确认添加->发表
操作后关联结果如下：
2) 需求关联-ART关联到产品需求
4. 产品需求/缺陷管理
- 需求拆分
- 需求自动化同步设定
使用自动化助手功能，操作路径：自动化助手->创建自动化规则->直接创建->选择合适的项目->配置自动化规则->保存
- 缺陷管理
缺陷统一创建在ART项目中， 选定缺陷的修复版本与测试模块即可。
模式二：跨项目需求单模块发布
适用于跨项目需求按照模块各自发布的团队，发布节奏较快，不同模块间依赖较少。
1. 单模块发布整体流程
为避免较长的变更交付周期影响客户的满意度，所以推出周期较快的单模块发布流流程，SaaS主要的策略如下：①周迭代发布、②需求级发布
2. 运作方案
- 项目层级
整体项目在CODING上运作，设计到的项目分为如下三类：
客户项目集（1个）：由客户成功维护，可在CODING创建1个通用客户需求项目以及多个单独客户需求项目，由各客户代表进行提交和维护，客户项目集中的需求可以关联到产品项目中；
产品项目集(N个）：由各子产品经理创建并维护，来源为客户需求或各子产品团队的Roadmap，可通过史诗-需求-子任务的形式录入到项目中，这些项目可以使用Scrum或KANBAN或其他方式来进行运作
运维项目（1个）：由运维维护，开发完成后需完成部署工作时，由产研提单到运维项目，再由运维同学完成部署工作
- 制定项目发布计划
发布计划：使用CODING的”版本“功能，在各自的产研项目中，由产品经理&技术Leader来主Owner
- 提交发布单
发布单：可创建单独的项目用于管理发布单，其中涵盖各模块发布清单，建议统一提交格式规范，便于运维人员需求发布核对。（建议创建“发布模块”属性用于区分一次发布中包含的模块）
- 发布单关联版本计划
当发布的单子较少时，可以直接关联需求单/缺陷单；当发布的单子较多时，建议将需求单/缺陷单纳入“版本”计划，并将发布单关联到版本计划，操作步骤如下：
3. 业务需求管理
- 需求创建
在如上项目中选择“创建事项-->客户需求”，一线同学可自行提单，如果由产研直接对接客户，可由产品经理直接提单；需要将需求纳入不同业务模块的迭代，便于分组查看；
- 产研更新需求状态
状态更新
接受此需求且近期有版本规划 | 不接受此需求 |
|---|---|
状态更新：更新状态从“待版本”到“已规划”，并将预计上线时间更新到“截止日期”字段中 | 状态字段：更新状态到”已拒绝“ |
- 产研进行需求关联
需求关联-业务需求关联到产品需求
产研更新到已规划的需求，需要将业务需求关联到产品需求：
使用引用资源功能（与模式一关联方式一样）
操作路径：引用资源->更多资源->项目资源->选择合适的项目->选择合适的需求->确认添加->发表
操作后关联结果如下：
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。