《敏捷軟件開發 : Scrum實戰指南》

敏捷軟件開發

Scrum實戰指南

(第2版)

[美]米奇·萊西(Mitch Lacey)? ? ? 著

王國良? 熊小龍? 葉虎? 鄭璐璐? ? 譯

清華大學出版社

北京

推薦序１：追求技術卓越，創造最大價值

多年來，Mitch和我一起培訓開發人員使用Scrum。隨著敏捷實踐(75%為 Scrum)成為全球最主流的軟件開發模式，學習這本書可以幫助使用者克服在最近幾年中出現的最大的挑戰。

在《敏捷宣言》發布的十年之后，原來的一些簽署人以及更多敏捷思想領袖在猶他州的雪鳥度假村聚會，對敏捷軟件開發十年進行反思。他們慶祝了應用敏捷方法進行產品開發所取得的成功，回顧了取得類似成功必須要清除的關鍵障礙。由此，他們一致認為未來十年的須具備以下四個成功要素。

1. 追求技術卓越。

2. 推動個人變革，進而引領組織變革。

3. 整理知識，加強教育。

4. 在整個流程中將價值創造最大化。

讓我們看看Mitch這本書怎么幫助你養成敏捷領導力。

追求技術卓越

引爆互聯網和智能手機應用的一個關鍵因素就是用小的增量來部署應用，并從最終用戶那里得到快速反饋。這一流程在敏捷中得到了規范，即在短期 Sprint 中開發產品，Sprint長度常常是一個月或者是更短時間，更常見的是兩個星期。在《敏捷宣言》中，我們如此表達這個問題：“相比于詳盡的文檔，我們更看重可工作的軟件。”

《敏捷宣言》十年回顧得出結論，就是大多數敏捷團隊的短期 Sprint產品開發仍然困難重重(通常因為管理層、業務部門、客戶以及開發團隊并不追求技術卓越)。

工程實踐是軟件開發的基石，17%的 Scrum 團隊在實施 Scrum 的同時實施 XP 工程實踐。第一個這樣做的團隊出現在 1993 年，那時XP還沒有出現。這對于職業工程師來說，只是一些常識而已。

Mitch 在第 1 章中說道，他認為一些特定的 XP 實踐是必不可少的，比如：可持續的步伐、代碼集體所有、結對編程、測試驅動開發、持續集成、代碼規范以及重構。這些都是技術卓越的基石。使用 Scrum 但不用這些工程實踐的 61%的敏捷團隊應該仔細讀讀 Mitch 的這本書，并遵循他的指導。缺乏必要的XP工程實踐正是他們在Sprint 結束時不能產生可交付代碼的原因。

Mitch 的書中還有更多對技術卓越的指導，敏捷領導，不管是從事管理工作還是技術工作，都應該追求 Mitch 如此清楚表達出來的技術卓越。

推動個人變革，進而引領組織的變革

除了技術卓越以外，采用敏捷還需要能夠對變化的需求做出快速響應。這就是敏捷宣言的第四個原則：“響應變化高于遵循計劃。”但是，個人適應變化遠遠不夠。組織也必須有能夠敏捷地響應變化的組織結構。如果不是這樣，它們將因為無法消除阻擋前進的障礙而摧毀高效團隊或制約高效團隊的產生。

Mitch 一步一步地解釋了哈佛商學院提出的成功變革的關鍵因素。這里還需要有一種緊迫感。沒有它，變革就不可能。敏捷領導者需要對此身體力行。指導委員會對于制度變革至關重要。敏捷領導者需要確保管理層受到教育、培訓、支持并參與 Scrum 實施。

建立一個愿景并為其他人賦能是成功的基石。獨裁的決策以及控制與命令式管理必定會扼殺敏捷的效力。敏捷領導者需要通過計劃短期的勝利、鞏固提高、消除障礙以及制度化新方法來避免這些災難。敏捷領導者需要成為管理層的一部分或給管理層培訓工程實踐，Mitch這本書可以幫助你發現你需要做什么以及怎么做。

整理知識，加強教育

大多數經理和很多開發人員都不是特別了解團隊和生產力。Mitch在整本書中都在討論這些問題。

軟件開發固有的不可預測性

很少有人知道 Ziv 定律，即軟件開發是不可預測的。全球范圍內大量項目的失敗在很大程度上就是因為缺乏對這個問題以及正確處理這個問題的方法的理解。 Mitch 描述了對持續的變化進行檢查與調整的需要。這本書中的策略可以幫助你避免很多陷阱，消除Scrum 實施過程中的很多障礙。

用戶在看見可工作的軟件之前并不知道自己真正需要什么

傳統項目管理錯誤地假設在構建軟件之前用戶知道自己需要什么。這個問題被正式稱為Humphrey定律，該法則在大學教育以及經理與項目領導者的行業培訓中被整體上忽視。這本書可以幫助你從容面對這個問題。

組織結構會被嵌入代碼中

