簡介
ATDD和工具如FitNesse, Cucumber, and Robot Framework的使用使得有必要創建自動化驗收測試。這些驗收測試是用在用戶故事中的驗收標準的一個自然延生。你使用驗收測試去了解需要開發哪些需求，這樣你才能開發正確的功能。爲了開發正確的功能，你需要在所有團隊成員中創建關於利益相關者的共識。你使用故事工坊（Scrum中的產品積壓細化會議）這樣每個人都可以爲發現故事的whys, hows, and whats盡一份力。你把大故事劃分爲小故事（又名用戶故事），和你的利益相關者一起在這些工坊中創建新的用戶故事。和你的利益相關者一起創建共識有以下好處：
1. 你更有可能想出一個能真正提供商業價值的解決方案。緊密協作讓你瞭解預期結果。你明白爲什麼爲何要創建該功能以及其商業價值是什麼。
2. 你可以更好地開發正確的解決方案。你從客戶的角度理解了需求和問題後一心專注於解決方案。沒有這樣的理解，敏捷只能幫你更快地創建錯誤事物。
3.你的從找出缺陷到在商業價值和開發層面阻止缺陷的心態和做法轉變。記住，從精益的角度，找缺陷是一種浪費。
4.你能在明確驗收測試裏寫下何謂成功開發一個用戶故事。你只開發需要的——不多不少。故事工坊不僅要創建共識和驗收測試用例，還要爲整個團隊提供測試機會。測試用例可以自動化，所以開發員要和測試員一起合作。測試用例需要充實並添加新用例，現在任何人都可以做到。共識也爲你安排和你的團隊一起定義探索性測試章程。而且你也知道，只要有經驗豐富的測試員指導，人人都可以執行手動測試。那還蠻有意思的。但是你怎樣才能真正運行成功的故事工坊呢？需要哪些步驟，你能玩哪些遊戲？你該如何推動會議？
本文中，我們將告訴你我們該如何使用嚴肅遊戲做故事工坊。
嚴肅遊戲是什麼？
如果像我們一樣，你參加了由一些人主宰，無聊且無用的會議，參與其中只會感覺痛苦。你只出現說了幾句話，因爲這正是管理層希望你去做的。其實並不一定非得那樣。你可以在你所有的會議中使用遊戲機制讓它們更有趣且更有益多產。會議成功的方法是通過嚴肅遊戲。
嚴肅遊戲是一個設計來解決業務問題的遊戲。一款“尋常”遊戲的目的是娛樂。嚴肅遊戲中，你使用讓全世界玩“尋常”遊戲數以百萬的人蔘與其中的遊戲機制。嚴肅遊戲將人們放入一個他們真正參與其中並相互協作的創造性的環境之中，移動周圍的事物並討論觀點。你可以使用嚴肅遊戲的地方就是在故事工坊裏瞭解利益相關者需求，明確用戶故事並提煉測試用例。
故事工坊是什麼？
故事工坊的預期結果是建立整體團隊對用戶故事的共識並使之變爲合適的規模。你通過探討爲什麼需要他們，他們爲客戶解決了什麼問題建立一個共識，以及通過提煉測試用例建立共識。故事工坊的輸出有：
1.我們希望每個需要精煉的用戶故事都有兩至三個例子。
2.我們希望每個需要精煉的用戶故事都有一個明確的探索性測試章程。
3.我們想評估規模來進行權衡。
4.我們想評估故事將對預期商業價值造成的影響。
精益會議的恰當的時間空當是一至兩個小時。儘管因爲帕金森定律這種情況基本很少發生，但如果完成地早，你可以隨時結束會議。故事工坊中你應對的第一個問題就是更好地理解用戶故事。用戶故事是對特定人物需求的敘述。你需要了解人們有什麼問題和需求。這是一個發現問題。需要回答的問題是：“客戶有哪些問題，爲什麼他/她要解決這個問題？”故事工坊中你應對的另一個問題是設計問題。用戶故事也是一個對開發必須設計的解決方案的 實驗。因此需要回答的問題是：“最適合客戶需求的解決方案是什麼？”設計的準確細節不是由故事工坊提供的，但它的確開始瞭解決方案的思維過程。最後是一個是測試問題。需要回答的問題是：
1.我們如何得知解決方案解決了客戶的問題？我們的解決方案的價值超過他/她現有的解決方案嗎？
2.我們如何得知我們在解決正確的問題？我們正在解決的問題是客戶想讓我們解決的問題嗎？
3.我們如何得知我們已經正確地解決了問題？我們如何確定解決方案的成功和失敗數呢？
在故事工坊中我們試着解決所有這些問題。
如何推動故事工坊
如果你想要一個成功的工坊，你就需要考慮一些事情。首先你需要申明工坊的目標。爲了讓人們參與其中，在會議一開始就申明目標很重要。接下來你需要明確地探討你工坊的步驟。那麼議程是什麼，我們要做什麼？然後你必須定義工坊的規則。手機鈴聲怎麼規定？工坊裏可以看郵件嗎？交談中打斷別人怎麼辦？如果你已經和團隊做了一些工坊，你只要快速記下他們的規則並問問他們是否滿意。爲了提高創造力，任何事都是有時間限制的，所以你想交流時間限制。工坊裏你也想告知團隊時間進度。比如你可以每10-15分鐘讓他們知道還剩多少時間並討論你是否仍在做最重要的事情。最後，擁有一個停車場很有用。如果你有任何佔用太多時間或不相關的問題，你可以將它們放在停車場並在會議最後覆蓋它們。
一個成功故事工坊的遊戲順序
在一個提煉測試用例來建立共識的故事工坊中，你要執行下列步驟：
1.登記：解釋會議的目標和議程。
2.瞭解商業價值：產品負責人講述了有目標的一系列連貫的故事（如果你在使用Scrum就是迭代目標）並將它們與經營目標相連接。團隊討論了“爲什麼我們在做這個？”我們使用影響圖和5個爲什麼做這件事。
3.瞭解客戶價值：團隊分成兩個子團隊，每個子團隊得到一半的用戶故事。子團隊聚在一起探討他們各自創建的場景。團隊探討“爲什麼人們想要這個？”我們使用故事板和人才流入圖做這件事。這也是你量化你的目標的步驟，這樣你就能在迭代最後知道你創造了多少價值。
4.提煉驗收測試：團隊爲用戶故事創建驗收測試。根據你的工具，你用Gherkin規格，流程表和決策表創建用戶故事敘述。團隊分成子團隊，與產品負責人一起寫表格和Gherkin場景。子團隊聚在一起探討結果。我們使用表格和場景編寫在白板上做這個。
5.定義探索性測試章程：明確你的探索性測試的風險。一旦你明確了需要手動測試的故事，你就爲每一個故事設置一個探索性測試章程。我們使用一個風險影響矩陣做這件事並使用探索性測試來驅動我們的測試。
6.關閉：結果和最終評論的快速彙總。
上述遊戲順序只是運行故事工坊的一種方法。假設你已經有了隨時可以開始的用戶故事。解釋的遊戲是我們花費最多時間的遊戲。還有許多遊戲你可以使用。我們鼓勵你在你的工坊裏嘗試一些探討哪一個最適用於你的特定情況。
版權聲明：本文出自 SPASVO澤衆軟件:http://www.spasvo.com/news/html/201586161231.html
原創作品，轉載時請務必以超鏈接形式標明本文原始出處、作者信息和本聲明，否則將追究法律責任。
