三、推模式
在創(chuàng)建階段,系統(tǒng)根據(jù)不同的創(chuàng)建模式為任務(wù) 節(jié)點產(chǎn)生了一個或多個工作項,每個工作項或分配給單個資源或分配給角色、部門等。那么接下來,系統(tǒng)就需要將這些工作項推送給相關(guān)的資源進行執(zhí)行,這個推送 的過程即是推模式所包含的內(nèi)容。需要注意的是,推模式討論的是對單個工作項的推送。
在前面我們已經(jīng)了解到,工作流系統(tǒng)通過工作項管理器即不同類型的工作項列表與用戶進行交互,這里的推送也可以理解為系統(tǒng)將生成的工作項推送至相應(yīng)資源的工作項列表里。
圖 5-17
如圖5-17所示,推模式對應(yīng)著工作項到三種狀態(tài)的變遷:提供給一個資源拾取執(zhí)行;提供給多個資源拾取執(zhí)行(這些資源中只會有一個會實際執(zhí)行,屬于競爭關(guān)系);指派給一個資源負(fù)責(zé)執(zhí)行。
推模式共有9種,分為3組, 第一組包括提供給單個資源、提供給多個資源和指派給單個資源,討論工作項推送的最終分配狀態(tài);第二組包括隨機指派、循環(huán)指派和最短隊列指派,關(guān)注當(dāng)工作項 分配給角色、部門等包含多個資源的資源組時,如何從中確定最終的一個資源并進行指派;第三組包括提前分配、即時分配和推后分配,關(guān)注將工作項推送給用戶的 時間。
1、提供給單個資源(WRP_12: Distribution by Offer - Single Resource)
描述
能夠在非綁定的基礎(chǔ)上將工作項推送給單個資源。
圖 5-18
如圖5-18所示,任務(wù)A工 作項被系統(tǒng)推送至員工甲的可拾取列表。這意味著員工甲不必為該工作負(fù)責(zé),他可以選擇執(zhí)行該工作也可選擇忽略或拒絕。如果他選擇拒絕或忽略且工作項超時,那 么會導(dǎo)致系統(tǒng)對該工作項的重新分配。如果他選擇執(zhí)行該工作,那么他首先需要拾取該工作項,這會使該工作項進入他的代辦列表,意味著其必須對該工作負(fù)責(zé)。
應(yīng)用
該模式類似于現(xiàn)實工作中的征求意見,先將工作分配給你,然后找你談話,征求你對該工作的看法,如果合適那么就由你執(zhí)行,否則再找他人執(zhí)行。
實現(xiàn)
參與者對工作項的拒絕會導(dǎo)致系統(tǒng)對工作項的 重新分配,這是實現(xiàn)該模式的難點。如何重新分配該工作項,采取何種重新分配策略,這些都具有很大的復(fù)雜性。實際上這些工作流模式單個看起來可能比較清晰明 了,但一旦組合起來,例如該模式與創(chuàng)建模式結(jié)合起來,那么就有了多種情況變得復(fù)雜起來。對于復(fù)雜的問題,最好的解決辦法就是留給實施階段,由用戶情況作出 使用限定。這也再次強調(diào)了工作流實施在工作流應(yīng)用中的重要性。
2、提供給多個資源(WRP_13: Distribution by Offer – Multiple Resource)
描述
能夠在非綁定的基礎(chǔ)上將工作項推送給多個資源。
圖 5-19
如圖5-19所示,任務(wù)A所 生成的工作項被推送給多個員工的可拾取列表。這些員工不必為該工作負(fù)責(zé),他們可以選擇執(zhí)行該工作也可選擇忽略或拒絕。如果他們都選擇拒絕或忽略且工作項超 時,那么會導(dǎo)致系統(tǒng)對該工作項的重新分配。如果有一名員工選擇執(zhí)行該工作,那么該工作項進入他的代辦列表,其他員工將不再具有拾取該工作項的機會。
應(yīng)用
該模式是典型的競爭參與,即多人可以完成該工作,先執(zhí)行者先得。類似于尋找志愿者。
實現(xiàn)
該模式的實現(xiàn)一般是創(chuàng)建階段將工作項分配給角色、部門等包含多個資源的分組,在推送階段,將該工作項送至這些組下所有資源共享的可拾取列表里,工作項的實例只有一個,但是多資源可見。
3、指派給單個資源(WRP_14: Distribution by Allocation – Single Resource)
描述
能夠在綁定的基礎(chǔ)上將工作項推送給單個資源。
圖 5-20
如圖5-20所示,任務(wù)A工作項被系統(tǒng)推送至員工甲的待辦列表。這意味著員工甲必須為該工作負(fù)責(zé)。
應(yīng)用
該模式是應(yīng)用最多的模式,直接指定任務(wù)的負(fù)責(zé)人。
在采用軍事化管理的企業(yè)里,上級的命令一定要執(zhí)行,下屬沒有商量和拒絕的權(quán)利。
實現(xiàn)
相比提供,指派實現(xiàn)非常容易,直接將工作項推送至選定資源的待辦列表。
4、隨機指派(WRP_15: Random Allocation)
描述
當(dāng)存在多個資源可供選擇時,從中隨機選擇一個資源進行工作項的指派。
圖 5-21
如圖5-21所示,任務(wù)A所生成的工作項在創(chuàng)建階段分配給了開發(fā)人員這一角色,在推送階段,系統(tǒng)會隨機選取一名開發(fā)人員負(fù)責(zé)該工作項的執(zhí)行。
應(yīng)用
該模式提供了一種指派資源的非確定性機制。
5、循環(huán)指派(WRP_16: Round Robin Allocation)
描述
當(dāng)存在多個資源可供選擇時,循環(huán)選擇其中一個資源進行工作項的指派。
圖 5-22
如圖5-22所示,任務(wù)A所生成的工作項在創(chuàng)建階段分配給了開發(fā)人員這一角色,在推送階段,系統(tǒng)會循環(huán)輪流選取一名開發(fā)人員負(fù)責(zé)該工作項的執(zhí)行。
應(yīng)用
不患貧而患不均,平等的分配工作。
6、最短隊列指派(WRP_17: Shortest Queue)
描述
當(dāng)存在多個資源可供選擇時,選擇其中一個具有最少待辦工作即最短工作隊列的資源進行工作項的指派。
圖 5-23
如圖5-23所示,任務(wù)A所生成的工作項在創(chuàng)建階段分配給了開發(fā)人員這一角色,在推送階段,系統(tǒng)發(fā)現(xiàn)員工甲的待辦列表里有兩條待辦工作(任務(wù)B和任務(wù)C),員工乙的待辦列表里沒有待辦工作,所以系統(tǒng)將任務(wù)A工作項指派給員工乙負(fù)責(zé)該工作項的執(zhí)行。
應(yīng)用
該模式的目的在于能夠最快開始工作的執(zhí)行,找出相比而言最為空閑的資源迅速開始工作。但是實際應(yīng)用中,僅僅依靠工作的數(shù)量來判斷資源是否空閑是不可靠的,因為工作和工作之間還存在著難易之分。
7、提前分配(WRP_18: Early Distribution)
描述
在工作項實際可以執(zhí)行之前即將該工作項通知或潛在的分配給資源。
圖 5-24
如圖5-24所示,任務(wù)A還在執(zhí)行,任務(wù)B還未激活,但此時任務(wù)B的工作項已經(jīng)提前分配給員工甲,該工作項的主要職責(zé)是通知員工甲將由其來完成任務(wù)B并能開始一部分準(zhǔn)備工作,而實際的工作則要等到任務(wù)B被激活后才能進行。
應(yīng)用
該模式強調(diào)的是預(yù)先計劃,即管理的計劃性。
在我們實際的項目開始之前,項目經(jīng)理已經(jīng)通知我們將要進行的開發(fā)工作,讓我們提前熟悉相關(guān)的技術(shù)。這樣當(dāng)項目開始時就能提高最初迭代的開發(fā)效率。
從某種意義上說,稍微復(fù)雜一點的工作都應(yīng)該做到提前通知、提前準(zhǔn)備,即計劃的必要性。
實現(xiàn)
讓工作流系統(tǒng)直接支持該模式比較困難,因為該模式嵌套在控制模式和不同的工作項創(chuàng)建模式里,找不出一種通用的模式,無法預(yù)判工作項的生成和實際的參與者。在一定范圍內(nèi),可以采用下面的方式變通:
圖 5-25
如圖5-25所示,在自動節(jié)點執(zhí)行時能確定任務(wù)B的參與者的情況下,可以通過自動節(jié)點給員工甲發(fā)送郵件或消息進行通知,工作流系統(tǒng)并不生成工作項。
8、即時分配(WRP_19: Distribution on Enablement)
描述
在工作項實際可以執(zhí)行時將該工作項分配給資源。
應(yīng)用
機器執(zhí)行的工作,重復(fù)單一的審批工作,無計劃性的工作,如各種突發(fā)情況的處理。
實現(xiàn)
大多數(shù)工作流系統(tǒng)的標(biāo)準(zhǔn)實現(xiàn),滿足任務(wù)執(zhí)行條件時先激活任務(wù)節(jié)點,然后創(chuàng)建工作項、分配工作項。
9、推后分配(WRP_20: Late Distribution)
描述
在工作項實際可以執(zhí)行后的某個時間才將該工作項分配給資源。
圖 5-26
如圖5-26所示,任務(wù)B已經(jīng)激活且已生成可以執(zhí)行工作項,但是系統(tǒng)并沒有將其分配至員工甲的工作項列表里。這是因為員工甲正在執(zhí)行任務(wù)A的工作項,直到其執(zhí)行任務(wù)A完畢,系統(tǒng)才會把任務(wù)B工作項推送至工作項列表。
應(yīng)用
保證流程和資源對工作的負(fù)載處于一種良好的狀態(tài),避免出現(xiàn)下圖的情況:
圖 5-27
在敏捷開發(fā)里,我們強調(diào)客戶合作,整個的開發(fā)過程對用戶透明,用戶知道當(dāng)前正在進行的開發(fā)工作,也清楚開發(fā)團隊的開發(fā)速度,在這種情況下,一旦有新的需求加入,用戶會推遲該需求的實現(xiàn),或者推遲當(dāng)前其他需求的實現(xiàn),從而保證整個團隊的開發(fā)效率。
實現(xiàn)
該模式的實現(xiàn)依賴于推后的策略,即在什么情況下推后分配,滿足什么條件下進行分配。具體實現(xiàn)同樣采取推后模式,推后到實施階段實現(xiàn)。
http://www.tkk7.com/ronghao 榮浩原創(chuàng),轉(zhuǎn)載請注明出處:)