人們普遍不理解的第三個主要問題是Conway定律。組織的結構會體現到代碼中。一個傳統的層級組織結構會對面向對象的設計有負面的影響，會導致脆弱的代碼、糟糕的架構設計、很差的可維護性與適應性以及過度的成本與過高的失敗率。Mitch 花了大量的篇幅來解釋如何正確建立 Scrum 組織。一定要仔細研讀！

在整個流程中創造最大價值

如果準備好產品Backlog，并且在每個 Sprint 結束時交付可工作的軟件，軟件開發團隊就可以使用敏捷實踐輕易提高一倍或兩倍生產力。生產力提升為組織的其他部分帶來問題，使其缺乏敏捷變得更明顯，讓他們更痛苦。

運營與基礎設施缺乏敏捷

一旦人力與資源用于改善產品Backlog，流向生產系統的軟件的速度至少會加倍，有些情況下可以是 5～10 倍之多。這就暴露了這樣一個事實：開發運營與基礎設施拖慢了生產系統，必須要修正。

管理、銷售、市場以及產品管理缺乏敏捷

在流程的前端，商業目標、戰略以及目的常常都不清楚。這導致即使軟件的產量翻倍了，利潤流卻下降或沒有增長。

因此，組織中的每個人都需要接受如何在整個價值流中優化績效的教育與培訓。敏捷個人需要通過提高其組織知識的能力并培訓整個組織來引導這個教育的流程。

底線

很多 Scrum 實施取得的提高很有限，并且發現很難消除那些使他們陷入持續掙扎的障礙。應該可以做得更好。所有的團隊都可以做得很好，很多團隊可以做得很優秀！工作可以很有樂趣，業務可以是盈利的，客戶可以真的滿意！

如果你準備搞 Scrum，Mitch 的這本書可以幫助你。如果你在實施過程中苦苦掙扎，這本書對你的幫助更大。如果你已經做得很好，Mitch 可以幫助你做得更好。改進是永無止境的，Mitch 的洞察力真的對大家有實際的幫助。

推薦序2：一本真正的實戰指南

1988年，Smalltalk研究團隊從Xerox PARC研究中心(Palo Alto Research Center)分離出來之后，我是ParcPlace Systems雇傭的第一個員工。我們的任務是將面向對象技術的使用商業化。在對象技術運動的早期階段，我們經常討論編寫一種類似食譜的書，用來幫助公司開始使用對象技術。我們的想法是收集我們看到的公司遇到的最重要的情況/問題，并將它們作為一組模式或菜譜呈現出來，格式是“如果你發現自己處于這種情況下，試著做下面的……”然而我們從來沒有寫過那本書。

時光荏苒，二十年過去了，我們來到敏捷開發的時代，Mitch Lacey已經寫了自己的書：關于Scrum主題的一本實戰指南，與準備使用Scrum或者那些仍處于應用初期階段的的公司分享他豐富的Scrum經驗。

我第一次見到Mitch是在2007年，在我成為全球Scrum聯盟第一任總裁之后不久。那時，Mitch已經是認證Scrum培訓師(CST)，并且已經應用Scrum好多年，包括在他第一次接觸Scrum的微軟內部，和后來在他作為Scrum培訓師和教練所服務的大大小小的公司。

我可以從我們的第一次會面上看出，Mitch對幫助人們在Scrum中取得成功充滿熱情。在第一次見面時，他拿出筆記本電腦，開始給我看他收集的數據。他的目標是用從他的經歷中獲得的真實數據來強化軼事式的成功故事。事后看來，這一交流預示著這本書的誕生。

當你讀這本書的時候，你會體會到我在2007年那次談話中以及后來我在與Mitch的多次討論和辯論中的那種感受——因為他有敏銳的收集和分析現實世界經驗并將其歸納為可執行建議的能力。在每一章中，你都會受益于這種建議。每一章的開頭都是一個故事，講述Mitch在某一特定主題上的經歷。我覺得這種技法非常有效，因為我喜歡好的故事，而Mitch則是一個講故事的高手。但是不要在讀完一章的故事介紹后就停下來！故事之后是對故事中所提出的概念的擴展和解釋，而這種擴展和解釋詳述了所提供的建議。

在閱讀這本書的時候，你會注意到的一點是，Mitch并不是在教你理論。他在努力讓你免于碰壁。即使是幾大部分的題目，也傳達了這樣的意圖：“戰前準備”“戰地基礎”“戰地急救”“高級生存”和“荒野必備”。一本真正的實戰指南！

閱讀本書的第2版也有它的好處。自從2012年第1版出版以來，Mitch就一直沒有停過。這個新版本包含許多原始章節的更新版本，以及在新增的“荒野必備指南”中五個全新的章節。這些章節涉及各種各樣的主題，包括如何完成工作、故事點與小時的關系、面試和招聘的技巧、如何將激勵與成果結合起來，以及在敏捷開發過程中管理風險的最重要的話題。如果你已經對第1版很熟悉了，我相信你會從Mitch對新版本的修改和補充中獲益！

