ASD：Agile Software Development——敏捷軟件開發(fā)
1、什么是敏捷軟件開發(fā)？
敏捷軟件開發(fā)是一個概念意義上的框架，用來取代軟件工程項目的概念；它強調(diào)在項目的整個生命周期中，擁抱并促進由于軟件進化式的發(fā)展所帶來的變化。
請注意其中的三個關(guān)鍵詞：
在項目的整個生命周期中：這就涉及到了【敏捷項目管理】、【敏捷需求獲取】、狹義的【敏捷軟件開發(fā)】三個主要的領(lǐng)域和過程。要注意的是，上述三個過程并不是互相分開的，而是你中有我，我中有你。
擁抱并促進變化：世界上唯一不變的是變化。不論在任何領(lǐng)域，漠視、甚至否認、抗拒變化，都不是一個理性，嚴肅的人所應(yīng)有的態(tài)度。學(xué)會如何識別變化的大勢，并在可能的時候，促使變化向好的方向發(fā)展。這才是面對變化的正確應(yīng)對之法。
軟件進化式的發(fā)展：雖然上面提到促進變化的發(fā)展，但是軟件的演化過程，我相信是有其自身內(nèi)在邏輯的，存在一些根本規(guī)律和指導(dǎo)方針；并不是完全以人的主觀意識為主導(dǎo)。
了解了這三個方面，下面就要引入敏捷宣言（Manifesto for Agile Software Development）了，2001年提出的第一版的敏捷軟件開發(fā)宣言：
我們正在通過實踐和幫助其他人實踐，揭示更好的開發(fā)軟件的方法。我們從實踐中得出的價值觀是：
☆ 人和交互重于過程和工具。
☆ 可以工作的軟件重于求全責(zé)備的文檔。
☆ 客戶合作重于合同談判。
☆ 隨時應(yīng)對變化重于循規(guī)蹈矩。
在敏捷宣言的背后，有其遵循的12條原則：
★ 我們最優(yōu)先要做的是通過盡早的、持續(xù)的交付有價值的軟件來使客戶滿意。
★ 即使到了開發(fā)的后期，也歡迎改變需求，敏捷過程利用變化來為客戶創(chuàng)造競爭優(yōu)勢。
★ 經(jīng)常性地交付可以工作的軟件，交付的間隔可以從幾個星期到幾個月，交付的時間間隔越短越好。
★ 在整個項目開發(fā)期間，業(yè)務(wù)人員和開發(fā)人員必須天天都在一起工作。
★ 圍繞被激勵起來的個體來構(gòu)建項目。給他們提供所需的環(huán)境和支持，并且信任他們能夠完成工作。
★ 在團隊內(nèi)部，最具有效果并且富有效率的傳遞信息的方法，就是面對面的交流。
★ 工作的軟件是首要的進度度量標(biāo)準(zhǔn)。
★ 敏捷過程提倡可持續(xù)的開發(fā)速度。責(zé)任人、開發(fā)者和用戶應(yīng)該能夠保持一個長期的、恒定的開發(fā)速度。
★ 不斷地關(guān)注優(yōu)秀的技能和好的設(shè)計會增強敏捷能力。
★ 簡單——使未完成的工作最大化的藝術(shù)——是根本的。
★ 最好的構(gòu)架、需求和設(shè)計出自于自組織的團隊。
★ 每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然后相應(yīng)地對自己的行為進行調(diào)整。
2、一種深入解釋：
轉(zhuǎn)載地址：http://www.cnblogs.com/blusehuang/archive/2007/10/17/926802.html
這兩個圓圈表示不同的視角上的敏捷實踐，包括開發(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ā)人員明確目標(biāo)，就是讓測試通過。
Continuous Integration，持續(xù)集成。
在以往的軟件開發(fā)過程中，集成是一件很痛苦的事情，通常很長時間才會做一次集成，這樣的話，會引發(fā)很多問題，比如build未通過或者單元測試失敗。敏捷開發(fā)中提倡持續(xù)集成，一天之內(nèi)集成十幾次甚至幾十次，如此頻繁的集成能盡量減少沖突，由于集成很頻繁，每一次集成的改變也很少，即使集成失敗也容易定位錯誤。一次集成要做哪些事情呢？它至少包括：獲得所有源代碼；編譯源代碼；運行所有測試，包括單元測試、功能測試等；確認編譯和測試是否通過，最后發(fā)送報告。當(dāng)然也會做一些其它的任務(wù)，比如說代碼分析、測試覆蓋率分析等等。 在我們公司里，開發(fā)人員的桌上有一個火山燈用來標(biāo)志集成的狀態(tài)，如果是黃燈，表示正在集成；如果是綠燈，表示上一次集成通過，開發(fā)人員在這時候獲得的代碼是可用而可靠的；如果顯示為紅燈，就要小心了，上一次集成未通過，需要盡快定位失敗原因從而讓燈變綠。在持續(xù)集成上，我們公司使用的是自己開發(fā)的產(chǎn)品。
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。
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ā)語言、自動化測試工具，能夠編寫自動化測試腳本或者用工具錄制。
Adaptive Planning，可調(diào)整計劃。
敏捷開發(fā)中計劃是可調(diào)整的，并不是像以往的開發(fā)過程中，需求分析->概要設(shè)計->詳細設(shè)計->開發(fā)->測試->交付，每一個階段都是有計劃的進行，一個階段結(jié)束便開始下一個階段。而敏捷開發(fā)中只有一次一次的迭代，小版本的發(fā)布，根據(jù)客戶反饋隨時作出相應(yīng)的調(diào)整和變化。 PS：
敏捷開發(fā)方法通常應(yīng)用時間定量的迭代和進化式開發(fā)、使用自適應(yīng)計劃、提倡增量交付并包含其它提倡敏捷性（快速和靈活的相應(yīng)變更）的價值和實踐。具備進化式精化的計劃、需求和設(shè)計的短時間定量迭代是敏捷方法所共有的基本實踐。他們還提倡反映簡易、輕量、溝通、自組織團隊等更多敏捷性的實踐和原則。