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

核心原則

◆主張簡單

當(dāng)從事開發(fā)工作時，你應(yīng)當(dāng)主張最簡單的解決方案就是最好的解決方案。不要過分構(gòu)建

敏捷開發(fā)

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

◆擁抱變化

需求時刻在變，人們對于需求的理解也時刻在變。項(xiàng)目進(jìn)行中，Project stakeholder可能變化，會有新人加入，也會有舊人離開。Projectstakeholder的觀點(diǎn)也可能變化，你努力的目標(biāo)和成功標(biāo)準(zhǔn)也有可能發(fā)生變化。這就意味著隨著項(xiàng)目的進(jìn)行，項(xiàng)目環(huán)境也在不停的變化，因此你的開發(fā)方法必須要能夠反映這種現(xiàn)實(shí)。

◆你的第二個目標(biāo)是可持續(xù)性

即便你的團(tuán)隊(duì)已經(jīng)把一個能夠運(yùn)轉(zhuǎn)的系統(tǒng)交付給用戶，你的項(xiàng)目也還可能是失敗的--實(shí)現(xiàn)Projectstakeholder的需求，其中就包括你的系統(tǒng)應(yīng)該要有足夠的魯棒性(robust )，能夠適應(yīng)日后的擴(kuò)展。就像AlistairCockburn常說的，當(dāng)你在進(jìn)行軟件開發(fā)的競賽時，你的第二個目標(biāo)就是準(zhǔn)備下一場比賽?？沙掷m(xù)性可能指的是系統(tǒng)的下一個主要發(fā)布版，或是你正在構(gòu)建的系統(tǒng)的運(yùn)轉(zhuǎn)和支持。要做到這一點(diǎn)，你不僅僅要構(gòu)建高質(zhì)量的軟件，還要創(chuàng)建足夠的文檔和支持材料，保證下一場比賽能有效的進(jìn)行。你要考慮很多的因素，包括你現(xiàn)有的團(tuán)隊(duì)是不是還能夠參加下一場的比賽，下一場比賽的環(huán)境，下一場比賽對你的組織的重要程度。簡單的說，你在開發(fā)的時候，你要能想象到未來。

◆遞增的變化

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

◆令Stakeholder投資最大化

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

◆有目的的建模

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

◆多種模型

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

◆高質(zhì)量的工作

沒有人喜歡爛糟糟的工作。做這項(xiàng)工作的人不喜歡，是因?yàn)闆]有成就感;日后負(fù)責(zé)重構(gòu)這項(xiàng)工作(因?yàn)槟承┰?的人不喜歡，是因?yàn)樗y以理解，難以更新;最終用戶不喜歡，是因?yàn)樗嗳?，容易出錯，也不符合他們的期望。

◆快速反饋

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

◆軟件是你的主要目標(biāo)

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

◆輕裝前進(jìn)

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

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

工具

Visual Studio Team Foundation Server

TFS，即團(tuán)隊(duì)基礎(chǔ)服務(wù)器是微軟應(yīng)用程序生命周期管理服務(wù)器，用于幫助團(tuán)隊(duì)在VisualStudio的協(xié)作開發(fā)。最近，它進(jìn)有了升級包括工作項(xiàng)目執(zhí)行改進(jìn)、富文本編輯器的改進(jìn)，以及富文本編輯器中改善的超鏈接體驗(yàn)。

TFS中的Kanban面板也做了改善，提升了可以錄入和跟蹤的項(xiàng)目數(shù)量，該服務(wù)器現(xiàn)在有一個“利益相關(guān)者”許可，來規(guī)范服務(wù)器的訪問權(quán)限。

Atlassian Jira

Atlassian的是一個很流行的工具，主要用于跟蹤產(chǎn)品開發(fā)、幫助團(tuán)隊(duì)整理問題、安排工具，以及記錄團(tuán)隊(duì)行為。它Jira

Agile插件使開發(fā)人員更容易部署關(guān)鍵敏捷策略，這包括用戶故事開發(fā)、沖刺模塊構(gòu)建，以及可視化的團(tuán)隊(duì)活動。

Axosoft

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

LeanKit

使用 LeanKit的團(tuán)隊(duì)可以看到工作負(fù)載的分布并導(dǎo)出歷史數(shù)據(jù)。最近 LeanKit 進(jìn)行了一次升級，包含單點(diǎn)登錄功能和附加報(bào)告功能，從而提供更細(xì)粒度的數(shù)據(jù)詳細(xì)信息。

Planbox

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

國內(nèi)敏捷軟件開發(fā)轉(zhuǎn)型熱潮方興末艾，敏捷組織里的角色和責(zé)任比起傳統(tǒng)組織已經(jīng)完全不同，每個組織實(shí)施敏捷都是量身定制的，每個團(tuán)隊(duì)執(zhí)行敏捷也是因人而異，如何判斷一個團(tuán)隊(duì)就是敏捷團(tuán)隊(duì)呢?項(xiàng)目管理面臨的挑戰(zhàn)是什么?如何把握時代的脈搏，在住址變革中占領(lǐng)制高點(diǎn)，發(fā)揮最大價(jià)值?一天不學(xué)習(xí)恐怕就OUT了，這是一個持續(xù)學(xué)習(xí)，精益求精的時代，項(xiàng)目經(jīng)理的領(lǐng)導(dǎo)在哪里?

一切答案盡在《項(xiàng)目經(jīng)理在敏捷環(huán)境中如何轉(zhuǎn)型》研討會，報(bào)名地址：http://www.huodongxing.com/event/4378803066000