還有，對于那些熟悉《Scrum精髓》的讀者，我相信你會發現我的書和這本書相得益彰，特別是由于兩者在特定的問題或方法上的不同之處。很顯然，其他很多人都同意！對于第1版，你可以快速瀏覽一下亞馬遜網站，你會發現，這本書經常和我的《Scrum精髓》一起購買。所以，就像美酒和奶酪一樣，我希望你們喜歡這樣的天作之合！

譯者序：執柯伐柯，活出SCRUM

《詩經》里有一句話：“執柯伐柯，其則不遠”，意思是說，一個人拿著斧子到樹林里去砍一截樹枝當斧柄，如果不知道該砍什么樣的樹枝合適，那么只要看一看自己手里的斧柄就知道了。我們譯者團隊在接受翻譯任務時，當即決定用Scrum來管理我們的翻譯過程，因為我們有多年的Scrum使用經驗，深知Scrum是取得項目成功的助力。

在試譯階段，我們套用Scrum“完成的定義”這個概念，清晰定義了試譯完成的標準，包括完成時間、質量要求、對翻譯活動的問題發掘和后續基本工作原則，并以此為基礎組建了一個高質量團隊。

在確定要正式翻譯之后，我們按Scrum的團隊估算和任務認領等方式制定了發布計劃。非常巧的是，發布計劃剛好是100天，大致從端午節到中秋節。我們確定了完成的定義，包括結對評審和配置管理版本控制等，以保證質量。我們確定了迭代頻率、協作工具、任務板的布局和發布燃盡圖，以保證有效協作和對進度的準確檢查和適應。翻譯過程中，我們的任務板和發布燃盡圖數據更新了100多版。

回到這本書本身，我們認為它是一本真正的實戰指南。它有以下幾個特點。第一，整本書是按話題組織的，每一章是一個話題。各個話題既相互獨立，也合起來組成一個有機的整體。話題既包括一些基本的，比如Scrum工件和儀式的有效操作，也包括一些高級的，比如合同、激勵和招聘等。全書提供了在真實組織環境中運作Scrum時方方面面的建議。第二，書中的建議以“模式”這種經過分類整理和可重用的方法呈現。在每一章的模式之前提供一個故事，讓讀者可以生動領會該模式適用的場景。在模式之后提供了成功要領，讓讀者有機會再次思考解決方案與問題之間邏輯關系。第三，變通性。針對每一問題，并不是提供機械式的唯一解決方案，而是在討論中提供了多種可能性，并在分析各種可能性的基礎上，提出與場景最適配的方案建議。

翻譯這個業余工作能夠順利完成，離不開家人的支持。我們每位譯者在此對各自的家人致以最真誠的感謝。鑒于譯者水平和時間限制，翻譯中如有錯漏之處，歡迎讀者通過各種途徑與我們交流。

又及，我們有一群熱心的小伙伴為本書的故事錄制了部分音頻，掃描相應章節的二維碼，就可以收聽。他們是玲瓏月、書山有伴、馬暢、吳非、余丹、幸運、小熊、陳玲、Wade煒、麗嬋?CC、吳言、魯巧麗、Seven以及西卡。大家一起讀故事，一起分享和深化對Scrum的理解。

前言

歡迎閱讀第2版。

當我提出想要修訂本書第1版時，我妻子懷疑這是不是個理智的決定。畢竟，她提醒我，第1版幾乎把要分享的都寫完了。然而，當我回想起我的第一次寫作過程時，我覺得我不僅有更多要說的，而且我還想調整我已經發表的一些內容。簡而言之，我想要重構，添加一些新特性，并發布2.0版本。所以就有了第2版。

閱讀本書的方法跟閱讀第1版一樣：挑選能解決你在公司遇到的問題的一章并閱讀它，然后應用我的建議，看看會發生什么。

敏捷是一個旅程。自2012年第1版出版以來，我學到了很多東西。如果你以前讀過這本書，你會立刻發現我已經在原來的章節中添加了新的想法和概念。很多章節重寫超過80%；其他的則只有10%。你將看到一個新的部分，第V部分“荒野必備”，包含了更多的實戰技巧，其靈感來自于我與全球組織合作的第一手經驗。這些新章節包括管理風險、面試、一次做對的謬論等等。

本書誕生過程

我女兒 Emma出生時，我感到有些力不從心。相比我們的其他孩子，我們這次在醫生辦公室的時間似乎要更多一些。我一直問我妻子：“這正常嗎？”一天晚上，我在枕頭邊上發現我妻子那本《新生兒父母手冊》，里面有她寫的一張小紙條：“讀讀這本書，你會感到好受一些。”

我讀了。由此我知道了我們所經歷的每件事情對于我的孩子都是正常的，即使對我或我以前觀察到的來說不常見。這使我感到更有信心與安全感。這也正好是我開始試驗 Scrum 與敏捷的時間。隨著我開始遇到障礙與面臨不熟悉的情況，我開始認識到，在做 Scrum與XP的第一年(甚至之后)，我真正需要一本指導手冊。

