工程\整合用戶故事 - 如何編寫客戶價值？

Question

我正在爲一家大型電信公司工作，而且我們部門最近轉向了「企業敏捷」工作模式（所有這些都非常令人興奮！）過去我們運行了特定的敏捷項目，但現在正在嘗試我們的整個程序使用敏捷原則。我們的大部分工作都是基於系統集成和配置的，我們在內部運行的軟件開發很少。

我現在試圖從我們的lifecyle計劃中提供功能，並試圖鼓勵團隊編寫以客戶價值爲重點的故事，但當功能需要大量技術基礎工作時，如何實現這一功能，非常鎖定一部分用戶功能？ （第三方軟件已經定義了用戶可以做什麼和不可以做什麼）

作爲示例，我們有一個功能可以通過新的報告解決方案提供現有的客戶報告。沒有新的功能將被交付 - 至少作爲初始版本的一部分。我們已經確定了一組我們將爲用戶構建的標準報告。這些是我們的客戶價值故事。但爲了提供一個故事，我們需要部署和配置新的主機，一個新的業務對象數據庫，新的數據收集點，一個新的數據聚合和提取層，並將當前客戶數據導出到解決方案中並驗證\調整表示 - 然後才能構建並提供實際的報告。

新客戶隊列報告的交付是我們的EPIC故事，我們應該如何獲取實現此目標所需的所有技術基礎工作？是否可以將主機和數據庫的構建作爲用戶故事編寫，或者僅僅作爲技術任務編寫。如果它被寫爲一個非估計的任務，我們將運行大約4-5次迭代，然後才能提供單個用戶故事。即使試圖提供最低限度的功能，這個故事也適用於擁有大量數據的大規模客戶，並且需要大量技術工作來交付第一個價值故事/

我在這個優秀的網站上搜索過，在網絡上以及諸如邁克·科恩的書籍中，並且建議似乎主要是基於軟件開發的。我很喜歡在這方面得到一些答案，我可以將其應用於大型企業明智的工程項目。隨着敏捷運動不斷髮展壯大，其軟性開發根源不斷擴大，這對於團隊來說必定是一個日益嚴重的問題？

Answer 1

我想也許你正在接近這個錯誤。一個大的可交付成果將違背敏捷哲學 - 即你需要能夠迅速響應客戶需求的變化。

例如，允許定義新報告的新技術的實施。如果客戶已經簽署了這個協議，那麼毫無疑問，這應該提前發佈，只有少量的報告。

另一方面，如果客戶尚未簽署此協議，則此時的敏捷交付可能是樣本報告和證據，您可以在自己的基礎架構上交付客戶需要的內容，直到您擁有購買英寸

對我來說，敏捷意味着能夠改變方向 - 而且您的方法並不能爲此自我解決，因爲您的用戶故事過於關注後來的可交付成果。