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

1. 背景

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

1.1 业务特点

1. 电子政务，受政策影响大。
2. 相关政策指导下，相关软件存在产品化的趋势。
3. 各地区需求各异，造成虽然名为同一个产品，但是感受上像是维护着多个项目。（如何从技术上适应这种业务场景不是本文的关注点，忽略）。
4. 产品项目化，需求产品化。
5. 产品长尾效应突出，往往是延续数年的维护和更新。而且商务为了加大中标概率，往往在投标文件上进行过多承诺。

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 - 开发协作流程 - 起步版）：

2.2 使用到的工具

上图中可以看到，本次流程中主要工具为 禅道 + SCM

1. 基于禅道实现整体协作流程的职责拆解和明确，确保各司其职，以及相关职责执行情况和总体项目进度的监控。
2. 禅道与SCM工具（主要是SVN与GIT）的双向打通，建立起代码实现，需求描述之间的相互关联，为后期维护打下基础，降低人员变动对系统稳定性的影响。
3. 其他工具不是本文的重点。构建本地化DevOps流程涉及到的相关工具链，感兴趣的可以参见笔者过往博文 【DEVOPS】基于Jenkins + Ansible实现Windows环境下自动化打包部署 。

2.2 关键理念

2.2.1 前奏

1. 以禅道内部的标准名词和概念，流程为基础。这一步主要体现对于“产品"和"项目"这两大功能模块以及对应团队职责的继承。
2. 尽可能地兼容团队既有知识体系， 减少禅道专有名词和概念数量和异议的引入，降低推进阻力。这里的典型例子就是上面已经提到的对于"项目"概念的理解，禅道中的项目类似于敏捷开发下的"迭代"，但当下团队内部对于项目的理解就是一个被实际落地的系统建设和维护过程。
3. 推迟测试功能模块的标准化引入，避免在售后和地方运维侧投入过多的精力，让他们先按照既有操作流程进行，将主要精力先集中在产品和研发侧。

2.2.2 只创建一个项目

这是整个自定义流程中，相较于禅道标准化流程最大的区别。基于这唯一的项目，我们可以收获如下优势：

1. 降低现有团队成员对产品/项目这两个概念名词的敏感度，减少在这些概念上反复解释和科普的时间。现有团队完全没有敏捷开发的相关概念和理论基础，与其强行推动两周一次的项目建设，还不如直接将现有对于项目的理解落到团队里，兼容现有人员习惯。
2. 在"只有一个项目"的前提下，产品经理在对需求进行分析确认之后，只需要将该需求关联到该项目下，然后指派给研发负责人即可，这对于他原本的工作习惯改变非常小，由此不会引发过大的反弹。而这一小小的一步，却算是正式启动代码研发阶段的管控。
3. 在"只有一个项目"的前提下，技术负责人在原有认知体系下的变动也很少，他只需要将原本"分配指派来的需求给下面的研发人员"，变更为"拆解需求为任务，填入预估工时，然后将任务指派给下面的研发人员"。这一阶段在操作上的工作量增加，以及新概念的引入数量依然属于不会造成过大反弹力量的层面。
4. 在"只有一个项目"的前提下，业务研发人员只是将原本"完成需求"变更为"完成任务，同时进行实际完成工时填报"，因此也不会引发过大的反弹。
5. 反弹力量小，也就意味着我们不用花费过多的前期时间在培训和监督上，也就能尽早看到效果，以争取到之后更多的资源倾斜，为流程的进一步规范化打下基础。

事物都有两面性，这一步所谓的"最大的改良"问题也不少：

1. 首当其冲的就是对于禅道所倡导的敏捷流程的违背，这直接导致相关操作页面上功能的失效。例如"【产品】 > 【项目】“页面，”【项目】>【看板】"页面等等。
2. 为之后的禅道使用进一步标准化留下隐患。毕竟相较于白纸上画画，我们现在本身就是在一张已经涂黑的纸张上重新调整绘制，现阶段为了为了减少阻力进行的改良很可能导致之后很长时间一定禁锢现有改良后的工作方式里，因为届时各方都会觉得"用得挺好的，改它做啥"，“彼时彼刻，恰如此时此刻”。

在想明白"只创建一个项目"的思路之后，其实可以理解为：项目不再是一个迭代周期，而被认为是一个容器：

1. 产品经理和现场实施人员向这个容器中注入需求，测试人员向其中注入bug，
2. 研发部门(研发负责人 + 业务研发人员)解决这些需求和bug。
3. 以上角色相互分工协作，借助禅道的既有流程驱动，完成操作留痕，确保流程可追溯的基础。