問題在于，不像一本指導手冊，我不可能準確告訴你，在第 1～3月或者 9～12 月，你的團隊應該做什么或者是應該擔心什么。團隊并不像小孩那樣，不會以一個可以預測的速度發展。相反，在他們第一年的實踐中，隨著他們學習團隊合作、采用敏捷工程實踐、與他們的客戶建立信任、和以增量迭代方式工作的過程中，他們常常會摔倒、蹣跚、犯錯誤，前進兩步就倒退一步。

有鑒于此，我更傾向于以這種方式“我遇到了一個問題，該怎么辦”來組織這本書。我收集了我參與過或者見證過的、在他們第一年敏捷旅途中的那些團隊的故事。隨著我繼續我的敏捷旅途，我注意到各個公司中這些故事、模式通常都很相似。我在一個公司中實現一個想法，稍微調整一下就可以應用在下一個公司中。重復這個過程，我得以收集了這些現實世界的解決方案， 并把它們加入我隨身攜帶的虛擬工具箱。在這本書中，我將與你分享一些最常見的痛苦與解決方法。當你的團隊遇到麻煩或者是受傷的時候，你可以找到最接近你的癥狀的那一章，然后你可以發現，即使不能解決你的問題，至少也有一個辦法可以減輕你的痛苦。

第2版旨在幫助你精心調試你自己的實踐，在一些你不熟悉的領域提供指南以及在前進的道路上更輕松地克服我們都遇到過的困難。

誰應該讀這本書

如果你正在考慮開始 Scrum 或者敏捷的實踐，或者剛剛開始你的旅途，或者已經實踐了一年左右但卻感覺好像迷失了方向，這本書就是為你準備的。我正式的目標群體就是，從那些在6個月以內將開始他們的項目，到那些已經實踐了一年的公司，即有 18 個月的時間窗口。

這本書是為推崇實踐的人準備的。如果你想學習理論或者是高深的討論，可以從很多優秀的 Scrum 和敏捷的書籍中找到一本。另外一方面，如果你想尋求基于我在微軟做過的項目以及我在福布斯 100強的大型公司指導顧問過的團隊的實踐建議與真實數據，這本書會物有所值。

怎樣閱讀這本書

設計這本書是為了方便你在任何時間以任何順序閱讀任何章節。每一章都以一個故事開始， 這些故事都是從我工作過的或者是指導過的團隊、公司、項目中提取出來的。可以想象，為了保護那些清白的(或者是犯錯的)人，我改變了他們的名字。在你看過這些似曾相識的故事后，我會介紹一個模型。這些模型是我在實戰中用來幫助解決故事中存在的問題的。一些模型你可能會感到不太舒服，或者是認為對你的公司可能不適用。我強烈要求你反抗你的忽視建議或者是修改模型的直覺，至少努力嘗試三次，然后看看結果如何，你可能會對結果感到驚訝。在每章的最后，我總結了成功要領，其中的因素事關實踐成敗。

這本書組織為五部分。

第Ⅰ部分“戰前準備”，對你準備開始使用 Scrum 提供建議，幫助你為成功做好準備。如果你正在考慮 Scrum，或者是剛剛開始使用Scrum，就從這里開始。

第Ⅱ部分“戰地基礎”，討論的話題可以幫助你克服開始敏捷的旅途之后團隊與組織會遭遇的初步障礙。如果已經開始了 Scrum 的實踐，但是遇到了困難，你可以從這里開始。

第Ⅲ部分“戰地急救”，著眼于解決公司所面臨的一些更大、更深層次的問題， 比如往項目中增加人手或者是解決每日站會的功能失調。這些都是在第一年實踐中某個時候很可能會遇到的情況。這幾章可以幫助你診斷并處理這些情況，使團隊恢復到健康的狀態。

第Ⅳ部分“高級生存”，討論人們在實踐 Scrum的任何階段都常常掙扎的一些話題。 比如， 項目成本、 合同的制定、敏捷與 Scrum 項目中的文檔等。

第V部分“荒野必備”，包含了一些章節，這些章節關注的是那些被忽視的，但也同樣代價高昂的問題。這些問題是大多數組織在敏捷采納的過程中所面臨的，比如風險管理，面試，一次做對，等等。

如果你是從零開始，對 Scrum 還一無所知，我在本書的附錄中包括了一個對 Scrum 的簡短介紹，旨在幫助你熟悉這些術語與概念。在開始研究這本書之前，你可能還需要多了解一下 Scrum。

為什么需要閱讀這本書

不管你在敏捷旅途中身處何地，我們都需要一個友好的提醒，即我們的遭遇是正常的， 我們還需要解決這些問題的建議和一些成功要領。這本書把這些東西都組織在一起，方便你根據具體需要選擇閱讀需要的章節或者整個部分或者全書。這是真實生活中的情況，可以與你產生共鳴，它的解決方法可以應用于任何團隊。打開書開始閱讀這些故事，這本書將是你經歷 Scrum 與極限編程之高潮與低谷的忠實伴侶。

