敏捷宣言以及敏捷開發的特點 - 鴻鵠當高遠 -
敏捷宣言的簡單介紹 - superzhang828 -
最近在複習軟體工程，對敏捷宣言並不是很理解，因此蒐集並整理了一些資料，方便自己複習。
敏捷宣言，也叫做敏捷軟體開發宣言，正式宣布了對四種核心價值和十二條原則，可以指導迭代的以人為中心的軟體開發方法。
敏捷宣言強調的敏捷軟體開發的四個核心價值是：
1、個體與互動高於流程和工具
敏捷開發的第一條價值觀就是「 以人為本」，強調「 個體（人）」 及「 個體」 間的溝通與協作在軟體開發過程中的重要性。這個順序不是偶然而為之的，敏捷開發將重視個體潛能的激發和團隊的高效協作作為其所推崇的第一價值觀。
這意味著雖然流程和工具重要（尤其是大型組織），但是它們無法替換有能力的個體和高效的互動。個體的技能和他們之間的互動才是最關鍵的。
2、工作的軟體高於詳盡的文件
敏捷開發的第二條價值觀就是「 目標導向」。同其他眾多管理理論和模型一樣，敏捷開發認同目標導向是成功的關鍵，因為沒有目標也就無所謂成功。敏捷開發的價值觀中清楚地闡明，軟體開發的目標是「 可工作的軟體」，而不是面面俱到的文件。而遺憾的是，很多軟體專案已經在紛繁的文件之中迷失了自己的目標。這意味著已整合、已測試、潛在準備發布的產品才是關鍵度量，它能夠有效地跟蹤專案進度和對發布做出決策。
3、客戶合作高於合同談判
敏捷開發的第三條價值觀就是「 客戶為先」。雖然敏捷開發強調的第一價值觀是「 以人為本」，但敏捷宣言的締造者們並沒有忘記客戶，相反他們真正的理解客戶的需求、懂得如何與客戶合作。敏捷價值觀裡強調的「 客戶為先」即不是簡單地把客戶當作「 上帝」、刻板的推崇「 客戶至上」，客戶要求什麼、我們就做什麼；也不是把客戶當作「 談判桌上的對手」 甚至「 敵人」，去鬥智鬥勇。敏捷價值觀把客戶當成了合作者和夥伴，把自己的使命定位為「 「 幫助客戶取得競爭優勢」。這意味著我們應該超越談判並嘗試提公升與客戶的合作。我們還應該建立以合作為基礎的關係，而不是靠公司內的正式介面。
4、響應變化高於遵循計畫
敏捷開發的第四條價值觀就是「 擁抱變化」。人們常說「 世界上唯一不變的就是變化」，大多數人也相信事實確實如此。而以往很多的軟體專案卻忽視了這一點，或者更準確地說是他們不願意「 正視」。他們總是試圖用詳盡的計畫去預先窮舉這些變化，然後又試圖通過嚴格遵循計畫來控制變化的發生，而結果往往是被不斷湧現的變化擊垮。敏捷開發價值觀中承認變化是軟體開發的一部分、並相信正是客戶在不斷變化其需求的過程中明晰了其真正的需要。因而敏捷開發歡迎變化、擁抱變化，並可坦然應對變化，正是這些變化為客戶和專案帶來了價值。這意味著歡迎需求變化，哪怕是開發後期。
最後，還應記住敏捷宣言中的最後一句話：「 儘管右項有其價值，我們更重視左項的價值」—敏捷宣言並未否定或貶損「 右項」 的價值，在敏捷開發的價值觀中承認「 流程和工具」、「 詳盡的文件」、「 合同談判」 以及「 遵循計畫」 的重要性，只是兩相比較，「 更重視左項的價值」。
敏捷軟體的十二條原則
1.我們最重要的目標，是通過持續不斷地
及早交付有價值的軟體使客戶滿意。
盡早並持續交付的能力是滿足客戶的關鍵。及時交付部分功能比最後交付全量功能更好，至少我們應該給我們客戶乙個選擇。
2.欣然面對需求變化，即使在開發後期也一樣。為了客戶的競爭優勢，敏捷過程掌控變化。
我們的目標是為了開發能夠幫助客戶提公升價值的產品，要支援任何變化。變化不是一種否定，它體現了團隊和產品負責人在敏捷開發過程中的一種工作方式。
3.經常地交付可工作的軟體，相隔幾星期或一兩個月，傾向於採取較短的週期。
開發周期和發布週期完全不同。儘管有發布週期，但我們的目標是短開發周期。發布週期的長度依賴業務決策，並且和客戶的期望緊密關聯。短開發周期的頻繁交付縮短了反饋週期並增強了學習。頻繁交付還能讓團隊及早暴露弱點並及時移除障礙，增加了敏捷性和靈活性。
4.業務人員和開發人員必須相互合作，專案中的每一天都不例外。
只要在業務和研發之間建立起橋梁，我們就能從中受益。業務人員和產品管理知道市場狀況、客戶需求和客戶的價值。開發團隊知道產品和技術可行性。如何將這兩方面結合？我們需要作出睿智的決策。
5.激發個體的鬥志，以他們為核心搭建專案。提供所需的環境和支援，輔以信任，從而達成目標。
知識類工作(比如軟體開發)是由具有技能和激情的人來做的。為了激發個體的鬥志和創造力，自由是最重要因素。要讓角色去適應人而不是讓人去適應角色。
6.不論團隊內外，傳遞資訊效果最好效率也最高的方式是面對面的交談。
面對面交談在分布式開發中尤為重要。當我們看到人們彼此交談時，資訊更多以聽說的形式被傳遞。文件(雖然它很重要)不能代替交談，將每件事都寫下來簡直是不可能的。我們不應該只依靠寫文件來傳遞重要資訊。
7.可工作的軟體是進度的首要度量標準。
跟蹤有多少功能已經實現，整合，測試是一種更可靠的進度度量。
8.敏捷過程倡導可持續開發。責任人、開發人員和使用者要能夠共同維持其步調穩定延續。
9.堅持不懈地追求技術卓越和良好設計，敏捷能力由此增強。
10.以簡潔為本，它是極力減少不必要工作量的藝術。
11.最好的架構、需求和設計出自自組織團隊。
12.團隊定期地反思如何能提高成效，並依此調整自身的舉止表現。
與傳統開發方法相比，在敏捷開發的整個過程中，有以下幾個主要的特點：
（1）敏捷開發的過程有著更強的適應性而不是預設性，從敏捷宣言的第四條響應變化高於預設計畫便可以看出來。因為軟體開發過程的本身的不可預見性，很多使用者在專案開始時不可能對於這個專案有著乙個完整而明確的預期。很多對軟體的預期都在後期的修改和完善過程中產生。因此高適應性顯然更加符合軟體工程開發的實際。而敏捷開發實現其適應性的方式主要在於，第一，縮短把專案提交給使用者的週期；第二，增加使用者，業務人員，開發人員這三者之間的交流；第三，通過減少重構的成本以增加軟體的適應性。
（2）敏捷開發的過程中，更加的注重人的因素。在傳統軟體工程中，個人的因素很少的被考慮到分工中，每個個體都是只是整個**開發機器的乙個小小的螺絲釘，個人的意志和創造力很大程度上的被抹去為了更好的為集體服務。而在敏捷開發過程中，每個個人的潛力被充分的考慮，應用什麼技術很大程度上直接由在第一線開發的技術人員決定；每個人的特點和創造力都可以充分地發揮，這樣開發出來的軟體更加的具有生命力，因為他融入了開發者的心血和創意，開發者不再是進行機械的乏味的堆砌，而是創造屬於自己的藝術品，這樣的條件下產生的**必然在質量上更佔優勢。
（3）在敏捷開發的過程中，整個專案是測試驅動的而不是文件驅動的。不僅每個模組有著自己的相應的測試單元，開發人員在開發自己的模組的過程中必須保證自己所開發的模組可以通過這一單元的測試，並且整合測試貫穿了整個開發過程的始終。整合測試每天會進行十幾次甚至幾十次，而不是像傳統方法一樣只有當各個模組的編碼都結束了之後再進行聯合除錯。這樣，在軟體開發的程序中每一點改動所引起的問題都容嘉容易暴露出來，使得更加容易在錯誤剛剛產生的時候發現問題從而解決問題。這樣就避免了在最後整個系統完成時錯誤隱藏的太深給除錯造成極大的困難。
敏捷開發的高適應性，以人為本的特性，和輕量型的開發方法即以測試為驅動取代了以文件為驅動，這三個主要的特點，也就是敏捷開發相對與傳統開發方式的主要有點。因為它更加的靈活並且更加充分的利用了每個開發者的優勢，調動了每個人的工作熱情。
敏捷確實是專案進入實質開發迭代階段，使用者很快可以看到乙個基線架構版的產品。敏捷注重市場快速反應能力，也即具體應對能力，客戶前期滿意度高。
與傳統開發方式相比，敏捷開發的最主要的劣勢在於敏捷開發歡迎新的需求，而在每次新的需求產生時都可能引起整個系統的大幅度的修改。因為開發者在開發上乙個版本的時候，完全沒有考慮以後的優化將要如何進行。這樣的開發方式實際的軟體開發過程中，並不一定總是有效的。
而另乙個方面，敏捷開發因為缺乏很多在敏捷開發中被認為「不重要」的文件，這樣在乙個大型專案比如乙個作業系統開發的時候，由於其專案週期很長，所以很難保證開發的人員不更換，而沒有文件就會造成在交接的過程中出現很大的困難。
敏捷注重人員的溝通，忽略文件的重要性，若專案人員流動大太，又給維護帶來不少難度，特別專案存在新手比較多時，老員工比較累。
需要專案中存在經驗較強的人，要不大專案中容易遇到瓶頸問題。
軟體工程之敏捷過程
第五章 敏捷開發 敏捷的概念 敏捷軟體工程是哲學理念和一系列開發指南的綜合。這種哲學理念推崇 讓客戶滿意且盡早的增量發布 小而高度自主的專案團隊 非正式的方法 最小化軟體工程工作產品以及整體精簡開發。開發的指導方針強調超越分析和設計 儘管並不排斥這類活動 的發布，以及開發人員和客戶之間主動和持續的溝...
敏捷宣言 敏捷原則 小型敏捷宣言
敏捷宣言 敏捷原則 敏捷宣言 是乙個籠統的術語，描述和管理用於處理it團隊和專案的幾種輕量級且更全面的敏捷方法。scrum，看板，精益開發，crystal和極限程式設計 xp 是最受歡迎的輕量級敏捷方法。雖然 小型scrum 適用於 敏捷宣言 但以下所述的六個附加值應補充和增強小型團隊的敏捷性。與專...
敏捷軟體開發宣言
注 以人為本的思想，利用工具的是人，遵循過程的也是人，如果有最好的工具和過程，而個體卻沒有很好的去利用工具，遵循過程的話，工具和過程也不能發揮預計的效果 另外，流程和工具的一部分作用也是為了團隊成員更好地互動 所以個體和互動是跟本，過程和工具固然重要，卻是輔 注 文件有很多作用，比如變更的記錄和交流...