在瀏覽了martin的blog 後才真正對敏捷開發有了乙個初步的概念。首先談一下敏捷，敏捷可以應用與任何乙個軟體過程。但是為了實現這乙個目標，非常重要的一點是過程的設計應使專案團隊適應與任務，並且是任務流水線化，在了解敏捷開發方法的流動性的前提下進行計畫的制定，消除所有最基本的軟體產品並精簡軟體開發過程，強調這樣乙個增量交付策略，根據具體的產品型別和執行環境，盡可能快的將切實可行的軟體交付給使用者。應用敏捷的軟體開發模式，可以將變更費用明顯降低，其原因就是增量交付的策略。
下面就是要求進行敏捷過程，敏捷過程必須具有可適應性。敏捷團隊需要客戶的反饋以做出正確的適應性改變。其中敏捷聯盟提出了12條原則：
1.我們優先要做的是通過盡早、持續的交付有價值的軟體來使客戶滿意。
2.即使在開發後期，也歡迎需求變更。敏捷過程利用變更為客戶創造競爭優勢。
3.經常交付可執行軟體，交付間隔可以從幾個星期到幾個月，交付的時間間隔要越短越好。
4.在整個專案開發過程中，業務人員和開發人員必須天台你都工作在一起。
5.在團隊內部，最富有效果和效率的資訊傳遞方式是面對面交流。
6.可執行軟體是進度的首要度量標準。
7.圍繞有積極性的個人構建專案。給他們提供所需的環境和支援，並且信任他們能夠完成工作。
8.敏捷過程提倡可持續的開發速度。負責人、開發者和使用者應該能夠長期保持穩定的開發速度。
9.不斷的關注優秀的技能和好的設計會增強敏捷能力。
10.簡單是必要的。
11.最好的構架、需求和設計出自於自組織團隊。
12.每隔一段時間，團隊會反省如何才能更有效的工作，並相應的調整自己的行為。
在敏捷開發工程中，要求團隊人員必須具有以下要求：
1.基本能力 2.共同目標 3.精誠合作 4.決策能力 5.模糊問題解決能力
6.相互信任和尊重 7.自組織
敏捷開發有一種方式叫做極限程式設計，其要求開發者只對即時的需求做設計，不考慮長遠需求。這樣做的目的是為了使**簡化。極限程式設計使用單元測試來作為主要的測試策略。每進行一級開發，開發團隊就設計乙個單元測試來測試每個操作是否按照規定功能完成。它包含了策劃、這幾、編碼和測試4個框架活動的規則和實踐。其中，設計環節要求程式設計遵循保持簡潔的原則，設計的故事提供不多也不少的實現，不鼓勵額外功能性設計。彪馬過程要求團隊不是直接編碼，而是開發一系列用於檢測本次發布包括所有故事的單元測試，一旦建立單元測試，開發者就更能夠集中精力於必須實現的內容以通過單元測試。
另外乙個重要概念就是自適應軟體開發，包括思考、協作和學習三個階段。
敏捷建模，就是通過建模的方式保證參與者更好的理解要做什麼，將問題有效的分配給個人和對正在設計和構建的質量系統進行評估。建模的要求即為：1.有目的的模型
2.使用多個模型 3.輕裝上陣，即只保留提供長期價值的模型 4。內容重於表述形式，即說清楚乙個內容要比完美的闡述但是難以理解的更加有效 5.理解模型及工具
6.適應本地需要，即適應團隊的需要。
針對敏捷開發，我個人認為，是一種符合如今時代發展的快速軟體開發技術，擁有極高的開發靈活性，能夠在眾多的情況下更靈活的進行軟體的開發。
以上即為我在開完blog 和課本有的一點總結和理解。
關於敏捷開發
前一段參加了北軟教育的乙個 敏捷開發技術 的培訓，一直沒來的總結一下。剛好結合最近的專案，把老師提到的應用了一把，感覺還不錯。敏捷的特點 1 小版本發布 可以給開發人員持續的成就感 2 測試驅動開發 3 持續整合 4 重構 獲得更好的 結構 5 結對變成 最好選取水平相當的兩人 一定要是交叉結對 6...
關於敏捷開發
scrum 英式橄欖球爭球隊 軟體開發模型是敏捷開發的一種。scrum的基本假設是 開發軟體就像開發新產品，無法一開始就能定義軟體產品最終的規程，過程中需要研發 創意 嘗試錯誤。scrum 將軟體開發團隊比擬成橄欖球隊，有明確的最高目標，熟悉開發流程中所需具備的最佳典範與技術，具有高度自主權，緊密地...
關於敏捷開發
這兩天花了些時間,閱讀了 敏捷開發修煉之道 其中的條款挺多的,要完全記住,著實有些困難,況且本人的記性還不是很好,因此寫乙個觀後總結.要做得敏捷開發,其實首先就是要形成乙個良好的開發習慣,而習慣卻往往是很難形成,也很難改變的.要培養或改變到好的習慣上來,態度是最重要的,因此,此書就從態度開始.著重是...