如何向同事證明使用案例很重要？

Question

... 以及如何向管理層證明用例可以是非正式的並且仍然有用？

嗨夥計，

我來到一個項目中，發現了有沒有用例，用戶故事，要求，既沒有任何類似的規範。由於截止日期很短，目前的開發團隊不想花時間在這些事情上。我想加入這個項目，但通過深入挖掘，我發現當前的開發僅僅考慮了他們的「哇效應」，並通過使用底層技術提供的易用性來選擇添加什麼。我很驚訝他們如何在沒有要求的情況下走得太遠（超過4個月），但這是我們現在擁有的。我相信他們選擇的方式是殺死具有良好營銷價值的產品的最可靠的方式。

我是對的嗎？在類似的情況下，你會怎麼做，以證明開發團隊/管理層在繼續前做出用例/需求？在此先感謝，嗯。

P.S.兩本Cockburn的書在書架上...

Answer 1

你應該給你的同事用例高談闊論：D告訴他們，因爲他們是那個用例是有用的：

• 的方式捕獲業務流程的一種方式是通過所有合理理解利益相關者。這有助於彌補程序員，客戶和用戶之間的差距。
• 可追溯的功能單位。用例在分析階段形成（理想情況下），在設計階段引用，並且可以在稍後用作測試用例的源。
• 即使非正式，寫起來也很有用，而且很有用。

如果你需要更多的彈藥，你可能需要閱讀用例 - 無非伊瓦爾·雅各布森等昨天，今天和明天。

如果你的同事仍然無法看到的用例的潛在有用的業務分析工具，那麼他們很可能超越的幫助：P您應該提醒他們，他們正在開發軟件，以滿足其他人的需求並從長遠的角度解決他們的問題，而不是在短期內用小噱頭誇大他們。所以一點點的方向和規範都有幫助。即使用例本身沒有被證明是有用的，但想出它們的簡單行爲將迫使你的同事考慮軟件的實際潛在目的。

Answer 2

只顯示它們。

例子不是教育人的最好方式，它是唯一的一種。

Answer 3

問問題，雙方。在開發過程中，詢問他們是否確定他們考慮使用應用程序的所有方式都是最終用戶想要使用它的所有方式;如果他們說他們有，請求證明。在管理方面，問他們是否曾經使用能夠完成他們想要的任何事情的軟件，但最終還是很難使用（他們會有）。這些問題將產生這樣的概念：雙方都可能不會達成所期望的目標;然後使用這個想法的種子來開放討論（不是文檔，而不是開始），討論如何使用軟件以及以何種方式解決任何差異。他們最終會到達用例文檔。

Answer 4

我是一位專業的產品經理，我對您的文章的第一反應是，創意可以來自任何地方，如果開發團隊有不錯的想法，他們應該被納入產品。

話雖如此，一個產品不能通過一系列不連貫的想法來發展靈魂（簡單的信息），這些想法並不能達到最終目的：解決目標用戶的需求。最終歸結爲使時間更適合用於對產品有意義的需求/用例，而沒有明確策略/最終目標的機會成本會導致過多的廚師和疲憊的產品信息。

讓這個消息回家的最終方式是讓其他利益相關者參與進來，並讓開發展示他們的工作。最終，會有分歧，更正式的（少牛仔）方法將導致更精煉和簡單的產品。

Answer 5

以示例爲主，關注擴展和例外。換句話說強調故障情況，因爲每個人都知道系統應是如何工作的。書面使用案例的真正價值在於確定在發生什麼事情時會發生什麼錯誤。

請注意，考慮到您可能必須在沒有書面用例的情況下才能生活。而且，對於您描述的環境而言，主要的勝利是任何需求文檔。屏幕合成和/或原型製作通常更容易引入。

Answer 6

您提到的其中一個問題是由開發人員自己引發的時間緊張和範圍蠕變。解釋它們，通過使用用例，您可以通過刪除功能來獲得時間，這可能會導致「未使用」堆棧。通過使用案例，您可以瞭解客戶需要哪些功能以及哪些功能需要支付，並通過刪除範圍之外的不重要功能來實現。除了定義範圍之外的用例還有助於識別所有利益相關者，這可能有助於您在定義範圍時更好地關注焦點並防止忘記不太明顯的微不足道的事情，但如果產品應該可用。關於用例的第三件最重要的事情是，它們允許你開始思考在開發之前可能對客戶很重要的角落案例，因此你可以找到與客戶什麼是理想的解決方案，而不是讓編碼人員決定他/她自己受到最後期限的壓力。