敏捷倡導團隊文化

需求在不斷地變更，客戶的權力接力棒在不斷地轉接，很多的軟件開發企業的領袖都選擇敏捷開發作爲其軟件過程，那麼在打算實施敏捷以前先得知道是否具備敏捷的一些潛質，敏捷的本質又是什麼？而我們的建議是不要讓敏捷成爲混亂的一個藉口，這同時也是軟件架構師可以考慮的問題。

一般而言很多人都把2001年敏捷聯盟大會的成立作爲敏捷軟件方法的誕生日期，實際上追溯敏捷的產生可能時間更早。早在上世紀末，XP技術就已經嶄露頭角，Kent Beck在很多的軟件工程的大會上發表其關於XP相關思想的一些講話。

衆多的大師積極研究敏捷的原因是因爲由於軟件開發所涉及的人、物投入越來越多，越來越多的項目被拉進了延期的泥潭中，相應的投入越來越多，但是產能比卻不斷下降。

工程師一再抱怨工作壓力太大，每天根本沒有足夠的睡眠時間，而客戶卻不斷的指責謾罵開發的軟件產品爲什麼如此多的Bug。

這與上世紀軟件英雄時代所形成的鮮明對比，所以所有的這些使得這些大師都在思考，到底是什麼造成了軟件開發如此臃腫的身軀？軟件開發過程中到底那些部分可以省略？爲什麼人們對軟件過程的定義越來越多，但是所開發出來的軟件質量卻不見多少好轉？面對這種狀況又如何去改變？於是在2001年敏捷（Agile）軟件聯盟宣佈成立，並發表了軟件敏捷聯盟宣言作爲團隊宗旨。敏捷軟件開發宣言認爲：

◆個體和交互勝過過程和工具;

◆可以工作的軟件勝過面面俱到的文檔；

◆客戶合作勝過合同談判；

◆響應變化勝過遵循計劃。

根據這四條宣言，敏捷聯盟提出了12個敏捷的原則，這12個原則也是區別基於敏捷開發和傳統過程方法的準則，分別如下：

◆最優先要做的工作，持續交付有價值的軟件使得客戶滿意；

◆擁抱變化，通過變化爲客戶創造價值；

◆經常交付軟件；

◆業務人員要和開發人員加強溝通；

◆基於被激勵起來的個人構建項目；

◆最有效的溝通的面對面的交談；

◆工作的軟件是首要的進度度量標準；

◆要保持恆定的開發速度；

◆不斷關注優秀的技術和好的設計模式；

◆簡單是軟件的根本；

◆最好的架構和設計出自自己的團隊；

◆時時反省，隨時調整。

對敏捷的理解

上世紀60、70年代一直到90年代中期，軟件產品一直籠罩了很多的英雄主義色彩，從微軟帝國的Billgates到Linux之父Linus Torvalds，從UCDOS作者鮑嶽橋到WPS的求伯君，所有這些大師的開發團隊無不是激情四溢的。

確定一個簡單的開發目標，快速動手實現原型，以卓越技術爲追求目標，每個團隊成員都是被激發起來的“編程機器”等這些方法使得整個的開發過程的效率和成果質量迅速提升。因此當軟件的開發成本越來越高、時間越來越長的時候，藉助這些方法實現軟件的好、快、省成了順理成章的事情。

可以肯定的是很多敏捷的思想並不是從敏捷聯盟成立的時候纔有的，通過長期的一點一滴地積累，一次一次地實踐，敏捷思想形成了一個體系。目前流行的敏捷開發的方法大概有極限編程(XP)、特徵驅動開發（FDD）、SCRUM、自適應軟件開發（ASD）、動態系統開發方法（DSDM）和水晶方法族（Crystal Methods）等。顯然這些方法彼此之間是有差別的，但是敏捷編程肯定是有一些共性的，敏捷首先是一種氛圍，一種文化。

自信

自信是敏捷開發的重要因素之一。這裏自信的意思是相信自我，一個採用敏捷開發的團隊首先要相信自己的團隊是最優秀的團隊，做的是世界上最優秀的軟件。敏捷的團隊是絕對不允許有人比我更好的，那對他們而言是一種恥辱。

很多的敏捷開發書籍中將這種行爲描述爲“追求卓越”，這並不全面，除了追求卓越，更重要的是追求適用、質量、市場等一系列的目標。一直持續追求超越自我的團隊，一種不斷改進的文化是敏捷開發的核心。如果沒有這樣的一個核心作爲基石，即使採用小版本編譯，測試驅動這些敏捷的方法，也終究不過是習之皮毛。更有甚者，如果成了“邯鄲學步”那就更爲糟糕。

