敏捷開發讀後感

　　敏捷開發是一種以人爲核心、迭代、按部就班的開發方法。在敏捷開發中，軟件項目的構建被切分紅多個子項目，各個子項目的成果都通過測試，具有集成和可運行的特徵。毫無疑問，敏捷開發方法正在大舉進軍今天的企業，可是通往敏捷的道路倒是崎嶇的。它更像是一條多車道的高速公路，各類類型的司機們都在選擇各自適合的路線向目的地進發。

 

軟件開發背景介紹

　　軟件開發的發展經歷了從無、到繁重、再到敏捷的過程。與咱們剛開始學編程的時候同樣，早期多數軟件開發仍然是一個顯得混亂的活動，即典型的「邊寫邊改」。設計過程充斥着短時間的、即時的決定，而無完整的規劃。 這種模式對小系統開發其實很管用，可是當系統變得越大越複雜時，要想加入新的功能就愈來愈困難。同時錯誤故障愈來愈多，愈來愈難於排除。一個典 型的標誌就是當系統功能完成後有一個很長的測試階段，有時甚至有遙遙無期之感，從而對項目的完成產生嚴重的影響。

　　軟件行業中最初的一場運動是要改變這種狀況，而引入了「正規方法」的概念。這些方法對開發過程有着嚴格而詳盡的規定，以期使軟件開發更有可預設性並提升效率，這種思路是借鑑了其餘 工程領域的實踐 － 所以我把它們稱爲工程方法。工程方法已存在了很長時間了，可是沒有取得使人矚目的成功，由於它有作太多的事情須要作，從而延緩整個開發進程。

　　敏捷型方法的發展是對這些工程方法的反叛。它們在無過程和過於繁瑣的過程當中達到了一種平衡，使得能以很少的步驟過程獲取較滿意的結果。敏捷型與工程型方法有一些顯著的區別，一般只要求儘量少的文檔，認爲最根本的文檔應該是源碼。可是，我認爲文檔減小僅僅是個表象。

 

敏捷型方法的適應性

　　敏捷型方法是「適應性」而非「預見性」。 工程方法試圖對一個軟件開發項目在很長的時間跨度內做出詳細的計劃， 而後依計劃進行開發。這類方法在通常狀況下工做良好，但（需求、環境等） 有變化時就不太靈了。所以它們本質上是拒絕變化的。而敏捷型方法則歡迎變化。其實，它們的目的就是成爲適應變化的過程，甚至能容許改變自身來適應變化。通常來講預見性是不可能的。那麼，咱們如何對付一個不可預測的世界呢？最重要，也是最困難的是要隨時知道咱們在開發中的情形處境，這須要一個誠實的反饋機制來不斷準確地告訴咱們。這種機制的關鍵之點是「迭代式」開發方法。迭代式開發的要點是常常不斷地生產出最終系統的工做版本，這些版本逐步地實現系統所需的功能。它們雖然功能不全，但已實現的功能必須忠實於最終系統的要求，它們必須是通過全面整合和測試的產品。知足用戶不斷變化的需求是軟件開發的長期沒法解決的難題之一，經典的瀑布模式在一個迭代週期內表現優異，但一旦需求變化,瀑布模式卻顯得無能爲力。敏捷方法知足需求的辦法主要經過迭代。在每一次迭代週期結束時，都能交付用戶一個可用的、可部署的系統，用戶使用並體驗該系統並反饋意見，在隨後的迭代週期這些意見和需求的其餘變化一塊兒在產品中實現和集成。每次迭代週期應儘量短，以便能及時地處理需求變化和用戶反饋。

 

 

敏捷型方法把人放在第一位

　　敏捷型方法是「面向人」的而非「面向過程」的。 工程型方法的目標是定義一個過程，無論是誰用都工做。而敏捷型方法則認爲沒有任何過程能代替開發組的技能，過程起的做用是對開發組的工做提供支持。實施一個適應性過程並不容易，特別是它要求一組高效的開發人員。高效既體如今高素質的個體，也體如今有能讓團隊協調一致的工做方式。但技術人員並不能包打天下，他們須要應用系統的需求引導。這致使了適應性過程 的另外一個重要方面：他們須要與應用領域的業務專家很是緊密的聯繫。這種聯繫的緊密度超過了通常項目中業務人員的介入程度。若是開發人員和業務人員只有偶爾的溝通，那麼敏捷型過程是不可能存在的。他們須要不斷地獲取業務方面的專門知識。此外，這種溝通不是由管理層來處理的，而是每一個開發人員須要作的事。由於開發人員在他們的行業裏是有能力的專業人員，所以他們可以與其餘行業的專業人員同等地在一塊兒工做。

 