本書的補充材料

在你閱讀本書的過程中，你可能會想：“我真希望有個工具或者是可以下載一個模板來幫助我實踐這個概念。”很在多情況下，這是可以的。訪問 http://www.mitchlacey.com/supplements/，你可以看到我在我每天的 Scrum 項目中用到的一系列文件、圖片、Excel 表格以及工具。盡管其中一些信息是精心準備過的，但大多數東西還很簡陋。為什么？在我的項目中，我不需要它們很完美，我只需要它能用。你在我的網站上得到的將是第一手的、真實的、偏重實戰且有用的東西。

致謝

在我第一次想寫這本書的時候，我的想法還很粗糙，我還不知道這是一項艱巨的工程。我的妻子 Bernice，讓我有時間專注于這本書，我的孩子也是這樣。沒有她們的支持，就不會今天有這本書。

David Anderson，Ward Cunningham和Jim Newkirk幫助我和我在微軟的第一個團隊取得了成功。他們仨當時都在那里工作，指導我們走過了一些艱難的時期。現在我依然會回頭看看早期與Ward 討論的一些筆記，其中一個是重點顯示的問題：“我們能不能不做TDD？”他們仨都在幫助我們團隊從不適應到變成一個真正特別的團隊。David、Ward 和 Jim，謝謝你們。

沒有我的的妻子Bernice Lacey和這個星球上最好的編輯Rebecca Traeger的幫助，我也無法完成此書。兩個人都花了無數個小時編輯，讓我保持正確的方向并專注于此，幫助我把我的原始想法和文字變成渾然一體的章節。

我還要感謝幫助我精心寫就今天這本書的所有朋友。列在這里的每個人都給予我有價值的反饋并抽出很多時間聽我總結自己的想法或者閱讀草稿。我對他們每個人的感謝溢于言表，他們包括 Tiago Andrade e Silva，Adam Barr，藝術家Tor Imsland，Brent Barton，Martin Beechen，Arlo Belshee，Jelle Bens，John Boal，Jedidja Bourgeois，Stephen Brudz，Brian Button，Sharon Button，Mike Cohn，Jim Constant，Michael Corrigan，Scott Densmore，Esther Derby，Stein Dolan，Marc Fisher，Paul Hammond，Bill Hanlon，Christina Hartikainen，Christian Hassa，Martina Hiemstra，Jim Highsmith，Liz Hill，Donavan Hoepcke，Bart Hsu，Wilhelm Hummer，Ron Jeffries，Lynn Keele，Clinton Keith，James Kovaks，Ben Linders，Rocky Mazzeo，Steve McConnell，Jeff McKenna，Brian Melton，Ade Miller，Raul Miller，Jim Morris，Jim Newkirk，Jacob Ozolins，Michael Paterson，Bart Pietrzak，Dave Prior，Peter Provost，Michael Puleio，Scott Robinson，René Rosendahl，Ken Schwaber，Tammy Shepherd，Lisa Shoop，Michele Sliger，Ted St. Clair，Jeff Sutherland，Gaylyn Thompson，Isaac Varon，Bas Vodde以及Brad Wilson。

我還要感謝 Addison-Wesley 的團隊，包括Elizabeth Ryan，Chris Zahn 與 Chris Guzikowski。感謝你們的團隊所做的一切。此外，Carol Lallier和Kim Arney——編輯和出版項目協調員——感謝你們。你們敏銳地抓住了被我忽略的那么多東西，并使這一切變得很容易。

寫書并不只是一個將頭腦中的想法躍然于紙上的過程。就像我經歷的很多項目一樣，這真的是集體努力的成果。我所提到的這些人(以及我很可能遺漏的一些人)傾聽我的想法，在我迷失的時候提醒我，給我提供好的想法以便對團隊與客戶進行實踐并在我需要有人審核的時候自告奮勇。我可以想象，他們和我一樣高興見到這本書終于付梓。我希望在您讀到此處的時候，也會像我一樣感謝他們為這本書面世所做出的貢獻。

Mitch Lacey是Mitch Lacey&Associates公司的創始人，他采用包括Scrum和XP在內的敏捷實踐并以此建立高績效組織，幫助公司充分發揮潛力。

Mitch 自稱“技術宅”，1991年從計算機游戲公司Accollade Software開始他的技術生涯。先后擔任軟件測試工程師、測試經理、開發人員以及期間各種不同角色之后，他開始了個人職業生涯中最重要的工作，即項目管理與項目集管理。

2005年把敏捷加入項目工具箱之前，Mitch是一個接受過正規培訓的項目集經理。他在微軟開始發展敏捷，他的團隊成功發布了MSN核心企業服務，他也在多個部門中推動敏捷的應用。

