三、推模式

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

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

图 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

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

实现

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

http://www.blogjava.net/ronghao 荣浩原创，转载请注明出处：）