Agile 敏捷建模思想1

      AM的價值觀包括了XP的四個價值觀：溝通、簡單、反饋、勇氣，此外，還擴展了第五個價值觀：謙遜。

      溝通. 建模不但能夠促進你團隊內部的開發人員之間溝通、還能夠促進你的團隊和你的project stakeholder之間的溝通。

      簡單. 畫一兩張圖表來代替幾十甚至幾百行的代碼，通過這種方法，建模成為簡化軟件和軟件（開發）過程的關鍵。這一點對開發人員而言非常重要－它簡單，容易發現出新的想法，隨著你（對軟件）的理解的加深，也能夠很容易的改進。

      反饋. Kent Beck在Extreme Programming Explained中有句話講得非常好：“樂觀是編程的職業病，反饋則是其處方�！蓖ㄟ^圖表來交流你的想法，你可以快速獲得反饋，并能夠按照建議行事。

      勇氣. 勇氣非常重要，當你的決策證明是不合適的時候，你就需要做出重大的決策，放棄或重構（refactor）你的工作，修正你的方向。

      謙遜. 最優秀的開發人員都擁有謙遜的美德，他們總能認識到自己并不是無所不知的。事實上，無論是開發人員還是客戶，甚至所有的project stakeholder，都有他們自己的專業領域，都能夠為項目做出貢獻。一個有效的做法是假設參與項目的每一個人都有相同的價值，都應該被尊重。

      敏捷建模的原則

      敏捷建模（AM）定義了一系列的核心原則和輔助原則，它們為軟件開發項目中的建模實踐奠定了基石。其中一些原則是從XP中借鑒而來，在Extreme Programming Explained中有它們的詳細描述。而XP中的一些原則又是源于眾所周知的軟件工程學。復用的思想隨處可見！基本上，本文中對這些原則的闡述主要側重于它們是如何影響著建模工作；這樣，對于這些借鑒于XP的原則，我們可以從另一個角度來看待。

      核心原則：

      主張簡單. 當從事開發工作時，你應當主張最簡單的解決方案就是最好的解決方案。不要過分構建（overbuild）你的軟件。用AM的說法就是，如果你現在并不需要這項額外功能，那就不要在模型中增加它。要有這樣的勇氣：你現在不必要對這個系統進行過分的建模（over-model），只要基于現有的需求進行建模，日后需求有變更時，再來重構這個系統。盡可能的保持模型的簡單。

      擁抱變化. 需求時刻在變，人們對于需求的理解也時刻在變。項目進行中，Project stakeholder可能變化，會有新人加入，也會有舊人離開。Project stakeholder的觀點也可能變化，你努力的目標和成功標準也有可能發生變化。這就意味著隨著項目的進行，項目環境也在不停的變化，因此你的開發方法必須要能夠反映這種現實。

      你的第二個目標是可持續性. 即便你的團隊已經把一個能夠運轉的系統交付給用戶，你的項目也還可能是失敗的－－實現Project stakeholder的需求，其中就包括你的系統應該要有足夠的魯棒性（robust ），能夠適應日后的擴展。就像Alistair Cockburn常說的，當你在進行軟件開發的競賽時，你的第二個目標就是準備下一場比賽�？沙掷m性可能指的是系統的下一個主要發布版，或是你正在構建的系統的運轉和支持。要做到這一點，你不僅僅要構建高質量的軟件，還要創建足夠的文檔和支持材料，保證下一場比賽能有效的進行。你要考慮很多的因素，包括你現有的團隊是不是還能夠參加下一場的比賽，下一場比賽的環境，下一場比賽對你的組織的重要程度。簡單的說，你在開發的時候，你要能想象到未來。

      遞增的變化. 和建模相關的一個重要概念是你不用在一開始就準備好一切。實際上，你就算想這么做也不太可能。而且，你不用在模型中包容所有的細節，你只要足夠的細節就夠了。沒有必要試圖在一開始就建立一個囊括一切的模型，你只要開發一個小的模型，或是概要模型，打下一個基礎，然后慢慢的改進模型，或是在不在需要的時候丟棄這個模型。這就是遞增的思想。     

      令Stakeholder投資最大化. 你的project stakeholder為了開發出滿足自己需要的軟件，需要投入時間、金錢、設備等各種資源。stakeholder應該可以選取最好的方式投資，也可以要求你的團隊不浪費資源。并且，他們還有最后的發言權，決定要投入多少的資源。如果是這些資源是你自己的，你希望你的資源被誤用嗎。

      有目的的建模.對于自己的artifact，例如模型、源代碼、文檔，很多開發人員不是擔心它們是否夠詳細，就是擔心它們是否太過詳細，或擔心它們是否足夠正確。你不應該毫無意義的建模，應該先問問，為什么要建立這個artifact，為誰建立它。和建模有關，也許你應該更多的了解軟件的某個方面，也許為了保證項目的順利進行，你需要和高級經理交流你的方法，也許你需要創建描述系統的文檔，使其他人能夠操作、維護、改進系統。如果你連為什么建模，為誰建模都不清楚，你又何必繼續煩惱下去呢？首先，你要確定建模的目的以及模型的受眾，在此基礎上，再保證模型足夠正確和足夠詳細。一旦一個模型實現了目標，你就可以結束目前的工作，把精力轉移到其它的工作上去，例如編寫代碼以檢驗模型的運作。該項原則也可適用于改變現有模型：如果你要做一些改變，也許是一個熟知的模式，你應該有做出變化的正確理由（可能是為了支持一項新的需求，或是為了重構以保證簡潔）。關于該項原則的一個重要暗示是你應該要了解你的受眾，即便受眾是你自己也一樣。例如，如果你是為維護人員建立模型，他們到底需要些什么？是厚達500頁的詳細文檔才夠呢，還是10頁的工作總覽就夠了？你不清楚？去和他們談談，找出你想要的。

      多種模型.開發軟件需要使用多種模型，因為每種模型只能描述軟件的單個方面，“要開發現今的商業應用，我們該需要什么樣的模型？”考慮到現今的軟件的復雜性，你的建模工具箱應該要包容大量有用的技術（關于artifact的清單，可以參閱AM的建模artifact）。有一點很重要，你沒有必要為一個系統開發所有的模型，而應該針對系統的具體情況，挑選一部分的模型。不同的系統使用不同部分的模型。比如，和家里的修理工作一樣，每種工作不是要求你用遍工具箱里的每一個工具，而是一次使用某一件工具。又比如，你可能會比較喜歡某些工具，同樣，你可會偏愛某一種模型。有多少的建模artifact可供使用呢，如果你想要了解這方面的更多細節，我在Be Realistic About the UML中列出了UML的相關部分，如果你希望做進一步的了解，可以參閱白皮書The Object Primer -- An Introduction to Techniques for Agile Modeling。

      高質量的工作.沒有人喜歡爛糟糟的工作。做這項工作的人不喜歡，是因為沒有成就感；日后負責重構這項工作（因為某些原因）的人不喜歡，是因為它難以理解，難以更新；最終用戶不喜歡，是因為它太脆弱，容易出錯，也不符合他們的期望。

      快速反饋.從開始采取行動，到獲得行動的反饋，二者之間的時間至關緊要。和其他人一共開發模型，你的想法可以立刻獲得反饋，特別是你的工作采用了共享建模技術的時候，例如白板、CRC卡片或即時貼之類的基本建模材料。和你的客戶緊密工作，去了解他們的的需求，去分析這些需求，或是去開發滿足他們需求的用戶界面，這樣，你就提供了快速反饋的機會。

      軟件是你的主要目標. 軟件開發的主要目標是以有效的方式，制造出滿足project stakeholder需要的軟件，而不是制造無關的文檔，無關的用于管理的artifact，甚至無關的模型。任何一項活動（activity ），如果不符合這項原則，不能有助于目標實現的，都應該受到審核，甚至取消。

      輕裝前進.你建立一個artifact，然后決定要保留它，隨著時間的流逝，這些artifact都需要維護。如果你決定保留7個模型，不論何時，一旦有變化發生（新需求的提出，原需求的更新，團隊接受了一種新方法，采納了一項新技術...），你就需要考慮變化對這7個模型產生的影響并采取相應的措施。而如果你想要保留的僅是3個模型，很明顯，你實現同樣的改變要花費的功夫就少多了，你的靈活性就增強了，因為你是在輕裝前進。類似的，你的模型越復雜，越詳細，發生的改變極可能就越難實現（每個模型都更“沉重”了些，因此維護的負擔也就大了）。每次你要決定保留一個模型時，你就要權衡模型載有的信息對團隊有多大的好處（所以才需要加強團隊之間，團隊和project stakeholder之間的溝通）。千萬不要小看權衡的嚴重性。一個人要想過沙漠，他一定會攜帶地圖，帽子，質地優良的鞋子，水壺。如果他帶了幾百加侖的水，能夠想象的到的所有求生工具，一大堆有關沙漠的書籍，他還能過得去沙漠嗎？同樣的道理，一個開發團隊決定要開發并維護一份詳細的需求文檔，一組詳細的分析模型，再加上一組詳細的架構模型，以及一組詳細的設計模型，那他們很快就會發現，他們大部分的時間不是花在寫源代碼上，而是花在了更新文檔上。
