2016年9月15日星期四09:09

敏捷中的深潜模型:过程流Pt 1

撰写者

这个简短的系列文章“敏捷中的DeepDive模型”为产品所有者社区提供了有价值的信息,以便他们在项目中使用其他良好实践。

在本系列的每篇论文中,我们将介绍敏捷中最常用的可视化模型之一,并说明如何创建模型以及如何使用它来帮助构建,修饰或阐述敏捷积压工作。

本系列的第一个是“流程”。该系列的其他版本将包括:业务数据图,状态表/状态图,决策树/决策表,业务目标模型和功能树。

什么是流程?

流程是RML人员模型,它描述用户完成目标或完成任务所需采取的步骤。此模型非常适合了解项目的当前和未来业务状态流程,并从最终用户的角度了解这些流程。
RML流程流是按级别创建的,以便既可以查看系统中流程的概况,又可以深入研究单个更详细流程的细节。这与具有超过100个步骤的大型过程图相反,而这些过程图试图显示全部内容-但不可读!在通常称为L1级别的最高级别上,通常以7-10个步骤来描述系统中最终用户的整个端到端过程。这个级别往往没有泳道或没有做出决定,因此非常抽象。请参见下面示例中的第一行:

流程1


从那里开始,L1流程的每个步骤都分解为较低级别的流程,称为L2和L3流程。这些是大多数人乐于谈论和引起的水平。每个L2或L3过程不应超过20个元素以保持可读性,即使如此,也应按泳道划分以在图中创建较小的组。 L3流程通常是可选的,如果流程很大或很复杂,或者需要引出较低级别的信息来创建需求,则使用L3流程。请参见上面的L2和L3处理流程示例。

什么时候在敏捷项目上使用流程?

流程流通常用于面向用户的项目/系统,尽管它们的表亲“系统流”实际上可以以相同的方式用于记录系统流程和逻辑。

在敏捷项目中时,产品负责人(PO)或业务分析师(BA)通常会在sprint 0或计划类型阶段引出高层流程(L1)。从那里开始,在同一计划类型阶段中,将优先创建要创建的L2流程,并且PO或BA通常将在L2级别上处理1-2个最高优先级的流程。这是为了建立初始的积压。

一旦处于开发阶段或冲刺本身,PO或BA将向前看(通常向前冲1-2个冲刺),并确定是否需要构建额外的L2或L3处理流程来识别即将发生的冲刺的新故事或进行详细说明(通过L3流程)已经确定的故事。
这可以继续直到项目结束。此外,PO或BA在计划即将到来的冲刺时,可能需要使用已发现的新信息更新现有的L2或L3处理流程。在这种情况下,应该在阐述故事的过程中花费时间,并且应该保留一组通用的流程,以便它们是最新的!

如何创建流程?

流程流是更容易引发和创建的RML模型之一。为了获取信息,BA或PO应该与用户和利益相关者讨论当今系统中的流程,执行这些流程的人员以及何时进行。用户倾向于自然地思考他们每天所采取的步骤,因此这通常是很容易得出的模型。

在启发会议上,您可以携带草稿或草人模型,以产生评论和想法。您也可以从头开始创建白板,便利贴和用户,以创建流程。

对于将来的状态,PO或BA通常将从当前状态的流程开始,并从用户/涉众那里获取有关将来系统中将发生变化或不同的信息。

RML的流程模型本身大约有7种元素类型,其中,我们今天只涵盖4种左右。我们在此不介绍的元素是派生,联接和事件。所有元素都通过带有箭头的线连接在一起,这些箭头显示了流向。

-该步骤是最常用的元素,因为它包含所有过程步骤。这通常是带有主题动作名词短语形式的简短短语的矩形(用户登录)。这些句子应尽量简短,以便在不理解所有细微差别的情况下跨过这一步。

决断 -该元素通常显示为菱形,描述了用户在此过程中必须前进的决定。决策通常是二元决策(是/否),但可以是非二元决策,只要所有选项都是互斥且共同穷举的。每个决策钻石都需要至少2个选项才能做出决策。

泳道 -泳道描述执行步骤的用户或一组用户,或者描述正在执行一系列步骤或决策的系统。单个流程的泳道应全部为一种类型(用户或系统),以便于理解。泳道是一种组织流程中步骤的方法,无需在每个步骤中都重复用户或系统,从而可以集中注意力并节省空间。

传入/传出元素 -由于RML流程是内置级别的,因此每个较低级别(L2或L3)的流程都应具有“传入和传出”元素。这些元素是流程集的“您在这里”。它们告诉您当前过程之前紧接的哪个步骤以及下一步读者将去哪里。

如何从流程流中得出用户故事?

一旦PO或BA具有良好的流程草案草稿,他就可以开始从Process Flows中导出故事以构建或添加到他的积压中。

得出的故事级别取决于流程流的级别和流程的复杂性。在大多数情况下,L1处理流程中的每个步骤至少会成为一个Epic用户案例(太大而无法容纳单个sprint)。 L2或L3处理流程中的每个步骤都将成为积压的一个或多个用户故事,每个决定可以少至1个用户故事或多达7个用户故事。请参阅下面的示例。

流程2

流程3

因为用户故事是从用户的角度编写的,而流程是从用户的角度创建的,所以流程很容易使自己识别用户故事。例如,如果“处理流程”步骤为“用户登录到系统”,则用户故事非常相似,可能看起来像“作为用户,我希望能够登录到系统,以便我可以访问我的帐户信息。”

决策有些混乱,因为如果它是较低级别的决策(例如在L3流程中),则可能是一个故事,决策线是接受标准。如果是L2流程,则决策可能会为决策菱形的每个分支产生一个故事。为此,PO或BA将不得不利用她对团队的了解和流程来决定最适合故事的内容。

结论

流程流是从用户角度推导出用户故事的最简单的RML模型之一,因为它们是从用户的角度出发的,并允许PO或BA系统地遍历流程并为需要支持的每个步骤编写用户故事。

但是,最后一点是,这些流程不需要完全或完整就可以使用。 PO或BA可以草拟流程,与用户或利益相关者进行审查,并从不完整的流程中获取用户故事。只要在流程步骤和用户故事之间具有可追溯性,就很容易知道如果流程发生更改时要更新什么,或者如果添加新步骤则存在空白。此外,即使采购订单或采购订单以外的团队成员也可以编辑和更新处理过的内容(如果他们居住在集中的位置)。

最后,这些是我们在面向客户的敏捷项目中发现的最有用的模型之一,因为它们可以快速创建和更新,并很容易地将它们应用到敏捷需求层次结构的各个层次上。

Candase Hokanson

Candase是Seilevel的高级产品经理,也是PMI-Agile认证的从业者,他在敏捷方法方面为产品所有者,scrum管理员和业务分析人员提供培训和教练,并为客户推荐这些角色中的产品。她与团队合作,围绕实现交付业务价值的共同最终目标团结每个团队成员,以节省多达数百万美元的开发成本,以解决那些无法使用或无法为预期业务价值做出贡献的功能。她还与客户合作,帮助他们将敏捷实践的规模扩展到一个团队或一名飞行员到整个组织。

©BA Times.com 2020

麦格雷戈徽标白色网站