誠然創建一種人人激情四射的氛圍不是一件容易的事情，但是如果認爲無法創建這樣的一種氛圍，不如早早的打消敏捷開發的目的。

敏捷12條原則中有一些是基於這個核心的，比如“圍繞被激勵起來的個人構建項目 ”，“敏捷過程提倡恆定的開發速度”等，這幾條原則的目標其實就是想創建一種敏捷的氛圍，讓所有參與項目的人能夠保持一種持續激情的狀態。這和軟件英雄主義的團隊目標何其的相似。而不斷的應用新的技能和好的設計模式更可以提高團隊的自信，使得團隊自信度不斷的提升。

交流

創建敏捷團隊敏捷氛圍的另一個假設是成員之間相互信任。互信這種說法針對中國國情而言尤爲重要，由於基於東方人的特點，大多數時候喜獨處，不喜交流。特別是對於技術上的問題，很多人寧願自己一次一次的從搜索引擎中查詢也不願意和夥伴交流，即使這個知識點別人可以給以幫助。

很多編程者根本無法容忍兩個人同時共享同一段代碼的做法，所以互信或可以稱爲交流的這個因素就尤爲重要了。就個人的實踐而言，如果兩個人能夠同時編寫同一段程序是有好處的，一方面可以擴充知識層面，除了幫助文檔以外又多了一個更重要的幫助——編程的夥伴，更重要的是可以避免走入“死衚衕”。

寫過程序人大多都有這種體驗，有時候經常在一個地方無法進展下去，總是認爲自己是對的，可是結果總是不在自己的預想之內，但是當第二天再來看程序的時候會發現原來昨天的錯誤是那麼的“愚蠢”，其實如果兩個人共享這段代碼，夥伴一定會在第一時間提醒錯誤在哪裏，這是多麼省時省事的一種做法。

敏捷開發的原則中認爲最有效的溝通方式就是面對面的交流。而XP中對“互信”有更加詳細的規範，結對編程是互信的一個典型體現。結對編程要求結對人員強烈的進行交互，而最終的代碼由兩人共同設計、維護。這大大加快了思想、知識在整個團隊中的傳播速度，使得整個團隊形成統一的合力，使得整個項目不單單依賴個人的力量，在一些關鍵時刻，常常能有“替補隊員”代替所需要的專家。

敏捷開發的原則對交流也有說明，“團隊內部最有效果，最有效率的傳遞信息的方法就是面對面地交談”，所以交流是敏捷開發的另一個要素。採用敏捷開發的團隊在軟件開發過程往往到處可以聽到討論的聲音，但也有人擔心這樣的一種氛圍會影響開發的進度，致使工作效率降低。

自律

很多人在討論敏捷與混亂的區別，的確使用敏捷開發的缺點之一就是如果控制不好團隊會演變成“有組織，無紀律”的一個羣體。因爲敏捷方法通常是沒有很多的條文框架的，敏捷的規範不是來自規範制定者，而是來自實施者，大部分的敏捷團隊的程序員不是遵守紀律，而是進行自律。

敏捷團隊中的成員未必是最優秀的開發工程師，但是這些工程師卻都知道自己應該做什麼事。敏捷團隊的任務不是由項目經理派送的，工程師往往自己決定自己應該做的工作。

那麼敏捷團隊是如何做到這點的呢，其實自律的文化和自信、交流兩個話題緊密聯繫。首先團隊成員相信自己是世界上最優秀的團隊，每個人都有這樣的目標；其次團隊內有很多的交流，這樣每個人都能瞭解其他人做的事情，整個項目的進展如何。這樣每個工程師就知道自己應該做什麼事情，而且也能很快地定位自己應該做的事情。

敏捷在中國的傳播

實際上中國對敏捷的思想接觸較早的，從2001年敏捷聯盟成立以來，很多的敏捷編程就開始被翻譯成中文，其中勢頭最盛的就是極限編程（XP）。

敏捷編程能夠在中國大行其道是有國情背景的，一直以來軟件工程的思想在中國的推進都不是一帆風順的，CMM和RUP等這些在國外執行的還不錯的思想在中國本地只能是課本上的一種教材案例，或者是一些企業拿來撐充門面的旗幟。所以如何建立有中國特色的軟件項目管理體系是很多的項目管理者苦苦探求的事情，而敏捷似乎給了中國人一次機會。