Given-When-Then的悲劇。 | IT風險經理

1. 系統是什麼樣的。
2. 系統中的計算以及所需的資料。
3. 系統的行為基於其內部狀態，以及系統內部和外部的系統互動。

傳統工具
在網際網路之前，使用者體驗被認為沒什麼價值，因為大多數系統使用者都是公司的內部員工。如果他們想要完成他們的工作，就別無選擇地使用這些系統。
這意味著低保真原型主導了人們描述系統外觀的方式。有些人使用visio或powerpoint來建立這些原型。由於建立原型的速度以及我的同事對Excel的熟悉程度，我的偏好是Excel；

然後使用業務領域模型描述資料和計算。使用Rational Rose之類的工具進行資料和計算的抽象描述；使用用例usecase描述系統與外部參與者（人和其他系統）的互動。
這些都沒有標準格式，但每個人都受到Alistair Cockburn的“只要能寫出有效用例即可”的影響：

傳統的分析世界是系統資料，而“計算和行為”這些抽象描述用於系統開發。

真實客戶和示例規範
網際網路開始將真正的客戶暴露給軟體公司，客戶可以自由選擇使用服務。因此，使用者體驗（研究和設計）已成為產品開發和系統設計的重要組成部分。低保真原型已經被高保真原型所取代，這些原型在軟體開發開始之前就已經與真實客戶進行了測試。高保真原型現在是系統規範的一部分，有時具有畫素級精度。
網際網路時間意味著快速、交貨時間短。較短的交付週期需要自動化測試，並導致測試驅動的開發。自動化測試意味著需要“透過示例進行規範”以滿足測試驅動的開發需求。
這就不是使用Rational Rose來表達抽象域模型，而是使用電子表格中表達資料和計算，並使用相關的正式計算定義。
2003年，Sanela Hozic和我使用電子表格，用例子來說明石油交易的信用風險計算。這是由Andy Pols和Joe Walnes在原型中實現的。2007年，我們使用包含示例的電子表格來指定複雜信用衍生產品的現金流量計算。這些示例與測試人員共同建立，並由通常計算現金流量的交易助手進行驗證和新增。這些示例是使用JUnit實現的。2010年，Nat Pryce和團隊建立了一個基於spredsheet的生態系統。

抽象用例和狀態轉換圖已被Given-When-Then格式的示例所取代。usecase用例的一個缺點是，該方法不鼓勵業務分析師探索替代路徑，這導致了“快樂路徑”的心態。Given-When-Then格式的重點允許業務分析師建立“快樂路徑”場景，然後舉行“三個Amigoes”會話以探索“質量路徑”（假定波動性市場資料缺失）和“技術路徑” “（假定伺服器不可用）。

Given-When-Then的悲劇之一：
如果莎士比亞寫過一部關於“Given-When-Then”的劇本，那麼他可能已經開始使用“當你擁有的所有東西都是錘子時，世界似乎是由釘子製成的”。
儘管Given-When-Then是描述互動，狀態和行為的絕妙方式，但使用者描述資料和計算卻是一種糟糕的方式。一個常見的反模式是Given-When-Then用於描述資料和計算：

• Give給定一組表中的市場資料和交易
• When當<執行諸如計算的任意事件>時
• Then那麼，<基於輸入的資料將被計算並被儲存到資料表中>

Given-When-Then的悲劇之二：
與Given-When-Then相關的常見反模式有三個角色在使用者故事中儲存為驗收標準的場景上進行協作。然後，測試人員將這些Given-When-Then場景轉換為Cucumber格式的特徵檔案。這與開發並行發生，而不是在開發之前。將測試者降低為專業翻譯/打字員是一個悲劇。這意味著業務分析師不一定會看到實際的Given-When-Then語句，並且它們與測試人員和開發人員之間會發生斷開連線。Cucumber被視為一種測試自動化工具，而不是系統規範的儲存庫。

Given-When-Then的悲劇之三：
業務分析師和測試人員/開發人員之間的脫節反映在Given-When-Then社群中。業務分析師通常不會看到功能檔案，也不會完全理解該過程。他們認為Cucumber沒有價值，將其視為測試自動化工具。
為了填補這個空白，開發人員建立了對開發人員有吸引力的流程，這是開發人員告訴業務分析師他們認為業務分析師應該如何完成工作， 事件風暴和示例對映在培訓課程和會議中很受歡迎。它們是有趣，積極的促進過程。它們易於學習和顯而易見，但創造了複雜的結果。他們也無法滿足業務分析師的需求，他們本質上是在複雜的文件編制和定義複雜系統的空間中運作。業務分析需要應用結構化學習技術，這需要學習和實踐掌握。

悲劇是，Given-When-Then已經創造了一個更大的空白。

敏捷是那些學習“做並幫助別人去做”的人建立的，除了業務分析的情況，開發人員也做了業務分析師應該做的事情......是觀察員，而不是行動者在定義過程與流程。

Given-When-Then的悲劇：結局
理想情況下，我們將意識到Given-When-Then是一個用於描述系統的互動，狀態和行為的工具。我們將意識到使用Given-When-Then格式描述資料和計算會導致悲劇，應該使用Excel來記錄示例。
Given-When-Then社群將聯絡業務分析社群，傾聽，傾聽他們的問題，傾聽他們的需求。他們將放棄他們預先設想的解決方案，併合作建立工具，彌合業務分析師和開發團隊之間的溝通差距。
當我們擁有一把錘子時，我們會發現世界不只是釘子而已。