補充原則：

      內容比表示更重要.一個模型有很多種的表示方法。例如，可以通過在一張紙上放置即時貼的方法來建立一個用戶界面規格（基本/低精度原型）。它的表現方式可以是紙上或白板上的草圖，可以是使用原型工具或編程工具建立和傳統的原型，也可以是包括可視界面和文本描述的正式文檔。有一點很有意思，一個模型并不一定就是文檔。它們通常作為其它artifact的輸入，例如源代碼，但不必把它們處理為正式的文檔，即使是使用CASE工具建立的復雜的圖表，也是一樣。要認識到一點，要利用建模的優點，而不要把精力花費在創建和維護文檔上。

      三人行必有我師.你不可能完全精通某項技術，你總是有機會學習新的知識，拓展知識領域。把握住這個機會，和他人一同工作，向他人學習，試試做事的新方式，思考什么該做，什么不該做。技術的變化非常的快，現有的技術（例如Java）以難以置信的速度在改進，新的技術（例如C#和.NET）也在有規律的產生�，F存開發技術的改進相對會慢一些，但也在持續的改進中－－計算機產業屬于工業，我們已經掌握了其中的試驗基本原理，但我們還在不斷的研究，不斷的實踐，不斷的改進我們對它的了解。我們工作在一個變化是家常便飯的產業中，我們必須通過訓練、教育、思考、閱讀、以及和他人合作，抓住每一個機會學習新的處事之道。

      了解你的模型.因為你要使用多種模型，你需要了解它們的優缺點，這樣才能夠有效的使用它們。

      了解你的工具.軟件（例如作圖工具、建模工具）有各種各樣的特點。如果你打算使用一種建模工具，你就應當了解什么時候適合用它，什么時候不適合用它。

      局部調整. 你的軟件開發方法要能夠反映你的環境，這個環境包括組織特征，project stakeholder的特征，項目自身的特征。有可能受其影響的問題包括：你使用的建模技術（也許你的用戶堅持要看到一個細節的用戶界面，而不是初始草圖或基本原型）；你使用的工具（可能你沒有數字照相機的預算，或是你已經擁有某個CASE工具的license）；你遵循的軟件過程（你的組織采用XP的開發過程，或是RUP，或是自己的過程）。因此你會調整你的方法，這種調整可能是針對項目的，也可能是針對個人的。例如，有些開發人員傾向于使用某一類工具，有些則不用。有些人在編碼上花大力氣，基本不做建模，有些則寧可在建模上多投入一些時間。

      開放誠實的溝通.人們需要能夠自由的提出建議，而且人們還應該能夠感受到他們是自由的。建議可能是和模型有關的想法：也許是某些人提出某部分新的設計方法，或是某個需求的新的理解；建議還可能是一些壞消息，例如進度延誤；或僅僅是簡單的工作狀況報告。開放誠實的溝通是人們能夠更好的決策，因為作為決策基礎的信息會更加準確。

文章來源于領測軟件測試網 http://www.kjueaiud.com/

TAG: Agile 建模 思想