産品特色

內容簡介

　　短短幾年時間，Scrum躍升為敏捷優選方法，在全球各地得以普遍應用。針對如何用好、用巧這個看似簡單的框架，本書結閤故事、模型和成功秘訣三大要素，透徹講解確保Scrum取得成功的基本要素。全書4部分30章。在簡單介紹Scrum知易行難之後，在一、中闡述導入Scrum之前的準備工作。接著，二、重點介紹實戰基礎。三、提齣急救包的概念，討論如何使每日站會富有成效，如何提齣Scrum的第四個問題，如何讓人們在結對編程時保持專注，增加團隊新成員時應該怎麼辦，發生文化衝突時應該怎麼辦，衝刺應急過程等。四、則鎖定八大主題，重點介紹高級生存指南。在附錄中概述Scrum框架，以幫助讀者快速入門。
　　針對如何用好、用巧這個看似簡單的框架，本書結閤故事、模型和成功秘訣三大要素，透徹講解確保Scrum取得成功的基本要素。本書適閤打算實現敏捷轉型並導入Scrum的所有人員閱讀，比如開發人員、架構師、測試人員、經理和項目負責人，是幫助他們順利度過Scrum理想參考書。
　　

作者簡介

　　Mitch Lacey，敏捷實踐者和培訓師，Mitch Lacey & Associates公司創始人。他擁有16年項目管理經驗，現在的主要身份為敏捷講師和敏捷教練，指導過許多計劃性項目和敏捷項目。在微軟工作期間，Mitch曾運用敏捷相關知識成功發布瞭Windows Live裏的核心企業級服務。Mitch在微軟的第一個敏捷團隊由Ward Cunningham（維基之父、極限編程的創始人之一）、Jim Newkirk（nUnit創始人）和David Anderson（看闆倡導者）所指導。他是認證Scrum講師(CST)和PMI項目管理專傢(PMP)，也經常齣席全球大會發錶主題演講。他是Scrum聯盟和敏捷聯盟的委員會成員，曾經擔任Agile 2012大會的主席。

　　傅勃，瀑布和敏捷的見證者和實踐者。從事多年軟件開發工作之後，在一個CMMI五級的組織裏開始承擔項目管理工作。經曆過混亂到依賴嚴格流程來控製軟件開發過程的轉變，有成功，也有失敗，因而也對傳統軟件開發與項目管理的過程與方法有諸多存疑和睏惑。到2007年，初次接觸Scrum之後，感覺曙光乍現，盡管最初有些難受，但另一扇希望之門已經緩緩開啓。到2009年年初，組織內部已經全麵推廣學習、嘗試敏捷開發實踐（Scrum與XP）。

目錄

第1章 Scrum：知易行難
故事
Scrum
什麼是Scrum
實施Scrum
Scrum適閤我嗎
變化是睏難的
實踐與集成
新的現狀
成功秘訣
引用
第Ⅰ部分 戰 前 準 備

精彩書摘