Mitch 的第一個敏捷團隊是由 David Anderson、Ward Cunningham 與 Jim Newkirk 指導的。他在各種各樣的項目中擔任各種不同的Scrum角色。如今，帶著他幾十年的經驗，Mitch繼續通過在許多不同的組織中與領導和項目團隊一起試驗和實踐來發展他的技能。

Mitch豐富、實際的經驗和他的實用主義方法受到了許多公司的信任，包括Adobe Systems，Aera Energy，Bio-Rad，EchoStar，Microsoft，Oracle，Qualcomm，Salem Hospital，SAP和Sony等。他是認證Scrum培訓師(CST)、PMI項目管理專業人員(PMP)和敏捷認證實踐者(ACP)。

Mitch 在全球各種大會上發表演講，他還是2012年和2014年敏捷大會的主席，Scrum聯盟與敏捷聯盟的董事會成員。

更多的信息，可以訪問 www.mitchlacey.com。在那里可以找到Mitch的博客以及各種文章、工具與視頻，這些東西都有助于你采用Scrum與敏捷。還可以用@mglacey(Twitter)或者電子郵件mitch@mitchlacey.com聯系他。

目錄

第1章? Scrum知易行難????? 1

故事???????? 1

Scrum?????? 6

什么是Scrum？????? 7

實施Scrum????? 8

Scrum的基本價值觀????? 8

Scrum 需要轉變思維方式??? 9

Scrum采用的是最短路徑，而不是預設路徑????? 10

Scrum發現問題????? 12

Scrum的最佳搭檔 12

什么時候適合用Scrum？????? 13

變化是困難的???????? 15

現狀后期???????? 16

從外部元素和混亂到思想轉變???? 16

實踐與集成???? 16

新的現狀???????? 17

成功要領???????? 17

引用???????? 18

第Ⅰ部分? 戰前準備

第2章? 取得支持與組建團隊???? 23

故事???????? 23

模型???????? 29

轉變需要時間???????? 30

建立緊迫感???? 30

成立一個強大的指導聯盟???? 31

建立愿景/繪制未來的藍圖?? 31

溝通愿景???????? 31

授權人們為愿景采取行動???? 32

計劃并創造短期成功???? 33

進一步改善，鞏固成效，繼續深化改革???? 33

制度化新的方式方法???? 33

成功要領???????? 33

引用???????? 34

參考???????? 34

第3章? 用團隊顧問來優化團隊表現???????? 35

故事???????? 35

模型???????? 40

建立一個團隊顧問池???? 40

建立團隊???????? 42

核心團隊???????? 43

團隊顧問???????? 44

團隊大小???????? 44

核心團隊與團隊顧問一起工作???? 46

團隊顧問與會議???? 46

成功要領???????? 47

責任???????? 47

試驗???????? 48

小心過度???????? 48

計劃可能的空閑時間???? 48

團隊顧問不能代替專職團隊???????? 49

引用???????? 49

參考???????? 49

第4章? 預估團隊的速率???? 50

故事???????? 50

模型???????? 55

使用歷史數據的問題???? 55

為拍腦袋增加一些依據???????? 56

估算Product Backlog????? 57

分解參考故事???????? 57

點數與小時數的大致關系???? 58

團隊的生產能力???? 58

估算團隊的速率???? 59

增強對這種技術的信心???????? 60

走著瞧(使用靠譜的數據)?????? 60

收集并以圖表形式表示真實的數據???? 61

計算平均速率，但要對范圍進行交流???????? 61

截斷數據???????? 62

成功要領???????? 64

引用???????? 65

第5章? Scrum的三大角色 66

故事???????? 66

模型???????? 70

選擇角色???????? 71

組合角色???????? 72

如果實在萬不得已，又該何時組合這三大角色???????? 74

成功要領???????? 74

第6章? 確定Sprint的長度 76

故事???????? 76

模型???????? 79

項目期限???????? 80

產品負責人與項目干系人???? 81

Scrum 團隊??? 82

確定 Sprint 的長度?????? 82

警告???????? 85

問卷之外???????? 85

成功要領???????? 86

長于1個月的Sprint?????? 87

延長Sprint長度????? 87

引用???????? 87

第7章? 如何定義“完成”???????? 88

故事???????? 88

模型???????? 90

介紹???????? 91

頭腦風暴???????? 91

分類???????? 92

排序與整合???? 93

生成與發布DoD???? 95

沒有完成的工作呢？???? 95

成功要領???????? 96

引用???????? 96

第8章? 全職的ScrumMaster????? 97

故事???????? 97

模型???????? 100

成功要領???????? 106

消除障礙/解決問題??????? 106

結束爭論/當團隊的保姆??????? 107

報告團隊的行為表現???? 107

引導并在必要時提供幫助???? 107

教育組織并驅動組織變革???? 108

結語???????? 109

引用???????? 109

參考???????? 110

第II部分? 戰地基礎

第9章? Scrum中工程實踐的重要性 113

故事???????? 113