行文至此，不得不感慨下：

1. 笔者曾经耗费了大量的时间和精力去宣讲和推广基于禅道标准化的流程，为此将禅道官方文档整个捋了一遍。但始终无法进行正式的启动。以上流程其实是在笔者多次推广之后，部门内部的某个产品经理经过反复调研，结合实际提出的，不得不说相较于笔者原本的设想，这一套流程更有可落地性。这也再次印证了那句话：“实事求是”，另外就是：主观能动性最重要，笔者将禅道的整个操纵流程和思想介绍了不下十位周边同事，但要不就压根没尝试，要不就是尝试了一两次觉得太麻烦就又走回了老路。
2. 我们的目标是推进下去，不是做知识科普，抓住主要矛盾。

3. 最终效果

以上流程经过最近几个月试点之后，说下感受：

1. 分工明确。相较于过往眼神交流，心领神会的沟通方式，本套流程实现了明确的职责分工，并且这些分工被明确地反映到禅道操作上，除了确保流程可追溯外，也为我们正在进行了流程监管门禁的建设提供了可能性 。另外分工带来的诸如"流程越往前推进，岗位所需要了解的信息就越少，就越具备可替代性"，”关注点分离，让各岗位操作熟练度增加“等等好处就不一而足了。
2. 倒逼需求优先级的确定。过往产品经理一股脑地将需求扔给研发负责人，研发负责人将需求池按人数分给下面研发，这样的模式下往往缺少对于需求优先级的确定，导致很容易出现"你怎么先做这个，那个xx功能客户明天就要看"类似的指责，而现有流程里明确要求进行的优先级确定和预估时间的填写，相当于倒逼负责人思考对于需求的把控。
3. 加强了整体把控。之前是工作进度是靠挨个询问，然后只能依赖于对方的表述，以及自己最终汇总各方陈述之后的分析，缺乏广泛客观数据支撑；而现在只需要查看我们二次开发的数据报表，即可直观了解团队当前的进度情况，而且这些信息是团队内部集体共享。
4. 先实现首尾监管。
   a. 要求地方必须将需求录入禅道，是的，过往我们不少地方以需求很简单为"理由"，拒绝进行禅道录入，而在本次推进禅道过程中，我们进行了至上而下的认知传达，如果不进行录入，一线研发进行逐级上报，研发小组长，研发负责人，项目/产品经理，研发主管，部门经理；而且因为上面所说的本地化流程改造所带来的"见效快"，这一步很容易得到本部门内部的极力配合。
   b 对于尾部的监管。除了定期回访之外，二次开发更多维度的报表也是非常重要的一个途径，通过反复梳理整个自定义流程，提取反映项目进度的指标进行集中的图表展示，方便团队及时了解自身情况，拉平团队对于项目的认知，消除信息壁垒，杜绝因为响应不及时引起的投诉。图表也更容易让禅道推进得到领导的支持，当下我们也已经完成了每日报表定时发送给各负责人。
5. 再实现过程监管。在上一步的基础上，我们依然是需要反复梳理调试整个研发流程，找出我们给每个阶段预设的任务要求，然后进行针对性地门禁限制。（这一块推进采取webhook + IM通知负责人的形式；这样既确保了研发流程不会因为起步阶段的门禁设置不合理导致研发流程无法走下去的阻力，也能做到错误发生时的及时提醒。
6. 杜绝一线研发直接接触地方。现在逐渐透明的工时统计让业务研发人员会自动报备接到哪些地方私下联系的需求（否则他申报的工时就会和技术负责人下发的共识形成差异，当然如果你说预设的工时内我就是做好事不留名地给地方上完成一个计划之外的任务，我们虽然说不鼓励这种行为，但也不会阻拦）。

基于上述流程，截至目前开发的一些自定义统计报表：

1. 人员状态统计表：
   
2. 需求新增 / 任务完成 / 禅道操作日志量 变化趋势图
   
   第三张趋势图表"禅道操作日志量"，其数量来源其实就是【项目】 > 【动态】下的内容数量。之所以会有这张趋势图表，主要是因为本文所介绍的流程建立初期的头两周，我们是有一个专门的高级研发人员放下手上的其它工作，全职盯着项目组内人员在禅道中的操作，一旦出现不符合要求的，第一时间进行面对面的沟通，以这种高强度的反馈来确保团队度过最开始的不适期。

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

4. 一些最佳实践

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

5. 附录

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

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

几点补充：

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

6. 参考

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