敏捷開發以用戶的需求進化為核心，采用迭代、循序漸進的方法進行軟件開發。在敏捷開發中，軟件項目在構建初期被切分成多個子項目，各個子項目的成果都經過測試，具備可視、可集成和可運行使用的特征。換言之，就是把一個大項目分為多個相互聯系，但也可獨立運行的小項目，并分別完成，在此過程中軟件一直處于可使用狀態。

核心原則

◆主張簡單

當從事開發工作時，你應當主張最簡單的解決方案就是最好的解決方案。不要過分構建

敏捷開發

(overbuild)你的軟件。用AM的說法就是，如果你現在并不需要這項額外功能，那就不要在模型中增加它。要有這樣的勇氣：你現在不必要對這個系統進行過分的建模(over-model)，只要基于現有的需求進行建模，日后需求有變更時，再來重構這個系統。盡可能的保持模型的簡單。

◆擁抱變化

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

◆你的第二個目標是可持續性

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

◆遞增的變化

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

◆令Stakeholder投資最大化

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

◆有目的的建模

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

◆多種模型

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

◆高質量的工作

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

◆快速反饋

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

◆軟件是你的主要目標

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

◆輕裝前進

你建立一個artifact，然后決定要保留它，隨著時間的流逝，這些artifact都需要維護。如果你決定保留7個模型，不論何時，一旦有變化發生(新需求的提出，原需求的更新，團隊接受了一種新方法，采納了一項新技術...)，你就需要考慮變化對這7個模型產生的影響并采取相應的措施。而如果你想要保留的僅是3個模型，很明顯，你實現同樣的改變要花費的功夫就少多了，你的靈活性就增強了，因為你是在輕裝前進。類似的，你的模型越復雜，越詳細，發生的改變極可能就越難實現(每個模型都更“沉重”了些，因此維護的負擔也就大了)。每次你要決定保留一個模型時，你就要權衡模型載有的信息對團隊有多大的好處(所以才需要加強團隊之間，團隊和project

stakeholder之間的溝通)。千萬不要小看權衡的嚴重性。一個人要想過沙漠，他一定會攜帶地圖，帽子，質地優良的鞋子，水壺。如果他帶了幾百加侖的水，能夠想象的到的所有求生工具，一大堆有關沙漠的書籍，他還能過得去沙漠嗎?同樣的道理，一個開發團隊決定要開發并維護一份詳細的需求文檔，一組詳細的分析模型，再加上一組詳細的架構模型，以及一組詳細的設計模型，那他們很快就會發現，他們大部分的時間不是花在寫源代碼上，而是花在了更新文檔上。

工具

Visual Studio Team Foundation Server

TFS，即團隊基礎服務器是微軟應用程序生命周期管理服務器，用于幫助團隊在VisualStudio的協作開發。最近，它進有了升級包括工作項目執行改進、富文本編輯器的改進，以及富文本編輯器中改善的超鏈接體驗。

TFS中的Kanban面板也做了改善，提升了可以錄入和跟蹤的項目數量，該服務器現在有一個“利益相關者”許可，來規范服務器的訪問權限。

Atlassian Jira

Atlassian的是一個很流行的工具，主要用于跟蹤產品開發、幫助團隊整理問題、安排工具，以及記錄團隊行為。它Jira

Agile插件使開發人員更容易部署關鍵敏捷策略，這包括用戶故事開發、沖刺模塊構建，以及可視化的團隊活動。

Axosoft

Axosoft以前被稱為Axosoft OnTimeScrum，這一軟件套件有四個功能模塊：Scrum、Bug追蹤器、幫助臺和Wiki。它是基于HTML5構建的，幫助開發團隊管理待辦事項列表、發布和沖刺，帶有燃盡圖功能，有一個管理儀表板用于跟蹤編碼和修改BUG的時間。

LeanKit

使用 LeanKit的團隊可以看到工作負載的分布并導出歷史數據。最近 LeanKit 進行了一次升級，包含單點登錄功能和附加報告功能，從而提供更細粒度的數據詳細信息。

Planbox

Planbox敏捷管理工具通過燃盡圖跟蹤進程，集成客戶反饋，它的目標人群很廣泛。最近它對應用的前端和后端都做的升級，添加了更強大的報告功能和新儀表盤，來提升項目速度。時間跟蹤特性和工具允許用戶得到所有他們在Planbox產生的數據。

國內敏捷軟件開發轉型熱潮方興末艾，敏捷組織里的角色和責任比起傳統組織已經完全不同，每個組織實施敏捷都是量身定制的，每個團隊執行敏捷也是因人而異，如何判斷一個團隊就是敏捷團隊呢?項目管理面臨的挑戰是什么?如何把握時代的脈搏，在住址變革中占領制高點，發揮最大價值?一天不學習恐怕就OUT了，這是一個持續學習，精益求精的時代，項目經理的領導在哪里?

一切答案盡在《項目經理在敏捷環境中如何轉型》研討會，報名地址：http://www.huodongxing.com/event/4378803066000