實踐???????? 117

重構???????? 119

持續集成以及更頻繁的提交???????? 120

結對編程???????? 121

自動化集成與驗收測試???????? 123

成功要領???????? 124

不是銀彈???????? 125

開始行動???????? 125

獲得團隊的支持???? 125

DoD 125

把工程實踐加入Product Backlog 126

獲得培訓與指導???? 126

結語???????? 126

引用???????? 127

參考???????? 127

第10章? 團隊核心時間?????? 128

故事???????? 128

模型???????? 131

在一起工作的團隊???????? 131

分布式團隊與兼職的團隊???? 133

成功要領???????? 134

第11章? 發布計劃?????? 136

故事???????? 136

模型???????? 140

項目成本???????? 144

成功要領???????? 146

事先進行溝通和交流，并且要頻繁???? 147

每個Sprint后都更新發布計劃????? 147

努力先做優先級最高的條目???????? 147

交付可工作的軟件???????? 148

引用???????? 148

第12章? 分解故事與任務? 149

故事???????? 149

模型???????? 152

做好準備???????? 152

故事分解???????? 153

任務分解???????? 156

成功要領???????? 159

引用???????? 160

參考???????? 160

第13章? 缺陷管理?????? 161

故事???????? 161

模型???????? 163

成功要領???????? 164

附加信息???????? 165

引用???????? 165

參考???????? 166

第14章? 可持續工程與Scrum??? 167

故事???????? 167

模型???????? 170

專用時間模型???????? 170

隨時收集數據???????? 171

專職團隊模型???????? 171

成功要領???????? 173

專職維護團隊成員的輪換???? 173

用良好的工程實踐來改進遺留代碼???? 174

結語???????? 174

引用???????? 174

第15章? Sprint評審會???????? 175

故事???????? 175

模型???????? 179

進行會議???????? 180

成功要領???????? 181

花時間準備???? 181

記錄決策???????? 182

要求認可???????? 182

勇敢???????? 182

參考???????? 183

第16章? Sprint回顧會???????? 184

故事???????? 184

實踐???????? 187

讓回顧會議發揮應有的作用???????? 187

計劃一個有效的回顧會議???? 188

召開回顧會議???????? 189

成功要領???????? 191

告訴他們為什么要保留回顧會議???????? 192

營造一個良好的環境???? 192

有需要就開???? 192

高度重視回顧會議???????? 193

引用???????? 193

第III部分? 戰地急救

第17章? 富有成效的每日站會? 197

故事???????? 197

模型???????? 200

準時開始和結束???? 201

開會遲到???????? 201

議程、節奏和站位???????? 202

打斷???????? 202

漫談和深入討論???? 202

暴露隱藏的障礙???? 204

忽略問題???????? 204

過于模糊???????? 204

結束就意味著開始???????? 204

成功要領???????? 205

保持會議的頻率???? 205

站著，不要坐???????? 206

像團隊一樣工作???? 206

耐心???????? 207

第18章? 每日站會的第四個問題?????? 208

故事???????? 208

模型???????? 211

成功要領???????? 212

引用???????? 212

第19章? 真正參與結對編程?????? 213

故事???????? 213

模型???????? 215

混排結對編程???????? 216

實踐混排結對編程???????? 216

混排結對編程的挑戰???? 217

微結對???? 218

成功要領???????? 220

引用???????? 221

第20章?? 222

新加入團隊成員???? 222

故事???????? 222

模型???????? 224

練習???????? 226

成功要領???????? 227

承認速率會下降???? 227

明智地選擇新成員???????? 227

風險???????? 228

引用???????? 228

第21章? 處理文化沖突?????? 229

故事???????? 229

模型???????? 234

成功要領???????? 239

掌握自己的命運???? 239

面對現實???????? 240

堅持到底???????? 241

引用???????? 242

參考???????? 242

第22章? Sprint緊急情況處理流程??? 243

故事???????? 243

模型???????? 246

消除障礙???????? 246

獲得幫助???????? 247

縮小范圍???????? 247

取消Sprint?????? 248

成功要領???????? 249

引用???????? 249

第IV部分? 高級生存

第23章? 可持續的步伐?????? 253

故事???????? 253

模型???????? 257

縮短迭代周期???????? 260

監測燃盡圖???? 260

增加團隊時間???????? 261

成功要領???????? 262

引用???????? 263

第24章? 交付可工作的軟件?????? 264

故事???????? 264

模型???????? 268

核心模型???????? 268

用戶數???? 269

從風險最高的組件開始???????? 270

擴展和驗證???? 270

成功要領???????? 271

思維的改變???? 272

返工???????? 272

專注于端對端的場景???? 273

參考???????? 274

第25章? 價值的度量與優化?????? 275

故事???????? 275

模型???????? 278

功能工作???????? 278

額外的工作???? 278

試驗性工作???? 279

技術債務???????? 280

其他潛在的類型???? 280

組織數據???????? 281

使用數據???????? 281