自適應過程

　　適應性不只是指在一個開發項目中如何頻繁地修改軟件以適應不斷的需求變動，還有過程自己隨着時間推移變化。一個項目在開始時用一個適應性過程，但隨着時間的推移，開發團隊會發現什麼方式對他們的工做最好，而後改變過程以適應之。自適應的第一步是常常對過程進行總結反省。這樣，若是開始時使用的過程有問題的話，隨着項目的進行，該過程會得以逐步的完善， 以使其能更好地適合開發團隊。

 

敏捷開發的至理名言

（這是我在網上淘到的一篇文章，看起來以爲頗有道理，先收藏在此再慢慢體會。）

一、完整地幹完一件過後在開始另外一件事：用廚房比喻來講就是：「先上這道菜，再開始作下一道」。軟件開發的最大問題就是同時開始幾件事情，這將不可避免的形成某些工做被廢棄，從而形成浪費。專一於一件事；完整地實現其功能；運行測試；編寫文檔；簽入全部，把這當作一項工做完成，而後再開始下一件事。
二、不要破壞構建：很是明顯，但必須被包含在任何軟件開發建議清單中。程序員在簽入以前採起全部合適的預防措施進行測試，則永遠不會破壞構建。若是構建被破壞，一般是由於有人偷懶了。

三、在用例須要以前，不要實現程序：當你實現一個特定的類，你應該在腦海中有一個特定的用例，同時應該只實現用例須要的方法。你能夠考慮該類潛在的功能，寫入註釋之中，但直到用例真正須要時，才應去實現它。

四、在用例須要以前，不要添加數據成員：同上一條，不過這是從類的數據成員角度考慮的。彷佛顯而易見地，「客戶」記錄須要「送貨地址」，但直到有用例明確須要送貨地址，才應該實現它。

五、不要懼怕作決定，不要懼怕改變先前的決定：敏捷開發是關於相應變化和快速相應的。開發初期，你沒有完整的信息。你應該儘量的推遲決策，直到你必須作出決策的時候。沒有信息，沒法支持你的決定，相反，在有效信息的基礎上作出最佳決定。有了新的信息，不要懼怕改變先前的決定。（某些「恐龍」稱之爲搖擺不定，但我稱之爲響應變化的環境）

六、持續學習如何改善質量：這項工做永不會結束，所以你應常常留意能夠改善的事情，並收集質量問題被確認和處理的案例。

七、度量、度量、度量：敏捷開發幫助處理將來不肯定性問題，但對於過去應沒有不肯定性。測試應持續運行，每次運行的性能表現應被度量和記錄。

八、爲人而設計，而不是系統：開發者經常因技術而使設計誤入歧途。毫不要忘記設計的最終目標，那就是幫助人們完成工做。

九、測試是產品的一部分：不少開發者和經理認爲產品就是交付給客戶的東西，而其它全部東西都不那麼重要。測試應被認爲是產品實實在在的一個部分，值得在設計時仔細考慮，甚至，在不少狀況下，和產品一塊兒交付給客戶。（後半部分有爭議，可是內建測試做爲軟件交付的一部分僅僅佔用可有可無的空間，卻在必要時提供顯而易見的好處，這種方式應該被考慮。）

十、在代碼以前編寫測試：測試自己能夠用來闡釋真正須要的設計。設計的缺陷經常是經過測試用例被發現的。想一想看，編碼以前，經過這些用例，能夠節約多少時間。可是，爲用例1編寫測試，而後編碼，而後再開始用例2。

十一、消除浪費：坦率的說，這是另外一個必須包含在任何開發原則清單中的陳詞濫調，由於它過重要了。發現浪費並消除它，這項工做沒有盡頭。消除任何不能增長客戶價值的東西。若是你不能確認客戶價值，那極可能你並不須要它。

十二、創建對構建破壞當即響應的文化：要明白當構建被破壞，會影響項目中的每個人，所以，最重要的是確認核心代碼被構建併合理測試。我曾見過有些團隊聽任失敗測試持續數月，由於那是其它人的工做。每一個人都痛苦，但沒人採起行動。想反，必須造成共識，那就是小工做能爲團隊得到大的回報。

1三、全部團隊成員應理解客戶須要：大型的複雜項目定然被分解爲獨立的團隊，進而被分派給開發人員。可是，不該在此範圍內作的是，失去關注最終項目真正用戶的指望和目標。

