大致配合翻譯和詞典閱讀了一下這篇文章之后，我另外還查閱了維基百科、百度百科和MBA智庫百科還有一些網絡上的文章。對敏捷開發有了一個大致上的淺顯的認識。

?

敏捷建模（Agile Modeling，AM）的價值觀包括了XP（Extreme Programming：極限編程）的四個價值觀：溝通、簡單、反饋、勇氣，此外，還擴展了第五個價值觀：謙遜。

?

我在互聯網上又查閱了一些其他的關于敏捷開發的資料，包括一些有過這樣實踐經驗的程序員對敏捷開發的看法，還有他們用敏捷開發的辦法實際上達到的效果。首先，我個人很喜歡敏捷開發的功能。我不喜歡閱讀長篇的文檔，和別人合作寫程序的時候，如果對方給我一份很長的說明文檔，那我的工作效率不會很高，還需要另外花時間去閱讀文檔和代碼。我最喜歡敏捷開發里的一點就是面對面溝通。如果我能在程序前面對面地和我一起合作的同伴進行討論，那么我們交流會順利很多，效率也會高很多。敏捷開發講究面對面溝通，這一點對小組內的效率有很大的提高。另外，敏捷開發的小組會議主張的是站立會議即強調“stand up”，既然是站立會議，那么就不會有太長的時間，這也強調了小組成員之間交流的效率。就我自身的一個例子來說，在上一次的結對編程作業中，我一開始拿著代碼毫無思路，然后和同學一起面對面討論了不多久，就明顯感覺對代碼有了一個比較完整的理解。不同的人在討論的過程中，一句不經意的話有可能就會給別人剛好需要的提示。在結對編程過程中，讀懂代碼之后，有段時間還是對新的算法毫無頭緒。在和高小洲同學討論的過程中，我們就一起想出了更好的算法。而我們討論的時間其實也并不長，實際上關鍵的也就是討論中的那么一兩句話，但是這一兩句話對于整個工作的意義非常重要。之后的實現算法編寫代碼都很簡單輕易了。

?

另外，敏捷開發講究實際講究效率，第一位的是做出能夠運行的軟件。我十分贊同這種講究高效率的態度。在軟件編寫的過程中，其實很難去說清楚現在的進度進行到百分之多少了，有可能工作只差一點點就完成了，但是這個難關需要耗費的時間有可能比之前所有的零碎工作加起來還要長也不一定。因此只有一步一步腳踏實地，做出能夠運行的軟件了，才能認為是進度向前推進。一切不能運行的東西都是浮云。我很喜歡這個觀點。敏捷開發本來就比較適合規模不大的團隊來運用。這樣的腳踏實地的觀點，能夠讓整個隊伍更加求實，減少在隊伍中劃水的人。讓整個隊伍更加有效率的運行起來。

?

敏捷開發講究的重在做出可以運行的軟件，進行小版本發布，不僅僅能夠在組內讓效率更高，整體上來說，經常有小版本發布，也能讓外界對于這個軟件的熱情更加持久，不會出現一段時間沒有更新這個軟件就沒有人氣的狀況。持續的小版本更新也能夠讓客戶更加快地體驗到軟件的進行方向，讓客戶更好地進行反饋，讓開發人員得到更多的信息，更加好地獲得需求，從而讓軟件開發不至于走向錯誤的路線。

?

敏捷開發需要較少的文檔。太多的文檔很煩，我深有體會，敏捷開發強調要“較少的”文檔，而重在面對面的快速高效的交流，這在前文中我已經說過我對此的看法了，因此不再多做贅述。敏捷開發的文檔要少要精煉，要少但不是不要。沒有文檔很多工作會很難進行，因為畢竟開發人員不可能把所有相關的東西都記在腦海中，還是要進行一些記錄的。但是重點是要怎樣在不多的文檔中把必要的事情記錄下來。這一點上，我還沒有過進行這類工作的經驗，網絡上的別人寫的資料中，也基本都僅僅是提到了敏捷開發的小組的文檔需要簡短精干這一點，而且必要記錄的東西是不能少的這幾點，并沒有多做陳述，因此我也只能說在今后的編程中盡量往這個方向去做去努力。

?

在文中，提到了“Is Design Dead?”，我認為并不能這么說。文中說敏捷開發的確不會在工程一開始就對每個步驟進行詳細的設計與謀劃 ，這是因為剛剛開始整個工程的時候，不可能把開發過程中會遇到的問題完全考慮到，那么如果在開發過程中遇到問題，就有可能被之前妄加的謀劃倒入誤區，導致問題復雜化。但是敏捷開發不再一開始進行詳細地設計，并不是說敏捷開發要完全放棄設計。敏捷開發也會進行相應的設計，只是使用了不一樣的方法而已，不會在工程一開始便謀劃清楚所有事情，但是每個部分也會有設計，最終的工程會按照設計滿足用戶的需求，達到開發的目的。

?

對于我個人來說，值得一提的是，結對編程也是敏捷開發的工作小組常用的方法之一。在進行上一次的結對編程作業的時候我就明顯地感受到了這個工作方法的好處。這個方法看似來兩個人干一個人的活，對整體效率有降低。但是，首先，如上文說的，至少在我個人來說，我明顯感受到了成員之間的討論對于工作特別是整體思路上的好處，有些一個人冥思苦想不得解的問題，能夠在兩個人的討論中很快地解決掉，而這其實就在很大程度上提高了開發效率。其次，兩個人結對編程，一個人在編寫代碼的時候，犯下的簡單錯誤，經常能夠由另一個人很快指出，這樣一來節省下來很多調試的時間。在一個人單獨寫程序的時候，有很多時間都用在調試上了，結對編程就能夠把這些時間中的很大一部分節省下來。再次，兩個人的知識面比單獨一個人的知識面要廣得多，有很多時候，編程過程中遇到一個問題不會，或者一個需要的技術不會，如果是一個人獨立編程的話，那么我必須去查閱資料啊文檔之類的，學習相關知識再來解決問題。而如果是結對編程的話，同伴能夠互相高效率的解決對方不會的問題。這樣能讓整體進度勢如破竹。結對編程是敏捷開發的常用方法之一，也是敏捷開發的思想的具體表現之一。敏捷開發的高效交流等等特點都能體現在結對編程方法上。

?

雖說，我個人很喜歡敏捷開發這種開發方法，但是敏捷開發也并非適用于所有情況下。我之所以覺得這個方法很好，是因為我身為一個學生，開發的軟件種類、規模有限，組成的工作小組能力、人數有限。對于編寫規模不大的軟件的人數不多的小組，要實現面對面地高效交流、保持人員精干、保持隊伍工作效率之類的都并非難事。但是如果是規模相當大的軟件開發，比如說微軟的windows7操作系統的開發，上千萬行的代碼量，成千上萬的工作人員，這種規模的軟件開發每次都要實現面對面的高效交流基本是不可能的。因此進行這樣規模的開發，就需要在文檔中，把敏捷開發中在面對面交流時說清楚的東西完全寫清楚，這樣雖然不比面對面交流來得效率高，但是卻能夠讓這個大規模多人數的工作組織正確地運行起來，完成小團隊無法完成的大工程。

?

以上觀點均是我的個人觀點，錯誤和紕漏的地方，敬請各位大神和各位老師、前輩指正。

粗略閱讀《Agile Software Development》后的感想