【DEVOPS】基于禅道 – 重构研发协作流程

如何让标准研发流程在一个多年处于蛮荒时期，”野惯了”的研发团队中落地。这个流程也不是标准化的敏捷开发流程，但它至少能够让我们走出了切实的一步。

0. 目录

• • • 1. 背景
    • • 1.1 业务特点
      • 1.2 团队特点
    • 2. 解决方案
    • • 2.1 协作流程
      • 2.2 使用到的工具
      • 2.2 关键理念
      • • 2.2.1 前奏
        • 2.2.2 只创建一个项目
    • 3. 最终效果
    • 4. 一些最佳实践
    • 5. 附录
    • 6. 参考

1. 背景

虽然已经在过往不少文章里或多或少总结了传统软件研发团队典型特点，但基于本次想要介绍的内容，这里再重述一次：

1.1 业务特点

1. 电子政务，受政策影响大。
2. 相关政策指导下，相关软件存在产品化的趋势。
3. 产品项目化，需求产品化。
4. 产品长尾效应突出，往往是延续数年的维护和更新。而且商务为了加大中标概率，往往在投标文件上进行过多承诺。

1.2 团队特点

1. 部门内部多达百余名的研发人员，看起来非常庞大的研发团队。
2. 实际上这个研发团队被部门所承接的产品和项目拆分为多则十来人，少则一两人的研发小团体。
3. 产品私有化独立部署，对应地方上有专门的实施人员进行维护。注：这些实施人员基本没有专业技能要求，绝大部分只能起到传声筒的作用，加之待遇差，成长空间小等原因导致离职率居高不下。
4. 产品，研发，售后，地方实施团队等每个岗位都同时担着多个产品/项目职责，并行属于司空见惯。
5. 就单个产品/项目团队而言，都会由专职的产品经理，研发团队（2-5人居多），售后（兼职业务功能测试）组成，无专业运维(本地测试时候的部署由研发或售后完成，客户现场部署由地方实施人员完成)。
6. 需求存在阶段性集中爆发期（例如对于电子政务而言，每年的3，6，9以及年底阶段），这个时候需要协调其它团队研发人员进行协助。
7. 研发团队整体待遇一般。结果就是人员专业水平低，基本代码质量难以保证，甚至员工犯错也不敢轻易辞退。
8. 团队过往完全没有标准化研发流程的经历和思想，需求反复，问题集中爆发，各岗位之间相互指责时有发生，尤其是交付阶段，或者问题爆发到高层领导那时候，更为显著。
   a. 团队对于禅道的态度是”平时工作就够忙了，谁还有时间折腾这么个玩意”。
   b. 虽然”使用”禅道多年，团队对于禅道的认知停留在需求和BUG新建，指派和手工状态修改这三类操作上，占据总操作量的95%。
   c. 禅道里的其他概念，诸如”产品线，模块，分支，计划，发布，文档；项目，任务，版本；用例，测试单”等等整体流程里基本没有涉及。
   d. 团队对于产品和项目的理解与禅道存在偏差。在团队的理解里：”支付宝”是一个产品，支付宝-北京，支付宝-上海这是两个项目。
9. 公司整体管理水平较为粗糙。项目进度了解基本靠汇 ，每次问题讨论像复盘等等较为常见。

2. 解决方案

介绍完背景，我们进入正题，介绍一下笔者在过去半年里，与团队一起，经过调研学习，理论积累，技术预言，团队试点和推广，实践总结的一整套覆盖产品，研发，测试，地方实施团队在内的产品全生命周期研发和维护流程。

2.1 协作流程

首先让我们看看相关协作流程图 （在线高清图参见： DEVOPS – 开发协作流程 – 起步版）：

以上方法很明显不是长久之计，所以我们扩展了这张趋势图表来辅助我们审查团队对于禅道流程的遵从，我们知道这存在很大的不完美，但总比没有强。

4. 一些最佳实践

