宣傳語
用小說體的形式來講述敏捷開發的故事，讓複雜的概念變得通俗易懂。
不用高深的術語蒙人，在最大程度地幫助喜歡敏捷開發的讀者了解到什麼是敏捷開發的同時，增加閱讀的快感。
作者簡介
王立傑，目前就職於一家美國公司，從事電信移動網路監測系統的開發與維護。在網際網路、電信、電子和鐵路等行業，在敏捷開發和項目管理等方面，具備多年實踐經驗。
2006年開始將Scrum套用到項目管理實踐，致力於在中國的軟體開發業界推廣Agile理念和方法論，篤信以人為本，關注敏捷，專注Scrum和XP。
作者自序
敏捷是怎樣煉成的
很早之前，就有了寫小說的衝動，寫一本給程式設計師看的小說，寫一本能夠反映中國程式設計師生活的小說。曾幾何時，“沉默寡言”、“喜歡獨自思考”，甚至“木訥”成為程式設計師的標籤。其實在每個程式設計師心中，除了對技術的痴迷，他們也熱愛生活。他們改變著技術，同時也被技術改變著。他們是一群普通的人，也是自己心中的英雄。
之所以選擇敏捷開發的主題作為《軟體英雄傳》的第一部，不僅僅是因為敏捷開發在這兩年被炒得火熱，其實更多的還是在於在今天這樣一個軟體工業化開發的時代，團隊合作和項目管理已經成為每一個程式設計師不可缺少的必修課。而目前，有關敏捷軟體開發方面的書籍95%來自於國外，或者中文翻譯，或者影印，還沒有一本真正寫給中國程式設計師自己看的書。選擇用小說體的形式來講述敏捷開發的故事，讓複雜的概念變得通俗易懂，不用高深的術語蒙人，可以最大程度地幫助喜歡敏捷開發的讀者在了解什麼是敏捷開發的同時，增加閱讀的快感。
王立傑是我多年的好友和同事，在敏捷開發方面有著豐富的實踐經驗。我們一起努力將自己對敏捷開發的理解和開發過程中的所見所聞所想所憂結合起來，儘可能地用深入淺出的方法把理論和實踐通過小說里的人物和故事講給讀者。有意思的是，由於之前我們都沒有太多寫作小說的經驗，在《敏捷無敵》這部小說的早期策劃階段，我們首先將想要納入這部小說的知識點、方法論、涉及的敏捷工具等像列backlog一樣羅列出來，而後在MSN和gTalk的閒聊中，在麻辣誘惑的福壽螺和毛血旺的飄香中，阿捷、大民、阿朱、阿紫、Charles李等個性鮮明的人物就誕生了。出現在主人公阿捷身邊的愛情故事，則是希望每一個熱愛技術的程式設計師都可以在忙碌的工作之餘，找到自己生活的另一半。
由於交稿的時間相對有限，我們像組織敏捷軟體開發一樣將所有的章節分成若干個Sprint來完成，幾個快跑下來，《敏捷無敵》的書稿就這樣煉成了。目前《軟體英雄傳》的第二部——《安全至上》也已經在我們的策劃中，在《安全至上》中，您不僅可以更深入地了解到軟體開發中軟體安全的重要性，而且會對現有軟體開發模式中一些習以為常的做法產生新的認識。希望我們的《軟體英雄傳》能讓每一個程式設計師在自己的“程式人生”中都成為英雄。
許舟平
2009年3月底
Richard和敏捷
Richard是我接觸最多的一個老外，因為大家一直一起做事，無論E-mail，MSN還是Conference Call，每天都要交流上幾次。他們一幫老外負責做一個供內部其他Team用的測試工具，我們一撥國內兄弟負責做該工具所需的Library，有點像Visual Studio與MSDN Lib的關係，兩者互為補充，缺一不可。本屬於一條繩上的螞蚱，但從未一榮俱榮過，更多的是一損俱損。Richard們是非常有創新精神的，一個本地使用的工具，為了更好地分層，不僅僅分成Server和Client，還創造性地使用了CORBA和ORB，融合了C和Java兩大主流開發語言，進而帶來了性能和維護上的N多問題。現在想想，一下子就能接觸到這么多技術，應該說這是公司提供給我們所有人的一次寶貴練手機會。
給內部客戶服務從來不是什麼簡單的事情。首先人家是客戶，是直接給公司創造Revenue價值的，他們說的話永遠是對的，雖然大多時候我們從未認同過，卻沒有任何理由來反駁人家；其次，因為客戶離得太近（就在公司內部），可以隨時跑過來沖你咆哮，或者給你一個Escalation。時間久了，出的問題多了，我們跟Richard們再也不能和睦共處了。因為內部客戶提出的任何一個Issue，我們都必須做一個Root Cause Analysis，找出最初的罪魁禍首，當然最終源頭無非是他們還是我們，萬萬不能往客戶身上賴的。為此Richard們還專門發明了一個IMF（Issue Management Form）。
終於有一天，大家發現，這樣內耗不行，還得一致對外才是正道，因為無論是我們問題多些，還是Richard們問題多些，對於那些難纏的內部客戶而言，他們是根本不Care的。於是Richard們決定實行SLA（Service Level Agreement），逼迫用戶簽訂城下之盟。簡單講，我們把需求按照容易程度分成A/B/C/D/E五類，為每類需求給出一個回響時間，Release之後可能會存在的Defect數目。同時，對於需求文檔，客戶自己要簽字畫押，即使錯誤，我們也會絕對忠實於原始需求來實現，出現任何問題客戶自己負責。譬如A類需求需要4周的開發測試時間，一旦客戶提出來，我們說這個需要四周的時間才能Release，回去耐心等待好了，中間不可以變更，如果要變更，那得走一個Requirement Change Management流程，然後我們再重新估算，Release時間再定。
這樣實行幾個月後，大家都歡欣鼓舞，因為內部用戶的責難和Escalation驟降，大家的壓力減輕了很多。一方面是一些內部客戶覺得等不及我們的實現，就不再提需求；另一方面，在出現問題時，我們總會調出他們曾經自己簽字畫押的需求文檔，讓他們三緘其口。不過，大家都知道這樣雖然可以保護自己，但對公司的利益來講是一種傷害，但苦於找不到更合適的辦法。
直到2005年底，在一次Conference Call上，Richard非常興奮地跟我們講用Scrum流程，足以解決跟內部客戶的衝突。雖然Richard解釋得很細，但大家還是聽了個雲山霧罩，約略記住了幾個關鍵字：Agile，Scrum，Sprint，Backlog，Iterative development，Quick Response，Small Release。會後，下去惡補了兩三個禮拜的Scrum知識後，就跟Richard們一起開始了跌跌撞撞的Scrum 之路，並漸漸地把SLA拋在了腦後。不過也奇怪，我們跟內部客戶的關係居然變得越來越融洽了。
好景不長，在公司的一次WFM（Work Force Management）運動中，我們負責的內部工具成為首要目標，Richard們被迫離開了公司，而我們國內的這撥兄弟也被瓜分到了其他Team，開始真的為公司創造Revenue。沒想到的是，Scrum的種子卻從此在國內團隊開始孕育、發芽，乃至開花。
短短兩年過去了，一次又一次的WFM，讓越來越多的天才Richard們離開了公司，雖然國內的兄弟們不用擔心WFM，畢竟低成本的優勢幾年內還不至於讓WFM燒到中國，但還是有兄弟因為各種原因，或者加入銷售，或者四處走路，以尋求更好的發展。 漸漸地，中午一起吃飯的“飯協”日漸衰落，終於在一次“摸錯門”後，曾經紅極一時的“飯協”正式作鳥獸散，留下為數不多的幾個人還在“深度套牢”中。
直到有一天開會，遇一新人，進來坐到偶旁邊，怯怯地問：“你也是新來的吧？”當場狂暈！這時才發現，自己已經真的沉寂很久了，或許我應該把這些都記錄下來，而且不能僅僅就是Scrum。
幾年來，曾經看過很多書，但留下印象的不多，其中印象最深的無非是Perter F . Drucker的《旁觀者》、Tom . Demarco的《最後期限》、Eliyahu . Goldratt的《目標》、《絕不是靠運氣》、《關鍵鏈》、《仍然不足夠》TOC系列。突然有一天，跟許舟平談起寫一本關於Scrum的書時，小說體的念頭立刻就蹦了出來，並一拍即合，於是你就看到了《敏捷無敵》。
寫書其實是一件很辛苦的事情，感謝這期間各個朋友的幫助、特別是博文視點的李雨來、胡辛征，以及尚未謀面的責編高老師。還有我的愛人和即將滿兩歲的豆豆。她們是我的動力，讓我發現了幸福生活的真諦；她們帶給了我無限的歡樂，是我的幸福源泉；她們讓我明白了世界上無條件的愛和付出的存在。每每勞累時，想到這些，就又會動力充沛起來。
或許你看了，會覺得這不就是誰誰嘛、這不就是某某公司啊。呵呵，對號入座可不是我的本意，如果你能發現某個人或者自己的影子，就當是看了一場大戲好了，畢竟《敏捷無敵》也是虛構的。不是經常可以看到聽到“本故事純屬虛構，如有雷同，概不負責”嘛，請享受這個故事吧。
王立傑
2009年3月底
目 錄
第1章 末日帝國——Agile公司的困境 1
國際上的競爭對手在技術上緊緊追趕，國內的廠商在客戶關係和產品價格上已經屢次讓Agile中國吃了苦頭。如果說當年的Agile獨霸天下，那現在的Agile已經日薄西山，而Agile中國研發中心更像是“最後的武士”，在努力維護著Agile中國的產品開發和質量的尊嚴。
第2章 重任在肩 22
阿捷知道，Agile公司的Project Manager實際是一個只有在中國才有的Title，並不在Agile公司正式的Manager序列里，在Manager Mail Group里也看不到你的名字。如果你幹得好，可以從Project Manager升為Manager里最低一檔的Line 1 Manager，也就是經常被人們簡稱的PM，不過這裡PM是指People Manager，因為只有一線以上的經理才會具有人事權。如果你沒討大老闆喜歡，那么這個項目結束，你也就會從Project Manager打回到Engineer的原形。
第3章 橄欖球與軟體開發 29
敏捷聖賢：嗯！差不多！你知道在橄欖球中這個術語叫什麼嗎？
阿捷：國內都叫司克蘭。
敏捷聖賢：嗯，英文就是Scrum！意思是密集爭球！實際上，我想說的Scrum這個敏捷項目管理方式，寓意就來自於“密集爭球（scrum）”，寓指整個團隊攢足力量，為了一個共同的目標，一起向前快跑！
第4章 兵不厭詐——我們的第一次快跑 42
軟體開發根本就沒有什麼靈丹妙藥可言。雖然敏捷編程技術可以很快開發出優秀的套用軟體，但不是說這項技術適合每個項目。在實施敏捷之前，一定對現有項目做好分析，要對症下藥。
第5章 成長的煩惱 54
阿捷這幾天一直很苦惱，再加上7月的北京已經開始變得炎熱起來，阿捷就有點著急上火，不僅僅睡覺不踏實，連嘴邊都起了大泡。從感覺上講，Scrum應該是一個很好的項目管理模式，不然敏捷聖賢也不會推薦給自己，而且要不然像Google、Microsoft等大公司也早就放棄了。可能只是自己實踐的方式不對吧，但卻又不知道到底該怎么去改善，看來只能靠敏捷聖賢的幫助了。阿捷每天都上網，並待到很晚才下去，希望能碰到敏捷聖賢。
第6章 不僅僅是站立 69
敏捷聖賢：這個“立會”不僅能讓所有人了解其他人在做什麼，當前項目計畫進展如何，還可以幫助大家解決那些阻礙做事情的問題，以及共享承諾。其實，這些都是非常有利於提高團隊合作精神的。
阿捷：噢，可我們每天花這么長的時間開會，影響工作效率。有什麼可以使會議保持緊湊有效的小竅門嗎？
敏捷聖賢：竅門和經驗有很多，我自己總結了8條，想聽嗎？
第7章 鏡子反射 81
從前，有個古老的傳說，講的是當印第安人在趕了3天路後，就會停下來小憩一天，因為他要等著自己的靈魂跟上來。這跟敏捷開發在經歷了一次疊代或者衝刺（Sprint）後，也需要休整，是一個意思。我們也需要等待團隊的靈魂跟上來，這一過程被稱之為“敏捷回顧（Agile Retrospectives）”。如果將項目開發比作一次征途，那么在項目中期進行短期休整是很有必要的。
第8章 我燒，我燒，我燒燒 91
“每天下班前，要求大家對自己負責的任務，給出一個還需要多長時間才能完成的估算。然後，把所的任務的最新估算值，累加起來，就是每天的剩餘多少工作量了。譬如，截至今天，我們還需要170小時，那我們就在這個圖上170左右的位置標註了一個點，用直線跟昨天的剩餘多少工作量點連起來。時間一久，這個實際燒制曲線就出來了。”
第9章 沒有規矩，不成方圓 99
在“衝刺”和“衝刺”之間，留幾天緩衝時間很重要。團隊需要一段時間做一下調整，乾一些非Sprint計畫中的事情。這段時間是一個很好的用來解決一些技術或者工具問題的機會。你會發現你慢一下後，會變得更有效率。這就是為什麼叫“Sprint”的一個理由，你不可能無休止地衝刺。
沒有規矩，不成方圓。由團隊共同制定出來的Scrum團隊規則，可以更好地保證Scrum的順利實施。
第10章 持續集成 107
持續集成最大的優點是可以避免傳統模式在集成階段的除蟲會議。持續集成主張項目的開發人員頻繁地將他們對源碼的修改提交（Check In）到一個單一的源碼庫，並驗證這些改變是否給項目帶來了破壞
第11章 你開車，我導航 118
就像Scrum一樣，並不是所有的Team都有能力實行XP，也不是所有的項目都適合實行XP，要看實際情況而定。
XP中，多數實踐方法是互相加強甚至是互相保證的，不能單單拿出某一個實踐來單獨實施，譬如結對編程，缺乏TDD/重構/簡單遞增設計等實踐的有效補充，結對編程的效果可能會大打折扣。
第12章 背水一戰 133
其實，不說阿捷也知道這個單子的重要性，可是關鍵是如何出奇兵制勝呢？阿捷對Agile公司的產品和技術實力都是有充分信心的。中國研發中心經過這幾年的技術沉澱，已經完全有實力可以獨自完成大部分OSS模組的設計、開發、測試和發布工作了。只是傳統上還一直由美國那邊來控制。阿捷有一個大膽的想法：那就是能不能利用敏捷開發的方法讓中國Team第一次可以完成從模組設計、軟體編碼、系統測試到客戶安裝發布這一整套流程？
第13章 紙牌、下午茶與軟體發布 139
使用計畫紙牌可以極大地提高估算速度。一次估算中，如果任何兩個人的估算值相差過大，一定要停下來澄清後，再重新估算。
給團隊配置兩倍的人，並不能得到兩倍的生產力。人越多，交流的成本越大，效率就越低。如果希望靠增加人員來提高軟體團隊的生產力，無疑是南轅北轍。
第14章 精益求精 153
在敏捷軟體開發中，可以把當前Sprint要做的每個任務，通過這種可視化看板管理起來，每個任務只能處於這三個狀態，當所有的任務都移動到了Done狀態時，這個Sprint才能結束。這樣應該更能讓所有人清楚當前的項目狀態，以及當前的項目瓶頸出現在哪個任務上。這樣，就可以避免Burndown Chart所帶來的假象了。
第15章 柳暗花明又一村 171
在一個Sprint執行過程中，如果遇到一些問題導致Sprint的原始目標不能實現，此時需要及時地調整目標。如果不願意調整目標，任意延長Sprint的時間，就嚴重違反了Sprint的Time-Box特性，以後大家再遇到問題時，會自然而然地想再延長Sprint，那么Sprint快跑的意義也就不存在了。
第16章 滑雪、工作量與生產力 178
好的管理人員會想辦法鼓勵團隊去創新，會選擇預留一定時間讓團隊去思考如何創新，而不會壓榨員工的每一分鐘。
第17章 瓶頸再現 193
對於一個敏捷團隊而言，再單純地以測試人員發現的Bug數量，作為衡量其績效的唯一標準，是非常沒有意義的。
如果有一個核心測試集，能夠覆蓋用戶使用一個產品的常用情形，會更有價值。對所有用戶使用情形都做自動化測試是沒有必要的。
第18章 決不是靠運氣 207
大家對於敏捷軟體開發的實質認識得更加清楚了。在這個過程中，不能為了短期生產力的提高，而做一些殺雞取卵的事情。一切回歸自然，按照事物本身的發展規律去做，一切也就會按部就班地進行：開發團隊也不會為了追趕進度，而犧牲軟體的內在質量；Product Marketing會重新認識客戶需求的價值所在，做好優先權排序，而不會不明就裡地要求全部完成。
第19章 羊群效應 220
羊群是一種很散亂的組織，平時在一起也是盲目地左沖右撞，但一旦有一隻頭羊動起來，其他的羊也會不假思索地一哄而上，全然不顧前面可能有狼或者不遠處有更好的草。這就是“羊群效應”，也稱“從眾心理”。在一個組織中，特別對具有決策能力的管理者而言，“共同承擔責備效應”（Blame Sharing Effect）的存在是導致了“羊群效應”的根本原因。
第20章分散式開發的喜與憂 239
“最高指導原則就是溝通、溝通、再溝通。對於一個分散式團隊，最重要的就是解決溝通的問題。因為缺乏面對面的溝通，由於時間、文化、語言的不同，需要付出更多的人力和財力才能獲得預期的結果，而且小的誤解也會迅速變成大問題。這需要在建立團隊之初，就考慮好這個問題。溝通不要怕多，一定要充分才行。對這個問題，還有一個非常著名的康威定律（Conway's Law）”。
第21章 大地震 256
人才的流動是非常正常的事情，否則，社會也無法前進。但對於一個企業或者一個團隊而言，人才的流失會是一種損失。流失人才並不可怕，最可怕的是領導人沒有從中學到什麼，沒有搞清楚人才為什麼會流失，沒有採取亡羊補牢的措施。長此以往，招到的人才，還會不斷地流失。
第22章 英雄已無用武之地 275
阿捷突然感覺到自己很累，從未有過的累。當阿捷剛加入Agile公司時，Charles就像一座山，高高在上。當阿捷第一次晉升Manager的時候，Charles就像在前面的領路者，自己這一年多來取得的成績與Charles的支持和大度是分不開的。在心中，阿捷曾經偷偷想過自己40歲、50歲的時候會是怎樣，會成為一個像Charles李那樣的高級經理嗎？會帶領著自己的部門在這個瞬息萬變的市場上乘風破浪嗎？
附錄A 敏捷無敵人物介紹 285
附錄B 敏捷無敵大事記 286
附錄C Scrum名詞列表 289
附錄D 流行Scrum工具簡單比較 294
附錄E ScrumWorks,讓Scrum更敏捷 300
附錄F 從美式Scrum說起——一家美國公司的Scrum敏捷
項目紀要與思考 309
附錄G 軟體工程的進化論 314
附錄H 精益生產 321
附錄I X/Y/Z理論 323
附錄J 約束理論(Theory of Constraints,TOC) 327
後記 331
