Agile的大圖策劃

Question

我做了一些比較徹底的閱讀和搜索，並沒有在這個主題上找到任何東西，所以希望我不會創建一個笨蛋。如果這之前我已經問過，我會欣賞一個鏈接。

我工作的企業開發商店目前主要使用軟件開發項目的瀑布式流程。我已經閱讀了很多關於敏捷方法的書籍和文章，並且我可以看到其中很多方面可以真正改善我們的流程。我還可以設想在開發者層面如何應用很多實踐，即配對編碼，更短的迭代，重構，TDD等。我們已經做了很多。

我的想法和我們組織管理層的想法存在的巨大差距是敏捷過程中的長期計劃是如何工作的。在我們甚至可以開始開展項目工作之前，我們需要有內部客戶批准的預算支付我們正在生產的軟件。如果我們不事先做一些相當詳細的要求和估算，我們如何知道預算應該是多少？當然，我們的要求和估計並不完美（有時真的關閉），但他們總比沒有好。

一個相關的問題是如何判斷施工期間項目的長期狀態。如果一個特定的軟件產品對組織來說價值不菲，他們怎麼知道我們是否能夠在我們最終花費超過它的價值之前實現這個產品呢？我可以看到敏捷如何在確定下一次迭代過程中可以做什麼的時候工作，但是如何估計工作總和到達1.0版本以及是否可以完成這些工作到明年第四季度？

這個戰略級計劃是如何在敏捷商店中發生的？您是否僅針對最初的模糊用戶故事進行估算？你沒有對這種性質做長期規劃嗎？您是否仍然有一個預先的高級需求/設計階段，然後在項目離開時轉向敏捷過程？

感謝，

〜賈斯汀

Answer 1

使用純敏捷進行大規劃是非常困難的。第一個大問題是（正如你發現的那樣）純粹的敏捷和前瞻性規劃（預算，長期時間尺度等）基本上不能很好地協同工作。

如果您熟悉project management triangle（範圍，成本，時間表），敏捷的重點是修復成本和時間表，並允許範圍變化。在大型組織中，範圍和時間表通常是固定的（我們需要在下一季度將產品X與這些功能相結合），然後您花費大量時間討論成本（即開發人員的數量），並且常常最終遲遲不能投入，因爲時間表和僅允許的成本是不夠的。

這給我們帶來了第二個問題 - 在傳統的公司環境中運行純敏捷所需的思維模式的轉變。理想的建議是讓你的組織購買到敏捷批發，並認識到他們可以建立積壓功能，但並不是所有功能都可以交付。然而，交付的產品質量高，準時，成本高。熟練使用Mike Cohen's book可以導致組織思維的嚴重轉變。

不幸的是，要將整個組織的思想從單個項目的背後改變，非常非常困難，所以第三種方式是妥協 - 您不會做純粹的敏捷。你所做的事情就像RUP/Waterfall那樣，你需要做一些前期需求分析，並做一些設計和架構工作。只需突出風險區域並理解大圖複雜性即可。然後運行迭代「0」。

迭代0證明了高風險領域的概念開發，並有助於理解關鍵估計和團隊績效。這可能是一個被拋棄的原型，它可能是你的應用程序框架的基礎，但重要的一點是要獲得對估計質量和可能的團隊速度等方面的基礎感。這爲你創建基礎奠定了基礎一些計劃和設定一個可能的預算。

然後，您可以像普通的敏捷迭代一樣運行開發工作，獲得早期用戶反饋和可視性等益處。迭代方法還有助於爲您跟蹤計劃提供定期里程碑，允許重新計劃點和預先警告預算上/下運行。隨時使用估算/實際數據重新制定未來計劃。

Answer 2

在做戰略規劃，內部客戶往往更關心功能的要求。

我傾向於使用支持可追溯性的工具來創建功能路線圖（我更喜歡Sparx Systems的Enterprise Architect，但許多工具都會這樣做）。我在項目發起人一級審查了所需的功能和順序。然後，我會與適當的人員（有時是業務專家，業務分析師或IT架構師等高級IT人員）合作，將每個功能分解爲一組高級需求。我創建了從高級需求到功能的可追溯性。此時，需求通常處於「添加ABC屏幕」，「添加DEF屏幕」，「創建後臺進程以重新計算XYZ」等級的水平，無需更多詳細信息。此時，我會根據任何可用的度量標準（包括腸道感覺到屏幕平均需要添加多長時間的統計數據），與適當的人員合作估計每個高級需求的工作量。然後，我的建模工具將總結每個特徵的總預計工作量，然後將其呈現給項目贊助商並放入項目計劃中。

然後我們開始迭代以解決第一個特徵或特徵集。每個高級需求都被細化爲詳細的需求（「屏幕ABC需要一個名字字段，最大長度爲40，需要」等等）。根據項目需要，我們可能會重新估算更詳細的需求，並將它們升級到它們追溯的高級需求。更常見的情況是，開發人員將被分配開發屏幕ABC，將在sprint規劃工具中輸入他自己的估算，並且估算將回滾到原始模型。由於他正在實施（和估計）的需求追蹤到追蹤到特徵級別的高級需求，所以在我們進入每個迭代時，計劃會不斷更新。

它需要一些紀律和努力來設置它，但它是非常值得的。

Answer 3

不要做項目的價值如此之低，以至於不明顯你會得到合理的投資回報率。

不要嘗試在沒有的情況下創建假的確定性。大局規劃是，應該是模糊的。

敏捷實施流程允許客戶引導和適應。如果你有一個經驗豐富的團隊，一個知名且穩定的領域，沒有新的技術或方法，你就知道它的速度。這也限制了您可以估計的項目規模。團隊定期變化，技術每隔幾年就會改變一次。

如果客戶需要詳細的預算，她需要將用戶故事提供到可估計的級別。這意味着很多工作必須事先完成。所有可見的風險峯值都必須完成。只有當要求足夠穩定時，這項工作才值得。

Eric J.所描述的細節水平完全是不必要的。這應該在軟件中並從中提取，而不是事先在紙上指定。

有一個客戶或開發人員無法充分理解的故事列表可能很有趣。你不應該花很多時間在他們身上，因爲他們的穩定性很低。使用購物車排序，您可以快速瞭解尺寸和優先級。任何地方存在很大的位置差異，都有潛在的風險。 要求所有利益相關者提供新的故事可以幫助您評估完整性。

Answer 4

如何做大圖敏捷？以這種方式考慮：在瀑布項目中，業務分析師的主要目的是想出最基本的行爲需求的最小但高質量的大圖，而敏捷項目中的業務分析師的主要目的是提出對基本行爲要求的最小但高質量的大圖。

Answer 5

「安全」通過資助「敏捷發佈列車」，而不是Proyects的解決這個問題：

http://www.scaledagileframework.com/budgets/