摘要
某年會上我作為「磚家」和其他專家一起被擺上台，有人問了乙個問題：什麼是敏捷？
這個問題很難回答，當時我用四個字回答：簡單有效。人家一聽，這不是大忽悠嘛！本系列文章將會分幾篇文章為你分享什麼是敏捷，敏捷的「官方」定義，敏捷流程框架及最佳實踐，敏捷在中國面臨的挑戰，實踐敏捷所需要的土壤，最後給出我對敏捷的理解。本文是第一篇，我們將從「打針」說起！有沒有搞錯，「打針」居然和敏捷有關係？是滴，快看看吧！
本文大綱
1.從「打針」說起
2.敏捷的各大門派
3.敏捷四大宣言
4.敏捷十二個準則
5.敏捷的「官方」定義
1.從「打針」說起
網際網路中有一張關於敏捷的「神圖」，請仔細品味一下：
圖1.1 打針與敏捷的關係
在敏捷面前我們都是「小朋友」，小朋友要打的這個針叫「敏捷」！
a）最左邊的小胖帥哥，正在打針（正在實施敏捷），你看到他的「精彩」表情了吧！
b）中級的戴眼鏡的小帥哥，馬上就要到他打針了（即將實施敏捷），他見到小胖哥的誇張表情，整理猶豫和忐忑當中……
c）右邊一堆暫時還不需要打針（敏捷「圍觀」群眾）的小朋友，他們是不明「敏捷」真相的圍觀群眾。所謂針不到肉不知道疼，先圍觀樂著唄……
這個圖實在太神了！你屬於哪種情況呢？正在實施敏捷？即將實施敏捷？還是圍觀當中？
2.敏捷的各大門派
2023年初我聽說的一種敏捷叫做「xp」，當時還以為這個「xp」與 windowsxp 有關係呢！長時間的工作積累，讓我認識和實踐了多種敏捷，以下的敏捷門派，你聽說過嗎？
1）openup（rup敏捷版）
2）精益開發
3）極限程式設計（extreme programming,簡稱：xp）
4）scrum
5）msf（英文：microsoft solution framework，中文直譯：微軟解決方案框架，可以理解為：微軟研發的最佳實踐）
6）水晶方法
7）特性驅動開發
有一本書叫《敏捷開發知識體系》對上述提到的大部分敏捷門派都有所介紹，可以考慮入手一本看看。我還是這本書的編委之一呢，不過實在慚愧，我對本書貢獻很小，不過我會通過部落格和**陸續為大家分享敏捷方面的文章。
當我提到msf也算敏捷門派一種時，可能會有朋友會說：不是吧？且聽我逐一道來……
本系列文章並不會深入討論msf，msf似乎已經「廉頗老矣」，我會分享scrum及極限程式設計方面的敏捷實踐為主，將來有機會再詳細分享msf。這裡也需要稍微囉嗦一下，我其實並不熟悉全部的敏捷門派，僅僅是對msf、xp和scrum都比較熟，積累了一些實踐經驗，並且有自己的想法和體會。
3.敏捷四大宣言
敏捷其實無所謂「官方」，你只要足夠牛b，你自己都可以建立自己的門派，用你喜歡的名字來命名你的門派！但問題來了，如果這麼多門派都說自己才是正宗的敏捷，咋辦？
那簡單，開乙個武林大會決一勝負就是了，誰贏就是正宗滴！所以美國各大敏捷門派開了乙個敏捷大會，各大門派血戰九九八十一天，決不出勝負，乾脆成立了乙個敏捷聯盟，達成了乙個重要的一致決定，那就是：敏捷的四大宣言和十二準則，要滿足這四大宣言和十二準則才能叫敏捷！這下好了，決不出勝負，他們乾脆抱團結盟，為敏捷立下了門檻了。
哈哈，上述一段是戲說，當家不要完全當真。其實事實真相是：美國各大敏捷流派經過討論協商後，提煉出各大門派的共性，這就是四大宣言和十二準則。當然可能有人會跳起來說：幹嘛是美國？不能是中國嗎？我也很想是中國啊，可惜我們在這方面是落後於人家滴，所以只能說人家制定標準，我們學習羅！有朝一日，希望我們能超過美國吧！
我們用乙個圖看看敏捷四大宣言吧：
圖1.2 敏捷四大宣言
看這個圖是需要一點「學問」滴，這個圖要點是：敏捷是乙個相對的詞彙，敏捷代表左邊比右邊更好一點。於是這個圖可以用以下四句話來表達：
1）「個體和互動」更優於「流程和工具」；
2）「工作的軟體」更優於「詳盡的文件」；
3）「客戶合作」更優於「合同談判」；
4）「相應變化」更優於「遵循計畫」。
例1：有人說做cmmi就是用一套流程和文件將事情複雜化，然後為了管理這一套流程和文件，再用一套流程和文件來管理前面的這一套流程和文件。這樣是相當悲催的事情，說它是反敏捷已經輕了，我覺得是***！這樣的做法明顯就是違背了敏捷宣言的第1、2句話。
例2：某公司過了cmmi3級，過程要求必須產生一系列的文件，結果文件有了，但軟體不能工作。這樣做明顯違背了敏捷宣言的第2句話。實踐敏捷的你覺得爽了，這下可以「打正旗號」地不寫文件了，但問題哪怕文件不用寫，你能保證軟體是可以工作的嗎？你能做到「持續整合」和「測試先行」嗎？「持續整合」和「測試先行」其實就是第2句話所演化出來的最佳實踐。（後續文章再為詳細大家分享「持續整合」和「測試先行」）
例3：某軟體公司為了讓客戶「高興」，一直滿足客戶的「無理」要求，但客戶最後還是將軟體公司告上法庭，於是雙方在法庭上引用合同條款互毆。軟體公司律師辯護的理據：一直按照客戶的要求來做出軟體，軟體公司沒有過失。客戶律師的理據：軟體公司沒有提供專業服務，沒有能滿足客戶的真正需要。最後法庭判客戶勝訴！遇到強勢的客戶，可能你會覺得難以做到「客戶合作」，但如果你一味奉承客戶，而不想辦法和客戶好好溝通，達至雙方合作和雙贏，最後如果要鬧上法庭，我們軟體公司敗訴的機會是很大的。因為軟體是一項專業的服務，客戶並不是專業人士，我們要承擔更多的過失責任。這個案例體現了「客戶合作」更優於「合同談判」。
例4：為了更好實踐敏捷宣言第4句話，我們的專案乾脆就不需要計畫了，因為計畫趕不上變化！請問這是在敏捷嗎？恰恰相反，計畫正是應對變化的最好辦法，但我們的計畫需要及時響應變化。「敏捷」常常成為「偽敏捷」外殼，或者成為「手工作坊」模式的遮醜布，這些都是我們需要注意的。
上述4個例子還不能充分說明這四句話的內涵，先簡單體會一下吧，我們還需要在實踐中反覆體會這四句話。
4.敏捷的十二個準則
四大宣言可能有點粗，所以美國敏捷聯盟還弄了12個準則，這12個準則可以看成是這四大宣言的細化。
12準則如下：
1）我們的最高目標是，通過盡早和持續地交付有價值的軟體來滿足客戶。
2）歡迎對需求提出變更——即使是在專案開發後期。要善於利用需求變更，幫助客戶獲得競爭優勢。
3）要不斷交付可用的軟體，週期從幾周到幾個月不等，且越短越好。
4）專案過程中，業務人員與開發人員必須在一起工作。
5）要善於激勵專案人員，給他們以所需要的環境和支援，並相信他們能夠完成任務。
6）無論是團隊內還是團隊間，最有效的溝通方法是面對面的交談。
7）可用的軟體是衡量進度的主要指標。
8）敏捷過程提倡可持續的開發。專案方、開發人員和使用者應該能夠保持恆久穩定的進展速度。
9）對技術的精益求精以及對設計的不斷完善將提公升敏捷性。
10）要做到簡潔，即盡最大可能減少不必要的工作。這是一門藝術。
11）最佳的架構、需求和設計出自於自組織的團隊。
12）團隊要定期反省如何能夠做到更有效，並相應地調整團隊的行為。
這12個準則比四大宣言多了不少字，是不是已經可以幫助你精準理解敏捷了？
如果你回答是，恭喜你，你是超級小神童！如果你的回答是否，那我們要握一下爪了，夥計，我終於找到乙個和我一樣的正常人了！
敏捷四大宣言和十二準則，需要不斷地通過實際工作來理解和體會！
5.敏捷的「官方」定義
那次年會被人措手不及的問了這個問題：什麼是敏捷？
當時我招架不了，回答了：敏捷就是用「簡單有效」的原則做事情。
到現在我還死要面子，堅持這個回答是正確的。好吧，我承認我不是什麼名人，我說什麼是敏捷不算數，那麼就來個「官方」定義吧：
那就是「符合敏捷四大宣言和十二個準則的做法，都是敏捷！」
這可不是我說的，是美國敏捷聯盟達成一致的結果。但這句話說得輕巧，要理解敏捷四大宣言和十二個準則，需要花多長的時間去實踐和體會啊。
作為敏捷入門者來說，先簡單了解到這裡就可以了；作為敏捷實踐資深人士來說，也沒有必要就糾結「敏捷」這個概念，有用就行了管他是不是敏捷，敏捷只是個說法而已。
那我為什麼要寫「神馬是敏捷？」這個系列文章呢？後續還有多篇文章將會陸續分享，你將會知道我寫這系列文章的真正用意，敬請期待！
請看下一文！
摘要：scrum是當前最火的敏捷流派，我們就以她為代表學習一下吧……
創新工場創業課堂（敏捷課程）講師
軟體研發管理資深顧問
cmmi首席專家
《火球——uml大戰需求分析》作者
www.umlonline.org創辦人
張傳波 軟體知識原創基地(www.umlonline.org)
敏捷是怎樣煉成的
很早之前，就有了寫 的衝動，寫一本給程式設計師看的 寫一本能夠反映中國程式設計師生活的 曾幾何時，沉默寡言 喜歡獨自思考 甚至 木吶 成為了程式設計師的標籤。其實在每個程式設計師心中，除了對技術的痴迷，他們也熱愛生活。他們改變著技術，也同時被技術改變著。他們是一群普通的人，也是自己心中的英雄。之所以...
敏捷是慢的藝術
是的，你沒有聽錯，我說的確實是 慢 但如果敏捷關注的是慢，我為什麼還要用敏捷呢？要解答這個問題，首先需要回答，為什麼你需要 快 客戶需要軟體，是因為要獲取某些價值或者利益，而這些價值當然是越早獲得越好，特別是在有競爭對手的情況下，慢 就意味著價值的流失，甚至無法得到價值。正是因為這個原因，通常我們就...
敏捷開發，英文是Agile，我所理解的敏捷
理論上的知識我看的不多，沒有很準確的概念，我想無論哪種開發方式都有自己的理論基礎，和相應的方法步驟，比如 瀑布模型，增量模型，迭代模型，敏捷方法等，並且由於專案不同，比如是否是新專案，二次開發專案，或者是維護專案，採用的方法也不盡相同，沒有固定不變的，不同的公司也可能不一樣，所以我只是說說我所理解的...