　　第1章
　　Scrum：知易行難
　　Scrum優雅得具有欺騙性。它是最容易理解的框架之一，同時也是最難以實施好的框架之一。我說“實施好”是因為Scrum固有的簡單性容易誘導我們認為使用Scrum很容易，然而在現實中可能需要很多年纔能把它做好。Scrum似乎與我們過去多年以來瀑布式開發中所習得的完全對立。顯而易見，我們需要一些時間來忘記我們的舊習慣，並調整到一個新的現實中。
　　在本書的附錄中，我解釋瞭Scrum的機製。如果你對Scrum以及如何使用它還不熟悉的話，我建議你從那裏開始。如果已經瞭解Scrum的一些背景，你就知道它的機製是十分簡單直接的。事實上正因為它如此簡單直接，纔導緻很多人誤以為自己已經掌握瞭Scrum，可以立即開始修改Scrum以更好地適應他們的現狀。太過尋常的是，他們反而發現自己迷失瞭方嚮或者受瞭傷而需要幫助，這就是這本書的作用。後麵的故事闡述一點：如果不能理解或者缺乏這些使Scrum有效的核心敏捷概念中的堅實基礎，應用Scrum會很快陷入睏境。
　　故事
　　Jeff是一名敏捷教練，他在一傢大型軟件公司內部幫助團隊應用Scrum。一天，他收到部門的項目群經理Suzy的一封電子郵件。
　　“Jeff，請幫個忙。我們已經做瞭六個月的Scrum，但是我們的代碼質量還是沒有像我希望的那樣提高。我想我們需要你過來和我們討論結對編程。下周一就是我們計劃周的開始，你能來嗎？”
　　Jeff坐在椅子上。討論結對編程相對簡單，他可以帶上他的朋友Julie，一個優秀的開發人員和經驗豐富的敏捷實踐者，沒有問題。但是電子郵件中的兩個字一直浮現在他的腦海中，計劃周？Scrum要求有兩個Sprint計劃會議，每個不超過四個小時。這個團隊要做一周？他感到不僅是結對編程，還有其他更多的事情需要他去做。下周一會比較有趣。
　　星期一，Jeff和Julie到達會議現場，發現Suzy和她的八人團隊一起已經在會議室裏就位瞭。Suzy做瞭一個簡短的介紹以後，Jeff和Julie進行自我介紹，然後開始就Suzy告訴他們的代碼質量問題進行詢問。
　　團隊很快就開始迴答。首席測試員Mike首先說道：“我們的代碼質量差是因為我們沒有時間做測試。開發人員直到我們四周Sprint的最後一天還在寫代碼。‘編碼與測試Sprint’應該既做編碼，也要做測試。但是我們的測試要麼被擠到Sprint的末尾，要麼就演變為‘集成Sprint’。”
　　Julie打斷他說道：“抱歉，Mike，你剛纔說‘集成Sprint’？”她看著Suzy，Suzy點點頭。
　　“哦，我還沒有解釋我們的修改，是吧？”Suzy說道，“我們知道Scrum要求每四周有一個發布，但是對於我們做的這種工作，這是不可能的。我的意思是，在我們嘗試Scrum之前，我們努力按照季度來發布，這完全是一場災難！所以我們所做的就是修改Scrum使其更好地融入我們的流程和現實。”Suzy走到白闆前開始在上麵寫。
　　“首先，我們有一周來做Sprint計劃；然後在四周的實際Sprint中，開發人員寫代碼，測試人員寫測試用例；在這之後，我們就做集成，然後部署。當然，我也常常增加一周作為緩衝應急，以防萬一。”Suzy說道。
　　她話音剛落就已經在白闆上寫好瞭以下內容。
　　Jeff和Julie相互看瞭一眼，然後又看著Suzy。團隊的其他人則顯得很無聊。Jeff問瞭一個很顯然的問題：“Suzy，你們的Sprint真的是八九周嗎？”
　　“對，”Suzy迴答道，“你覺得很意外。我知道這不是正宗的Scrum，但這對我們是適用的。我想我們可能還需要增加一周，你知道嗎，寫規範和測試計劃，把它加進去還有點麻煩。現在我們是在緩衝的那周來做，但是我真的討厭占用我們的緩衝。”
　　“好，我們過會兒再討論這個，”Julie說道。她看著Jeff，Jeff舉著手好像在說：“我們該怎麼辦？”Julie繼續問道：“Mike，你說你們沒有時間做測試？”
　　Wyatt搶在Mike前麵說：“彆聽Mike的。他們有很多的時間來做測試。我們纔永遠沒有足夠的時間。我們每個Sprint都費盡力氣盡可能完成我們所能完成的代碼。為什麼我們需要整整四周？真的就需要這麼長時間。”Wyatt看著Mike接著說，“自從我們開始使用Scrum以來，你和所有測試人員就一直做抱怨你們沒有時間做測試。也許Scrum纔是問題根源。”
　　Jeff和Julie交換瞭一下眼神。
　　Suzy插話說：“各位，我們在這裏不是抱怨Scrum的。我們是來提高代碼質量的。”她暫停瞭一下，深深吸瞭一口氣，“我說這個已經有六個月瞭。”她對Jeff和Julie說並很快無奈地翻瞭翻眼珠。
　　Jeff點點頭說：“我知道你很沮喪，我也知道Mike和Wyatt也很沮喪。我能夠和團隊深入一點討論這個問題嗎？看看我能不能找到問題的根源？”Suzy熱切地點點頭。
　　Jeff以他標準的第一個評估問題開始：“好的，Scrum和極限編程（XP）都要求每日有檢查點。在Scrum中，就是每日Scrum站會。你們怎麼評價你們的每日Scrum站會？”Jeff對團隊提問。
　　Mike笑道：“每日會議？你開玩笑嗎？我們沒有時間做這些。我們每周開兩次會，一共一個小時，這已經很花時間瞭。”
　　“好的，Mike，給我講講你們是怎麼開這些會議的。”Jeff問道。
　　“首先，我們每次開會都說同樣的事情，開發人員說他們在完成任務，我們說我們在寫測試用例，這是大新聞吧。然後我們大概花20分鍾左右的時間對缺陷列錶進行分類，總結來說就是把缺陷列錶挨個過一遍，分為‘設計造成的’和‘在下一個Sprint修改’。當然，我們從來就沒有修改這些缺陷。這純粹就是功能失調所引起的混亂。”Mike說道。
　　看得齣，Suzy很生氣，所以Jeff也給機會讓她來說。
　　“謝謝Mike。Suzy，你的看法是什麼呢？”
　　“Mike說對瞭一件事情。每日站會的確對我們不適用。我們隻有每兩天開一次會。我的日程太忙瞭，沒有辦法每天開會；而有些團隊成員還在其他的項目上。我知道這不是理想的狀況，但是我們隻能這樣做。讓我頭疼的是，即使我們每周開兩次會議，團隊仍然和我爭論，他們認為負擔太重。你聽見瞭剛纔Mike是怎麼說的。他們都抱怨這些會議、時間安排以及沒有足夠時間！但是我也無法拒絕管理層要求我們更快發布。更何況，就像我一直告訴他們的那樣，這是我的項目。我製定計劃，我組織團隊。告訴他們，Jeff，我是ScrumMaster。他們應該按照我說的去做，對吧？”Suzy迫切期待著Jeff的肯定。
　　Jeff不置可否地聳聳肩，保持沉默。他開始意識到他們對Scrum的瞭解是多麼的貧乏。他看瞭一下Julie，給她一個錶示他們還不懂的錶情。Julie輕輕點頭迴答。Jeff繼續他的評估。
　　“好的，我聽見瞭。我們先討論我們現在的問題。看上去一個潛在的問題是你們的每日站會沒有每天都開，沒有生産力，持續時間太長。我們可以糾正它。讓我們先把這個問題放一放，把我們的思考過程提高一個水平。告訴我，你們為什麼會采用8周的Sprint？”
　　Wyatt發話瞭：“我在這裏已經有十年瞭，我見過這裏所有流行過的東西，它們瞬息即逝。但是這次我是一個盲從者，我真的認為Scrum可能不一樣，這是不是有點不可思議！整個事情起源於管理層要求我們更快發布。我們已經做到瞭按季度發布。讓我告訴你，從年度發布到季度發布，真的很睏難，但是我們實現瞭。但是對於管理層，這還不夠快，是吧？”Wyatt會兒停瞭一會兒，環視瞭一下會議室，希望得到迴應。
　　他繼續說道：“所以，有一天我和Suzy坐在一起吃午飯，剛好遇到在另外一個部門工作的我的一個同事。他告訴我們他的團隊正在使用Scrum，他們如何每四周就交付一次，而且他們如何高興。他說他們突破瞭質量的天花闆，管理層已經很多年沒有這樣滿意過，客戶也很欣喜。你知道嗎，這個人和我一樣是個懷疑論者。所以我想如果他都說Scrum有效果，就肯定有效果。Suzy和我就花瞭一個下午的時間嚮他學習Scrum。Scrum看上去非常簡單，但是也有一些問題。首先就是那些每日站會，誰有這麼多時間呢？我們就簡單改為每周兩次。然後四周為一個周期顯然對我們不適用，畢竟我們幾乎不能做到以季度為周期，所以我們決定加倍成為八周為一個周期。以此為基礎，我們就把我們的工作流分解到八周裏麵，就是把所有的事情都壓縮下來。畢竟，Scrum隻是另外一種增量開發的流程而已。”
　　Jeff和Julie又相互看瞭一眼。
　　Wyatt繼續說：“我看見你們的錶情瞭。但是我告訴你們，我們瞭解自己的團隊和産品。原汁原味的Scrum我們可能用不上，所以我們做瞭任何一個軟件團隊都會做的事情，那就是根據我們自己的需要對Scrum進行修改，按照最符閤我們過去做事方法進行組織。”
　　“對，”Suzy確認道：“我的意思是，Scrum是項目經理管理工作的一種方法，隻不過周期更短而已。”
　　Jeff往後坐瞭一下，他準備的評估問題不是為這種情況而設計的，他還不確定現在該說什麼。Julie挺身幫助他：“你們有一個通用的‘完成定義’嗎，Wyatt？”
　　“我們當然有啊。第一周後，我們有設計評審會；然後在第五周結束的時候，我們有代碼完成的裏程碑；在集成結束的時候，我們有完成測試和集成。一旦我們完成這些裏程碑，我們就發布上綫。這真的不難理解。”Wyatt說道。
　　“對，這很簡單，我明白。”Julie安慰道，“團隊，剛纔Wyatt、Mike和Suzy解釋瞭你們的流程。我的理解是你們有每周兩次的站會，八周（有時候九周）的Sprint，而且在特定的關鍵時期也有檢查點，這樣你們就知道你們完成瞭。這樣的工作方式你們感覺怎麼樣？你們感覺工作有樂趣嗎？代碼質量提高很多瞭嗎？”Julie問道。
　　“嗯，還不錯，”Wyatt迴答道。
　　“不錯？！”Suzy問道，“簡直糟糕透瞭。”
　　“這樣糟糕不是我們的過錯！我們試圖做測試，但是就像我講的那樣，我們沒有時間做！”Mike高聲叫道。團隊的其他人盯著桌子，沒有參與這個爭論。
　　“Mike，雖然我可以，但是我沒有指責你，沒有。真正的問題是Scrum，”Wyatt說道，“這是一個愚蠢的流程，它根本就不適用。”
　　“不要又講這個，”Suzy說道，“這個問題我們要爭論多少次？每次迴顧會議我們都在爭論這個問題。”
　　“迴顧會議？”Wyatt插話說：“這隻是一個名字聽著好聽的兩天一次的垃圾會議。迴顧會議不能改變任何事情。Scrum不能改變任何事情。我收迴這句話。Scrum的確改變瞭一件事情，就是使得我們都很悲摧。”
　　“Wyatt，使用Scrum也是你的主意。既然你所做的就是破壞這個流程，當初你為什麼要首先發起呢？”Suzy激動地問道。
　　Jeff站齣來瞭。現在應該是停止提問並開始讓團隊麵對真相的時候瞭。
　　“瞧，這不是那一個人的過錯，也不是Scrum的過錯。對於我來說，我相信Julie也會同意，看上去你們並沒有真正在做Scrum。你們所做的和過去做的是一樣的，隻是壓縮到八周的一個周期中。你們把這個就稱為Scrum。”
　　Wyatt和Suzy準備開始爭辯，但是Julie舉手製止瞭他們。“讓我問一個問題，是問團隊的。Wyatt、Suzy和Mike，請你們不要迴答。”Julie在先看瞭看會議桌團隊的每一個人，然後繼續說道，“這種新的工作方式使得你們的工作更糟糕呢，還是一直就是這樣，可能隻是沒有這麼明顯？”Julie問道。
　　每個人都低著頭，看得齣他們陷入瞭沉思。
　　“過去也很糟糕。”會議室後麵傳來瞭一個聲音。
　　“對，”另外一個團隊成員說：“我隻是沒有意識到過去有這麼的糟糕。”
　　隨著團隊的自我覺醒開始萌芽，會議室陷入一陣沉寂。
　　Wyatt嘆氣一聲說道：“你說的對。過去也沒有比現在好多少，隻是沒有現在這麼明顯。我們原來是每個季度感受一次痛苦，現在是每八周感受一次。”
　　Mike插話說：“知道嗎？看看過去的六個月，我們發現瞭很多應該而且能夠解決的問題，但是我們什麼也沒有做，真的沒有。”
　　Suzy打斷瞭他。
　　“夥計們，我真的纍瞭。我們能夠推遲幾天再來討論嗎，下周？”她問道。
　　團隊點頭同意，他們也纍瞭。
　　Suzy離開會議，意識到事情很糟糕。她花瞭一個周末以及下一周的前半段來思考如何推進工作。她召開瞭另外一個會議並把Jeff和Julie也邀請迴來，她希望以此為團隊確定一個新的基調。
　　“各位，我感到很抱歉。”她以此開始會議，“我知道事情有些糟糕，但是我不知道是那麼糟糕。我原來是請Jeff和Julie來幫助我們做結對編程，我以為那樣可以解決我們的質量問題。顯然，我沒有意識到我們真正的需求，為此我嚮大傢道歉。我們把一切都搞錯瞭，不是Scrum失敗瞭，而是我們錯誤使用瞭Scrum。我想問問你們所有人，我們是不是可以重新開始，我覺得Jeff和Julie可以幫助我們具體實施。”
　　Wyatt點點頭看著團隊說：“我知道我有時候有點犯渾。我在這裏的時間太長瞭，以至於我有時候都覺得我擁有這個地方，但是我沒有。我知道我可以做得更好，我會停止抱怨，真正嘗試Scrum，但是有一個條件。”
　　“什麼條件？”Jeff問道。
　　“就是我們要做就做真正的Scrum，”Wyatt說道：“不要再修改Scrum。而且我們需要一個教練來告訴我們應該怎麼做，這並沒有看上去那麼容易。”
　　Mike抬頭說：“我也有一個條件。我們要修復那些缺陷，真的修復它們，而且不能為此相互指責。”他把手伸嚮Wyatt，“我們能做到嗎？”
　　Wyatt看著Mike，看著他的手，然後握手說：“我覺得我們可以迎接挑戰瞭。如果Jeff還會幫助我們，這就行瞭。”Wyatt玩笑式地朝著Jeff擠眉弄眼。
　　團隊都笑瞭，他們作為一個團隊很久都沒有這樣開懷大笑瞭。這是一個好的開始。他們圍繞著會議桌，各自口頭承諾使用Scrum，這次真正使用Scrum。過瞭一會，Jeff和Julie離開會議，他們感覺完成瞭很多工作，但是還有更多的事情等著他們去做。
　　“你準備怎麼做，Jeff？”Julie問道。
　　“我準備做的第一件事情就是教他們Scrum是什麼，包括它的價值、框架以及他們需要經曆的思維方式的轉變。”Jeff迴答道。
　　“不要忘記告訴他們Scrum是怎麼管理風險和如何幫助發現問題的。”Julie說道。
　　“肯定的。我會從基礎開始並隨著問題的齣現逐個解決。肯定會經常齣現睏難，但是他們能夠做到。沒有痛苦，就沒有收獲，對吧？”
　　Scrum
　　Scrum看上去很基本，但是很多人不能明白的是，要做好Scrum，就必須從根本上改變原來開發軟件的方式，而這並不容易做到。你會掙紮，你會遇到障礙。我們故事中的團隊以其所經曆的艱難曆程發現瞭這一點。如果你拿起這本書，你可能也已經意識到瞭這個問題。為瞭理解為什麼這麼簡單的事情做起來居然可以這麼睏難，讓我們深入探究一下Scrum。
　　什麼是Scrum
　　《危險邊緣》（Jeopardy） 是我最喜歡的電視遊戲節目之一。我一直希望有一個類似的關於軟件開發的版本，其中有這樣一些類彆：方法和框架、導緻軟件故障的常見原因、著名的軟件架構師以及聰明人說的傻話。我可以想齣一大堆符閤這些類彆的問題，比如，“說齣是誰，據說他說過‘對書呆子要友善’；‘你可能到頭來會為我工作’。”我設想在“方法與框架”這個類彆裏麵，可以有這樣一個問題：“說齣一個美式橄欖球的術語，這個項目管理框架可以每兩到四周就交付可工作的軟件。”一個可以接受的答案，當然是以問題的形式，就是“什麼是Scrum？”
　　那麼究竟什麼是Scrum？Scrum不是一個方法或者一套工程實踐。它其實是一個輕量級的框架，設計初衷是管理軟件和産品開發。Ken Schwaber和Jeff Sutherland [Schwaber 01]是這樣描述的：
　　Scrum是一個框架，在這個框架中人們可以解決復雜的適應性問題，同時以高效生産力、創造性方式交付價值最大化的産品。Scrum有以下三大屬性：
　　？ 輕量的
　　？ 簡單易懂的
　　？ 十分難以掌握的
　　Scrum是一個流程框架，從二十世紀九十年代早期就被用來管理復雜産品的開發。Scrum不是産品製造流程或者技術；相反，它是一個框架，在這個框架裏麵，你可以使用各種流程與技術。Scrum把産品管理和開發實踐的效率清楚展現齣來，以便於後期持續改進。
　　Scrum依賴於固定節奏的迭代周期，稱為Sprint。每個Sprint以計劃會議開始，以對潛在可交付産品的演示而結束。Scrum的特徵是團隊內外的反饋和透明。它的短周期和協同的本質使其相當適用於快速變化或者有緊急需求的項目。
　　Scrum建立在五個核心價值之上，它有三個不同的角色、三個工件以及三四個會議。關於Scrum機製的更多細節，可以參見附錄“Scrum框架”。
　　實施Scrum
　　盡管Scrum看上去可能很容易實施，它實際上很有挑戰性。為什麼？因為它的實施不僅局限於設置好正確的機製，然後按一下按鈕。正確實施Scrum需要團隊願意做齣以下改變。
　　？ 理解Scrum的價值觀。
　　？ 往往要經曆巨大的思維方式的轉變。
　　？ 準備變化的發生並適應變化。
　　？ 處理新暴露齣來或新冒齣來的問題。
　　？ 引入敏捷工程實踐。
　　Scrum的基本價值觀
　　任何有使用價值的框架都是建立在一些原則與價值之上的。每一個原始的敏捷實踐：XP、Scrum、DSDM、Crystal、FDD以及看闆和精益，都有一套核心價值。這些價值給我們指明方嚮；在我們睏惑的時候進行澄清；最重要的是，幫助我們理解我們為什麼要這樣做。就像你從前麵開篇故事中讀到的那樣，這個團隊試圖使用Scrum，但是他們不理解為什麼要這麼做。他們 Scrum實戰：故事、模型與成功秘訣 下載 mobi epub pdf txt 電子書

物流迅速，性價比超高

正版好書，在京東購買很方便快遞很及時

敏捷開發入門是書籍

不錯，書不錯，活動也不錯

用生動的故事講，很喜歡

書很好，送貨及時。每個月都在京東買書。

比較期待

書寫的不錯 係統學習瞭一把

還沒看很厚，滿減，買的很劃算。