 |
-- 會員 / 註冊 --
|
 |
|
|
|
Scrum實戰：故事、模型與成功秘訣 ( 簡體 字) |
| 作者：Mitch Lacey著 | 類別：1. -> 程式設計 -> 綜合 |
| 譯者：傅勃譯 |
| 出版社：清華大學出版社 |  3dWoo書號： 39382
詢問書籍請說出此書號！【缺書】
NT售價： 395 元 |
| 出版日：8/18/2014 |
| 頁數：467 |
| 光碟數：0 |
|
站長推薦：   |
| 印刷：黑白印刷 | 語系： ( 簡體 版 ) |
| |
加入購物車  │加到我的最愛
(請先登入會員) |
| ISBN：9787302367277 |
| 作者序 | 譯者序 | 前言 | 內容簡介 | 目錄 | 序 |
| (簡體書上所述之下載連結耗時費功, 恕不適用在台灣, 若讀者需要請自行嘗試, 恕不保證) |
| 作者序： |
| 譯者序： |
前言：推薦序1
Jim Highsmith，Thoughtworks執行顧問
“Scrum真的是優雅得近乎完美。它是最容易理解的框架之一，同時也是最難以實施好的框架之一”這本啟人深思的、寶貴的Scrum指南開篇就是這樣描述的。我見過太多團隊陷入假設Scrum很簡單的迷局，他們看似永遠無法超越Scrum 101以更深沉的角度來理解Scrum。他們生搬硬套地進行敏捷實踐，不覺得有任何諷刺意味。他們不理解變革，特別是在大型組織中，變革更難。不管如何投身于變革，道路都是曲折的，幾條簡單的規則遠遠不夠。這本指南可以幫助你超越Scrum 101，穩定、現實地實施Scrum。這本書（除了附錄以外）不講基本的Scrum框架，它講的是難點和實際的操作，幫助你和團隊用好Scrum框架。
在敏捷轉型的過程中，應用Scrum（或者其他框架）時，有兩個熱點問題往往被忽略：發布計劃與技術實踐。Mitch一開始就明確指出，技術實踐對有效實施Scrum至關重要。如同他指出的那樣，如果沒有堅實的技術實踐，幾乎不可能實現每個Sprint都提交可交付軟件的目標。他的基本列表：測試驅動開發、重構、持續集成與頻繁的代碼提交、結對編程以及自動化集成與驗收測試，很好地定義了技術實踐。
看見第11章的故事中的對話（每章都有一個引導故事來描述將要討論的問題）：“但是Stephen，我們用Scrum，我不能準確告訴你我們什么時候可以完成”，我實在忍俊不禁。Stephen，當然就是在管理鏈中需要知道項目完成信息的經理。要想成為一個高效的敏捷領導者，需要的其中一個關鍵心態就是我所說的“和”的管理，即在兩個看似沖突的力量中找到共同點的能力。在Scrum項目中的其中一個悖論就是在“預測性”與“適應性”之間。傳統方法者傾向于站在預測性這一方，而一些敏捷方法者則傾向于站在適應性這一方。當然，秘密就在于這兩者之間的平衡，即搞清楚如何在恰當的級別上同時做到這兩者。在他這本書的第11章中，對于如何以 “和”的管理方式來解決這個悖論，Mitch給了我們一些很好的指導。
在最近一次談話中，有一個同事提到，他認為在Scrum實施初期中的兩個關鍵是學習與快速致勝。在第2章中，當Mitch深入探討對變革的管理以及在向Scrum轉型的過程中開發學習與適應能力的時候，他同時提到這兩點（表明它們是多么的重要）。在Mitch描述的深受歡迎的John Kotter的變革管理系統中，快速致勝是其中的一個要點。
本書的另外一個亮點就是這些短小的章節，都分別專注于一個主題，通過倡導一個關鍵的實踐，把基本的Scrum框架變成一個可操作的框架。這些主題的范圍廣泛，從討論Scrum的價值，到定義Scrum的角色、計算速率、確定Sprint的長度、分解用戶故事、主持客戶的審核會議。書中另外還有一章令人陶醉，第7章定義了“完成”的真正含義，這是Scrum項目取得成功的根本。
對于任何一個正在實施Scrum或者是其他任何敏捷方法的人，Mitch的這本書絕對可以幫助你實現從優雅的簡單性轉為有效的實際成果。它可能不會把困難的事情變得更容易，但至少你會看得更清楚。
推薦序2
Jeff Sutherland，Scrum公司
Mitch和我一起工作了很多年，為開發人員培訓Scrum。因為敏捷實踐（75%為Scrum）已經成為全球最主流的軟件開發模式，學習這本書可以幫助用戶克服在過去十年中出現的最大的挑戰。
在敏捷宣言發布的十年之后，原來的一些簽署人以及更多敏捷思想領袖在猶他州的雪鳥度假村聚會，這次是為敏捷軟件開發所十年做回顧會議。他們慶祝了應用敏捷方法進行產品開發取得的成功，檢討必須克服的障礙。他們一致同意未來十年的四個成功關鍵如下。
1. 追求技術卓越。
2. 推動個人變革，進而引領組織的變革。
3. 建立知識體系，加強教育。
4. 在整個流程中最大化價值創造。
讓我們看看Mitch的這本書可以怎么幫助你成為一個敏捷的領導者。
追求技術卓越
引爆互聯網和智能手機應用的一個關鍵因素就是用小的增量來部署應用，從最終用戶那里得到快速反饋。這在敏捷中得到了規范，即在短期Sprint中開發產品，常常是一個月或者是更短時間但更常見的兩個星期中。在敏捷宣言中，我們這樣表達這個問題：“相比復雜的文檔，我們給予可工作軟件更多的價值。”
敏捷宣言十年回顧得出結論，就是大多數敏捷團隊的短期Sprint開發仍然困難重重（通常因為管理層、業務部門、客戶以及開發團隊并不想追求技術卓越）。
工程實踐是軟件開發的基石，17%的Scrum團隊在實施Scrum的同時實施XP工程實踐。第一個這樣做的團隊出現在1993年，那時XP都還沒有出現。這對于職業工程師來說，只是一些常識而已。
Mitch在第1章中說道，一些特定的XP實踐是必不可少的，比如：可持續的步伐、代碼集體所有、結對編程、測試驅動開發、持續集成、代碼規范以及重構。這些都是技術卓越的基石。使用Scrum但不用這些工程實踐的61%的敏捷團隊應該仔細讀讀Mitch的這本書，并遵循他的指導。缺乏工程實踐正是他們在Sprint結束時不能產生可交付代碼的原因。
Mitch的書中還有更多對技術卓越的指導，敏捷領導者，不管是從事管理工作還是技術工作，都應該追求Mitch如此清楚表達出來的技術卓越。
推動個人變革，進而引領組織的變革
除了技術卓越以外，采用敏捷還需要能夠對變化的需求做出快速響應。這就是敏捷宣言的第四個原則：“響應變化優于遵循計劃。”但是，個人適應變化遠遠不夠。組織也必須有能夠敏捷的響應變化的組織結構。如果不是這樣，它們將因為無法消除阻擋前進的障礙而摧毀高效團隊或限制高效團隊的產生。
Mitch一步一步地解釋了哈佛商學院提出的成功應對變革的關鍵因素。這里還需要有一種緊迫感。沒有它，變革就不可能。敏捷領導者需要適應這個現實。指導委員會對于制度變革至關重要。敏捷領導者需要確保管理層受教育、培訓、支持并參與Scrum實施。
建立一個愿景并授權是成功的基石。獨裁的決策以及控制與命令式管理必定會扼殺敏捷的效力。敏捷領導者需要通過計劃短期的勝利、鞏固提高、消除障礙、新方法制度化來避免這些災難。敏捷領導者需要成為管理層的一部分或給管理層培訓工程實踐，Mitch這本書可以幫助你發現你需要做什么以及怎么做。
建立知識體系，加強教育
大多數經理和很多開發人員都不是特別了解團隊和生產力。Mitch在整本書中都在討論這些問題。
軟件開發固有的不可預測性
很少有人知道Ziv法則，即軟件開發是不可預測的。全球范圍內大量項目的失敗率在很大程度上就是因為缺乏對這個問題的理解以及正確處理這個問題的方法。Mitch描述了對持續的變化進行檢查與調整的需要。這本書中的策略可以幫助你避免很多陷阱，消除Scrum實施過程中的很多障礙。
用戶在看見可工作的軟件之前并不知道自己真正需要什么
傳統項目管理錯誤地假設在構建軟件之前用戶知道自己需要什么。這個問題被正式稱為“漢弗萊法則”，該法則在大學教育以及經理與項目領導者的行業培訓中被忽視。這本書可以幫助你從容面對這個問題。
組織結構會被嵌入代碼中
人們普遍不理解的第三個主要問題是柯維法則。組織的結構會體現到代碼中。一個傳統的層級組織結構會對面向對象的設計有負面的影響，會導致脆弱的代碼、壞的糟糕的架構設計、很差的可維護性與適應性以及過度的成本與過高的失敗率。Mitch花了大量的時間來解釋如何正確建立Scrum組織。要仔細研讀！
在整個流程中最大化價值創造
如果準備好產品列表，就可以使用敏捷實踐輕易提高一倍或兩倍生產力，并且在每個Sprint結束時交付可工作的軟件。生產力提升為組織的其他部分帶來問題，使其缺乏敏捷變得更明顯，讓他們更痛苦。
運營與基礎設施缺乏敏捷
一旦人力與資源用于改善產品列表，流向生產系統的軟件的速度至少會加倍，有些情況下可以是5∼10倍之多。這就暴露了這樣一個事實：開發運營與基礎設施拖慢了生產系統，必須要修正。
管理、銷售、市場以及產品管理缺乏敏捷
在流程的前端，商業目標、戰略以及目的常常都不清楚。這導致即使軟件的產量翻倍了，收入流出卻下降或沒有增長。
因此，組織中的每個人都需要接受如何在整個價值流中優化性能的教育與培訓。敏捷個人需要通過提高其組織知識的能力并培訓整個組織來引導這個教育的流程。
底線
很多Scrum實施取得的提高很有限，并且發現很難消除使他們陷入持續掙扎的障礙。應該可以做得更好。所有的團隊都可以做得很好，很多團隊可以做得很優秀！工作可以很有趣，業務可以是盈利的，客戶可以真的高興！
如果你準備搞Scrum，Mitch的這本書可以幫助你。如果你正在實施過程中掙扎，這本書對你的幫助更大。如果你已經做得很好，Mitch可以幫助你做得更好。改進是永無止境的，Mitch的洞察力真正很有幫助。
.
譯者序
傅勃(Brain)
敏捷開發，特別是Scrum，已經成為很多組織進行軟件開發的默認方法。但是有多少團隊因此成為了高效率團隊呢？如果你是這樣的團隊，那么真的要恭喜你，這確實是一個很難達到的狀態。
如果還不是一個高效率團隊，你一定會有不少的困惑。很多Scrum團隊和你的團隊一樣，在經歷初期的提高之后，很快就陷入效率提升的瓶頸。是敏捷方法言過其實，還是我們學藝不精？
Ken Schwaber和Jeff Sutherland在《Scrum指南》（Scrum Guide）中僅僅用13頁的篇幅（2013年版）就定義了Scrum框架，這可能也是軟件開發中最精煉、最簡單的方法之一。也許正因為這樣的簡單性，才造就了我們在實踐中的五彩繽紛。其中，一些人和團隊在淺嘗輒止之后，就認為Scrum不過爾爾；也有一些人和團隊在未能顯著提高效率之后，對Scrum產生了質疑；還有一些組織，其文化與敏捷格格不入，Scrum團隊要么被迫成為（短命的）獨立王國，要么仍然屈從于命令式管理的淫威。這些情況其實都不意外，正如Mitch在第1章中指出的那樣，Scrum是最容易理解的框架之一，同時也是最難以實施好的框架之一。
我認為Scrum與敏捷雖有其固然的局限性，但仍不失為我們“武器庫中的殺手?”（Mitch在本書中稱為“工具帶中的工具”）。相比動輒就歸咎于方法本身，我們作為敏捷實踐者應該具有開放、謙虛和學習的態度。那么，在形形色色的各種具體實現以及浩瀚無邊的知識海洋中，我們如何才能做到大浪淘沙、去偽存真，以他山之石攻玉呢？
依我愚見，有兩個判斷標準。Scrum與敏捷的實踐雖然具有多樣性，但是萬法歸宗，其核心與精髓就是它們的原則與價值觀，這被很好地總結在眾人皆知的敏捷宣言中。竊以為敏捷宣言應該是敏捷實踐者信奉的圣經。同時敏捷也是一個開放的社區，《Scrum指南》開宗明義地指出Scrum是基于經驗流程的控制理論。所以，第二個鑒別的標準就是各種具體的理論與方法是否來源于實踐，是否能夠應用于你的實踐。
Mitch首先在第1章中詮釋了Scrum依據的價值觀以及實施Scrum所需要的條件。如果你的組織與團隊不符合這些價值觀，不具備這些條件，也許需要降低期望值或者考慮放棄Scrum。在現實中很多在困境掙扎的團隊，他們的命運也許在此已經注定。
在隨后的章節中，Mitch介紹的每一個方法都提煉自他個人親身的經歷，并成功應用于他的實踐中。難能可貴的是，其中的一些方法還來源于軟件開發領域的一些理論與實證研究，或者是從中得到佐證。他這些方法要解決的場景與困難，在我讀起來總是感到似曾相識。我相信你在閱讀此書的時候也會感同身受。
雖只是翻譯，也得一字一字地碼出來，個中辛苦不以言表。這個過程感覺是回到當年寫程序的時候，忍不住改來改去，但很難完全令人滿意。因時間倉促，個人中英文以及敏捷實踐的水平有限，錯誤難免，歡迎勘正。
最后，希望這本書物有所值，成為你的“及時雨”，對你的實踐有所啟迪與幫助。
前言
我的女兒Emma（愛瑪）出生于2004年末，我感到力不從心，我們在醫生辦公室的時間似乎多于與其他孩子在一起的時間。我一直問我妻子：“這是正常的嗎？”一個晚上，我在枕頭邊上發現我妻子那本書《新生兒父母手冊》，里面有她寫的一張小紙條：“讀讀這本書，你會好受一點。”
我讀了。由此我知道了我們所經歷的每件事情對于我的孩子都是正常的，即使對我或我以前觀察到的來說不常見。這使我感到更有信心與安全感。這也正好是我開始試驗Scrum與敏捷的時間。隨著我開始遇到障礙與面臨不熟悉的情況，我開始認識到，在做Scrum與敏捷的第一年，我真正需要一本指導手冊。
問題在于，不像一本指導手冊，我不可能準確告訴你，在第1∼3月或者9∼12月，你的團隊應該做什么或者是應該擔心什么。團隊并不像小孩那樣，不會以一個可以預測的速度發展。相反，在他們第一年的實踐中，隨著他們學習團隊合作、采用敏捷工程實踐、與他們的客戶建立信任、以增量迭代方式工作的過程中，他們常常摔倒、蹣跚、犯錯誤，前進兩步就倒退一步。
有鑒于此，我更傾向于以這種方式“我遇到了一個問題，該怎么辦”來組織這本書。我收集了我參與過或者見證過的、在他們第一年敏捷旅途中的那些團隊的故事。隨著我繼續我的敏捷旅途，我注意到各個公司中這些故事、模式通常都很相似。我在一個公司中實現一個想法，稍微調整一下就可以應用在下一個公司中。重復這個過程，我得以收集了這些現實世界的解決方案，并把它們加入我隨身攜帶的虛擬工具帶。在這本書中，我將與你分享一些最常見的痛苦與解決方法。當你的團隊遇到麻煩或者是受傷的時候，你可以找到最接近你的癥狀的那一章，然后你可以發現，即使不能解決你的問題，至少也有一個辦法可以減輕你的痛苦。
《Scrum實戰》旨在幫助你精心調試你自己的實踐，在一些你不熟悉的領域提供指南，以及在前進的道路上更輕松地克服我們都遇到過的困難。
誰應該讀這本書
如果你正在考慮開始Scrum或者敏捷的實踐，或者剛剛開始你的旅途，或者已經實踐了一年左右但卻感覺好像迷失了方向，這本書就是為你準備的。我正式的目標群體就是，從那些在六個月以內將開始他們的項目，到那些已經實踐了一年的公司，即有18個月的時限。
這本書是為推崇實踐的人準備的。如果你想學習理論或者是高深的討論，可以從很多優秀的Scrum和敏捷的書籍中找到一本。另外一方面，如果你想尋求基于我在微軟做過的項目以及我在福布斯100強的大型公司指導顧問過的團隊的實踐建議與真實數據，這本書會物有所值。
怎樣閱讀這本書
設計這本書是為了方便你在任何時間以任何順序閱讀任何章節。每一章都以一個故事開始，這些故事都是從我工作過的或者是指導過的團隊、公司、項目中提取出來的。可以想象，為了保護那些清白的（或者是犯錯的）人，我改變了他們的名字。在你看過這些似曾相識的故事后，我會介紹一個模型。這些模型是我在實戰中用來幫助解決故事中存在的問題的。一些模型你可能會感到不太舒服，或者是認為對你的公司可能不適用。我強烈要求你反抗你的忽視建議或者是修改模型的直覺，至少努力嘗試三次，然后看看結果如何，你可能會對結果感到驚訝。在每章的最后，我總結了成功秘訣，這些因素事關實踐成敗。
這本書組織為四部分。
第Ⅰ部分“戰前準備”，對你準備開始使用Scrum提供建議，幫助你為成功做好準備。如果你正在考慮Scrum，或者是剛剛開始使用Scrum，就從這里開始。
第Ⅱ部分“戰地基礎”，討論的話題可以幫助你克服開始敏捷的旅途之后團隊與組織會遭遇的初步障礙。如果已經開始了Scrum的實踐，但是遇到了困難，你可以從這里開始。
第Ⅲ部分“戰地急救”，著眼于解決公司所面臨的一些更大、更深層次的問題，比如往項目中增加人手或者是解決每日站會的功能失調。這些都是在第一年實踐中某個時候很可能會遇到的情況。這幾章可以幫助你診斷并處理這些情況，使團隊恢復到健康的狀態。
最后一部分即第Ⅳ部分“高級生存技術”，討論人們在實踐Scrum的任何階段都常常掙扎的一些話題。比如，項目成本、合同的制定、敏捷項目與Scrum項目中的文檔等。
如果你是從頭開始，對Scrum還一無所知，我在本書的附錄中包括了一個對Scrum的簡短介紹，旨在幫助你熟悉這些術語與概念。在開始研究這本書之前，你可能還需要多了解一下Scrum。
為什么需要閱讀這本書
不管你在敏捷旅途中身處何地，我們都需要一個友好的提醒，即我們的遭遇是正常的，它為我們提供了解決這些問題的建議和一些成功秘訣。這本書把這些東西都組織在一起，方便你根據具體需要選擇閱讀需要的章節或者整個部分或者全書。這是真實生活中的情況，可以與你產生共鳴，它的解決方法可以應用于任何團隊。打開書開始閱讀這些故事，這本書將是你經歷Scrum與極限編程之高潮與低谷的忠實伴侶。
本書的補充材料
在你閱讀本書的過程中，你可能會想：“我真希望有個工具或者是可以下載一個模板來幫助我實踐這個概念。”很在多情況下，這是可以的。訪問http://www.mitchlacey.com/supplements/，你可以看到我在我每天的Scrum項目中用到的一系列文件、圖片、Excel表格以及工具。盡管其中一些信息是精心準備過的，但大多數東西還很簡陋。為什么？在我的項目中，我不需要它們很完美，我只需要它能實現功能。你在我的網站上得到的將是第一手的、真實的、偏重實戰且有用的東西。
致謝
在我第一次想寫這本書的時候，我的想法還很原始，我還不知道這是一項艱巨的工程。我的妻子Bernice（柏妮絲），讓我有時間專注于這本書，我的孩子也是這樣。沒有她們的支持，就不會今天有這本書。
David Anderson、Ward Cunningham與Jim Newkirk幫助我和我在微軟的第一個團隊開始了我們的敏捷之旅。他們每個人當時都在那里工作，指導我們經歷了一些艱難的時期。現在回頭看看早期與Ward討論的一些筆記，其中一個是重點顯示的問題：“我們能不能不做TDD？”他們每個人都在幫助我們團隊從不適應變成一個真正特別的團隊。David、Ward和Jim，謝謝你們。
我要感謝Mike Cohn與Esther Derby，他們讓我得以在2006年敏捷大會上就我的初步想法向他們征求意見。Mike后來繼續支持我，我們經常開玩笑，我的書會比他的《Scrum敏捷軟件開發》更早問世。當這個目標沒有實現之后，他提議我，一個更好的目標是在他成為祖父之前完成這本書。嗯，Mike，我做到了，而且還是在你大女兒在上高中的時候，我實現了我的目標。
沒有Rebecca Traeger的幫助，我也無法完成此書，她是這個星球上最好的編輯。她使我保持正確的方向并專注于此，幫助我把我原始的想法與文字變成渾然一體的章節。
我還要感謝幫助我精心寫就今天這本書的所有朋友。列在這里的每個人都給予我有價值的反饋并抽出很多時間聽我總結自己的想法或者閱讀草稿。我對你們每個人的感謝溢于言表，他們包括Tiago Andrade e Silva，Adam Barr，my artists Tyler Barton and Tor Imsland，Martin Beechen，Arlo Belshee，Jelle Bens，John Boal，Jedidja Bourgeois，Stephen Brudz，Brian Button，Mike Cohn，Michael Corrigan，Scott Densmore，Esther Derby，Stein Dolan，Jesse Fewell，Marc Fisher，Paul Hammond，Bill Hanlon，Christian Hassa，Jim Highsmith，Donavan Hoepcke，Bart Hsu，Wilhelm Hummer，Ron Jeffries，Lynn Keele，Clinton Keith，James Kovaks，Rocky Mazzeo，Steve McConnell，Jeff McKenna，Ade Miller，Raul Miller，Jim Morris，Jim Newkirk，Jacob Ozolins，Michael Paterson，Bart Pietrzak，Dave Prior，Michael Puleio，Rene Rosendahl，Ken Schwaber，Tammy Shepherd，Lisa Shoop，Michele Sliger，Ted St. Clair，Jeff Sutherland，Bas Vodde，and Brad Wilson。
我還要感謝Addison-Wesley的團隊，包括Chris Zahn與Chris Guzikowski。Chris Zahn讓我質疑自己寫的所有東西，使我從另外一個角度來思考我的觀點。即使在我錯過了計劃日期的兩年之后，Chris Guzikowski仍然沒有放棄我。我感謝你的團隊指導我經歷整個過程。
寫作并不只是一個將頭腦中的想法躍然紙上的過程。就像我經歷的很多項目一樣，這真的是集體努力的成果。我所提到的這些人（以及我很可能遺漏掉的一些人）傾聽我的想法，在我迷失的時候提醒我，給我提供好的想法以便對團隊與客戶進行實踐并在我需要有人審核的時候自告奮勇。我可以想象，他們和我一樣高興這本書終于付梓印刷。我希望在你讀到此處的時候，也會像我一樣我感謝他們為這本指南面世所做的貢獻。
關于作者
Mitch Lacey是一名敏捷實踐者與顧問，也是軟件咨詢與培訓公司Mitch Lacey & Associates公司的創辦人。Mitch擅長于幫助各種公司通過采用Scrum與極限編程等敏捷原則與實踐來提高效率。
Mitch自稱“技術宅男”，在1991年從計算機游戲公司Accollade Software開始他的技術生涯。在擔任軟件測試工程師、測試經理、開發人員以及期間各種不同角色之后，他開始了自己職業生涯中最重要的工作，即項目管理與項目群管理。
在把敏捷加入他的項目工具帶之前，Mitch是一個接受過正規培訓的項目群經理。他在微軟開始發展敏捷的技能，他的團隊為Windows Live成功發布了核心企業服務。Mitch的第一個敏捷項目是由David Anderson、Ward Cunningham與Jim Newkirk指導的。Mitch在各種不同的項目中擔任產品負責人或者是ScrumMaster，積累了很多第一手的敏捷經驗。他繼續發展其敏捷技能，直至他可以幫助其他團隊采用敏捷實踐。時至今日，他已經有超過16年的經驗，Mitch通過在很多不同組織的項目團隊中試驗與實踐來繼續研磨他的技藝。
作為一名認證Scrum培訓師（CST）與PMI項目管理專業人士（PMP），Mitch通過ScrumMaster認證培訓課程、敏捷導入服務合同、大會演講、博客以及白皮書來分享他在項目管理與客戶管理方面的經驗。Mitch與全球各地的公司合作，從澳大利亞到哥倫比亞，從加利福尼亞到佛羅里達，從葡萄牙到土耳其，以及歐州各國。
Mitch在全球各種大會上發表演講，他還是2012敏捷大會的主席，敏捷聯盟與Scrum聯盟的董事會成員。
更多的信息，可以訪問www.mitchlacey.com。在那里可以找到Mitch的博客以及各種文章、工具與視頻，這些東西都有助于你采用Scrum與敏捷。還可以用@mglacey(Twitter)或者電子郵件mitch@mitchlacey.com聯系他。
|
內容簡介：內容簡介
短短幾年時間，Scrum躍升為敏捷首選方法，在全球各地得以普遍應用。針對如何用好、用巧這個看似簡單的框架，本書結合故事、模型和成功秘訣三大要素，透徹講解確保Scrum取得成功的基本要素。全書4部分共30章。在簡單介紹Scrum知易行難之后，在第Ⅰ部分中闡述導入Scrum之前的準備工作。第Ⅱ部分重點介紹實戰基礎。第Ⅲ部分提出急救包的概念，討論如何使每日站會富有成效，如何提出Scrum的第四個問題，如何讓人們在結對編程時保持專注，增加團隊新成員時應該怎么辦，發生文化沖突時應該怎么辦，Sprint應急過程等。第Ⅳ部分則鎖定八大主題，重點介紹高級生存指南。最后在附錄中概述Scrum框架，以幫助讀者快速入門。
本書適合打算實現敏捷轉型并導入Scrum的所有人員閱讀，比如開發人員、架構師、測試人員、經理和項目負責人，是幫助他們順利度過Scrum第一年的理想參考書。
Authorized translation from the English language edition, entitled The Scrum Field Guide: Practical Advice for Your First Year, 1E, 9780321554154 by MITCH LACEY, published by Pearson Education, Inc, publishing as Addison-Wesley Professional, Copyright ? 2012 Mitchell G. Lacey.
All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from Pearson Education, Inc.
CHINESE SIMPLIFIED language edition published by PEARSON EDUCATION ASIA LTD., and
TSINGHUA UNIVERSITY PRESS LIMITED Copyright ? 2014.
本書中文簡體翻譯版由Pearson Education授權給清華大學出版社在中國境內(不包括中國香港、澳門特別行政區)出版發行。
|
目錄：第1章 Scrum：知易行難 1
故事 1
Scrum 9
什么是Scrum 9
實施Scrum 11
Scrum適合我嗎 18
變化是困難的 19
實踐與集成 22
新的現狀 22
成功秘訣 23
引用 24
第Ⅰ部分 戰 前 準 備
第2章 取得大家的支持 29
故事 29
模型 38
變革需要時間 39
建立緊迫感 40
成立一個強大的指導聯盟 40
建立一個愿景/繪制未來的藍圖 41
溝通愿景 41
授權人們為愿景采取行動 42
計劃并創造短期成功 43
進一步改善，鞏固成效，繼續深化改革 43
制度化新的方式方法 44
成功秘訣 44
耐心 44
提供信息 45
引用 45
第3章 用團隊顧問來優化團隊表現 47
故事 47
模式 54
建立一個團隊顧問池 55
建立團隊 57
團隊大小 60
成功秘訣 63
責任 63
試驗 64
小心過度 64
計劃可能的空閑時間 65
團隊顧問不應替代專職團隊 65
第4章 確定團隊的速率 67
故事 67
模型 74
使用歷史數據的問題 74
為拍腦袋增加一些依據 76
計算平均速率，但要對范圍進行交流 81
截斷數據 83
成功秘訣 85
引用 86
第5章 Scrum的三大角色 87
故事 87
模型 92
選擇角色 94
組合角色 95
如果實在萬不得已，又該何時組合這三大角色 98
成功秘訣 98
第6章 確定Sprint的長度 101
故事 101
模型 105
項目期限 106
客戶/項目干系人組 107
Scrum團隊 108
確定Sprint的長度 109
警告 112
問卷之外 113
成功秘訣 113
長于4周的Sprint 114
延長Sprint長度 115
引用 115
第7章 我們如何知道何時才算完成 117
故事 117
模型 119
介紹 120
頭腦風暴環節 121
分類環節 122
排序與整合環節 124
生成DoD 126
沒有完成的工作呢？ 126
成功秘訣 127
引用 127
第8章 全職的ScrumMaster 129
故事 129
模型 133
成功秘訣 141
消除障礙/解決問題 141
結束爭論/當團隊的保姆 142
報告團隊的行為表現 142
引導并在必要時提供幫助 142
教育組織并驅動組織的變革 144
結語 144
引用 145
參考 145
第Ⅱ部分 戰 地 基 礎
第9章 Scrum中工程實踐的重要性 149
故事 149
實踐 155
實施測試驅動開發 156
重構 158
持續集成，隨時了解系統的狀態 159
結對編程 161
自動化集成與驗收測試 163
成功秘訣 165
不是銀彈 165
開始行動 165
獲得團隊的支持 166
DoD 166
把工程實踐加入產品列表 166
獲得培訓與指導 166
結語 166
引用 167
參考 168
第10章 核心團隊時間 169
故事 169
模型 173
在一起工作的團隊 174
分布式團隊與兼職的團隊 175
成功秘訣 178
第11章 制定發布計劃 181
故事 181
模型 186
畫出初步的路線圖 187
加上一個信心程度 189
得到日期并根據需要進行調整 190
在項目過程中維護發布計劃 193
確定項目的結束 194
成功秘訣 196
事先進行溝通和交流，并且要頻繁 196
每個Sprint后都更新發布計劃 196
努力先做優先級最高的條目 197
更新對大條目的估計 197
交付可工作的軟件 197
Scrum與發布計劃 197
引用 198
第12章 分解故事與任務 199
故事 199
模型 203
做好準備 203
故事分解 204
任務分解 208
成功秘訣 211
引用 213
參考 213
第13章 缺陷管理 215
故事 215
模型 217
成功秘訣 220
引用 221
參考 221
第14章 可持續工程與Scrum 223
故事 223
模型 227
專用時間模型 227
隨著時間收集的數據 228
專職團隊模型 229
成功秘訣 231
專職維護團隊成員的輪換 232
用良好的工程實踐來改進遺留代碼 232
結語 232
引用 233
第15章 Sprint審核會 235
故事 235
模型 240
準備會議 241
進行會議 242
成功秘訣 243
花時間準備 244
記錄決策 244
要求認可 245
勇敢 245
參考 246
第16章 Sprint回顧會 247
故事 247
實踐 251
回顧會議的檢查作用 251
計劃一個有效的回顧會議 252
召開回顧會議 254
成功秘訣 256
告訴他們為什么要保留回顧會議 257
營造一個良好的環境 257
有需要就開 258
高度重視回顧會議 258
引用 259
第Ⅲ部分 戰地急救
第17章 富有成效的每日站會 263
故事 263
模型 268
開會的時間 268
準時開始和結束 269
暴露隱藏的障礙 272
結束就意味著開始 273
成功秘訣 273
保持會議的周期 273
站著，不要坐 274
團隊工作方式 275
耐心 276
第18章 Scrum的第四個問題 277
故事 277
模型 281
成功秘訣 282
引用 283
第19章 真正參與結對編程 285
故事 285
模型 288
無序結對編程 289
微結對 291
成功秘訣 294
引用 295
第20章 新增團隊成員 297
故事 297
模型 300
練習 303
成功秘訣 304
承認速率會下降 304
明智地選擇新成員 304
風險 305
引用 305
第21章 當文化有沖突的時候 307
故事 307
模型 314
成功秘訣 320
掌握自己的命運 321
面對現實 321
堅持到底 323
引用 324
參考 324
第22章 Sprint急診現場 325
故事 325
模型 328
消除障礙 329
獲得幫助 330
縮小范圍 330
取消Sprint 331
成功秘訣 332
引用 333
第Ⅳ部分 高級生存術
第23章 可持續的步伐 337
故事 337
模型 343
縮短迭代周期 347
監測燃盡圖 348
增加團隊時間 349
成功秘訣 350
引用 351
第24章 交付可工作的軟件 353
故事 353
模型 359
核心故事 359
用戶數 360
從風險最高的組件開始 361
擴展和驗證 362
成功秘訣 363
思維的改變 363
返工 364
專注于端對端的場景 365
參考 366
第25章 價值的度量與優化 367
故事 367
模型 371
功能工作 371
額外工作 372
試驗 373
必要性工作 374
缺陷 374
組織數據 375
使用數據 375
成功秘訣 376
教育項目干系人 376
和項目干系人一起工作 377
確定模式與趨勢 377
參考 377
第26章 項目成本預算 379
故事 379
模型 386
功能規范 386
用戶故事 387
估算用戶故事 388
確定用戶故事的優先級 389
確定團隊的速率 390
計算成本 390
制定發布計劃 391
成功秘訣 391
引用 392
第27章 Scrum項目的文檔 393
故事 393
模型 397
我們為什么要寫文檔 398
做什么文檔 399
文檔什么時候寫？如何寫 400
敏捷項目的文檔 404
沒有大量文檔就開始項目 405
成功秘訣 406
引用 407
第28章 外包與離岸開發 409
故事 409
模型 413
考慮實際成本 413
面對現實 416
成功秘訣 418
選擇合適的離岸團隊 418
以痛苦最小的方式分配工作 419
堅守Scrum框架 420
建立團隊文化 421
準備差旅 422
配備一個項目/團隊協調人 423
絕不考慮離岸的情況 423
引用 424
參考 424
第29章 大型列表的優先級確定與估算 425
故事 425
模型 429
團隊 431
項目干系人 432
成功秘訣 435
預先計劃至關重要 435
專注于討論并設定時間限制 435
為未解決的爭議使用停車場 436
帶上額外的卡片/紙張以備現場產生用戶故事 437
提醒團隊事情會變 437
引用 438
第30章 擬定合同 439
故事 439
模型 444
傳統的合同與變更要求 445
時機 449
范圍與變化 451
成功秘訣 455
客戶的配合 456
驗收窗口 456
優先級 457
終止條款 457
信任 458
引用 458
附錄 Scrum框架 459 |
| 序： |
|
