工作流资源模式之推/拉模式

三、推模式

在创建阶段，系统根据不同的创建模式为任务 节点产生了一个或多个工作项，每个工作项或分配给单个资源或分配给角色、部门等。那么接下来，系统就需要将这些工作项推送给相关的资源进行执行，这个推送 的过程即是推模式所包含的内容。需要注意的是，推模式讨论的是对单个工作项的推送。

在前面我们已经了解到，工作流系统通过工作项管理器即不同类型的工作项列表与用户进行交互，这里的推送也可以理解为系统将生成的工作项推送至相应资源的工作项列表里。

 

图 5-17

如图5-17所示，推模式对应着工作项到三种状态的变迁：提供给一个资源拾取执行；提供给多个资源拾取执行（这些资源中只会有一个会实际执行，属于竞争关系）；指派给一个资源负责执行。

推模式共有9种，分为3组， 第一组包括提供给单个资源、提供给多个资源和指派给单个资源，讨论工作项推送的最终分配状态；第二组包括随机指派、循环指派和最短队列指派，关注当工作项 分配给角色、部门等包含多个资源的资源组时，如何从中确定最终的一个资源并进行指派；第三组包括提前分配、即时分配和推后分配，关注将工作项推送给用户的 时间。

 

1、提供给单个资源（WRP_12: Distribution by Offer - Single Resource）

描述

能够在非绑定的基础上将工作项推送给单个资源。

 

图 5-18

如图5-18所示，任务A工 作项被系统推送至员工甲的可拾取列表。这意味着员工甲不必为该工作负责，他可以选择执行该工作也可选择忽略或拒绝。如果他选择拒绝或忽略且工作项超时，那 么会导致系统对该工作项的重新分配。如果他选择执行该工作，那么他首先需要拾取该工作项，这会使该工作项进入他的代办列表，意味着其必须对该工作负责。

 

应用

该模式类似于现实工作中的征求意见，先将工作分配给你，然后找你谈话，征求你对该工作的看法，如果合适那么就由你执行，否则再找他人执行。

 

实现

参与者对工作项的拒绝会导致系统对工作项的 重新分配，这是实现该模式的难点。如何重新分配该工作项，采取何种重新分配策略，这些都具有很大的复杂性。实际上这些工作流模式单个看起来可能比较清晰明 了，但一旦组合起来，例如该模式与创建模式结合起来，那么就有了多种情况变得复杂起来。对于复杂的问题，最好的解决办法就是留给实施阶段，由用户情况作出 使用限定。这也再次强调了工作流实施在工作流应用中的重要性。

 

2、提供给多个资源（WRP_13: Distribution by Offer – Multiple Resource）

描述

能够在非绑定的基础上将工作项推送给多个资源。

 

图 5-19

如图5-19所示，任务A所 生成的工作项被推送给多个员工的可拾取列表。这些员工不必为该工作负责，他们可以选择执行该工作也可选择忽略或拒绝。如果他们都选择拒绝或忽略且工作项超 时，那么会导致系统对该工作项的重新分配。如果有一名员工选择执行该工作，那么该工作项进入他的代办列表，其他员工将不再具有拾取该工作项的机会。

 

应用

该模式是典型的竞争参与，即多人可以完成该工作，先执行者先得。类似于寻找志愿者。

 

实现

该模式的实现一般是创建阶段将工作项分配给角色、部门等包含多个资源的分组，在推送阶段，将该工作项送至这些组下所有资源共享的可拾取列表里，工作项的实例只有一个，但是多资源可见。

 

3、指派给单个资源（WRP_14: Distribution by Allocation – Single Resource）

描述

能够在绑定的基础上将工作项推送给单个资源。

 

图 5-20

如图5-20所示，任务A工作项被系统推送至员工甲的待办列表。这意味着员工甲必须为该工作负责。

 

应用

该模式是应用最多的模式，直接指定任务的负责人。

在采用军事化管理的企业里，上级的命令一定要执行，下属没有商量和拒绝的权利。

 

实现

相比提供，指派实现非常容易，直接将工作项推送至选定资源的待办列表。

 

4、随机指派（WRP_15: Random Allocation）

描述

当存在多个资源可供选择时，从中随机选择一个资源进行工作项的指派。

 

图 5-21