1四、把相關定義放在一塊兒：組織代碼以使高度相關的事情在一塊兒，或在一個類中。這是標準面向對象設計封裝原則。理想狀況下，全部的類外的代碼不須要知道內部工做細節。一些開發者樂於將細節擴散到多個文件中以便按不一樣方式組織，如全部相同的數據類型放在一塊兒，或者按字母順序組織。例如，在他們要用的不一樣包中，將全部常量放在一個類裏，這增長了沒必要要的程序複雜性。指導原則應該是按相關性分組從而隱藏複雜性。

1五、始終在簽入以前運行測試：這條準則幫助你知足「不要破壞構建」準則。

1六、過早的優化時萬惡之源：引用高德納被證明的話：代碼應編寫良好以免微觀層面的浪費，但獨立方法層次之外的優化應等待整個程序基於真實的最終用戶使用情景的壓力測試的進行。僅僅基於對代碼的靜態理解，直覺地判斷對總體性能什麼是重要的，結論幾乎老是錯誤的。相反，度量整個系統的行爲，辨別1%真正影響性能的代碼，並專一於此。

1七、減小積壓未完成的編碼任務：當開發人員開始一個用例，會發生成本，跟已修改卻未完成和測試的代碼相關聯。留着未完成的變化幾天或幾個星期會累積成巨大的重作風險。考慮每一個估算須要一天的三個任務，同時開始這三個任務，並在3天內同時進行，意味着9個單位的累計成本。可是順序進行每一個任務，完成一個再開始下一個，意味着只有3個單位的成本。這個不是直覺，直覺告訴咱們，在工做完成以前，咱們不妨同時作三件事情。但軟件不像物理構造。短小，快速和完整的工做不只減小認知的負擔，並且減小未完成工做與他人未完成工做之間衝突的可能。

1八、不要過分強調代碼的通用性：這就是著名的「YAGNI-你不會須要它」。當編寫一個特定類的時候，程序員總喜歡認爲該類可能用於其它用途。若是如今的用例須要這些用途，這很好，可是，程序員常常考慮未被說起的用途，或者那些實際上永遠不須要的。（這經常讓我聯想到經典的週六現場滑稽短劇，關於某產品既是地板蠟，也是糕點上的甜食。）

1九、兩行代碼能行，就不要用三行：有人閱讀時，簡潔的代碼總能得到回報。但不要將代碼壓縮到難以閱讀。更小的，編寫良好的代碼比之冗長的，編寫華麗的代碼更容易維護，也更容易發現錯誤。始終儘量簡化，但別過度。

20、不要用行數來度量代碼：完成特定任務所需的代碼行數，不一樣的程序員之間和編碼風格之間差別很大。代碼行數不能告訴你代碼完成和質量的些許東西。代碼質量能夠相差200倍，這足以抵消代碼行數的做用。應該統計功能用例的數目。

2一、持續地從新設計和重構：謹慎地使用這條準則，由於有些代碼脆弱而難以改變，但一般你不該懼怕更改代碼以符合實際使用狀況。一個數據成員過去多是整數，可是當一個用例要求它是一個浮點數時不要懼怕去改變它。

2二、刪除死代碼：涉及到大量不能很好理解的代碼是，有個傾向是不自找麻煩。一個例子就是往類中增長新的方法去替換另外一個，開發人員經常會留下舊的方法以防萬一。必須努力檢查方法是否必須，若是沒有證據代表它是必須的，那就刪除它。最糟糕的就是註釋掉大量的代碼，並把它留在那兒。註釋掉的代碼應在測試經過後儘快刪除，固然應在簽入以前。所以，某個時候你發現一些東西可能並不須要，付出小小的努力去驗證並消除此代碼能讓代碼基線更易維護。

2三、不要發明新語言：程序員喜好使用文本文件配置在運行時驅動功能。沒有配置文件可以不編譯而改變程序的行爲。XML的出現推進了無休止的專門定製「腳本語言」的浪潮，以使功能能被最終用戶定製而不須要編譯。這種推理的缺陷在於，離開某個特定實施的環境，操做行爲幾乎歷來沒能很好地精肯定義，同時，那些腳本語言只對那些對問題領域代碼的內部運行有深刻了解的人有用。所以，不具有詳盡內部知識的真實最終用戶永遠不可能知道預料複雜的命令組合的效果須要什麼。腳本語言有用，也不能被消除，可是設計者必須採起很是很是保守的態度，儘量使用現有的語言，避免新的發明。

