用户故事为什么要关联开发数据？

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



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



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

价值与价值流

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

（价值流动）



DevOps第一工作法

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

（自左向右的工作流）



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



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

（一个sprint内的工作项列表）



研发与自动化

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

（在一个sprint中的研发工作）



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

DevOps第二工作法

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



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



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

（持续管理的产品待办事项列表）



开发数据与前端业务

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



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



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



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



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



原文作者：Worktile高级系统架构师 孙敬云

Worktile官网：www.worktile.com

文章来自「Worktile官方博客」，转载请注明出处。