沒有銀彈！

方法論是暴露隱藏風險......
我們引入了一種開發團隊在構建軟體時可能遵循的軟體方法，它包括分析，編碼和測試等步驟，而且，我們研究了每個操作的是如何管理軟體交付過程中的風險。例如，開發人員無需知道他的編碼是否會破壞“功能Y”，因為該編碼功能的整合測試部分會在測試階段主動暴露這種隱藏的風險，而不是讓它浮出水面生產（它變得更加昂貴）。

這裡介紹有一些不同的軟體方法簡單的介紹一下，並試圖解釋為什麼它們是不同的。讓我們從瀑布開始。

瀑布

“瀑布式開發模型起源於製造業和建築業;高度結構化的物理環境意味著設計變更在開發過程中變得非常昂貴。” - 瀑布模型，維基百科

瀑布是一系列方法論，倡導對提供軟體系統所涉及的過程採用線性逐步方法。瀑布式方法背後的基本思想是軟體過程分為不同的階段，通常包括：

• 需求捕獲
• 規格
• 履行
• 驗證
• 交付和運營
• 在每個階段簽字

錯誤的風險？
在建築場景中，這很有意義。但是，軟體專案與構建專案不同。應用於軟體時，瀑布方法有兩個主要批評：
“1.客戶在看到可執行的軟體之前可能不知道他們的需求到底是什麼，因此如果他們改變需求，導致重新設計，重新開發和重新測試，並增加成本。”
“2.設計人員在設計新的軟體產品或功能時可能不會意識到未來的困難。” - 瀑布模型，維基百科

因此，當瀑布應用於軟體時，瀑布規定的可以減輕建築行業返工和成本超支的解決方案卻並不能解決（並且可能加劇）上面提到的兩個問題。
無法管理這些風險導致在1970年代確定了“軟體危機”：
軟體危機是計算科學早期使用的一個術語，因為它難以在所需的時間內編寫有用且高效的計算機程式......軟體危機是由於計算機能力的迅速增加和問題的複雜性造成的。無法解決。“ - 軟體危機，維基百科

敏捷
軟體危機表明，在很多時候，前期需求 - 捕獲，規範和固定價格出價幾乎無法管理軟體專案的成本和進度風險。因此，到了20世紀90年代，各種不同的軟體工程師團體都在倡導“敏捷”技術。

在極限程式設計解釋中，Kent Beck列出了他想要解決的風險以及他提出的解決這些風險的行動。這些風險與瀑布所解決的風險不同，不出所料，不同風險也會導致不同的行為。

針對不同風險的不同方法
以下是我們在其他一些流行方法中看到的一些高階別差異：

• 精益軟體開發：瀑布借鑑了建築行業的風險管理技術，而精益軟體開發應用了上個世紀製造業豐田開發的精益製造原則。Lean認為製造業面臨的最大風險來自浪費，浪費代表庫存、過度生產、在製品、等待時間或生產缺陷，將此方法應用於軟體意味著最大限度地減少在製品，頻繁釋出和持續改進。
• 專案管理知識體系（PMBoK）：這是傳統專案管理實踐的形式化。它規定了管理專案範圍，進度，資源，通訊，依賴關係，利益相關者等的最佳實踐。雖然“風險”被視為一個單獨的管理實體，但上述所有領域都是專案中的風險來源，我們將在後面看到。
• Scrum：是一種流行的敏捷方法。可以說，它比極限程式設計更“極端”，因為它促進了一組有限的，更可實現的敏捷實踐，例如頻繁釋出，每日會議，產品所有者和回顧。這種簡單性可以說更容易學習和適應並且可能有助於Scrum比XP更受歡迎。
• DevOps：許多軟體系統在“開發中”和“生產中”之間的邊界上掙扎。DevOps是對此的肯定，並且是關於更緊密地調整開發人員和生產系統之間的反饋迴圈。它支援諸如持續部署，自動釋出和自動監控等活動。

效果
“所有方法都是基於恐懼。你試圖設定習慣，以防止你的恐懼成為現實。” - 極限程式設計解釋，Kent Beck

任何一種方法論都是承諾它將幫助您管理某些隱藏的風險。但這是以犧牲您對方法實踐的努力為代價的。基於方法設計者關心的風險，方法論為我們提供了克服風險的途徑。當我們使用該方法時，這意味著我們正在考慮如何採用我們的行為才能避免這些風險。

方法論失敗​​​​​​​
當我們根據一種方法採取行動時，我們期望能如願以償，如果這沒有實現，那麼我們覺得這種方法失敗了。它可能只是對我們正在執行的專案型別不合適。我們自己的風險目標可能不是該方法設計者所設想的那樣。例如：

• 在發射太空飛船時，美國宇航局不遵循敏捷方法：沒有兩週發射一次，他們不可以迭代，因為失去火箭或衛星的風險太大，這不允許在生產中迭代。風險方向完全不同：您需要管理因需求變更風險而丟失硬體的風險。
• 同樣，政府監管專案通常需要大型的前期的瀑布式設計：讓政府機構的滿意往往表明您需要有一個精心規劃的實現監管的途徑。通常，監管機構和其他利益相關方在實施之前需要對變更進行稽核和批准。使用“迭代幾個月”的方法無法做到這一點。
• 另一方面，Facebook曾經採用 “快速行動，打破它”的方法。當他們嘗試降低在快速發展的社交網路領域中被競爭對手超越創新的風險時，這可能是最佳的。 現在他們已經對此進行了修改，以“在穩定的基礎設施中快速行動”，這可能反映了他們最大的風險不再是競爭，而是糟糕的宣傳。

選擇方法論
採用一種方法作為一個完整的過程集合是有價值的：選擇一種方法（或任何過程）可以減少個人必須做的思考量，但是它也會成為導致失敗的原因。

把責任歸咎於其他地方真好。但是，如果我們真正關心我們的專案，那麼我們必須將方法選擇與專案的風險概況相匹配。我們需要準確理解我們的方法可以幫助我們管理風險，以及它不會提供哪些風險保證; 哪裡合適用，哪裡不合適用。

“鑑於任何規則，無論科學上是”基本的“還是”必要的“，總有一種情況是，不僅要忽視這一規則，而且要採取相反的規則。” - 保羅費耶阿本德

現成的方法不太可能完全符合任何專案的風險。有時，我們需要將方法分解為其元件實踐，並僅應用我們需要的實踐。這需要對個體實踐如何運作以及它們帶來什麼有更細緻的理解。