需求在不斷地變更，客戶的權力接力棒在不斷地轉接，很多的軟體開發企業的領袖都選擇敏捷開發作為其軟體過程，那麼在打算實施敏捷以前先得知道是否具備敏捷的一些潛質，敏捷的本質又是什麼？而我們的建議是不要讓敏捷成為混亂的乙個藉口，這同時也是軟體架構師可以考慮的問題。
一般而言很多人都把2023年敏捷聯盟大會的成立作為敏捷軟體方法的誕生日期，實際上追溯敏捷的產生可能時間更早。早在上世紀末，xp技術就已經嶄露頭角，kent beck在很多的軟體工程的大會上發表其關於xp相關思想的一些講話。
眾多的大師積極研究敏捷的原因是因為由於軟體開發所涉及的人、物投入越來越多，越來越多的專案被拉進了延期的泥潭中，相應的投入越來越多，但是產能比卻不斷下降。
工程師一再抱怨工作壓力太大，每天根本沒有足夠的睡眠時間，而客戶卻不斷的指責謾罵開發的軟體產品為什麼如此多的bug。
這與上世紀軟體英雄時代所形成的鮮明對比，所以所有的這些使得這些大師都在思考，到底是什麼造成了軟體開發如此臃腫的身軀？軟體開發過程中到底那些部分可以省略？為什麼人們對軟體過程的定義越來越多，但是所開發出來的軟體質量卻不見多少好轉？面對這種狀況又如何去改變？於是在2023年敏捷（agile）軟體聯盟宣布成立，並發表了軟體敏捷聯盟宣言作為團隊宗旨。敏捷軟體開發宣言認為：
◆個體和互動勝過過程和工具;
◆可以工作的軟體勝過面面俱到的文件；
◆客戶合作勝過合同談判；
◆響應變化勝過遵循計畫。
根據這四條宣言，敏捷聯盟提出了12個敏捷的原則，這12個原則也是區別基於敏捷開發和傳統過程方法的準則，分別如下：
◆最優先要做的工作，持續交付有價值的軟體使得客戶滿意；
◆擁抱變化，通過變化為客戶創造價值；
◆經常交付軟體；
◆業務人員要和開發人員加強溝通；
◆基於被激勵起來的個人構建專案；
◆最有效的溝通的面對面的交談；
◆工作的軟體是首要的進度度量標準；
◆要保持恆定的開發速度；
◆不斷關注優秀的技術和好的設計模式；
◆簡單是軟體的根本；
◆最好的架構和設計出自自己的團隊；
◆時時反省，隨時調整。
對敏捷的理解
上世紀60、70年代一直到90年代中期，軟體產品一直籠罩了很多的英雄主義色彩，從微軟帝國的billgates到linux之父linus torvalds，從ucdos作者鮑嶽橋到wps的求伯君，所有這些大師的開發團隊無不是激情四溢的。
確定乙個簡單的開發目標，快速動手實現原型，以卓越技術為追求目標，每個團隊成員都是被激發起來的「程式設計機器」等這些方法使得整個的開發過程的效率和成果質量迅速提公升。因此當軟體的開發成本越來越高、時間越來越長的時候，借助這些方法實現軟體的好、快、省成了順理成章的事情。
可以肯定的是很多敏捷的思想並不是從敏捷聯盟成立的時候才有的，通過長期的一點一滴地積累，一次一次地實踐，敏捷思想形成了乙個體系。目前流行的敏捷開發的方法大概有極限程式設計(xp)、特徵驅動開發（fdd）、scrum、自適應軟體開發（asd）、動態系統開發方法（dsdm）和水晶方法族（crystal methods）等。顯然這些方法彼此之間是有差別的，但是敏捷程式設計肯定是有一些共性的，敏捷首先是一種氛圍，一種文化。
自信 自信是敏捷開發的重要因素之一。這裡自信的意思是相信自我，乙個採用敏捷開發的團隊首先要相信自己的團隊是最優秀的團隊，做的是世界上最優秀的軟體。敏捷的團隊是絕對不允許有人比我更好的，那對他們而言是一種恥辱。
很多的敏捷開發書籍中將這種行為描述為「追求卓越」，這並不全面，除了追求卓越，更重要的是追求適用、質量、市場等一系列的目標。一直持續追求超越自我的團隊，一種不斷改進的文化是敏捷開發的核心。如果沒有這樣的乙個核心作為基石，即使採用小版本編譯，測試驅動這些敏捷的方法，也終究不過是習之皮毛。更有甚者，如果成了「邯鄲學步」那就更為糟糕。
誠然建立一種人人激情四射的氛圍不是一件容易的事情，但是如果認為無法建立這樣的一種氛圍，不如早早的打消敏捷開發的目的。
敏捷12條原則中有一些是基於這個核心的，比如「圍繞被激勵起來的個人構建專案」，「敏捷過程提倡恆定的開發速度」等，這幾條原則的目標其實就是想建立一種敏捷的氛圍，讓所有參與專案的人能夠保持一種持續激情的狀態。這和軟體英雄主義的團隊目標何其的相似。而不斷的應用新的技能和好的設計模式更可以提高團隊的自信，使得團隊自信度不斷的提公升。
交流 建立敏捷團隊敏捷氛圍的另乙個假設是成員之間相互信任。互信這種說法針對中國國情而言尤為重要，由於基於東方人的特點，大多數時候喜獨處，不喜交流。特別是對於技術上的問題，很多人寧願自己一次一次的從搜尋引擎中查詢也不願意和夥伴交流，即使這個知識點別人可以給以幫助。
很多程式設計者根本無法容忍兩個人同時共享同一段**的做法，所以互信或可以稱為交流的這個因素就尤為重要了。就個人的實踐而言，如果兩個人能夠同時編寫同一段程式是有好處的，一方面可以擴充知識層面，除了幫助文件以外又多了乙個更重要的幫助——程式設計的夥伴，更重要的是可以避免走入「死胡同」。
寫過程式人大多都有這種體驗，有時候經常在乙個地方無法進展下去，總是認為自己是對的，可是結果總是不在自己的預想之內，但是當第二天再來看程式的時候會發現原來昨天的錯誤是那麼的「愚蠢」，其實如果兩個人共享這段**，夥伴一定會在第一時間提醒錯誤在**，這是多麼省時省事的一種做法。
敏捷開發的原則中認為最有效的溝通方式就是面對面的交流。而xp中對「互信」有更加詳細的規範，結對程式設計是互信的乙個典型體現。結對程式設計要求結對人員強烈的進行互動，而最終的**由兩人共同設計、維護。這大大加快了思想、知識在整個團隊中的傳播速度，使得整個團隊形成統一的合力，使得整個專案不單單依賴個人的力量，在一些關鍵時刻，常常能有「替補隊員」代替所需要的專家。
敏捷開發的原則對交流也有說明，「團隊內部最有效果，最有效率的傳遞資訊的方法就是面對面地交談」，所以交流是敏捷開發的另乙個要素。採用敏捷開發的團隊在軟體開發過程往往到處可以聽到討論的聲音，但也有人擔心這樣的一種氛圍會影響開發的進度，致使工作效率降低。
自律 很多人在討論敏捷與混亂的區別，的確使用敏捷開發的缺點之一就是如果控制不好團隊會演變成「有組織，無紀律」的乙個群體。因為敏捷方法通常是沒有很多的條文框架的，敏捷的規範不是來自規範制定者，而是來自實施者，大部分的敏捷團隊的程式設計師不是遵守紀律，而是進行自律。
敏捷團隊中的成員未必是最優秀的開發工程師，但是這些工程師卻都知道自己應該做什麼事。敏捷團隊的任務不是由專案經理派送的，工程師往往自己決定自己應該做的工作。
那麼敏捷團隊是如何做到這點的呢，其實自律的文化和自信、交流兩個話題緊密聯絡。首先團隊成員相信自己是世界上最優秀的團隊，每個人都有這樣的目標；其次團隊內有很多的交流，這樣每個人都能了解其他人做的事情，整個專案的進展如何。這樣每個工程師就知道自己應該做什麼事情，而且也能很快地定位自己應該做的事情。
敏捷在中國的傳播
實際上中國對敏捷的思想接觸較早的，從2023年敏捷聯盟成立以來，很多的敏捷程式設計就開始被翻譯成中文，其中勢頭最盛的就是極限程式設計（xp）。
敏捷程式設計能夠在中國大行其道是有國情背景的，一直以來軟體工程的思想在中國的推進都不是一帆風順的，cmm和rup等這些在國外執行的還不錯的思想在中國本地只能是課本上的一種教材案例，或者是一些企業拿來撐充門面的旗幟。所以如何建立有中國特色的軟體專案管理體系是很多的專案管理者苦苦探求的事情，而敏捷似乎給了中國人一次機會。
團隊管理和團隊文化
團隊管理和團隊文化 提起團隊管理和團隊文化，企業就把規範和歸屬感說的震天響，彷彿國內的團隊要超越黃埔，直達西點。實際上，只有20年時間的中國市場還相對脆弱，必須拋棄國外的團隊文化管理模式，按照中國自己的市場環境 社會環境和文化環境思考問題。團隊和江湖 團隊需要江湖氣嗎？在國外的團隊管理書本教材上，查...
再看微軟團隊文化
人 軟體企業的核心價值 微軟最後價值的是什麼？是 是固定資產？都不是！是那些在微軟工作了多年，開發過多個重要產品的開發團隊和程式設計師.他們的價值在於擁有這樣經驗的程式設計師在業界很難找到，而對於公司來說他們的替代成本相當高.bill gates曾經說過，如果微軟失去20名最優秀的員工，我很難想象微...
敏捷團隊建設
敏捷團隊建設 本文發表於4月 軟體世界 最近很多人都問我，有沒有適合的人可以推薦給他們公司，他們正在招人，面試了很多個，但有經驗的開發人員太難找了。有乙個朋友在問我要人的同時，他手下的乙個開發人員反而問我有沒有好的機會，他想跳槽。不久前乙份報告稱，中國本地軟體企業面臨的最大問題之一，就是高階技術人才...