如图5-21所示，任务A所生成的工作项在创建阶段分配给了开发人员这一角色，在推送阶段，系统会随机选取一名开发人员负责该工作项的执行。

 

应用

该模式提供了一种指派资源的非确定性机制。

 

5、循环指派（WRP_16: Round Robin Allocation）

描述

当存在多个资源可供选择时，循环选择其中一个资源进行工作项的指派。

 

图 5-22

如图5-22所示，任务A所生成的工作项在创建阶段分配给了开发人员这一角色，在推送阶段，系统会循环轮流选取一名开发人员负责该工作项的执行。

 

应用

不患贫而患不均，平等的分配工作。

 

6、最短队列指派（WRP_17: Shortest Queue）

描述

当存在多个资源可供选择时，选择其中一个具有最少待办工作即最短工作队列的资源进行工作项的指派。

 

图 5-23

如图5-23所示，任务A所生成的工作项在创建阶段分配给了开发人员这一角色，在推送阶段，系统发现员工甲的待办列表里有两条待办工作（任务B和任务C），员工乙的待办列表里没有待办工作，所以系统将任务A工作项指派给员工乙负责该工作项的执行。

 

应用

该模式的目的在于能够最快开始工作的执行，找出相比而言最为空闲的资源迅速开始工作。但是实际应用中，仅仅依靠工作的数量来判断资源是否空闲是不可靠的，因为工作和工作之间还存在着难易之分。

 

7、提前分配（WRP_18: Early Distribution）

描述

在工作项实际可以执行之前即将该工作项通知或潜在的分配给资源。

 

图 5-24

如图5-24所示，任务A还在执行，任务B还未激活，但此时任务B的工作项已经提前分配给员工甲，该工作项的主要职责是通知员工甲将由其来完成任务B并能开始一部分准备工作，而实际的工作则要等到任务B被激活后才能进行。

 

应用

该模式强调的是预先计划，即管理的计划性。

在我们实际的项目开始之前，项目经理已经通知我们将要进行的开发工作，让我们提前熟悉相关的技术。这样当项目开始时就能提高最初迭代的开发效率。

从某种意义上说，稍微复杂一点的工作都应该做到提前通知、提前准备，即计划的必要性。

 

实现

让工作流系统直接支持该模式比较困难，因为该模式嵌套在控制模式和不同的工作项创建模式里，找不出一种通用的模式，无法预判工作项的生成和实际的参与者。在一定范围内，可以采用下面的方式变通：

 

图 5-25

如图5-25所示，在自动节点执行时能确定任务B的参与者的情况下，可以通过自动节点给员工甲发送邮件或消息进行通知，工作流系统并不生成工作项。

 

8、即时分配（WRP_19: Distribution on Enablement）

描述

在工作项实际可以执行时将该工作项分配给资源。

 

应用

机器执行的工作，重复单一的审批工作，无计划性的工作，如各种突发情况的处理。

 

实现

大多数工作流系统的标准实现，满足任务执行条件时先激活任务节点，然后创建工作项、分配工作项。

 

9、推后分配（WRP_20: Late Distribution）

描述

在工作项实际可以执行后的某个时间才将该工作项分配给资源。

 

图 5-26

如图5-26所示，任务B已经激活且已生成可以执行工作项，但是系统并没有将其分配至员工甲的工作项列表里。这是因为员工甲正在执行任务A的工作项，直到其执行任务A完毕，系统才会把任务B工作项推送至工作项列表。

 

应用

保证流程和资源对工作的负载处于一种良好的状态，避免出现下图的情况：

 

图 5-27

在敏捷开发里，我们强调客户合作，整个的开发过程对用户透明，用户知道当前正在进行的开发工作，也清楚开发团队的开发速度，在这种情况下，一旦有新的需求加入，用户会推迟该需求的实现，或者推迟当前其他需求的实现，从而保证整个团队的开发效率。

 

实现

该模式的实现依赖于推后的策略，即在什么情况下推后分配，满足什么条件下进行分配。具体实现同样采取推后模式，推后到实施阶段实现。

 

四、拉模式

与推模式相比，拉模式的区别在于动作的主语发生了变化：推模式的主语是系统，由系统将工作项推送至资源的工作项列表，那么，接下来的主动权交由单个资源本身，由其拉动工作项的执行。

 

图 5-28

