敏捷開發(fā)（Agile Development）指南，看這一篇就夠了！

ACP敏捷項目管理認證 知識體系 考證須知 證書含金量 培訓(xùn)大綱 3分鐘小視頻 我要提問

PMI-ACP認證是由美國項目管理協(xié)會（PMI）于2011年推出的一種敏捷項目管理認證。它是PMI針對敏捷實踐者的資格認證，同時也是敏捷項目管理的行業(yè)標準。該認證旨在評估從業(yè)者在敏捷方法、實踐和工具方面的知識和技能，以及在敏捷環(huán)境中管理項目的能力。通過PMI-ACP認證，可以證明個人在敏捷項目管理方面的專業(yè)能力和實踐經(jīng)驗。

• 中文名ACP敏捷項目管理認證
• 英文名Agile Certified Practitioner
• 英文簡稱ACP
• 頒證機構(gòu)PMI（美國項目管理協(xié)會）
• 證書類別敏捷
• 同類認證Scrum Master、ITIL4 HVIT、DevOps

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

敏捷開發(fā)的路線

Test-Driven Development，測試驅(qū)動開發(fā)

它是敏捷開發(fā)的_重要的部分。在ThoughtWorks，我們實現(xiàn)任何一個功能都是從測試開始，首先對業(yè)務(wù)需求進行分析，分解為一個一個的Story，記錄在Story Card上。然后兩個人同時坐在電腦前面，一個人依照Story，從業(yè)務(wù)需求的角度來編寫測試代碼，另一個人看著他并且進行思考，如果有不同的意見就會提出來進行討論，直到達成共識，這樣寫出來的測試代碼就真實反映了業(yè)務(wù)功能需求。接著由另一個人控制鍵盤，編寫該測試代碼的實現(xiàn)。如果沒有測試代碼，就不能編寫功能的實現(xiàn)代碼。先寫測試代碼，能夠讓開發(fā)人員明確目標，就是讓測試通過。

Continuous Integration，持續(xù)集成

在以往的軟件開發(fā)過程中，集成是一件很痛苦的事情，通常很長時間才會做一次集成，這樣的話，會引發(fā)很多問題，比如 build未通過或者單元測試失敗。敏捷開發(fā)中提倡持續(xù)集成，一天之內(nèi)集成十幾次甚至幾十次，如此頻繁的集成能盡量減少沖突，由于集成很頻繁，每一次集成的改變也很少，即使集成失敗也容易定位錯誤。一次集成要做哪些事情呢？它至少包括：獲得所有源代碼、編譯源代碼、運行所有測試，包括單元測試、功能測試等；確認編譯和測試是否通過，_后發(fā)送報告。當(dāng)然也會做一些其它的任務(wù)，比如說代碼分析、測試覆蓋率分析等等。在我們公司里，開發(fā)人員的桌上有一個火山燈用來標志集成的狀態(tài)，如果是黃燈，表示正在集成；如果是綠燈，表示上一次集成通過，開發(fā)人員在這時候獲得的代碼是可用而可靠的；如果顯示為紅燈，就要小心了，上一次集成未通過，需要盡快定位失敗原因從而讓燈變綠。在持續(xù)集成上，我們公司使用的是自己開發(fā)的產(chǎn)品CruiseControl。

Refactoring，重構(gòu)

相信大家對它都很熟悉了，有很多很多的書用來介紹重構(gòu)，_著名的是Martin的《重構(gòu)》，Joshua的《從重構(gòu)到模式》等。重構(gòu)是在不改變系統(tǒng)外部行為下，對內(nèi)部結(jié)構(gòu)進行整理優(yōu)化，使得代碼盡量簡單、優(yōu)美、可擴展。在以往開發(fā)中，通常是在有需求過來，現(xiàn)在的系統(tǒng)架構(gòu)不容易實現(xiàn)，從而對原有系統(tǒng)進行重構(gòu)；或者在開發(fā)過程中有剩余時間了，對現(xiàn)在代碼進行重構(gòu)整理。但是在敏捷開發(fā)中，重構(gòu)貫穿于整個開發(fā)流程，每一次開發(fā)者check in代碼之前，都要對所寫代碼進行重構(gòu)，讓代碼達到clean code that works。值得注意的是，在重構(gòu)時，每一次改變要盡可能小，用單元測試來_重構(gòu)是否引起沖突，并且不只是對實現(xiàn)代碼進行重構(gòu)，如果測試代碼中有重復(fù)，也要對它進行重構(gòu)。

Pair-Programming，結(jié)對編程。

在敏捷開發(fā)中，做任何事情都是Pair的，包括分析、寫測試、寫實現(xiàn)代碼或者重構(gòu)。Pair做事有很多好處，兩個人在一起探討很容易產(chǎn)生思想的火花，也不容易走上偏路。在我們公司，還有很多事都是Pair來做，比如Pair學(xué)習(xí)，Pair翻譯，Pair做PPT，關(guān)于這個話題，錢錢同學(xué)有一篇很有名的文章對它進行介紹，名為Pair Programming (結(jié)對編程)。

