Scrum和要求

Question

您不能僅僅以用戶故事的方式記錄程序的功能。你最終得到了scrum的規範文檔嗎？如果你真的這樣做，你最終會分配時間來完成這項任務？

一個例子是一個複雜的工作流程。
另一個例子是一個新成員加入團隊。

Answer 1

將「文檔」作爲任務添加到每個用戶故事當然可以實現您的目標。

Answer 2

除了James Kolpack所說的之外，用戶故事地圖在項目完成後應該保留下來，因爲它也是一種文檔形式。我相信我們會計劃如何將它轉換爲一個文件，當所有內容都完成時，它就存在於我們的Wiki中。

這個想法是，這個文件對那些需要維護系統或在未來增加增強功能的人很有用，因爲他們會理解用戶的觀點。

Answer 3

這個問題會有很多好主意。我個人的經驗告訴我：

1〜工作產品本身就是一種文檔形式：假設產品被接受，然後詢問它在特定條件下應該做什麼等同於詢問它在這些條件下究竟做了些什麼條件 - 登錄並嘗試獲得答案。

2〜測試，無論是手動還是自動（或混合），都是一種文檔形式。當然，單元測試可能離技術不太成熟的團隊成員所說的領域語言太遠（例如：'業務專家'或客戶）。驗收測試可能更接近某種「中間地帶」。絕對BDD風格的測試似乎有最好的機會來建立一個無處不在的語言，每個人都可以理解（在這方面看Gojko's Bridging the Communication Gap）。儘管如此，所有這些形式的測試都是一種可用於確定產品應該做什麼的文檔形式。根據您的項目在光譜中的位置，您的文檔（以及通常所有的輔助製品）可能需要更高或更低的儀式程度。更小的產品，更小的團隊，上市時間至關重要可能會發現，與其增加的價值相比，非常正式的需求成本文檔方式太多了。另一方面，跨越多個團隊和多年開發的極其龐大的項目將會發現正式文檔的投資回報率非常不同。在完美的世界中，我們可能不需要以工作代碼的形式（其在象牙塔中也是不言自明的）和測試（主要是用於迴歸測試，和 - 邊緣 - 推動新功能的發展）。因此，需求文檔的問題是關於完美世界/象牙塔和真實世界/溝槽之間有什麼不同的問題。當然，答案根據具體情況而不同，具體取決於項目和團隊。例如，我們可以說：「所有的要求都應該保存在這個維基中，並且要保持極其謹慎，等等......」但是如果團隊對維基不熟悉並且很不習慣，這是行不通的。

5〜最後，利益相關者是你應該問的。當然，應該以協作的方式來討論這個話題，因爲團隊中的每個人都必須在整個項目中與需求進行交互，但是您必須找到一種滿足利益相關者需求的文檔形式。

之所以這麼說，這裏有一些地方我見過的要求記錄在案，同時應用的Scrum（爲什麼我覺得這樣的話，應始終遵循一個星號？）：

• PDF文檔
• 布告欄
• 維基
• 維基+自動化驗收測試（閱讀：FitNesse的）
• 單元測試
• 手冊測試計劃
• 用戶故事，用例圖（閱讀：企業架構師型號）
• 白板在辦公室
• 電子郵件
• 報事貼

而且，說實話，我不能說任何一個系統與一個成功項目的關聯性都要高於其他系統。我想，的確，我們沒有銀彈。

HTH，感謝發人深省的問題！

Answer 4

也許我對這個問題的理解是完全錯誤的，但是我的理解是，OP對用戶故事和需求之間的不匹配感到不舒服。有理由我會說。

在我看來，用戶故事講述瞭如何向產品所有者展示一大塊功能。故事的語言可以是產品所有者可以理解的東西，但主要由開發人員來理解。你可能有一些故事描述的東西甚至不是所有者直接要求的東西，但卻是事物的細分。

另一方面的要求是以域用戶的語言詳細說明系統需要做什麼才能生效。在許多情況下，需求文檔不是可選的（例如，固定價格的項目）。

我所做的是兩者的結合。我有一個需求文檔，在我的大多數Scrum故事中，我在筆記中都有一些將這個故事與一個或多個需求相關聯的內容。它與「請參閱FR-042和FR-45」（例如功能要求的FR）一樣簡單。

