敏捷誤解：無需設計的演示驅動開發 - Darko

banq發表於2021-06-11
敏捷

諸如Scrum等管理風格是以較短的開發週期為中心，也就是衝刺，許多組織誤解了這一點，並採取“無前期設計”和“從第一天開始編碼”的方法。
對他們來說，理論上我們不需要設計軟體解決方案。我們開始編碼，但增量很小。在每個衝刺結束時，向產品所有者和利益相關者展示工作軟體的演示。利益相關者提供反饋，然後我們修改應用程式，依此類推，直到我們可以交付軟體應用程式。
我把這種對敏捷原則的誤解稱為演示驅動開發（Demo Driven Development，也簡稱DDD）。根據對方法論的這種誤解，整個團隊都衝向這個短期目標，並鼓勵走捷徑，以便為衝刺結束做好演示準備。
這似乎是個好主意，它讓人們專注於一個共同的目標。有些人可能會說這讓他們在衝刺期間更加努力地工作，因為他們有一個可以實現的目標。此外，產品利益相關者有機會提供早期反饋，如果需求被誤解，可以儘早糾正。
這種開發方式還有許多其他所謂的好處，並且近年來一直在增長。我認為這種方法在一定程度上適用於某些情況：對於小型專案，對於具有相對簡單領域的專案，或者開發人員對領域非常瞭解的情況。
但是，我建議這種軟體開發風格不適合大中型專案或具有複雜領域的專案。
各種研究，例如Standish Chaos Report，表明超過一半的軟體開發專案沒有成功。
專案越大，失敗的可能性就越大。因此，如果您的專案並不小，那麼您就有統計資料對您不利。為了增加專案成功的機會，我建議採用領域驅動設計方法，而不是採用這些“從第一天開始編碼”和“無前期設計”的軟體開發風格，這種方法特別有益於大中型專案，或任何具有複雜領域的專案。
 
DDD是一種軟體開發方法，由Eric Evans在他的著作領域驅動設計：解決軟體核心的複雜性中創造，該書最初於 2003 年出版。從那時起，不斷增長的 DDD 實踐者社群的許多貢獻豐富了它。
在我們研究使用 DDD 方法如何使您的專案受益之前，讓我們更詳細地探討這個競爭對手的“演示驅動開發”實踐（我稱之為），或者更確切地說是檢查它的不足之處。
法國數學家埃米爾·博雷爾 (Emil Borel)在 1913 年提出了無限猴子定理，該定理指出，一隻猴子在打字機上隨機敲擊無限長的時間會產生威廉·莎士比亞的全集。
 

沒有前期設計
總體而言，敏捷，尤其是 Scrum，以“無前期設計”方法為榮。我們的想法是，每個衝刺我們都將積壓工作中的一個史詩或幾個故事帶入衝刺。我們專注於一次構建產品的一小部分。在衝刺結束時，我們展示我們生產的產品，產品負責人和其他利益相關者給我們反饋，告訴我們要改變什麼。透過從sprint到sprint的迭代，每次更改和重建產品，最終我們會得到一個完整的解決方案。嗯，這讓我想起了一件事……
是的，正如你猜的那樣，這聽起來像是：“如果你有無數次衝刺和一群猴子，你最終會得到想要的軟體解決方案”
好吧，我們確實使用軟體開發人員而不是猴子——所以我們不需要無限量的時間。但是，這種方法確實為大多數專案增加了大量時間。對於複雜的大型專案，這將導致程式碼在 DDD 社群中被稱為“大泥球”或“義大利麵條式程式碼”。持續重構方法可以提供幫助，但實際上有多少產品所有者和利益相關者允許這樣做？
 

儘快開始編碼
在 IT 工作了 20 多年之後，“從第一天開始編碼”對我來說是軟體開發專案中可能犯的最大錯誤。根據領域驅動設計原則，開發人員對領域的理解被提煉成程式碼。實際上，這意味著如果軟體開發人員誤解了領域和需求，他們將開始構建錯誤的產品。
確實，隨著專案的進展，經過多次迭代和衝刺，開發人員最終會了解他們需要什麼。不幸的是，到了這個階段，他們已經建立了大量結構不佳的程式碼，因此難以更改和維護。這就是開發人員對利益相關者說的重點：“我們真的應該廢棄所有現有程式碼並從頭開始重建。” 在這一點上，管理人員開始尋找一些“優秀的開發人員”來僱用，當然，這些並不存在。

問題 不在於開發人員的質量，而在於使用了錯誤的軟體開發方法。
 

領域驅動設計
幸運的是還有另一種方式。您不需要執行眾所周知的“兩年分析階段”，這通常被認為是瀑布方法的陷阱，您也不必在沒有任何設計的情況下開始編碼。相反，您可以採用領域驅動設計方法。
領域驅動設計 (DDD)是一種軟體開發方法：一組用於幫助開發複雜系統的技術、原則和模式。
實踐 DDD 的目標是用系統的方法處理複雜的場景，使領域專家（利益相關者、產品使用者等）和開發團隊（產品所有者、軟體架構師、開發人員等）可以有效地協作最小摩擦。通常，他們在域探索會話期間聚集在白板周圍，並使用 DDD 提供的多種技術生成各種型別的圖表。這些技術超出了本部落格的範圍，網際網路上有許多資源可以為您提供概述。
 

領域驅動設計和敏捷
DDD可以和Agile結合使用，畢竟是兩種不同的東西。敏捷是一種專案管理方法，而 DDD 是一套軟體開發技術和方法。
我想在這個部落格中提出的主要觀點是：不要在每個衝刺結束時專注於演示完全工作的軟體。相反，您可以演示作為 Knowledge Crunching 會話產品的各種 DDD 工件。例如，您可以演示域故事圖、事件風暴表、域模型中的實體圖、限界上下文圖……所有這些工件都可以在 Sprint 審查會議上進行演示和審查。
這意味著您仍然可以迭代，但不能透過重新開發程式碼，而是可以透過改進領域模型來迭代圖表。更改一些圖表比更改工作軟體更容易（也更便宜）。
此外，如果您正在與 DDD 建模並行進行原型設計，那麼您可以演示各種原型（同時向利益相關者強調“這只是一個原型。”）
 



 

相關文章