團隊活動/遊戲，用於說明SCRUM環境中的設計

我正在爲我的一些Scrum團隊尋找團隊建設/培訓活動。我希望能夠真正體現團隊在實施故事時具有的靈活性，以確定功能本身的範圍和複雜性。大多數團隊都具有長期的瀑布經驗，習慣於擁有明確的規格。我正在尋找一些東西，說明團隊需要根據可用的時間和資源來改變他們自己構建的範圍。團隊活動/遊戲，用於說明SCRUM環境中的設計

我在tastycupcakes.com找不到任何東西，谷歌沒有太多幫助。也許有人已經準備好了自己願意分享的東西？

編輯（在響應評論請求。例如）

假設團隊致力於建設一個故事，在用於分析的目的分頁列表中顯示的數據給用戶。驗收標準可以很容易地實現，但是不同的實現可能提供附加的功能，例如，包裝內置排序和分組功能的第三方控件。關鍵是，由於scrum時間窗口是絕對固定的，如果團隊認爲他們比計劃提前，那麼實施的範圍可能會被推高，特別是如果某些技術設計證明問題少於思想。相反，如果某些任務花費的時間比預期的長，團隊可以簡化用戶故事，同時確保他們提供的內容滿足驗收標準。

我試圖脫離的東西是目前的思維方式，該功能有一個規範，並且無論環境如何都將構建。

來源

2010-05-27 njr101

請將帖子限制爲有關編程的問題（請參閱http://stackoverflow.com/faq） – danben 2010-05-27 15:51:37

此問題沒有任何問題。 – DancesWithBamboo 2010-05-27 20:04:30

您能否舉例說明您在團隊中定義故事的權利？ – DancesWithBamboo 2010-05-27 20:09:30

我想我找到了你要找的東西，但是如果我錯了，隨時澄清。我對你正在尋找的一個練習印象深刻，它將顯示團隊在使用用戶故事時的實施細節的靈活性。

如果是這樣，請嘗試像這樣的練習。

將團隊拆分爲兩個團隊，並在他們之間擁有相同的產品負責人（或者如果兩個團隊都知道該練習，則可以爲每個團隊設置一個產品負責人）。

PO提供了一個虛構的故事：「作爲BigSales Co的一名執行官，我希望能夠一眼就能看到哪些銷售人員正在執行哪些操作，哪些不是，表演者改善整體團隊表現。「

像上面這樣的故事在實施細節上很簡單，但有一個非常明確的業務問題需要解決（作爲用戶故事應該）。使用這樣的故事，給團隊30分鐘的時間來完成一個滿足用戶故事的紙質原型。在這段時間內，他們可以根據需要與PO進行互動。參加採購訂單的人員應當小心，不要給他們實施細節，而是讓他們去團隊決定，同時表達和澄清業務需求。

在30分鐘結束時，讓每個團隊展示他們的解決方案並解釋如何滿足用戶故事。

這裏重要的是，一旦兩個團隊都出現了，這兩個演示文稿可能會有很大的不同，但都是有效的。這顯示了團隊具有的靈活性水平，無需明確告訴他們該做什麼，他們就可以提供他們認爲最佳的解決方案。

希望這會有所幫助。

來源

2010-06-09 06:41:16

託德，這正是我的意思。我喜歡這個練習的想法。我可能會用兩個PO來做，否則我認爲一個PO可能會推動兩支球隊朝同一個方向發展。我認爲你是對的，「實施」可能看起來非常不同，同時仍然解決業務問題。謝謝你。 – njr101 2010-06-09 12:25:24

我不認爲這是由團隊來定義一個故事的範圍和複雜性。定義接受條件是項目採購的工作，然後根據採購訂單的描述估算規模是團隊的工作。如果故事的大小合適，那麼條件通常會相當嚴格。這可能是爲什麼你沒有看到太多在那裏....

編輯：

我不認爲你的榜樣改變了我的答案。如果郵政局想要這種「附加功能」，比如排序等，他們會在故事或其他故事中定義它。建立一個沒有要求的東西就是浪費。花費時間處理積壓中低優先級的故事是低效的。敏捷的基礎是構建需要的東西，只有重要的東西才需要。所以我會因爲開發人員在特定的屏幕上工作而添加「額外的好東西」而沮喪。