Stand up，站立會議。

每天早上，項目組的所有成員都會站立進行一次會議，由于是站立的，所以時間不會很長，一般來說是15-20分鐘。會議的內(nèi)容并不是需求分析、任務(wù)分配等，而是每個人都回答三個問題：1. 你昨天做了什么？2. 你今天要做什么？3. 你遇到了哪些困難？站立會議讓團隊進行交流，彼此相互熟悉工作內(nèi)容，如果有人曾經(jīng)遇到過和你類似的問題，那么在站立會議后，他就會和你進行討論。

Frequent Releases，小版本發(fā)布。

在敏捷開發(fā)中，不會出現(xiàn)這種情況，拿到需求以后就閉門造車，直到_后才將產(chǎn)品交付給客戶，而是盡量多的產(chǎn)品發(fā)布，一般以周、月為單位。這樣，客戶每隔一段時間就會拿到發(fā)布的產(chǎn)品進行試用，而我們可以從客戶那得到更多的反饋來改進產(chǎn)品。正因為發(fā)布頻繁，每一個版本新增的功能簡單，不需要復(fù)雜的設(shè)計，這樣文檔和設(shè)計就在很大程度上簡化了。又因為簡單設(shè)計，沒有復(fù)雜的架構(gòu)，所以客戶有新的需求或者需求進行變動，也能很快的適應(yīng)。

Minimal Documentation，較少的文檔。

其實敏捷開發(fā)中并不是沒有文檔，而是有大量的文檔，即測試。這些測試代碼真實的反應(yīng)了客戶的需求以及系統(tǒng)API 的用法，如果有新人加入團隊，_快的熟悉項目的方法就是給他看測試代碼，而比一邊看著文檔一邊進行debug要高效。如果用書面文檔或者注釋，某天代碼變化了，需要對這些文檔進行更新。一旦忘記更新文檔，就會出現(xiàn)代碼和文檔不匹配的情況，這更加會讓人迷惑。而在敏捷中并不會出現(xiàn)，因為只有測試變化了，代碼才會變化，測試是真實反應(yīng)代碼的。這時有人會問：代碼不寫注釋行嗎？一般來說好的代碼不是需要大量的注釋嗎？其實簡單可讀的代碼才是好的代碼，既然簡單可讀了，別人一看就能夠看懂，這時候根本不需要對代碼進行任何注釋。若你覺得這段代碼不加注釋的話別人可能看不懂，就表示設(shè)計還不夠簡單，需要對它進行重構(gòu)。

Collaborative Focus，以合作為中心，表現(xiàn)為代碼共享。

在敏捷開發(fā)中，代碼是歸團隊所有而不是哪些模塊的代碼屬于哪些人，每個人都有權(quán)利獲得系統(tǒng)任何一部分的代碼然后修改它，如果有人看到某些代碼不爽的話，那他能夠?qū)@部分代碼重構(gòu)而不需要征求代碼作者的同意，很可能也不知道是誰寫的這部分代碼。這樣每個人都能熟悉系統(tǒng)的代碼，即使團隊的人員變動，也沒有風(fēng)險。

Customer Engagement ，現(xiàn)場客戶。

敏捷開發(fā)中，客戶是與開發(fā)團隊一起工作的，團隊到客戶現(xiàn)場進行開發(fā)或者邀請客戶到團隊公司里來開發(fā)。如果開發(fā)過程中有什么問題或者產(chǎn)品經(jīng)過一個迭代后，能夠以_快速度得到客戶的反饋。

Automated Testing ，自動化測試。

為了減小人力或者重復(fù)勞動，所有的測試包括單元測試、功能測試或集成測試等都是自動化的，這對QA人員提出了更高的要求。他們要熟悉開發(fā)語言、自動化測試工具，能夠編寫自動化測試腳本或者用工具錄制。我們公司在自動化測試上做了大量的工作，包括Selenium開源項目。

Adaptive Planning，可調(diào)整計劃。

敏捷開發(fā)中計劃是可調(diào)整的，并不是像以往的開發(fā)過程中，需求分析->概要設(shè)計->詳細設(shè)計->開發(fā) ->測試->交付，每一個階段都是有計劃的進行，一個階段結(jié)束便開始下一個階段。而敏捷開發(fā)中只有一次一次的迭代，小版本的發(fā)布，根據(jù)客戶反饋隨時作出相應(yīng)的調(diào)整和變化。

敏捷開發(fā)過程與傳統(tǒng)的開發(fā)過程有很大不同，在這過程中，團隊是有激情有活力的，能夠適應(yīng)更大的變化，做出更高質(zhì)量的軟件。

敏捷開發(fā)的特點

敏捷方法主要有兩個特點，這也是其區(qū)別于其他方法，尤其是重型方法的_主要特征:

（1）敏捷開發(fā)方法是“適應(yīng)性”(Adaptive)而非“預(yù)設(shè)性” (Predictive)。