Answer 5

Scrum說您應該在需要時記錄您需要的內容;它不說你不應該有文件。

因此，如果成品需要文檔（如幫助文檔）或生成成品（例如需求文檔），那麼在產品積壓中應該有文檔任務/用戶故事。

然後應爲該任務設置適當的優先級。

對於文檔的關鍵點是;只有

• 文檔你需要，只有當你需要它。

Answer 6

你不能只是有用戶故事 不知何故 程序的功能已被記錄在案。您是否在 以scrum結尾的規範文檔 ？如果你確實這樣做，你最終會分配 分配給 任務的時間嗎？

爲什麼你不能只有用戶故事？這些規格說明文件的用途是什麼？生產這些文件的投資返回什麼價值？利益是否會衡量成本？如果不是，那麼是不是創建這些文件所花費的時間，更重要的是維持這些文件的浪費？

我知道我提出的問題比提供答案要多，但我認爲Scrum和其他敏捷方法（如精益）所做的一部分工作就是強制您重新檢查當前的實踐，看看它們是否仍然有意義。

對於規範，一旦功能啓動，誰將更新和維護這些文檔？在我參加的大多數公司中，文檔都很稀疏，過時或很少被引用。

而是，爲什麼不使用可執行測試或BDD，以便文檔成爲代碼的一部分並且是可執行的。例如，請參閱Ben Mabey's talk on Cucumber

如果由於某種原因，出於法律合規的目的需要特定類型的文檔，您可以隨時將其添加到團隊的「完成」定義中，但是，在大多數情況下故事和測試都是足夠的文檔形式。

Answer 7

我大多數人都同意託德，但有時候我的團隊的任務的一部分是生成文檔：文檔是用戶故事本身我們的PO要求交付。

在這種情況下，我們遵循了以下原則：

• 嘗試儘可能多的，因爲我們可以從實際工作的代碼（通常是讀取內部數據結構或配置文件中的建築同時使用一些文檔生成程序解壓縮文件實際的程序和構建文檔）。
• 定義文檔中美國目標文檔的：
  • 誰讀者應該是
  • 什麼他應該能夠實現讀取文件。

根據我的經驗，使文件更容易編寫和實現某種測試（你問的人，通常PO，讀取文檔，並說，如果它的確定考慮的目標）。

Answer 8

您編寫文檔來驗證您的系統。如果以反映用戶與系統交互的格式正確寫入用戶故事，則可以達到同樣的目的。我會推薦使用BDD並使用Gherkin語法編寫故事。最終，您的場景成爲您的驗收標準，有助於驗證系統是否正常工作。

Answer 9

我們有一個文檔團隊爲我們的產品生成「使用說明書」。本手冊圍繞產品的主要功能以及用戶可在這些功能中執行的任務進行構建。

每個sprint，Scrum團隊都可以在爲產品功能添加功能的用戶故事上工作。

衝刺計劃完成後，文檔團隊與Scrum團隊會面，並查看哪些用戶故事將在此衝刺中進行開發。文檔小組然後開始通過編寫初始文檔來增強指導手冊。在衝刺期間，文檔團隊會遵循用戶故事的進度，並可以在產品部署到測試環境時使用該產品。在衝刺結束時，文檔團隊完成更新的說明手冊，並添加最終屏幕截圖等...

指令手冊船作爲發佈每個sprint的一部分。

Answer 10

我想你在這裏要求一些不同的東西。如果您要添加新的團隊成員，那麼作爲入職流程的一部分，系統的文檔應該面向他們在團隊中的角色。

如果您正在討論記錄系統功能，在我們的組織中，我們的培訓團隊將這些功能記錄爲發佈的一部分。他們在Sprint評估（演示）期間參與（作爲利益相關者），然後提供一個具有新功能的培訓環境，以在發佈前準備培訓材料。

如果您正在討論提供易處理性的文檔，您的積壓可以作爲與添加正確的過程&控件。

這些不同的項目中的每一個都需要規劃和有意識的過程開發，以有效運作並滿足團隊的需求。我們已將這些項目中的每一項納入我們的回顧過程中，因爲我們確定了一個問題，並隨着時間的推移開發了我們的流程。