2四、在你準備實現並測試前，別作設計：你應該有行進的整體思路和對系統架構的概覽，可是，直到開發迭代容許設計被實現和測試前，不要作詳細設計，不要編寫功能實現的詳細說明。詳細設計應當只涉及處處理目前的用例。軟件開發中最大的浪費源於將時間花在設計那些不須要，或者由於某些錯誤的設計假定而須要從新設計的事情之上。

2五、設計是可塑的：不像物理製造，軟件能夠很容易地得到顯著改變。事實上，有大量證據證實軟件自己比描述軟件的設計說明書更容易改變。此外，軟件比說明書更有效地傳達設計。所以，你應該把時間用於直接實現設計，讓客戶能看見設計的細節。若是你犯錯並改變設計，改變軟件比改變規格更容易。但最重要的是，客戶看到代碼運行後，你關於客戶想要什麼的信息大爲完善。

2六、花時間編寫發現和報告異常狀況的代碼中的問題的完整描述：程序員每每很懶惰，拋出粗淺描述錯誤的異常。認爲他們永遠是惟一會看到這個問題的人，而且他們從含糊的描述會記得這個問題的意思。但實際上，在客戶支持環境，不許確或者不完整的錯誤報告比其它緣由浪費更多的時間。編寫每一個錯誤消息，就好像你正向某個正好走進房間而且沒有此代碼經驗的人解釋情況。客戶和客戶支持團隊畢竟沒有此代碼的經驗。

個人啓發

　　據我所知，許多企業有選擇地部分採用了最適合他們的敏捷方式，而不是全盤敏捷化。根據某個網站的調查顯示，Scrum成爲全部敏捷技術中最受歡迎的，選擇Scrum方法的高達41％；其次是極限編程（XP），佔到15％。另有14％的被調查者選擇了混合使用Scrum和XP，13％的人使用自定義或其餘類型的混合敏捷方法。Crystal和動態系統開發方法都只有3％如下的使用者。可是衆所周知，沒有一種方法能夠涵蓋一切，你所遵循的過程必須適應你所在的環境。Scrum是不夠的，XP也是不夠的，敏捷建模一樣是不夠的。他們都只涉及總體過程當中的部分。因此，開發團隊能夠把用到的各類方法進行最佳組合，並從新對其改造以適應本身的須要。而敏捷開發方式每每能給企業和用戶帶來如下好處:

1. 精確。瀑布模式一般會在產品起點與最終結果之間規劃出一條直線，而後沿着直線不斷往前走。然而當項目到達終點時，用戶一般會發現那已經不是他們想去的地方。而敏捷方法則採用小步快跑，每走完一步再調整併爲下一步肯定方向，直到真正的終點。
2. 質量。敏捷方法對每一次迭代週期的質量都有嚴格要求。一些敏捷方法如極限編程等，甚至使用測試驅動開發，即在正式開發功能代碼以前先開發該功能的測試代碼。這些都爲敏捷項目的整個開發週期提供了可靠的質量保證。
3. 速度。敏捷團隊只專一於開發項目中當前最須要的、最具價值的部分。這樣能很快地投入開發。另外，較短的迭代週期使團隊成員能迅速進入開發狀態。
4. 豐厚的投資回報率。在敏捷開發過程當中，最具價值的功能老是被優先開發，這樣能給客戶帶來最大的投資回報率。
5. 高效的自我管理團隊。敏捷開發要求團隊成員必須積極主動，自我管理。在這樣的團隊中工做，每一個團隊成員的技術能力、交流、社交、表達和領導能力也都能得以提升。

　　很顯然我如今尚未能力去駕馭敏捷型開發，多數時候我仍然採用邊寫邊改的方法。我一直試圖用一些正規方法去改善個人編程，可是常常由於事情會變得很是複雜而放棄。可是不管如何我認爲引入一些紀律約束確定會比一片混亂要好，而敏捷型途徑的主要優勢就在於它比工程方法的步驟要少得多，遵循簡單過程總歸要比遵循繁瑣過程更容易一些，因此我以爲敏捷開發很值得一試。做爲一個新生事物，敏捷方法仍是太年輕，可能會遭到業內人士的懷疑，也可能存在各類各樣的問題，比方說敏捷方法能不能用於大的項目，敏捷方法的邊界條件有在哪裏。可是咱們並不能由於這些去阻礙它的發展，我相信經過更多人的實踐，敏捷方法有很大可能會引領軟件開發的潮流。