1. 初期争取领导的支持：要求以禅道内数据进行工作汇 ，至少将这一项作为比重较大的一项参考，逐步淘汰口头excel汇 。
2. 需求/任务粒度要小。初期阶段如果控制不住需求大小，那就将其拆成多个任务，确保工作量在1-2个工作日内完成。
3. 对于系统中需要调用第三方来完成的接口，推荐线使用YApi进行Mock模拟，不要把地方实施团队当小工用，费时费力。
4. 估时是个技术活。这一点要反复进行强调，不少时候负责人以时间估不准要求取消这项职责，这个时候一定要坚决拒绝：“作为一项技术活，本身就是存在熟练度的问题，估不准是需要加强练习的理由；而且估不准说明你需求拆分太大了，毕竟需求粒度越小，对于耗时的估计才会越发准确;；而且我们也没要求估计的精确度达到小时级别”。
5. 在推进禅道的同时，持续推进基础设施的完善，CI/CD等，让一线研发除了理解业务和编写业务实现代码之外，不需要关心别的，并在这个过程中不断积累针对业务场景的代码解决方案，抽取通用模块，迭代出粒度更粗的解决方案，用到下一个同类型需求中，形成正向循环。
6. 对于类似电子政务这种前期需求变化非常大的产品，推荐在产品和项目的需求规格说明书，或者前置到需求分析说明书出来后再开始接入禅道，走上述流程。

5. 附录

常见拒绝执行禅道流程的”理由”：

1. 现在工期紧张；每次员工关怀问你对公司有啥意见时，说公司流程不规范的好像有你外在这整个流程里，你现在只需要负责好你那个阶段的事情就可以了，另外我们前面已经试点成功的团队里，你所谓的耗时长操作，在他们那撑死也就五分钟。你忙到这个程度了吗/li>
2. 这个操作好复杂，没有以前灵活。。确实是的，以前那”一股脑子直接扎近问题，实在撞不破墙才承认走错了，绕回来重新走”，现在这种被逼着先动脑子的工作方式确实”复杂”。

几点补充：

1. 对于软件开发流程来说，全流程可追溯的能力从来不是可选项，而是必选项。像最近流行的区块链技术，除了发币以外，最典型的场景也是全流程可追溯。而要做到全流程可追溯，公认的切入口就是”将需求作为抓手，来串联打通各个环节”。是否对需求进行信息化管理不应该是个需要讨论的问题。
2. 引入额外的工具进行规范化管理确实会在初期造成效率上的损失，但这只是工具不熟悉带来的阵痛，我们应该讨论的是如何规避这些阵痛，而不是遇到问题就先退回去讨论”要不要用这个工具”。
3. “先僵化，后优化，再固化”，所谓的工具优化不易过早，上来都还不会用就开始想着改造流程，这并不是个好习惯。经过长期考验并被接受的工具，背后肯定承载着业内一系列最佳实践和优秀思想，所以在工具推进初期让人去适应工具是有必要的。
4. 关于工具的推进，建议初期以试点的形式来开展。相关的试点选择：
   a. 对于需求管理流程不规范性有着切肤之痛的小组和部门。所谓的”恨病吃药”，对于不规范带来的切身体会有助于缓解初期工具不熟悉带来的不适应。
   b. 相关知识和认知到位的小组和部门。对于知晓软件管理流程规范化的小组和部门，也可以尝试进行试点推广。
   c. 总而言之，试点项目的推进，最重要的是”改进意愿优先”，大家将精力集中到做事上来。

6. 参考

1. 《走出软件作坊》 三张表：需求列表，BUG列表，团队日历表。
2. 【DEVOPS】zentao核心概念速览
3. 【DEVOPS系列目录】
4. 依靠工具，让员工天天简简单单的管理自己的工作。 – 没错，笔者就是那”谁喝多了搞禅道二次开发的”。
5. 官方文档 – 禅道使用的基本流程

文章知识点与官方知识档案匹配，可进一步学习相关知识云原生入门技能树首页概览8751 人正在系统学习中