快速和骯髒的需求收集與設計重疊的工具和技術

Question

我已經閱讀並教了很多關於正式的需求收集，在瀑布背景下：花幾個月磨出用例，把它們變成一個規範，並最終提供一個沒有人想要的臃腫的crapware。

我現在正在開展的項目有一些特殊的特徵：利益相關者是學者，開發團隊非常小（2-3 FTE），整體時間很短（3-9個月），而且利益相關者對產品的最終形狀非常靈活。 （他們要求A，B和C但得到A，X和Z--沒有問題。）如果對利益相關者的訪問有限，我們通常會定期進行：例如每週1小時。

上述的一些後果：

• 我們需要得到10個小時的利益相關者的面試時間內編碼，較少。
• 我們可以在整個過程中不斷收集需求
• 範圍非常靈活。時間和預算是固定的，但範圍是我們耗盡時間時所完成的任何事情。

顯然我們使用敏捷方法，但是因爲團隊成員非常活躍，所以沒有真正的機會來構建一個穩定的scrum過程。

在我的PM /客戶聯絡的作用，我已經開發製作的需求收集電子表格（谷歌文檔）與類別如下習慣：

• 「我們現在可以實現」（我們認爲了解的不夠好，它的defini
• 「更多細節/ workshopping需要」
• 「低優先級」（通常的東西，一個用戶提到過一次，但由於我們還沒有聽說過的）
• 「大功能繼續討論「（一個重要的新功能集，特別是集成用別的東西。通常這些會很好，但我們不知道我們是否能及時完成 - 在這種情況下，我們不應該開始。）

我的「方法論」沒有解決的問題我很想聽聽你對建議：

• 追趕攪局者早就 - 嗅出，在很大程度上限制了我們的首選平臺/技術/解決方案/要求...
• 構建和計劃將來的需求收集會議，使得我們知道在我們遇到不確定性之前，我們可以在特定功能集上工作多久。
• 知道的東西是否足夠高優先級，這將肯定獲得晉級（如果沒有，花沒有更多的時間來調查吧）
• 管理組的相互依存的特點
• 可開發不同程度的管理功能（例如，花30％的成本獲得80％的收益 - 我們怎麼知道我們是否應該花其他70％？）
• 管理選擇（在一種情況下，難道我們實現認證機構X或Y - 沒有太多的好處這兩項工作，但周圍有兩個大的不確定性）
• 依賴關係：通常情況下，它是沒有意義開始實施Y直到我們看到用戶對X的反應如何。
• 問題跟蹤器中「要求」和「問題」之間的關係。你是否將所有內容都放在跟蹤器中，並且在更多地瞭解它們時不斷更新問題，可能會將它們拆分或合併？

所以 - 我有興趣聽別人如何對待這些問題。搜索「需求工具」變得毫無用處 - 只是一堆企業級桌面CASE工具。

Answer 1

在我看來，你需要與利益相關方/業務/客戶更多的互動，以1優先功能和2創建UAT測試計劃，讓你知道當你可以停止添加新的特性。

靈活的範圍是確定的，只要你能說是有一組核心功能，是至關重要的，這將讓用戶滿意。你說當時間不夠時，項目就完成了。那麼爲什麼什麼都做？也許你可以縮小範圍，直到你知道絕對必要的功能是什麼，並且如果用戶對此感到滿意，不要再添加更多。

Answer 2

這似乎是我們有同樣的問題。我們針對問題和要求使用問題跟蹤器（bugzilla）。這在新模塊的初始開發期間工作得很好。但是，如果半年後必須更改某些功能或擴展模塊的功能，那麼您擁有的所有問題和要求都是完全非結構化的。

此外，大量的信息中的問題或要求的討論主題中給出。這意味着需要閱讀大量文本以獲取大部分信息。

所以，重寫一個結構化文檔（字）中規定的要求之後，似乎是我唯一的解決辦法爲止。