唐僧與 QA MM

在一個典型的項目團隊里，包括了以下幾種角色（帽子）： PM（項目經理）、 BA（業務分析師）、 DEV（程序開發者）和 QA（質量保證人員），整個團隊的目標是向客戶交付價值。

那么，有一天， QA MM來找我，我是開發人員。 MM說，一張圖片沒有正常顯示，我想知道原因，同時想知道你能否修復。我的第一想法是，這不可能，一定是環境的原因。我說，好的，稍等。接下來，我張大嘴巴看到了 MM給我重現的 BUG：本該顯示圖片的位置一片空白，就像此時我合不上的嘴。這怎么可能呢？我想，這個功能完成的如此之得意，以至于測試用例里的數據都是以我的名字命名的。

幾分鐘后，或者更長，我叫來 MM，說，找到原因了。

我打開編輯器，光標在源程序的某一行閃爍，我說，最根本的原因在這里。我看到 MM的眼中閃過一絲迷茫。接下來，我卻換到另外一個源文件，光標繼續閃爍，我說，這里的程序因此受到影響。看得出， MM有點發暈。終于，當我打開第 N個源文件并試圖繼續講解時， MM昏過去了。

當 MM蘇醒過來時，我在她清澈的雙眼中看到了一只清晰的唐僧。

MM肯定感到了不好意思，因為我的講解中包含了比喻、類推、排比等我力所能及的各種語文知識，看得出，我很努力，我的語文老師也很努力，所以她委婉地說，能不能簡單一點？

我想了想，說，測試驅動時測試數據不全導致程序少考慮一種情況。

MM說，能修復嗎？

我說，可以。于是故事結束。

就 是這樣，當我們執行一項任務時，圍繞這項任務必然會產生許許多多的信息，這些信息對于該任務的執行者是必須的，但是對于其他人則不是，有效的溝通往往來自 于簡練的表達即只表達對方需要和可以理解的內容，浩瀚的細節只會將真正想表達的內容淹沒。其實這里還有這樣一層意思：我之所以用這么多的細節信息來淹沒 QA，實際上是不太情愿承認程序里有 BUG。 QA想要的結果很簡單，是否是程序 BUG，能否修復。而開發人員則往往把自己的程序與自己關聯在了一起，認為程序是自己的擴展，程序有 BUG則意味著自己有缺陷。這一關系明顯是矛盾的，可是一些團隊里開發人員和 QA能夠和平相處，而有些團隊卻勢如水火。

那么，對于單個任務而言，需要定義自己的變量，這些變量數據只與該任務相關，只在該任務里可見。典型的工作流應用于任務執行期間的中間數據存儲。在文檔處理中，一個重要的功能就是需要提供版本管理，在單個任務實例里，辦理者能夠管理自己處理過的文檔版本。

描述

任務能夠定義變量，在一個流程實例里，該變量只能被其任務實例所使用。

圖 6-2任務級別的數據可見性

如圖 6-2所示，我們在任務 B上定義了一個變量 M，此時，在一個流程實例里，只有任務 B的實例才能使用該變量。

實現

存在兩種實現方式，一種是如圖 6-1所示的，在任務節點定義中聲明變量，運行期初始化任務實例的同時初始化該變量并使用； 另一種是在流程定義級別統一聲明變量，但是各個任務實例都獨立初始化并存儲該變量。第二種實現方式在各個任務都需要使用同一語義的變量時很常見，例如各個任務實例都會有參與者，我們在流程定義時聲明一個名為 userid的變量，在流程實際執行時，各個任務實例都會獨自保存有自己的 userid數據。