成功要領???????? 283

教育項目干系人???? 283

和項目干系人一起工作???????? 284

確定模式與趨勢???? 284

引用???????? 284

參考???????? 284

第26章? 項目成本預算?????? 285

故事???????? 285

模型???????? 290

功能規格書???? 290

用戶模型???????? 291

估算用戶模型???????? 291

確定用戶故事的優先級???????? 292

確定團隊的速率???? 293

計算成本???????? 293

制定發布計劃???????? 294

成功要領???????? 294

引用???????? 295

第27章? Scrum項目中的文檔??? 296

故事???????? 296

模型???????? 299

為什么我們要做文檔???? 300

我們會做什么文檔???????? 300

什么時候以及怎樣做文檔???? 301

在項目開始的時候做大量文檔???? 301

在項目最后做大量文檔???????? 302

隨著項目的進展寫文檔???????? 303

敏捷項目的文檔???? 304

文檔準備不充分就開始項目???????? 305

成功要領???????? 305

引用???????? 306

第28章? 外包與離岸開發? 307

故事???????? 307

模型???????? 310

考慮實際成本???????? 310

交接成本???????? 310

增加的開銷???? 311

長期的人員流失???? 311

文化的挑戰與管理工作???????? 311

開發實踐???????? 312

面對現實???????? 312

預算與成本???? 313

時間、距離與文化???????? 314

成功要領???????? 314

選擇合適的離岸團隊???? 314

以痛苦最小的方式分配工作???????? 315

堅守Scrum框架???? 315

建立團隊文化???????? 316

準備差旅???????? 317

配備一個項目/團隊協調人?? 318

絕不考慮離岸的情況???? 318

引用???????? 318

參考???????? 319

第29章? 大型產品列表的優先級確定與估算? 320

故事???????? 320

模型???????? 323

團隊???????? 324

項目干系人???? 325

成功要領???????? 328

預先計劃至關重要???????? 328

專注于討論并設定時間限制???????? 328

將未解決的爭議放入“停車場”???????? 329

帶上額外的卡片/紙張以備現場產生用戶模型?? 329

引用???????? 330

第30章? 擬定合同?????? 331

故事???????? 331

模型???????? 335

傳統的合同與變更要求???????? 335

寫用戶模型???? 341

估算用戶模型???????? 341

成功要領???????? 343

引用???????? 345

第V部分? 荒野必備

第31章? 合作推動完成?????? 349

故事???????? 349

模型???????? 353

任務撲克???????? 353

結對編程???????? 354

限制進行中的工作條目???????? 355

兩周迭代???????? 358

用任務板創造可見性???? 359

成功要領???????? 361

每個聲音都有人聽???????? 361

對工作的共同理解???????? 361

每位團隊成員都對成果投入???????? 362

不要平均任務估算???????? 362

避免粒度更細的任務估算???? 362

Scrum建立在團隊工作的基礎之上????? 362

參考???????? 363

第32章? 故事點與時間的關系? 364

故事???????? 364

模型???????? 367

恐懼因素???????? 368

寬范圍???? 368

成功要領???????? 371

收集正確的數據???? 371

用數據來改善???????? 372

故事點的REFLECT原則 373

參考???????? 374

第33章? 沉浸式面試與招聘?????? 375

故事???????? 375

模型???????? 378

預測???????? 378

雇傭要有正確原因???????? 378

不良招聘的成本???? 379

技能，能力，還是兩者兼顧???????? 380

如何招聘???????? 380

候選人篩選???? 381

準備與計劃???? 382

候選人打分???? 383

招聘管理和非技術人員???????? 384

成功要領???????? 384

建立一個可重復的招聘流程???????? 385

專注于能力而不是問題???????? 385

技能容易學，能力不易學???? 385

找到比你強的人???? 386

理解成本并加大投資???? 386

引用???????? 386

參考???????? 387

第34章? 激勵與成果掛鉤? 388

故事???????? 388

模型???????? 391

設置關注點???? 391

按客戶滿意度統一目標???????? 391

優先級的排定和調整???? 392

其他好處???????? 394

成功要領???????? 394

銷售與開發一體化???????? 394

停止犧牲人員和質量：對項目組合進行排序???? 394

管理層的支持???????? 395

參考???????? 395

第35章? Scrum項目中的風險管理??? 396

故事???????? 396

模型???????? 397

客戶風險：PO???????? 399

社會化風險：ScrumMaster?? 399

技術風險：開發(核心)團隊? 400

成功要領???????? 400

放手???????? 400

敏捷起來???????? 401

參考???????? 401

附錄? Scrum框架

角色???????? 404

ScrumMaster?? 404

產品負責人???? 404

開發團隊???????? 404

工件???????? 405

Sprint Backlog 406

燃盡圖???? 407

會議???????? 407

計劃會???? 407

每日Scrum????? 408

Sprint評審會? 409

Sprint回顧會? 409

結語???????? 410

軟件開發 敏捷開發

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。