目 錄
第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
· · · · · · (
收起)
