从用户故事地图到Scrum敏捷研发管理
Posted 人月聊IT
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了从用户故事地图到Scrum敏捷研发管理相关的知识，希望对你有一定的参考价值。
今天谈下用户故事地图和敏捷项目管理方面的内容，由于最近1年我们基于DevOps成熟度模型对我们的研发过程管理进行持续改进，里面也包括了敏捷研发管理方面的内容，同时也包括了敏捷研发管理和DevOps的集成。
用户故事和用户故事地图
由于最近开始看devops成熟度模型的敏捷开发管理过程域，实际上核心仍然是scrum敏捷管理的内容，因此需要对这方面的内容做下重新回顾。特别是看到的用户故事地图，而实际原来在我们实践scrum敏捷方法论的时候并没有太用到。
原来我们谈的就是用户故事，product backlog和sprint backlog，先形成产品backlog，同时评估优先级和功能点复杂度，然后将不同的用户故事分配到具体的sprint backlog里面形成当前的迭代版本。将用户故事进一步细化为不同的工作任务项，将工作任务下达到具体的人员执行。在整个过程中基于backlog列表形成从需求到开发到测试的完整端到端跟踪和验证。
用户故事本身就是业务需求的实现，围绕用户故事的管理实现完整的业务价值交付。
对于用户故事地图建议大家可以参考下网上的这两篇文章
https://www.jianshu.com/p/5def007ae399
http://www.woshipm.com/pd/270289.html
当我们看到这些用户故事地图的时候，我们发现这种地图方式很好的解决原来backlog清单的单维度问题，形成了一种二维的可视化视图结构。将具体的用户故事内容很好的呈现在一个二维坐标体系里面，其中一个坐标是业务活动和任务，一个坐标是具体的迭代版本。
同时我们对用户故事本身也形成了完整的层次结构，即：
业务活动-》业务任务-》用户故事点
对于用户故事点，我们可以看到也叫最小化用户故事，而这个在我们多年前实施scrum敏捷方法论的时候并没有这样去管理，往往用户故事点还是偏粗，而是在任务安排上对用户故事点进行了细化。而在新的模式下可以看到用户故事点更加细化，是一个最小的功能实现点。
最小化用户故事点也可能不能独立交付，但是这不影响我们细化到最小化用户故事点进行管理。这种最小化用户故事点真正解决了我们原来遇到的两个问题，即对于同一个用户故事，用户故事本身不能再进行细分的，但是用户故事本身又包括了很多扩展边界，或者说用户故事本身包含了扩展业务规则逻辑，而这些在新用户故事视图模式下都可以进行可视化呈现，并分配到不同的迭代版本进行管理。
比如对一个简单的发送邮件用户故事，我们就会存在很多的小用户故事点，比如支持发送附件，支持发送图片都是扩展故事点，而对于发生时候需要校验邮箱有效性可能就是扩展的业务规则点。这些我们都需要进行管理并跟进优先级安排到不同的迭代版本去实现。
对于用户故事的形成，在上面一篇文章链接里面有专门讲到构建用户故事地图的8个步骤。在用户故事地图里面有一个关键行，即一级用户故事，它们组成了用户故事地图上的行走的骨骼（the walking skeleton）部分。而对于一级用户故事，我们也可以看到，正是我们原来在sprint backlog里面管理到的用户故事粒度。
而在一级用户故事上面，还有一层即user activities用户业务活动层，而这层实际上也相当关键，通过这层我们可以将我们的用户故事真正和实际的业务场景，业务流程和活动关联起来。通过这种图也可以很清晰的看到我们实现的用户故事究竟体现在哪个业务流程或业务场景中。
而对于这两层的构建，实际上也是存在两种方法可以考虑。
自顶向下：从业务场景和流程分解入手，先梳理清楚业务活动，再细分一级用户故事。
自底向上：先头脑风暴形成一级用户故事，然后再向上抽象归类形成业务活动层。
就这两种方法来说，自顶向下分析可以确保更加完整无缺漏，而自底向上方法往往则更加快速和敏捷。具体采用哪种方法进行需要根据项目团队实际情况来综合考虑。
在形成了业务活动和一级用户故事后，剩下就是对一级用户故事进一步拆分为最小化用户故事，最小化用户故事是否作为任务直接下达需要看我们研发项目任务管理的粗细度情况，在这里并没有明确的标准和要求。如果跟踪管理的细，持续集成过程也高效快速，那么就可以到最小化用户故事，否则就到一级用户故事。
实际上在一级用户故事的拆分上，还可以借鉴我们原来用例建模的经验，将最小化用户故事分为三类故事场景，即核心用户故事，扩展故事点，业务规则逻辑故事点并分别进行管理。其中对于核心用户故事点优先级最高，必须在第一个迭代周期实现，扩展故事和规则故事点也必须要依托核心故事点而存在。
而对于我们的backlog项目，我们实际建议还是管理到最小化的用户故事点，同时将用户故事点作为任务项来管理和跟踪，同时也基于最小化用户故事点来编写相应的测试用例点，只有这种方法我们整个跟踪才能够达到根据细粒度和敏捷，同时也确保关键扩展点和规则不遗漏。
在这种方式下唯一需要注意的就是最小化用户故事点要确认是否一定是可以独立交付的最小单位，这个问题我也还在进一步思考中，因为基于不同的业务需求和场景，往往需要多个最小化用户故事点打包交付往往才真正能够体现用户价值。但是最小化用户故事点本身又是可以独立进行开发和测试的单位。所以在这里需要我们在进行迭代版本规划的时候考虑到故事点的关联依赖性特征。
从业务活动到用户故事的简单举例
对于用户故事一定会涉及到用户故事地图的构建，要看到当前用户故事地图的构建上可以明确的体现出迭代版本规划，业务活动和用户任务等几个关键内容。而实际上迭代里面的用户故事已经是拆分到最小粒度的用户故事点，或者叫用户可以理解的业务功能点。这个业务功能点可以是我们在需求分析里面常说的基本流，也可以是扩展流或某条业务规则。
业务流程-》业务活动-》用户任务-》用户功能点
以上即构成了整个用户故事地图的层级，也更加容易从用户故事点追溯回具体的业务流程和业务场景。我们可以举例来详细看下整个过程：
第一级：业务流程到业务活动
对于出差我们当前是需要首先提交出差申请单，出差申请审批通过后才能够预定机票和进行报销。因此对于出差报销流程可以分为三个业务活动。
业务活动1：出差申请流程
业务活动2：订票流程，包括机票，酒店等预定
业务活动3：出差报销流程
从业务流程到业务活动，到用户任务，故事点的分解
第二级：业务活动到用户任务
我们这里拿出差报销流程举例说明，业务活动我们可以分解为填单，审批，付款三个关键业务活动。在三个业务活动中就有具体的用户任务，用户任务即已经到具体的业务功能点。
那么以上就是一个完整的用户任务下的细分故事点。那么这些故事点就需要我们安排到不同的迭代版本。迭代版本的安排重点是根据需求的优先级进行，其次需要考虑需求之间本身相互的依赖性。
基于以上思考，我们可以将以上功能安排到三个迭代版本去完成。
迭代1：完成基本功能，报销到项目，项目预算校验，接口核销
迭代2：完成机票酒店预定自动导入，部门间的费用分配
迭代3：完成附件上传功能，发票自动识别
以上即完成了一个完整的用户故事地图从业务流程到业务活动，用户任务，用户故事点到迭代版本任务安排的分解。通过这种方式将所有的业务活动点都进行分解即形成了一个完整的用户故事地图。这个用户故事地图可以看到就是我们整个迭代产品版本规划，后续的敏捷项目管理需求和任务的录入完全可以基于该用户故事地图分解的需求和故事点进行全流程管理和端到端跟踪。
对于业务活动往往会对应到我们实际业务系统中的菜单功能，而对应用户任务可能是菜单功能粒度，也可以是菜单功能中按钮级的粒度，这个需要根据实际情况来确定。
敏捷项目管理
在前面讲用户故事地图和用户故事的时候，我们可以看到如何形成详细的用户故事点，并将用户故事点规划到不同的迭代版本的一个初步方法。对于用户故事点，我们需要注意以下两点：
其一：每个独立的用户故事点必须要做到完全可独立验证
其二：故事点能够追溯回具体的业务功能和业务场景和业务流程
在用户故事地图这个关键的步骤做完后，我们实际上得到了一个关键的内容，即：
条目化需求-》对应到独立故事点
我们可以看到整个条目化需求也是我们后续进行敏捷项目管理的核心内容，整个需求的端到端跟踪和管理，敏捷项目管理，计划和任务的跟踪全部都需要根据条目化需求展开。
这个条目化需求如何呈现？
即我们经常谈到的Scrum里面提到比较多的两个内容，即Product Backlog和Spring Backlog
对应产品清单和迭代清单可以分开，即产品清单重点是列出所有的用户故事点，整理清楚前面我们谈到的用户故事地图的核心内容。将具体的用户故事点规划到具体的迭代清单中。
在产品清单中我们可以只对用户故事点，给出一个故事功能和场景，优先级的描述即可。对应其它熟悉项往往并不需要在Product Backlog里面详细展开。
当我们规划清楚迭代版本后，我们就需要对迭代版本建立详细的Spring Backlog迭代清单。
在原来的整个Scrum敏捷项目计划和任务管理里面，我们看到需要对于用户故事进一步在迭代清单中进行任务拆分，一个用户故事点又拆分为多个任务，可能是开发也拆分为多个任务，也可能是拆分为开发，测试等多个任务。而实际上我们看到：
当前用户故事点的粒度足够细的时候，我们的迭代版本清单中不用再进行到任务的拆分，而是通过一行到底的全流程跟踪方式。这样往往更加清晰和可视化。这种一行到底的全流程跟踪，再配合我们实际的Scrum看板基本就能够很好的完成相关跟踪工作。
而对于用户需求点，在迭代版本清单中我们就需要进一步做细化了，包括
用户故事详细描述
工作量
开发人员
测试人员
关键实现点
关键测试点
前置依赖
当前状态
可能还有一些关键属性项，我们可以根据项目实际情况来增加属性列。比如我们开发采用的是前后端分离的开发方式，那么我们的开发人员就拆分为前端开发，后端开发。
这个Backlog整理好后，我们就可以将我们的用户故事点放到看板上进行跟踪管理，当然不用看板也可以，之间在Spring清单里面进行进度跟踪和反馈。那么就增加相关的状态列即可。
通过Scrum敏捷看板进行进度跟踪
敏捷看板也是Scrum敏捷项目管理方法论里面比较重要的要给最佳实践。比如我们用的最简单的看板就是待办，正在做，已完成三个状态的看板。
但是实际上具体看板哪些列我们可以灵活定制，比如更好的一种方式为：
待开发
开发中
测试中
已完成
这样我们就能够清楚的看到每一个用户故事点当前的进度和状态，也比较容易根据这个来进行燃尽图的绘制。对于敏捷看板或我们传统的pms任务管理，更加重要的实际上是如何跟我们的任务跟踪和持续集成协同起来。这个是需要考虑的一个重点问题。比如：
对于一个需求故事点，自动拆分为多个开发或测试任务项。
对于任务的完成，自动对看板的状态进行更新和转移。
对于开发任务的完成，自动触发相应的持续集成并通知测试进行测试。
这些协同又可以进一步的提升我们整体的敏捷项目管理和开发集成效率。对于这个在我们后续的DevOps支撑平台敏捷研发过程管理子系统中会进一步去考虑如何自动化集成和协同。
研发管理的关键对象分析
对于研发过程管理，可以看到关键对象包括产品，项目，项目集，迭代版本，需求，任务，测试用例，缺陷，项目团队，这也是敏捷项目管理的核心业务对象。
产品一般指我们标准化的产品研发，产品本身也会有版本，但是产品版本如何升级，同样是需要规划的研发项目，在研发完成后进行了产品版本升级。因此项目既包括了对内的研发项目，也包括了对外客户的项目。基于一个标准产品我们会接很大对外项目，很可能都涉及到定制。
比如我们接到中国移动的项目，基于我们标准产品进行定制，那么这个时候首先要建立中国移动这个项目，项目和产品之间建立关联。项目本身最好还有大版本和小版本的概念，项目的小版本对应到具体的迭代版本。录入具体的需求，在需求录入完成后开始规划迭代版本，将具体的需求规划到迭代版本中。同时迭代版本本身属于一个项目或项目大版本。
对应需求可以拆分为多个任务，当然任务是独立的独立，可以关联到具体的需求，也可以独立存在不关联到需求。在任务创建完成后需要确定任务的开始完成时间，工作量评估，然后进入到具体的任务跟踪。
整个scrum是需求和用户故事驱动，因此需求录入完成后，需要基于需求进行测试用例的编写，一个需求可以对应多个测试用例，然后在开发完成后基于测试用例进行测试发现缺陷，那么缺陷自然关联到测试用例，同时也关联到具体的需求。
一个客户项目往往可能涉及到我们多个产品，因此一个客户项目最好规划为一个项目集，即将多个项目版本纳入到一个项目集中进行管理。这样后续分析的时候可以从项目集维度进行统一的分析和度量。
所有上面的对应后面都会方面我们进行研发过程度量分析使用。
关键功能和差异分析
首先项目和项目版本的概念分离，即项目版本即对应到迭代版本或迭代这个对象上面。
一个产品可以对应多个项目，项目可以是内部研发项目，客户是我们自己，也可以是外部项目对应具体的客户。当是内部研发项目的时候，研发完成后往往升级产品版本。
项目创建的时候重点是给出项目的执行周期，项目对应的客户，项目对应的产品，项目中的团队成员等关键信息。在项目规划完成后，规划具体的项目版本，比如南方电网ESB项目V0.1版本，南方电网ESB项目V0.2版本，
具体的需求注意不挂接在项目下面，而是必须挂接到项目版本下面。
对于版本启用大版本和小版本，注意大版本是可以直接发到客户的版本，小版本为内部版本，当然小版本还可以规划为小版本和迭代版本两个版本段。
我们来看下具体的场景，当前已经有了标准的ESB V1.0产品版本，当我们接到南方电网ESB项目后，我们首先要录入南网ESB项目，同时录入一个V0.1项目版本。然后我们将需求先录入到产品下面，录入到产品下面的意思就是一个需求可以规划到该产品下面不同的项目版本中。
我们来分析下，如果录入了20个需求点，其中5个是标准化产品需求，15个为定制需求，同时15个定制需求我们准备分三个迭代版本来进行实现。基于上面这个场景，具体操作应该是：
选择ESB产品，在产品中录入具体的15个已经拆分后的需求功能点
新创建研发项目V0.1版本，新创建南网项目V0.1, 0.2和0.3版本
分别将上面的20个需求纳入到具体的四个项目版本中
南网项目单独拉一个分支，同时注意对于项目版本的修改需要merge到南网项目分支上
这个梳理清楚后，我们再来看关键的需求到任务的关系。
我们举个简单的例子来看：
服务实例查询是一个独立的需求功能点，那么针对这个功能点就需要拆分任务，在这里我们建议增加一个批量添加任务的功能，即针对一个需求功能点，往往存在需求，设计，编码，测试设计，测试执行，或者开发会进一步分为前端开发，后端开发。我们只需要选择存在哪些步骤，然后基于这些步骤来自动创建相应的任务名称。同时任务和人员有匹配，如果任务类型在该项目下只有一个该类型人员，则可以直接将任务默认安排到该人员。即实际可能拆分完成后为：
服务实例查询-需求开发 -- 张三
服务实例查询-编码 -- 李四
服务实例查询-测试用例编写 -- 王五
服务实例查询-测试执行 -- 王五
我们再来看下scrum里面的敏捷看板管理，一种最简单的方法就是userstory，todo, doing, done几个关键状态进行管理，而实际上我们可以进行更细化的开发过程状态跟踪。即需求故事，待开发（任务清单），开发中，测试中，完成几个关键状态。
即我们可以设计为在编码任务，团队人员领取任务后即进入中开发中状态，在开发人员反馈任务完成的时候直接进入到测试中状态，在测试人员反馈测试执行任务完成后进入到已完成状态。跨泳道流转的主体为userStory。
测试人员具体具体的用户故事点进行测试，测试发现的缺陷录入到缺陷管理模块中，缺陷自然挂接到具体的需求，同时能够关联到具体的项目和项目版本。方便我们后面进行质量分析和项目度量。
敏捷项目管理工具应该具备的核心功能
最后谈下敏捷项目管理软件和工具里面的以下关键业务对象和关键功能。
需求-产品-项目-任务-用户故事-测试用例
这个可以说是整个敏捷开发过程管理的一个关键业务对象链条。
我们再来对这个关键对象链条做下说明。
定义一个产品，产品是一个总的概念，一个产品下会有诸多的产品需求，或者说需求提交上来后应该属于某一个产品。产品本身会涉及到产品版本规划，产品版本往往是产品通用性的功能迭代。
一个产品下面有很多需求，对于需求的实现我们需要安排到具体的项目里面。
项目本身也有项目版本，一个项目版本本身可以关联多个产品需求。将多个产品需求规划到一个项目迭代版本里面，后续的重点就是项目的计划，任务和跟踪。
产品需求需要细分为用户故事，往往产品需求并不一定到用户故事的粒度，因此建议是产品需求本身有一层细分能力，即将产品需求拆分为粒度更小的用户故事。后续的驱动和跟踪完全以用户故事进行。即设计，开发，测试等完全围绕用户故事而进行。
项目版本规划好后，涉及到任务安排，任务仍然是基于用户故事为粒度，但是任务本身分了不同的类型，不如一个最小化的用户故事点，往往也涉及到前端开发，后端开发，数据库设计，测试用例编写，测试执行等细分的任务，但是这些任务本身完全是基于用户故事展开和跟踪。
即我们基于用户故事进行工作量估算，任务拆分，进行测试用例编写等动作，形成细粒度的任务跟踪和监控工作。
项目和项目版本本身又是两个概念。即我们首先要有项目的概念，再有项目版本的概念，比如我们同样的ESB产品，可能会涉及到移动和联通两个客户，那么就是两个独立的项目。但是两个客户都会存在定制开发，因此在移动项目下会规划V1, V2等不同的版本，在联通项目下也会规划不同的版本。
如果是通用性的功能开发，实际上就属于通用项目下规划版本来展开，表示新功能开发适合所有项目。简单来说就是先收集需求，然后再将需求规划到不同的项目版本里面，再进行任务分解和安排，最后对任务执行跟踪和监控。同时以用户故事为最小化跟踪单位完成全流程的跟踪和监控。
项目集或项目群
一个项目群可以关联多个项目，实际上这种关联是一种弱关联。起到的作用就是我们可以根据项目集进行相应的项目授权和安全管理，可以根据项目集进行相应的统计分析。可以总体视角来看一个项目集的交付过程。
举例来说
我们是一个团队，团队成员同时兼顾了三个项目，那么我们建立一个项目集，加入最底层的三个项目，那么我们就能够对整个团队建立可视化的工作进度和绩效看板，实时了解整个团队的情况。或者说，我们面对现场一个客户，但是该客户同时采购我们我们SOA，MDM，BPM三个子产品，那么我们可以将三个子产品对应的项目加入到一个项目集中进行统一管理，这样我们就能够很方便的看到整体项目集交付进度。
项目集管理不会复杂到传统项目组合管理里面那么复杂，体现一种弱关联和数据聚合。
缺陷管理能力
缺陷管理是研发过程管理里面的一个重点功能。简单来说就是Bug的提交和跟踪。
需求会对应到测试用例，而实际的缺陷又基于某个测试用例。通过这种方式建立了用户故事-》测试用例-》缺陷之间的关联和映射关系。
缺陷提交后需要进行审核，或处理指派，由开发人员修改完成缺陷后转到待部署状态，由部署完成后转回到测试人员进行验证和最终关闭。而这个缺陷状态流转过程，需要结合DevOps实现一个自动化状态流转。
变更管理
需求本身就包括了新增需求和变更需求，实际上对应需求提交和处理分析流程完全统一，同时支持新增需求和变更需求。唯一就是对应变更需求需要增加变更影响分析。在微服务架构下，变更影响分析需要分析到究竟影响到哪些微服务模块，哪些具体的责任人，然后基于该影响分析进行任务拆分，在任务拆分后再进行任务跟踪。
那么如果对于前后端开发分离的情况下，一个变更就需要在前后端配套的修改都全部完成后才能够进行完整的黑盒功能测试。但是在后端功能完成后我们已经可以进行自动化的接口单元测试。
以上是关于从用户故事地图到Scrum敏捷研发管理的主要内容，如果未能解决你的问题，请参考以下文章