?

敏捷？

?????? 過去幾年中，軟件行業中出現了一個新詞匯——agile；與此同時，一個關于新的軟件開發方式的變革正悄然興起。

?????? 在老師的引導下，我閱讀了Agile Guide網站上的幾篇文章，并查閱了相關資料。不得不說，這一系列全新的軟件工程方法確實給了我在團隊作業方面的諸多啟發。

?????? 個人理解，敏捷開發并不是一種確定的開發方式，而更像是一種軟件開發過程中的思路指導。有一些概念，與敏捷開發是分不開的，如：極限編程，持續集成，結對編程，TDD等等。這些概念并不完全隸屬于敏捷開發，但又與其有著千絲萬縷的聯系。因此，我更傾向于將敏捷開發當作一種開發的思路，它有著一些原則，從而衍生出一系列的開發方法。

?????? 無論如何，敏捷開發有著兩條基本原則：

1. Agile methods are adaptive rather than predictive.

敏捷開發具有適應性，而非預見性。

1. Agile methods are people-oriented rather than process-oriented. ?

敏捷開發是面向人的，或者說，以人為核心的。

?????? 這是兩條很關鍵的原則，與此相應的是傳統開發過程中的兩大弊病。首先，傳統開發過程中，往往制定了詳細同時繁雜的計劃。而這些計劃很難被遵守，因為需求時常是變動的；畢竟工程的開發并非一朝一夕，不變則跟不上潮流，做出的產品就會過時。于是，在修改功能的同時，又要去更新長篇大論的文檔。這種拉鋸的過程不能說沒有意義，但也頗為——原始。既然需求無法更改，我們就應該更改我們的思路：需求經常變動？那好，我們就不去做詳盡的計劃，而是靈活變動，小文檔，小版本，簡潔明了，經常發布，做好改動的準備。有預見性的開發，將更靈活，更直接。

?????? 其次，傳統工程開發將人作為部件，好像程序中的塊：每個人有自己的位置，有自己的功能，其他不需勞神。表面上看，這樣的方式清晰明了，只需要像零件一樣運作起來就可以了。但實際上，有一個致命的缺陷：人并不是零件。這樣的氛圍下，人失去了主動性，失去了工作的動力，忽視了思想碰撞火花能夠得到的優勢。在曾經的工作中，我也碰到過類似的情況：在一次活動的準備中，部里分工不同的小組只是機械地執行了互相間的聯系，而沒有對一些漏洞提出質疑。雖然，活動依然完成了，但是浪費了很多資源——我們本可以做的更快，更好。這就是當人成為機器的時候產生的可怕后果。我們應該改變傳統思路，以人為核心，發揮每個人的主動性，讓思想碰撞，讓思維交流。這也是敏捷開發中五大價值觀力圖強調的：溝通，簡單，反饋，勇氣，謙遜。生物學中存在集智的概念：低智商的螞蟻聚集在一起竟產生分工這樣的社會行為；對人類更要將此發揮至極致。

?????? 在這兩條原則的指導下，許多開發方法應運而生。這些方法與我們距離并不遙遠，事實上在團隊協作中觸手可及，許多都給予了我啟發。在團隊作業中，希望能夠在我的團隊中推進實踐。

?

啟發

極限編程（XP）

?????? 極限編程嚴格意義上并不是敏捷開發的一部分，而應該是與敏捷開發平起平坐的一種方法。顧名思義，其宗旨可以總結為：將需求做到極致。例如，我們需要了解客戶需求，那就極限為之，與客戶形影不離，使其成為團隊的一部分，那么對需求的理解與更新勢必登峰造極。諸如此類。

?????? 對于團隊作業，我們可以效仿這種極限的做法：

?????? 我們的工作環境要好，極限之：我們選定一個教室或其他場地，布置白板，工作圖，桌椅，電源等，工作時間就都處在一起，甚至圍坐一張圓桌，隨時交流意見；即使吃飯游戲也一同活動，成為標準的死黨和忠誠的隊友。

?????? 我們的編程非常關鍵，極限之：分為多組，采用結對編程，時刻將精力集中于編程。

?????? 我們的協調非常重要：每日進行例會，交流對項目的理解和學習工作進度。

?????? 等等……

?????? 既然要做，就做到極致吧！

站立會議

?????? 這是一種很有趣的會議方式。所有與會者圍站成一圈進行會議。這樣的會議可以改進坐式會議的許多冗余之處。站立會議更健康，更直觀，更活躍，而且更有效率，不會成為“座談會”。這可以成為我們團隊會議的新方式。

持續集成（CI）

?????? 團隊合作的項目往往是大家悶頭做很長時間，最終一集成就跪了。解決這種問題的方式除了寫文檔，還有一種更直接的方式——從一開始就進行集成，并持續下去——這也是極限編程思想的一種體現。CI減少了風險，減少了重復過程，對于團隊效率有著很大提升。

測試驅動開發（TDD）

?????? 極限編程又一實踐：軟件測試過程漫長且錯誤率高怎么辦？將測試用例寫在前面！在工程的開始就寫好測試用例，在用例驅動下進行編程，這樣就萬無一失了！

結對編程（PD）

?????? 在開發層次，結對編程能提供更好的設計質量和代碼質量，兩人合作能有更強的解決問題的能力；對開發人員自身來說，結對工作能帶來更多的信心，高質量的產出能帶來更高的滿足感。在心理上,當有另一個人在你身邊和你緊密配合, 做同樣一件事情的時候,你不好意思開小差, 也不好意思糊弄。在團隊管理層次上，結對能更有效地交流，相互學習和傳遞經驗，能更好地處理人員流動。因為一個人的知識已經被其他人共享。

?

結語

?????? 以上就是我對于敏捷開發及其相關概念學習之后一些總結和感悟。事實證明，我們是人：無論完成什么類型的工作，我們都需要以人為本，將人性的因素考慮進來——畢竟我們的根本屬性。

?????? 最后復習一下敏捷開發宣言：

Manifesto for Agile Software Development

We are uncovering better ways of developing

software by doing it and helping others do it.

Through this work we have come to value:

?

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

?

That is, while there is value in the items on the right,

?we value the items on the left more.

Agile Software Development ——敏捷開發