這里說的預(yù)設(shè)性，可以通過一般性工程項目的做法理解，比如土木工程，在這類工程實踐中，有比較穩(wěn)定的需求，同時建設(shè)項目的要求也相對固定，所以此類項目通常非常強調(diào)施工前的設(shè)計規(guī)劃。只要圖紙設(shè)計得合理并考慮充分，施工隊伍可以完全遵照圖紙順利建造，并且可以很方便地把圖紙劃分為許多更小的部分交給不同的施工人員分別完成。

然而，在軟件開發(fā)的項目中，這些穩(wěn)定的因素卻很難尋求。軟件的設(shè)計難處在于軟件需求的不穩(wěn)定，從而導(dǎo)致軟件過程的不可預(yù)測。但是傳統(tǒng)的控制項目模式都是試圖對一個軟件開發(fā)項目在很長的時間跨度內(nèi)做出詳細的計劃，然后依計劃進行開發(fā)。所以，這類方法在不可預(yù)測的環(huán)境下，很難適應(yīng)變化，甚至是拒絕變化。

與之相反的敏捷方法則是歡迎變化，目的就是成為適應(yīng)變化的過程，甚至能允許改變自身來適應(yīng)變化。所以稱之為適應(yīng)性方法。

（2）敏捷開發(fā)方法是“面向人” (people oriented)而非“面向過程”(process oriented)。

Matin Flower認為：“在敏捷開發(fā)過程中，人是_位的，過程是第二位的。所以就個人來說，應(yīng)該可以從各種不同的過程中找到真正適合自己的過程?！边@與軟件工程理論提倡的先過程后人正好相反。

在傳統(tǒng)的軟件開發(fā)工作中，項目團隊分配工作的重點是明確角色的定義，以個人的能力去適應(yīng)角色，而角色的定義就是為了_過程的實施，即個人以資源的方式被分配給角色，同時，資源是可以替代的，而角色不可以替代。

然而，傳統(tǒng)軟件開發(fā)的這些方法在敏捷開發(fā)方式中被完全顛覆。敏捷開發(fā)試圖使軟件開發(fā)工作能夠利用人的特點，充分發(fā)揮人的創(chuàng)造能力。

敏捷開發(fā)的目的是建立起一個項目團隊全員參與到軟件開發(fā)中，包括設(shè)定軟件開發(fā)流程的管理人員，只有這樣軟件開發(fā)流程才有可接受性。同時敏捷開發(fā)要求研發(fā)人員獨立自主在技術(shù)上進行決策，因為他們是_了解什么技術(shù)是需要和不需要的。再者，敏捷開發(fā)特別重視項目團隊中的信息交流，有調(diào)查顯示：“項目失敗的原因_終都可追溯到信息沒有及時準確地傳遞到應(yīng)該接受它的人?！?/p>

敏捷開發(fā)的價值觀

實際上敏捷開發(fā)運動在數(shù)年前就開始了，但它正式開始的標志是2001年2月的“敏捷宣言”（Agile Manifesto），這項宣言是由17位當(dāng)時稱之為“輕量級方法學(xué)家”所編寫簽署的，他們的價值觀是：個人與交互重于開發(fā)過程與工具；可用的軟件重于復(fù)雜的文檔；尋求客戶的合作重于對合同的談判；對變化的響應(yīng)重于始終遵循固定的計劃。

個人與交互重于開發(fā)過程與工具的原因：

一個由_的人員組成但使用普通的工具，要比使用_的工具但由普通人組成、紊亂的小組做得更好。多年來人們花了很多時間試圖建立一種過程，以便把人當(dāng)作機器上的一個可以替代的齒輪，但結(jié)果卻并不成功。敏捷過程是承認每個人都有特定的能力（以及缺點）對之加以利用，而不是把所有的人當(dāng)成一樣來看待。更重要的是，在這樣的理念下，幾個項目做下來，每個人的能力都從中得以提高。

可用的軟件重于復(fù)雜的文檔的原因:

可用的軟件可以幫助開發(fā)人員在每次迭代結(jié)束的時候，獲得一個穩(wěn)定的、逐漸增強的版本。從而允許項目盡早開始，并且更為頻繁的收集對產(chǎn)品和開發(fā)過程的反饋。隨著每次迭代完成軟件的增長，以_開發(fā)小組始終是處理_有價值的功能，而且這些功能可以滿足用戶的期待。

對變化的響應(yīng)重于始終遵循固定的計劃的原因：

敏捷開發(fā)認為對變化進行響應(yīng)的價值重于始終遵循固定的計劃。他們_終的焦點是向用戶交付盡可能多的價值。除了_簡單的項目以外，用戶不可能知道他們所需要的所有功能的每個細節(jié)。不可避免地在過程中會產(chǎn)生新的想法，也許今天看起來是必需的功能，明天就會覺得不那么重要了。

隨著小組獲得更多的知識和經(jīng)驗，他們的進展速度會比開始的時候期望值慢或者快。對敏捷開發(fā)來說，一個計劃是從某個角度對未來的看法，而具有多個不同的角度看問題是有可能的。