「首席架構師看敏捷建模」紀律：敏捷設計理念
- 2019 年 10 月 4 日
- 筆記
本文概述了敏捷軟體開發團隊的設計策略。這些策略對於擴展敏捷軟體開發以滿足現代IT組織的實際需求至關重要。敏捷的設計方法與傳統方法截然不同，顯然也更有效。重要的是要了解：
- 敏捷設計實踐
- 敏捷設計理念
- 整個敏捷生命周期的設計
1.敏捷設計實踐
從高級架構實踐到低級編程實踐，有一系列敏捷設計實踐，參見圖1。這些實踐中的每一個都很重要，如果您的團隊要在敏捷設計方面有效，則每個實踐都是必需的。
圖1.敏捷設計實踐。
2.敏捷設計理念
- 敏捷設計是緊急的，它們不是預先定義的。隨著時間的推移，您的整體系統設計將不斷湧現，不斷發展以滿足新的需求並酌情利用新技術。雖然在「迭代0」期間您經常會在項目的最初階段進行一些初始架構建模，但這足以讓您的團隊繼續前進。在您開始編碼之前，敏捷者不需要獲得完整記錄的模型集（儘管有時，有時候，您可能需要執行前瞻性建模）。
- 您的單元測試構成了大部分詳細的設計文檔。使用測試驅動開發（TDD）開發方法，您可以編寫測試，然後編寫足夠的域程式碼來完成測試。這種方法的一個重要副作用是，您的單元測試不僅驗證您的程式碼，它們還以可執行規範的形式構成您的大部分設計文檔。TDD是AMDD的補充，實際上是由AMDD擴展的。
- 設計模型需要勉強夠用。您不需要對模型中的每個細節進行建模，模型不需要完美，並且它們當然不需要完整。還記得你最後一次從設計規範編碼（如果你曾經做過）？你真的看過所有細粒度的細節嗎？不，因為你有足夠的能力自己處理細節。
- 多種型號。有效的開發人員意識到每種類型的模型都有其優點和缺點，因此他們需要為手頭的工作應用正確的模型。由於軟體開發很複雜，因此您很快意識到需要了解各種模型才能有效。本新聞稿中提到的所有模型等都在Agile Models Distilled頁面中進行了描述。
- 您通常只需要模型的子集。雖然您可以使用許多建模技術，但事實是任何給定的項目團隊只需要一個子集。可以這樣想：在家裡的工具箱里，你有各種各樣的螺絲刀，扳手，鉗子等等。對於任何給定的維修工作，您將只使用一些工具。不同的工作，不同的工具。您永遠不需要同時使用所有工具，但隨著時間的推移，您將以各種方式使用它們。
- 每種型號都可用於各種用途。UML類圖可用於描述高級域模型或低級設計，更不用說介於兩者之間的事物了。用例可用於模擬流程的基本性質或詳細的系統使用描述，其中考慮了架構決策。永遠不要低估模型的靈活性。
- 設計師也應該編碼。每當模型被移交給其他人進行編碼時，程式設計師就不會理解模型，會遺漏一些細微差別，甚至可能完全忽略模型以支援他們自己的方法。此外，即使交接成功，您也會發現模型中需要的細節遠遠多於您自己編寫的細節。簡而言之，將設計與編程分離是一個風險和昂貴的主張。在團隊中推廣可以設計和編碼的專家是更有效的。
- 用程式碼證明它。永遠不要假設你的設計有效相反，通過編寫程式碼來確定它是否確實有效，從而獲得具體的回饋。
- 回饋是你的朋友。永遠不要忘記你和你團隊中的其他人一樣只是凡人。期待收到回饋 – 我建議您積極尋求 – 關於您的工作，並準備好考慮並採取相應行動。您的系統不僅會更好，您還可以在此過程中學到一些東西。
- 有時最簡單的工具是複雜的CASE工具。在需求方面，我更喜歡紙和白板等包容性工具，但在設計方面，我傾向於使用複雜的工具（重新）為我生成程式碼。就像我的祖父總是說的那樣，你應該使用合適的工具來完成工作。
- 迭代，迭代，迭代。使用迭代的開發方法，您可以根據需求進行一些工作，進行一些分析，進行一些設計，一些編碼，一些測試，並根據需要在這些活動之間進行迭代。您還將在處理各種工件之間來回迭代，在正確的時間處理正確的工件。
- 設計非常重要，你應該每天都這樣做。在構建之前，仔細思考如何構建某些東西，實際設計它是至關重要的。您的設計工作可以採用白板上的草圖形式，使用複雜建模工具創建的詳細模型，或者在編寫業務程式碼之前編寫的簡單測試。敏捷開發人員意識到設計是如此重要以至於他們每天都在做，設計不僅僅是您在完成編寫源程式碼的「實際工作」之前在項目早期所做的一個階段。
- 明智地為您的實施環境設計。利用您的實施環境的功能，但要聰明一點。權衡是正常的，但要了解其影響並管理所涉及的風險。每次使用產品（例如資料庫，作業系統或中間件工具）中的獨特性能增強功能時，您可能會將系統與該產品耦合，從而降低其可移植性。為了最大限度地降低實施環境對系統的影響，您可以對軟體進行分層並包裝特定功能，使其對用戶顯得通用。
- 記錄複雜的事情。如果它很複雜，那就徹底記錄下來。更好的是，花時間設計它，這很簡單。記住AM練習創建簡單內容。
- 不要過度記錄。您需要記錄您的設計，但不應該過度記錄。請記住，用戶付錢給您構建系統，而不是記錄它們。在記錄和文檔之間有一個細微的界限，只有通過經驗才能找到它。在文檔方面盡量保持敏捷。
- 不要被數據社區所牽制。不幸的是，數據社區中的許多人認為您需要採用串列方法進行設計，尤其是涉及資料庫時。這種信念是由於不了解進化發展或某種被誤導的需要來確定「一個真理高於一切」。諸如敏捷數據建模，資料庫重構和資料庫回歸測試等進化資料庫設計技術在實踐中工作得非常好。
- 記住用戶體驗（UX）。對於最終用戶，用戶介面（UI）是系統。這意味著您的設計的一個重要方面是UX。有關更多資訊，請參閱敏捷可用性簡介以及如何將設計集成到敏捷過程中。
3.整個生命周期的設計
圖2描繪了通用敏捷軟體開發生命周期。為了便於討論，需要注意的重要一點是，傳統主義者不熟悉設計階段，也沒有需求階段。敏捷開發人員將在迭代0期間進行一些高級架構建模，也稱為預熱階段，在開發迭代期間甚至在最終遊戲期間（如果需要）進行詳細設計。
圖2. Agile SDLC（單擊以展開）。
圖3描繪了敏捷模型驅動開發（AMDD）生命周期，其重點是建模如何適應整個敏捷軟體開發生命周期。在項目早期，您至少需要了解如何構建系統。它是大型機COBOL應用程式嗎？一個.Net應用程式？J2EE？別的什麼？在迭代0期間，項目的開發人員將聚集在一個房間，通常圍繞白板，討論，然後勾勒出系統的潛在架構。這種架構可能會隨著時間的推移而發展，它不會非常詳細（它現在只需要足夠好），並且需要編寫很少的文檔（如果有的話）。目標是確定架構策略，而不是編寫大量文檔。
圖3. AMDD生命周期。
當開發人員有新的實施要求時，他們會問自己是否理解要求的內容。如果沒有，那麼他們會做一些即時（JIT）「模型風暴」來確定實施要求的策略。這種模型風暴通常在迭代開始時在迭代的詳細規劃工作期間完成，或者在迭代期間的某個時間如果他們意識到他們需要進一步探索需求。這種建模工作的一部分將是對需求的分析以及解決方案的設計，這通常會在幾分鐘的時間內發生。在極限編程（XP）中，他們將此稱為「快速設計會話」。
如果團隊採用測試驅動開發（TDD）方法，則詳細設計被有效地指定為開發人員測試，而不是詳細模型。因為在編寫足夠的生產程式碼來完成測試之前編寫測試，實際上在編寫測試時會考慮生產程式碼的設計。您不是創建必然會過時的靜態設計文檔，而是編寫一個可執行規範，開發人員可以通過該規範來保持最新，因為它實際上為它們提供了價值。該策略是單一採購資訊的AM實踐的一個示例，其中資訊被捕獲一次並用於多種目的。在這種情況下，詳細規範和確認測試。
當你停下來思考它時，特別是在圖2中，TDD有點用詞不當。雖然您的開發人員測試正在「推動」程式碼的設計，但您的敏捷模型正在推動您的整體思考。
原文：http://agilemodeling.com/essays/agileDesign.htm
本文：https://pub.intelligentx.net/agilemodeling-agile-design
