最近我和徐大神(Shaun Xu)在分享Scrum实践经验时,经常有听众问:“用户故事为什么要关联开发数据呢?”。这个问题里提到的“开发数据”指的是代码提交、代码评审、构建和部署记录,而“关联”指的是在Worktile工作项的开发面板中显示这些数据。

[孙敬云] 粘贴上传 -2020-05-29 10_04 42.png

如果简单回答,这是因为:基于DevOps三步工作法的第二步,我们要建立从右向左的、快速的、持续的工作反馈。通过将开发数据及时的关联到用户故事上,我们可以及时的发现问题,群策群力,建立更安全可靠的工作流程。

当然,要真正解释清楚这个问题,我还需要对一些概念进行说明。

价值与价值流

如果基于精益思想看Scrum,那么每一个产品待办事项就代表着一个用户价值,而每一个sprint就是一次价值流动的过程。在一个sprint开始时,我们定义这个sprint的产品增量目标,按照产品待办事项的优先级,选取价值相对较高的一些用户故事放入这个sprint中。在这个sprint结束时,我们交付产品增量,交付用户价值。随着一个又一个sprint的开始和结束,我们可以稳定的、持续的让价值流动起来

[孙敬云] 粘贴上传 -2020-05-29 09_58 54.png(价值流动)

DevOps第一工作法

第一工作法指的是,我们要建立从开发到运维再到客户的整个自左向右、快速的、平滑的、能向客户交付价值的工作流。如果我们将左侧延伸到需求的制定,那么大体上这个工作流是这样的:

[孙敬云] 粘贴上传 -2020-05-29 09_59 06.png(自左向右的工作流)

我们要为了这个全局的目标进行优化,让价值稳定的、持续的流动起来。比如:通过持续管理产品待办事项,让研发团队每个sprint有目标,并且这个目标和公司的目标相吻合。再比如:通过持续集成、持续部署缩短变更到上线所需的时间,同时提高服务的稳定性。

建立自左向右的工作流有很多的好处,其中之一就是让工作可见。与其他行业不同,技术行业的工作往往是不可见的,我们很难发现工作中的阻塞点。哪一个环节出了问题?当前的工作进展是什么?如果工作不可见就极容易出现“踢皮球”,团队积累的问题越滚越大,而管理者虽然想解决却无从下手。因此,通过建立工作流,尽可能的让工作可视化,辨别工作如何流动、在哪里阻塞,从而方便对其进行有效的管理。

[孙敬云] 粘贴上传 -2020-05-29 10_06 33.png(一个sprint内的工作项列表)

研发与自动化

其实技术也是可以标准化的,随着DevOps的发展,CI/CD的工具链已经相当成熟,每天部署成百上千次早已不是什么别人家的技术。通过技术工作流的加速,可以有效的缩短“满足客户需求”的前置时间,使得研发团队更加敏捷。

[孙敬云] 粘贴上传 -2020-05-29 09_59 32.png(在一个sprint中的研发工作)

因为主题的原因,今天先不展开研发工程化的话题,只是单纯的对研发数据进行说明。研发工程化产生的各类数据,对于工作流来说非常重要,它们是重要的指标数据。比如:一个用户故事关联了哪些子任务?这些任务上提交了哪些代码?哪些代码评审通过?哪些代码合入主分支?持续集成是否完成?新功能已经部署到哪些环境中?如果没有这些数据,研发就像是一个黑盒,内部工作对外界是不可见的,如果这个环节内出现阻塞,那我们将一无所知。如果有了这些数据,研发这个环节的价值流动就清晰起来,我们可以及时的发现并解决问题,保证研发过程的稳定性。

DevOps第二工作法

第二工作法指的是,我们要建立从右向左的、快速的、持续的工作反馈。当整个工作流运转的时候,我们需要及时的知道每个环节的实际状态,这样才能保证工作流是一个安全可靠的工作系统。

对于需求的管理,我们需要直观的可视化工具,通过实时更新的产品待办事项列表,保证需求是可控的、持续的、符合客户价值的。

对于研发的管理,我们也需要直观的可视化工具,实时的记录研发工作的进展,包括各类任务状态和自动化产生的研发数据。(测试和运维同理)

[孙敬云] 粘贴上传 -2020-05-29 10_13 00.png(持续管理的产品待办事项列表)

 

开发数据与前端业务

到这里我基本上已经把用户故事关联开发数据的价值解释完了,但是我想再稍微补充一些。

我知道很多公司面临的实际情况是这样的,前端的商务同事面临着非常大的压力,因为他们无法感知在他们身后的项目的实际进展,所以在与客户的商务合作中始终心里没底,最直接的体现在于已经确定的项目目标一再延期,要花很大的心力维护客户关系,然后担忧着下一次上线能不能准时完成。

项目的负责人也有很大的压力,他不得不费尽心血想要赶上每一个上线时间,如果时间紧张,就提前一段时间拉着相关的同事加班赶工期。久而久之每个人都心力憔悴,你可能认为项目组内几个核心成员的离职是突然之间发生的,但是内部的不稳定性其实是由来已久,这种必然发生的结局早已经埋下种子。

很多人认为转型敏捷开发、引入DevOps不过就是个口号,该干的活不还是照样干吗?其实不是,一个健康的敏捷团队一定是在保护所有人,同时让工作更顺畅。人在面对未知时是最恐慌的,当工作流能够可视化,开发团队又具有稳定的团队速度时(关于开发团队如何具有稳定的团队速度,可以看我之前写的一篇文章:《到底什么是故事点?如何预估故事点?》),未来也是可以预知的。

开发数据或许只是工作流中的一部分,没有这些数据这么多年也都走过来了。但是如果向更高层次迈进,进一步提升研发效能,这一部分的数据是决不能少的。有的时候,前端的商务同事就是因为这些数据心里多了那么一分自信,而这份自信写在脸上的时候,给客户的感觉是完全不一样的。

 

本文作者:Worktile 孙敬云

Worktile 官网:worktile.com

文章首发于「Worktile官方博客」,转载请注明出处。

版权声明:本文为worktile原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/worktile/p/12986647.html