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