這並不意味着您不應該查看積壓的所有故事，並根據未來需要制定架構計劃。

來源

2010-05-27 20:10:35 DancesWithBamboo

爲了估算故事成本，團隊將期望與採購訂單合作，至少在廣義上定義該功能的需求。在你給的例子中，團隊可以明確地詢問PO是否需要分類&分組功能。如果他們拒絕，由於採購訂單在該階段不能看到它的用途，那麼在此基礎上給出估算，並按照這個估算實施。 YAGNI原則上沒有考慮這些附加功能。如果由於人們使用產品的早期化身而隨後出現對分類排序的要求，那麼，這是另一個故事，並且估計相應地排入積壓。故事的實施範圍沒有改變，只是因爲你有一段時間留在一個迭代 - 而不是您只需從積壓拉的下一個優先項目，並與獲得。

當然，實現這個故事的球隊時也可以隨意使用他們認爲適合發展的產品大部分時間/成本效益的方法。如果這意味着要使用額外的能力的成分，即的功能的超那麼他們可以這樣做（除非這是違反了非功能性需求），只要驗收標準都通過了，但他們不應該去刻意添加在未被請求的功能中，僅僅是因爲他們在迭代中需要一些時間。

來源

2010-05-31 14:17:28

中增加了更多內容，「僅僅因爲你有一段時間還沒有完成迭代 - 相反，你只需從積壓的文件中提取下一個優先項目並繼續」。我很欣賞這種情緒，並會一直喜歡這條路線。然而，現實情況是（至少在我們的衝刺中）團隊要麼擠壓衝刺中的內容，要麼終於有幾天的剩餘能力。在這種情況下，他們不能開始一個新的故事，因爲知道他們不會完成它，他們將不會有可交付的代碼。所以他們需要在改變他們所建立的範圍方面做得更好。 – njr101 2010-06-01 17:51:15

你通常會有某種「技術債務」或「錯誤修復」項目可以使用，或者從下一個故事開始，但不要爲其提供代碼。是的，你必須發佈完整的代碼，但是沒有真正的理由，一旦代碼庫被標記爲當前sprint的構建交付物，你就不能繼續處理故事任務。記住，所有的敏捷方法對於你的團隊來說都是一個工具，在這個框架中，你可以靈活地做好交付產品所需的工作。您可以嘗試以更細化的方式將故事分解。 – 2010-06-01 23:13:01

我的看法是什麼地方你適應功能的時候，這是離開的描述之間，而「只是滿足驗收標準，這就是它的」其他兩個評論員的POV ...

在我的觀點，大家應該記得一個故事用戶的正式建立：

作爲-role-我想-feature-，所以-aim-。

考慮到期望功能的目的，開發人員可以更好地理解PO的真正需求。然後，他可以拿出更多的想法和要求PO，例如：

嘿PO，如果你想-aim-所以我們爲什麼不這樣做- 其它/除功能 -。那會更好嗎？

而PO可以同意和故事實現描述，但在另一種解釋，或者故事改編可能。這對我很重要的幾點：

的PO描述的目的，他想都應驗了，一個特點，就是適合這樣做
球隊不只是實現驗收規定 - 像發展殭屍，但他們是開放的，並且總體上符合PO的願景和特別的單一故事目的 - 因此他們可以提出額外的/替代的想法。
球隊也沒有加強自己的權威用戶故事或過工程師。這太浪費了！

我希望你能分享我的意見;-)

來源

2010-05-31 22:43:00

同意這個觀點100％。這一過程絕對需要與採購訂單密切合作。但是，這仍然沒有幫助我得到任何有關教授這一原則的培訓活動;） – njr101 2010-06-01 17:52:08

一個很好的演練和一個有趣的團隊建設活動是做XP Planning game。

的前提是產品負責人給出了視覺的東西（如咖啡機，機器人）的要求，所有要求必須繪製。開發人員必須制定要求。

有幾個短迭代（整個演習需要一個小時，並根據設定時間：90分鐘之間），它很有趣，看看如何改善溝通和權衡發生隨着比賽的進行。我在項目開球時以及在將團隊轉換爲敏捷實踐時都會親自實施，團隊一直認爲它很有用，也很有趣。

來源

2010-06-02 17:57:20 Paddyslacker

團隊活動/遊戲，用於說明SCRUM環境中的設計

回答

相關問題