敏捷的關鍵點： 通過及早和頻繁發佈的方式小步前進以控制風險，過程中跟客戶緊密合作，通過頻繁測試來保證質量，高效的溝通，緊湊的自組織團隊，注重每個人的參與性
敏捷開發的六個實戰經驗.
http://www.csdn.net/article/2013-12-09/2817746-6-practical-agile-techniques
簡單總結下，六點是：
1. 快速迭代 版本發佈週期縮短 可逼迫團隊不斷優化工作流程，提高效率，避免在無足輕重的地方浪費時間
2. 讓測試人員和開發人員參與需求討論 以討論組形式討論更有效率，讓這些人蔘與可以利用成員的互補性，討論更活躍，參與感更強。同時可輕鬆定義需求，對其進行分組確定優先級。
3. 編寫可測試的需求文檔 用用戶故事“user story”的方式編寫需求文檔，該方法可使我們關注於需求上，而不是解決方法和技術上。規劃需求可採用3W, who-what-why，一開始不應過分詳細。
4. 多溝通 儘量減少文檔 好的溝通是敏捷開發的先決條件。團隊確保日常交流，鼓勵日常的協調會和碰頭會，5-7人控制在十分鐘。碰頭會要過一遍昨天完成了什麼，今天要做什麼，哪些問題仍待討論，可用burndown chart（燃盡圖）來表示工作進度。
每次迭代要有計劃會議和評審會議，以對工作查漏補缺。 開會時，可將分組打破，讓整個團隊都參與到需求討論和測試中來，以突出成員個人，讓大家更樂意參與。
5. 做好產品原型 建議使用草圖和模型來闡明用戶界面。
6. 及早考慮測試 及早考慮測試在敏捷開發中很重要。敏捷開發中一個常見問題就是開發者沒有對已有的代碼庫進行充分的迴歸測試。由於迭代週期很短，可以對迭代的設計、實現和底層測試一塊進行迴歸測試。
一系列迭代之後，可以只針對測試活動再補充一個迭代，將重點放在系統測試、與其他系統的集成度、性能等方面。
開始敏捷開發可以從點滴做起，如經常開碰頭會，爲項目管理使用更高效的工具等。
敏捷實踐：如何讓團隊迭代交付週期縮短一半
http://www.csdn.net/article/2013-03-25/2814622-cto-club-95
應用敏捷讓迭代週期減少一半
應當用敏捷的思想，讓一個新組建的團隊成爲產品的主人和管理創新的驅動者。當團隊自發去持續優化產品，不斷提升產品質量和研發效率時，他們會樹立更高的目標去挑戰，當他們持續地“贏”得兩次以上高難度時，卓越成爲了團隊的習慣。
- 集中規劃和項目推演。這樣做的好處是：研發、測試團隊和和項目經理Scrum Master一起深入理解項目要求，測試團隊也應此能夠更早地開始編寫測試腳本，也避免了後期矛盾。
- 站會，每個人都是衆星捧月的明星。站着開會帶來的緊張感和疲勞感有效地避免了過於冗長的會議。同時，讓發言者站在中間的做法更能增強其自信心和責任感。
- 團隊自我驅動所做的一系列優化：明確只有可用的功能纔算完成；明確項目目標；把目標分配給明確的負責人；嚴格要求代碼提交環節；由敏捷教練管理，明確每個人的觀點；優化團隊規模等等。同時要避免整體重構，儘可能局部重構。項目經理更需要確定項目能否完成而不是僅是關注項目進度。
- 持續集成和產品演示環境。自動化集成和演示環境，省去了很多重複的工作。
- 別開生面的覆盤會。在覆盤會上，隊員都需要完成自評和他評，績效與任務難度掛鉤的方式也激勵員工做有挑戰的項目/功能開發。同時，嚴格的得失分析讓隊員更好地吸取經驗和教訓。
- 保證質量可信度。雖然研發速度很重要，但是沒有質量保證的快速開發非常危險，質量可信度是一項需要高度重視的標準。
2周，將想法變成開發級需求 成功需要正確的產品方向+正確的構建方法，因此在開發前弄清楚產品方向和構建方法至關重要
敏捷開發之12條敏捷原則
http://www.csdn.net/article/2010-08-05/277860 更多內容：敏捷方法之Scrum.pdf
對《Agile Software Development －Principles,Patterns,and Practices》（中文書名： 《敏捷軟件開發——原則、模式與實踐》）介紹的12原則進行的加工闡述。
1.我們最優先要做的是通過儘早的、持續的交付有價值的軟件來使客戶滿意。規劃迭代故事時必須按照優先級安排，爲客戶先提供最有價值的功能。通過頻繁迭代能與客戶形成早期的良好合作，及時反饋提高產品質量。敏捷使用用戶故事來羅列需求，用戶故事是一種表示需求的輕量級技術，敏捷估算中使用了這個模板：“作爲【用戶的類型】，我希望可以【能力】以便【業務價值】“。
使用使用基於用戶故事的需求分析方法時，仍可能需要原型和編寫文檔，只是工作重點更多的轉移到了口頭交流。
3.經常性的交付可以工作的軟件，交付的間隔可以從幾周到幾個月，交付的時間間隔越短越好。
迭代是受實踐框限制的，意味着即使放棄一些功能也必須按時結束迭代。只要我們可以保證交付的軟件可以很好的工作，那麼交付時間越短，我們和客戶協作就越緊密，對產品質量就更有益。
敏捷開發項目中對開發階段沒有什麼重要的分割，沒有先期的需求階段，然後是分析階段，架構設計階段，編碼測試階段等，在項目真正開始後，每次迭代中都會同時進行所有的上述階段工作。
4.在整個項目開發期間，業務人員和開發人員必須天天都在一起工作。
5.圍繞被激勵起來的人個來構建項目。給他們提供所需要的環境和支持，並且信任他們能夠完成工作。
6.在團隊內部，最具有效果並且富有效率的傳遞信息的方法，就是面對面的交談。敏捷團隊一般不會很多人（大團隊實施敏捷時也會分成多個小的敏捷團隊），面對面的交談反而更快速有效。
7.工作的軟件是首要進度度量標準。衡量某個功能是否完成的首要標準就是這個功能可以工作了，對用戶來說已經可以應用了。
8.敏捷過程提可持續的開發速度。責任人、開發者和用戶應該能夠保持一個長期的、恆定的開發速度。敏捷過程希望能夠可持續的進行開發，開發速度不會隨着迭代的任務不同而不同，不欣賞所謂的拼一拼也能完成的態度，開發工作不應該是突擊行爲。
9.不斷地關注優秀的技能和好的設計會增強敏捷能力。很多原則、模式和實踐也可以增強敏捷開發能力。
10.簡單——使未完成的工作最大化的藝術——是根本的。敏捷團隊不會去構建明天的軟件，而把注意力放在如何通過最簡單的方法完成現在需要解決的問題。
11.最好的構架、需求和設計出自與自組織的團隊。敏捷中有很多種實踐，大家都知道，迭代式開發是主要的實踐方法，而自組織團隊也是主要的實踐之一。一支高效的工作團隊的形成需要經過幾個階段，大家對工作理念和文化形成共識，相互之間理解並達成默契。
團隊中有必要指明一些人承擔一定任務的角色。第一個角色是產品所有者（Product Owner）。產品所有者的主要職責包括：確認小組所有成員都在追求一個共同的項目前景，確定功能的優先級以便總是在處理最具有價值的功能，以及作出決定使得對項目的投入可以產生良好的回報。
12.每隔一定時間，團隊會在如何才能更有效地工作方面進行反省，然後相應地對自己的行爲進行調整。
敏捷軟件測試的文化挑戰
http://www.infoq.com/cn/news/2010/12/agile-test-culture
軟件開發組織採用敏捷開發時，測試團隊通常需要花很長時間來完成轉變，會遇到難以接受的文化差異。
以如何定義軟件質量的可接受水平的角度思考組織的質量哲學。
合適的節奏 傳統的測試團隊習慣於在項目結束時快速、激烈地測試，這會導致週末和夜間的加班。這與敏捷價值衝突，敏捷價值的中心思想是讓大家時刻以最好的狀態工作。在敏捷項目中，鼓勵人們以一個合適的節奏工作。偶爾需要高強度地工作，但是這是特例，不是一般情況。
客戶關係
在傳統的軟件開發中，開發團隊和他們的客戶之間的關係更像是買賣關係。敏捷開發依賴於客戶或者至少是客戶代表的緊密參與。敏捷團隊邀請客戶協作，如果可能， 在同一地點工作，並且密切地參與開發過程。雙方都瞭解對方的強項和弱點。
溝通挑戰 一些敏捷過程提供了便於團隊交流的方法。例如，Scrum有Scrum會議，來自多個團隊的代表每天交流。如果工作的測試團隊或其他部門與編碼團隊分離，那麼需要找到保持不斷交流的方式。
先行動後道歉 通常在大的組織中，官僚政治的節奏太慢，團隊可能需要找到並執行自己的解決方案。
通常在大的組織中，官僚政治的節奏太慢，團隊可能需要找到並執行自己的解決方案。
授權團隊 在敏捷項目中，讓每個開發團隊感覺到有做決定的權力是很重要的。
對軟件開發有利的5個敏捷編程方法
http://www.csdn.net/article/2013-09-24/2817034-five-ways-agile-programming-benefits-software-development敏捷編程是一個以客戶爲導向的方法來管理軟件開發團隊和項目，它側重於終端用戶的參與、早期發佈和增量發佈，以及頻繁的質量控制測試。這一概念適用於各種規模的公司（尤其適用於小型和中型的IT公司）。下面介紹5種敏捷編程方式，能夠幫助開發者在軟件開發過程中獲得巨大的競爭優勢。
1. 快速收益 發佈一個有限的、高優先級設計功能的產品可以確保更快的獲得投資回報。歷史經驗表明，大多數市場統治者都是那些最先發布新產品的開發者，一旦發佈之後遇到質量問題，則採取斷斷續續的修補、改善措施。
2. 降低風險 一個帶有基本功能的測試版本也是可以發行的，接下來來自潛在客戶的反饋將是對產品進行改進的重要依據。
3. 提高效率 消除報告會議的方式，取而 代之的是授權團隊成員，讓他們自己做出正確決定。除了利用精簡實踐之外，開發團隊可以利用各種技術來提高工作效率，這首先想到的就是雲計算。
4. 更好的質量控制 “承諾測試”是與敏捷編程有關的最佳實踐項目的核心部分。除此之外，頻繁的測試過程能夠讓質量問題更早的浮出水面。
5. 提高顧客滿意度
在敏捷編程環境中，終端用戶的參與可以說是一種鼓勵行爲。這樣就無形當中增加了客戶滿意度，因爲客戶的積極參與，並用更加靈活的方式改變了軟件的特性。
高效敏捷的十大經驗法則
http://www.csdn.net/article/2012-12-12/2812720敏捷是一種應對快速變化的需求的一種軟件開發能力，相對於“非敏捷”，更強調程序員團隊與業務專家之間的緊密協作、面對面的溝通（認爲比書面的文檔更有效）、頻繁交付新的軟件版本、緊湊而自我組織型的團隊、能夠很好地適應需求變化的代碼編寫和團隊組織方法，也更注重軟件開發中人的作用。
本文是VersionOne 公司CEO Robert Holler，一家專注于敏捷開發工具和敏捷培訓的公司。Robert總結了這十年來的敏捷軟件開發經驗，縮減成十條經驗法則，希望對熱愛敏捷的公司、團隊和個人有所幫助。
1. 簡單至上
成功的敏捷人士需要具備不同的業務能力以適應與他們一起工作的相關人員，包括企業的相關利益者，產品企劃人員、開發者，測試人員等等。Holler稱很多公司在建立敏捷平臺時，每當面對有獨特需求的用戶時，他們很容易使自己陷入困境。
2. 定義自己的節奏 如開會之前就把問題準備好，以避免低效冗長的會議。
3. 敏捷就是紀律
4. 軟件很難Scale，但是敏捷卻不
5. Think of the Big Picture 把自己當做統觀大局的人 系統思考非常重要，這就需要一個真正成熟、能夠深入探究複雜與衝突議題的團隊，否則改變系統可能會帶來一定的風險。
6. 失去信仰 爲了適應不同的節奏，你應該儘可能的與敏捷迭代方面保持密切聯繫。
7. 持續關注商業價值 團隊中的成員需要縱觀全局以最大限度地降低項目開發週期。
8. 敏捷不只是爲軟件部們
9. 持續規劃 團隊中的成員需要縱觀全局以最大限度地降低項目開發週期。
10. 做敏捷但不要做重複的敏捷 行動永遠比空談有效，你無法預見將發生的所有困難與問題，直到你真正開始去做敏捷模式。
一個真實的敏捷開發案例
http://www.csdn.net/article/2010-08-05/277840
拆出一個只關注架構的團隊
項目負責人對核心需求很瞭解，但對安全、日 志、可用性、性能等方面就所知甚少。爲此創建了一個獨立團隊，他們只關注架構方面的內容。他們的工作就是弄清楚非功能性需求，好讓我們把它們轉換成 backlog中的用戶故事。
對於不適合放到Scrum Sprint中的工作（比如尋找關鍵人員，跟其他客戶部門交流），可以讓一個單獨的團隊去做，這樣效率更高。特性團隊可以集中精力開發軟件。有一個專職的技術文案也很好，即便這會增加溝通成本。
[探討]敏捷開發原則
http://www.csdn.net/article/2012-07-17/2807394
簡單至關重要 If I have some complicated work to do, I will give it to the laziest person I have, because they will find the simplest way to do it.如果你只關心和只做客戶想要的，而不去添加額外的功能和改進，那麼你的工作就會輕鬆很多，並且會很快達成目標。從根本上說，客戶也只關心這個。
其他鏈接：
http://blog.vsharing.com/agiledo/
敏捷之道Scrum篇 http://www.cnblogs.com/chenkai/archive/2012/04/15/2443164.html
敏捷 RUP：來自實戰中的經驗 http://www.csdn.net/article/2010-08-05/277857 爲在 IBM Rational Unified Process 或者簡稱爲 RUP 團隊上面應用敏捷策略提供了被證明爲行之有效的建議。
CIO如何幫助IT團隊迅速兌現敏捷開發 http://www.csdn.net/article/2009-12-15/274053-215800
敏捷工具：