如图5-17所示，拉模式对应着工作项的五种状态变迁：

由提供给一个资源拾取到指派给一个资源负责执行，这意味着该资源拾取了该工作项，其将负责该工作项的执行，并将在未来的某个时候执行该工作项；

由提供给多个资源拾取到指派给一个资源负责执行，这意味着多个资源中的一个资源拾取了该工作项，其将负责该工作项的执行，并将在未来的某个时候执行该工作项，余下的资源将不再有机会执行该工作项；

由提供给一个资源拾取到开始执行，这意味着该资源拾取了该工作项，其将负责该工作项的执行，并立即开始执行该工作项；

由指派给一个资源负责执行到开始执行，这意味着该资源开始执行该工作项；

由提供给多个资源拾取到开始执行，这意味着多个资源中的一个资源拾取了该工作项，其将负责该工作项的执行，并立即开始执行该工作项，余下的资源将不再有机会执行该工作项；

拉模式共有6种，分为两组：前三种模式关注工作项的状态变迁；后三种模式关注工作项显示在资源工作项列表里的顺序以及选择执行的方式。

 

1、资源驱动指派（WRP_21: Resource-Initiated Allocation）

描述

资源能够将工作项指派给自己，负责该工作项的执行，但是不必马上开始执行该工作项。

 

图 5-29

如图5-29所示，员工甲拾取了可拾取列表里的任务A工作项，该工作项由可拾取列表移至待办列表。可拾取列表通常是一个共享的列表，而待办列表则是某一资源的专属列表。资源拾取工作项，意味着工作项从共享状态进入到专属状态。

该模式实际对应着工作项的两种状态变迁：由提供给一个资源拾取到指派给一个资源负责执行；由提供给多个资源拾取到指派给一个资源负责执行。

 

应用

该模式符合大多数的工作场景，我选择负责执行该工作，但我并不马上开始，我可能还有其他的工作需要处理，等到处理完毕后才处理该工作。

 

实现

分配给角色、部门等资源组的工作项通常都以共享的形式分配给所有的组内成员，一旦有人拾取即进入他的专属待办列表，其他人不再可见。

 

2、资源驱动执行-指派工作项（WRP_22: Resource-Initiated Execution – Allocated Work Item）

描述

资源能够开始执行指派给其的工作项。

 

图 5-30

如图5-30所示，员工甲开始执行任务A工作项，该工作项由待办列表移至办理列表。

该模式对应着工作项的一种状态变迁：由指派给一个资源负责执行到开始执行。

 

实现

最基本的工作项状态变迁，所有的工作流系统都提供支持。

 

3、资源驱动执行-提供工作项（WRP_23: Resource-Initiated Execution – Offered Work Item）

描述

资源能够选取提供给其的一个工作项，并马上开始执行该工作项。

 

图 5-31

如图5-29所示，员工甲拾取了可拾取列表里的任务A工作项并立刻开始执行，该工作项由可拾取列表移至办理列表。

该模式对应着工作项的两种状态变迁：由提供给一个资源拾取到开始执行；由提供给多个资源拾取到开始执行。

 

应用

与描述略有不同，实际应用该模式是强制要求资源一旦拾取了共享的工作项就必须马上开始执行，基于两点的考虑：一是工作项能够尽快执行；二是工作项能够指派给当前最为空闲的资源，不会出现该工作项被一繁忙资源卡住，造成等待和阻塞。

在敏捷开发里，我们使用故事卡管理项目的开 发，故事卡足够小（如果大的故事卡则分解为多个任务），每天早上由开发人员挑选移动该卡，一旦该卡由可开发状态移动至开发状态，则必须进行该卡的开发工 作，这样项目的真实进展随时得到显示，同时不允许一个开发人员同时进行多张卡的开发。

 

实现

通过这三个模式我们可以发现，工作流系统实现这些模式只是在不同的工作项列表里移动这些工作项，以反映工作项不同的状态和变迁策略，这对于IT系 统而言这不是很困难，困难在于如何能保证人确实是这么做的，例如说一旦拾取就必须开始执行，工作项的跳转很简单，但无法保证的是拾取该工作项的人一定会按 照要求马上开始执行该工作项，也就是说业务流程项目的实施不仅仅包含技术实施，也包含了一套与之相应的管理实施。那种期望上一套流程系统就能马上提高生产 效率和管理水平显然是不现实的，其中一定包含管理方式的变化和组织机构的变化。

