我已閱讀敏捷宣言，並在網上衝浪尋找這個難以捉摸的答案。但遺憾的是，我沒有得到涵蓋所有基地的答案。固定成本項目中的Scrum
在收看敏捷傳道人的所有博客文章和新聞時，您只會聽到有關開放式範圍或開放「時間」項目的消息。你如何將這個應用於固定成本項目？
從我發現最大的問題是範圍管理。你如何確定是否有什麼東西不在預計的範圍內，你如何爲你的決定製定論據？由於您正在實施軟件的敏捷方式，因此沒有詳細的設計可供討論。在大多數情況下，您只有客戶交給您的模糊的願望清單。而且非常普遍，您可以將任何功能解釋爲它。
隨着固定成本項目的比例上升，這對我來說是一個真正的問題。
所以問題是：
Scrum並沒有取代有適當的要求，甚至有偶爾的主要版本或里程碑。相反，它爲您提供了一種讓您的團隊保持高效和專注的手段，並避免了瀑布流程浪費時間的副作用。
事實上，像Scrum這樣的敏捷流程最大的優點之一就是它會導致您在項目的有問題的領域「快速而大聲地失敗」。如果在幾次衝刺之後，您的團隊仍然無法有效估計實施特定功能所需的時間和資源，那麼可能需要推回該領域的需求 - 他們可能需要澄清，簡化，或完全報廢。然而，在傳統的瀑布過程中，這些「問題特徵」往往會被推回到最後一分鐘，導致大多數項目下達的通常死亡和交付不足。
但是，對於使用Scrum的團隊來說，產品負責人的角色更爲重要，因爲他們擁有大量需求。留在他們自己的設備上，大多數開發團隊將首先關注最有趣/有趣/令人討厭的功能（服務API，緩存，搜索），並將付款流程，用戶體驗設計和國際化等「雜亂」的東西留到最後一刻。強大的用戶聲音對於確保對最終用戶至關重要的功能得到公平的關注至關重要。
我最近回答了similar question on SO。你可能會發現這個答案很有用。
很好的答案。我發現你的陳述，即開發團隊切斷質量來傳遞一些令人驚訝的事情。 – Dejan 2009-09-16 19:47:22
這是許多軟件項目無法滿足最初期望的原因之一。 – 2009-09-16 20:52:19
好的，這不會是您正在尋找的理想答案，但可能有助於減少不足。
爲了您的第一點：
隨着敏捷，和Scrum尤其是風格適合對改變規格和不固定期限使用迭代模式。爲了能夠在固定範圍內管理這個項目將是一場噩夢。通常情況下，通常會爲特定範圍設定一個預算，並且任何附錄都會產生超出範圍預算的可計費小時。在Scrum中這樣做毫無意義，因爲產品積壓將不斷由利益相關者填充。如果在固定預算中沒有對範圍變化進行「懲罰」，那麼就沒有什麼能夠阻止人們回到你身上。
這裏的另一種方法是有固定的範圍衝刺繼承，所以例如：
5x Sprints = x Cost with minimal scope change。
關於你的第二點：
使用分析和設計的是一個寶貴的工具。通過使用用例，事件表，序列圖，狀態機等;長遠來看，你將會拯救自己的眼淚。基本上，一旦規劃完成，任何附錄都需要額外的（請注意額外的，而不是被忽略的東西）用例和大的代碼更改將超出範圍。事實上，任何在規劃中沒有被忽視的東西都不在規範範圍之內。
最後，您需要有非常好的計劃文檔以及與您的客戶達成非常穩固的協議，才能夠100％完成此項任務。
我希望這會有所幫助。
這只是我對事物的看法。我必須說我是Scrum的忠實粉絲。但是我不能理解我們遇到的「如果我們所有的都是錘子，所有問題看起來像釘子」問題。 – Dejan 2009-09-16 19:59:39
我在一個有固定成本和固定時間項目的環境中工作。我們已經從瀑布/ VModel方法轉向了Scrum類型的方法學。 Scrum在固定成本/時間項目中可以很好地工作，因爲它的概念是客戶被控制，然而爲了實現這個目標，您必須能夠在某種程度上準確地確定需要什麼工作以及需要花費什麼（時間，金錢，資源）。這是Scrum成爲理想人選的場景。
您將願望清單願望清單/需求/屏幕截圖分解爲可交付的可交付成果。例如。客戶可能會說「我想要電子商務，使用Paypal」，您需要將其分解爲實際的交付內容，例如「1.客戶註冊和登錄，2.產品目錄，3.購物袋，4.付款，5.訂單確認」。在這個階段，要確定需要多長時間還是不可能的，因此我們需要完成上述所有步驟才能完成項目（即，您無法在沒有付款的情況下進行電子商務）。所以再次分解它們，直到你有細粒度的可交付成果，可以在幾小時內，甚至幾天內流派，但肯定不是幾周，例如，
1 Catalogue
1a View all Items
1ai View all items on 1 page with an image and item name underneath in a grid, 4 items per row
1aii View 10 items per page with paging
1aiii View a user slected number of items per page, with paging
1aiiii View all items on 1 page with an image and item name, descriptioon and price on the same line, 1 item per row
1b View by Category
...
1c Search
...
1d Attribute Filter
...
等等，這是可以做到非常快，你現在也許可以推測將會需要多長的待辦事項X（OFC，我可能會打破上述下來，甚至進一步，添加更多的描述性文字來形容所需的工作，比如持續的數據結構可能需要什麼，這些結構中的數據，數據如何被添加，進一步甚至可能描述需要的開始和結束狀態）。
一旦你走了這個，你會注意到一些功能和依賴於其他人，e ..g你不能有一個目錄上的分頁功能，除非你有一個目錄啓動witj，並catagloge將需要CMS screesn添加和編輯項目等等。在任何你使用的工具中突出顯示這些'不能沒有功能'，這構成了核心項目，並且在一兩天內你有一堆可以開發的功能有點獨立，有成本，加起來就會造成項目成本。而現在客戶負責，他們決定添加一個功能，並增加成本，冷靜，完全取決於他們。
以上所有內容顯然只是scrum或敏捷過程的一小部分。
如果我們將顧客願望清單分解成更小的和平，我們在哪裏界定大前期設計和scrum之間的界限。因爲我們知道BUFD不起作用。所以在這裏我看到了一個如何做到這一點的問題。 – Dejan 2009-09-16 19:49:00
我同意，這確實需要一些判斷。把它看作功能規範的第一稿，而不是技術規範，你只是想從用戶的角度去描述某些東西是如何工作的，你不需要指定所有的東西。例如，上面我提到了分頁，但不是我如何實現分頁，或者用戶如何與它進行交互（是鏈接還是下拉，我可以返回，轉發，跳轉到頁面等）。你也可以使用UI Mocking Tool（我喜歡Balsamiq Mocks）來解決這個問題，如果你不能嘲笑它，它就太複雜了，你只能使用非常基本的UI元素。 – 2009-09-16 21:14:38
我不認爲與範圍蔓延和Scrum過程的固定價格合約是不相容的。你只需要和你的客戶達成一致就可以實現。如果您與您的客戶一起創建初始積壓工作，按照您的估算，您可以將其用作固定價格成本和計劃的基礎。您甚至可以同意「X」故事點數等於「Y」開銷和「Z」開始時間表的比率。
你然後做正常的scrum的事情，有客戶分配故事當前迭代等
隨着客戶的範圍蔓延配合，你與他們合作，加入「蠕變」作爲用戶故事積壓。每次添加一個新故事時，都要指出，對於積壓的每個X點，他們將不得不增加成本Y和時間表Z，否則他們將不得不放棄等值的故事點。由於他們選擇每次迭代的工作，他們放棄的點數（如果這是選擇）將是最不重要的功能。當你的日程安排結束後，你將被留下積壓的最不重要的功能，他們可以選擇放棄或給你一個新的合同完成。
訣竅，當然是要善於估算成本和進度的每個故事/任務;-)
問題不在於創建初始積壓，而是預先估計並凍結估計。有一個雙重的缺點：1.你必須在最糟糕的時刻估計（當你知道項目較少時）2.你不能在以後改變它們。這與Scrum不兼容，可以讓你在學習時不斷重新估計。 – 2009-09-16 19:09:47
就像在上面的評論中，我很難將這兩者結合在一起。這就是爲什麼要問這個問題的原因。 – Dejan 2009-09-16 19:34:05
+1爲一個很好的答案SingleShot。 @帕斯卡爾/德揚：故事點數/成本不等於小時;這兩者之間只有相關性。這可以通過計劃撲克來完成。沒有關係，只要平均值有+/- 25％的不準確性。 Scrum方法作爲傳統的瀑布方法有更多的自由度，因爲在項目期間可以交換Storys。更改可以在固定價格內併入，而不是作爲額外成本。 固定價格/固定範圍幾乎是不可能的（通常假設固定時間和固定質量）。這是一個很好的近似值。 – Adriaan 2009-09-25 07:36:45
該項目可以分解成更小的部分，固定利率，可以連接到這些。然後可以調整項目的其他階段。
您必須能夠針對競爭對手銷售敏捷流程。如果客戶有按時交付的固定投標項目的歷史，規格和成本，他們爲什麼會浪費時間接受其他開發商的投標？
對我來說，關於敏捷和固定價格的簡短答案是，你不能這樣做，至少不是固定範圍。
我知道有些人會說「這不是真的，我們正在這樣做」但是，在所有應有的尊重，我不認爲他們真的在做敏捷，我會解釋爲什麼。實際上，解釋很簡單：固定價格意味着固定範圍，並且基於可變性範圍，範圍管理和適應性方面的可預測性。因此固定價格的固定價格基本上與敏捷相反。
使用敏捷方法，固定價格爲給定團隊規模提供了多次迭代。在這些迭代過程中，客戶將能夠讓團隊首先構建最有價值的功能，從而最大限度地提高業務價值。然後，當迭代的成本大於生成的值時，整個想法就會停止迭代。這就是敏捷的工作原理。
所以當人們說他們以固定範圍以敏捷的方式完成固定價格時，他們實際上會引入一些與敏捷理論不兼容的約束 - 比如對一組給定的特徵進行預先估計並凍結這些功能和估計 - 並且它們失去了敏捷的重要優勢（除非他們對技術和業務領域有完全的瞭解，掌握它們足以預測一切，但我知道很少有像這樣的項目）。
無論如何，這是一個很好的彙編各種敏捷契約：10 Contracts for your next Agile Software Project可能會有所幫助。但我認爲他們都需要對客戶進行一些教育，尤其是那些習慣固定價格固定價格（以及延遲交付）的客戶。
我同意1000％。利益相關者需要成爲常規檢查點的一部分，以監測進展情況並確定職能領域的優先順序。如果堅持要在固定的時間內獲得固定的功能集，那麼利益相關者不會從敏捷過程中受益。如果沒有來自所有團隊（技術和業務）的全部投資，這個過程註定會失敗 - 如果不是失敗，則幾乎無用。 – 2009-09-20 13:32:17
固定成本並不意味着單衝刺。範圍被轉移到產品待辦列表中，隨着Sprint的進展，範圍被調整，協商和交付。 Scrum允許快速交付價值，並提供快速驗證，並有機會識別潛在的鍍金。
範圍更改可能會導致添加積壓項目，並刪除其他項目。它的投資回報率與所提供的固定預算之間的平衡。
如果範圍增加（並增加值），並且成本是固定的，則必須相應地管理三重約束（成本，時間和範圍）。
請記住，固定成本並不意味着固定長度。
在敏捷中，可以有詳細的設計。而且你沒有交出一個「模糊的願望清單」 - 你通常會有使用案例或用戶故事，這些案例或用戶故事應該對需要完成的事情非常具體，但不知道如何去做。 – 2009-09-16 18:37:24
在每次衝刺之後，不應該更新「模糊的願望清單」，以便產品所有者決定注意力集中在哪裏？ – 2009-09-16 19:03:46
在每次衝刺之後更新模糊的願望清單會很好。但是，當用戶對功能有固定期望並希望在預定日期使用此功能時，調整範圍可能會變得很糟糕。 – Dejan 2009-09-16 19:31:40