敏捷开发中，早上的站立会议是重要的部分，每个团队成员都会汇报昨天的进展和今天将要进行的工作，这样就保证了工作执行的有效性。

 

4、系统决定工作队列内容（WRP_24: System-Determined Work Queue Content）

描述

工作流系统能够排定资源工作项列表里的工作项顺序和内容。

 

图 5-32

如图5-32所示，员工甲共享的可拾取列表默认按时间排序工作项。

 

应用

实际应用中工作项的排序条件非常多，其目的就是将最重要或优先级最高的工作项排在最前面，引起资源的注意或优先执行。

 

实现

实际实现时有多种排序策略，通常会有时间排序，例如先进先出、先进后出等，同时也有很多其他的排序元素，例如工作项的预定完成时间、执行该工作项的成本预算、工作项的优先级或重要程度等，系统查询工作项时根据这些影响因素进行默认排序。

 

5、资源决定工作队列内容（WRP_24: Resource-Determined Work Queue Content）

描述

资源能够排定其工作项列表里的工作项顺序和内容。

 

应用

为资源提供一定程度上排定工作项的灵活性。每个人关注的视角和侧重点不同，就会产生不同的排序和内容过滤。

例如，作为老板，我可能更为关注各个工作的成本预算，我需要按成本排定各项工作；而作为秘书，我更为关注老板下发各项工作的重要程度，我需要按老板指定的重要程度排定工作。

 

实现

提供工作项列表的客户端排序，一般情况下列表显示系统给定的顺序，用户可以在客户端进行二次排序，典型的Web系统中，工作流系统提供JavaScript的表格控件，利用Ajax异步请求重新排序或进行工作项的过滤。

 

6、自主选择（WRP_26: Selection Autonomy）

描述

资源能够根据自己个人的情况选择执行工作项。

 

图 5-32

如图5-32所示，员工甲能够根据自己的情况选择执行任务A、B、C中任意一个工作项。

 

应用

尽管老板要求先实现功能最后再重构，但是我认为当前代码如果不进行一定重构会严重影响后续的开发效率，所以我决定先进行部分重构。

 

实现

几乎所有工作流系统都不会对用户实际选择执行工作项的方式进行限制，也没有办法限制。但是系统一般会把重要的工作项加以高亮显示，让用户优先选择。

评论

5 楼 whaosoft 2009-11-06  

讲的很好，工作流刚开始看，谢谢。

4 楼 xinnn 2009-11-06  

都想了老久老久，麻木了

3 楼 joknm 2009-11-05  

楼主说得很精辟，对于怎样任务发放和任务接收一头雾水的我茅塞顿开。
本人以前只想到用命令模式来去做。呵呵。

2 楼 ronghao 2009-11-05  

期待楼上的分析。
其实我的感觉是：这些模式了反映工作项不同的状态和变迁策略，这对于IT系统而言这不是很困难，困难在于如何能保证人确实是这么做的，例如说一旦拾取就必须开始执行，工作项的跳转很简单，但无法保证的是拾取该工作项的人一定会按照要求马上开始执行该工作项，也就是说业务流程项目的实施不仅仅包含技术实施，也包含了一套与之相应的管理实施。那种期望上一套流程系统就能马上提高生产效率和管理水平显然是不现实的，其中一定包含管理方式的变化和组织机构的变化。

1 楼 firebody 2009-11-04  

<div class="quote_title">对于楼主的专业分析，我表示敬意。 </div>
<div class="quote_title">在我做的很多系统里面很多业务场景分析确实很吻合楼主提出的这几种模式，不过很有意思的是，同一个问题会有不同的名词表述：</div>
<div class="quote_title">比如lz提到的“ 待拾取列表“，这个名词有点“怪异”， 我们一般称之为“待签收”或者“待确认”任务列表。 </div>
<div class="quote_title">“待签收”的任务需要某个用户自己去签收，然后变成我自己的“待办”事宜。  </div>
<div class="quote_title">另外lz提到的大多数场景其实都可以用简单的工作流的模式组合来实现。 下面我用我做的工作流引擎结合楼主提到的每一个场景给出具体的例子分析，来表用工作流实现这些业务，其实是多么简单。 </div>
<p> </p>