Scrum敏捷軟件開發 epub pdf mobi txt 電子書 下載 2024

Scrum敏捷軟件開發 epub pdf mobi txt 電子書 下載 2024

Scrum敏捷軟件開發 epub pdf mobi txt 電子書 下載 2024

産品特色

編輯推薦

　　《Scrum敏捷軟件開發》：

　　全景呈現Scrum敏捷成功之點滴

　　萃取Mike Cohn敏捷思想之精華

　　通用、經過實證且百分百行之有效的Scrum與敏捷實踐指南

　　對於Scrum與敏捷快速轉型及其與傳統之間的持久戰，《Scrum敏捷軟件開發》提供瞭通用、實際和可操作的指導。聲譽卓著的領軍人物MikeCohn，優秀的敏捷顧問和踐行者，從自己多年來幫助數百傢軟件公司進行Scrum和敏捷改革的無人媲美的經曆中，提取齣細節紛呈的建議、令人醒醐灌頂的提示和實際案例研究。

　　《Scrum敏捷軟件開發》是為實施s仁rum過程中勇敢麵對重重挑戰並渴望徵服這些難題的實乾傢準備的。Cohn全麵概述瞭整個轉型過程：啓動轉型、幫助個人適應新的角色、組建團隊、擴展Sct，Um到多團隊項目、分布式團隊項目以及*後的實施效果度量和持續改善。

　　貫穿全書，Cohn基於自己*成功的建議，創設瞭“試一試”特色段落。與此相得益彰的“反對”特色段落則重現與變革抵製人員之間的典型對話，提供實際有效的指導來打消其疑慮。

　　本書主題：

　　立即著手轉型和迅速進入正軌的幾種實用方法

　　剋服個人對Scrum變革的抵觸

　　建立由變革積極推動者組成的“改進社區”

　　選擇要使用或試驗的敏捷技術實踐

　　領導自組織團隊

　　*有效的的Scrum迭代、計劃和質量技巧

　　將Scrum擴展到分布式以及多團隊項目

　　將Scrum用於復雜的順序過程項目或富有挑戰的、有服從和管控需求的項目

　　理解Scrum對人力資源、後勤和PMO的影響

內容簡介

　　《Scrum敏捷軟件開發》是敏捷聯盟及Scrum聯盟創始人之一、敏捷估算及計劃的鼻祖Mike Cohn三大經典著作中影響為深厚的扛鼎之作，也是全球敏捷社區中獲得廣泛肯定的企業敏捷轉型參考。作者花四年時間，把自己近十五年的敏捷實踐經驗，特彆是近四年中針對各種敏捷轉型企業的谘詢和指導工作，並結閤旁徵博引的方式，從更高的思想層次對敏捷與Scrum多年來的經驗和教訓進行深入而前麵的梳理和總結，終集大成者便是這本令人醍醐灌頂的佳作。

　　《Scrum敏捷軟件開發》是軟件企業及其管理團隊成功進行敏捷轉型戰略及實施的必備參考書，適閤經理、開發人員、教練、ScrumMaster、産品負責人、分析師、團隊領導或項目領導，是幫助他們成功完成項目，甚至造就敏捷企業的重要參考。

作者簡介

　　Mike Cohn，Mountain Goat Software創辦人，以幫助客戶公司成長為卓越軟件開發組織為己任，專門提供Scrum與敏捷軟件開發培訓。Mike Cohn是敏捷運動兩大公認名著（《用戶故事與敏捷方法》和《敏捷估算與規劃》）的作者。他曾經曆任多個軟件開發公司（從新創公司到《財富》40強）的技術總監，曾服務子BBC（英國國際廣播公司）、Capital One（美國第—投資集團），Electronic Arts（藝電）、Experian（益百利）、Gooqle（榖歌）、Intuit（直覺軟件公司）、Lexis Nexis（律商聯訊）、Lockheed Martin（洛剋希德·馬丁）、微軟、諾基亞、飛利浦、Sabre、Salesforce.com、西門子、索尼、時代華納、雅虎等客戶。他參與創力瞭敏捷聯盟、敏捷項目領導網絡和Scrum聯盟。

目錄

第Ⅰ部分 啓航
第1章 為什麼敏捷轉型難（但值得）
第2章 ADAPT模型
第3章 Scrum實施模式
第4章 漸進敏捷
第5章 試點項目

第Ⅱ部分 個體
第6章 剋服抵觸
第7章 新角色
第8章 角色轉換
第9章 技術實踐

第Ⅲ部分 團隊
第10章 團隊結構
第11章 團隊協作
第12章 領導自組織團隊
第13章 産品Backlog
第14章 Sprint
第15章 做計劃
第16章 質量

第Ⅳ部分 組織
第17章 擴展Scrum
第18章 分布式團隊
第19章 與其他方法論共存
第20章 人力資源、後勤和PMO

第Ⅴ部分 下一站
第21章 看看進展如何
第22章 沒有終點

精彩書摘

　　因為ETC與Scrum開發團隊一樣使用Scrum，所以他們也通過Sprint取得進展。每個ETCSprint以計劃會議開始，以評審和迴顧會議結束。這些會議和Scrum開發團隊的那些會議完全一樣，也經常發生同樣的問題。來自KeyCorp（美國一傢大型的金融機構）的Thomas Seffernick，參加瞭他所在公司的ETC（也稱敏捷實施團隊）的第一次迴顧會議。他迴憶瞭團隊如何犯下許多新Scrum開發團隊都有的一個共同錯誤——與演示工作中取得的進展相比，他們更願意談論計劃。

　　因為領導要站著描述他們掃除障礙的計劃，所以第一次敏捷實施（ETC）Sprint評審會議比較痛苦。會中傳遞的信息是清晰的——計劃不錯，但結果有待證明。此後的評審會議就有變化，結果成為會議的焦點。（2007,202）

　　一些ETC舉行每日站會，我認為這是一項良好的實踐。但是，我並不認為必須像Scrum開發團隊一定要舉行每曰站會那樣，堅持要求做到這點。因為ETC成員要完成的工作不像開發團隊要完成的工作那樣緊密地互相交錯，所以每日站會是一件很有價值但非必須的事情。類似地，ETC成員很少是全職的，大多數人已有其他工作，許多時候，他們待在原來的工作上更有意義。例如，對於一位開發部門主管，讓他離開自己的崗位而服務於ETC，與任其留在自己的工作崗位相比，無疑後者更有助於排除企業的更多睏難。

　　ETC Sprint的長度取決於ETC成員。不過以我的經驗而言，兩周是最好的。這也是Ken Schwaber（2007，10）所推薦的Sprint長度。Elizabeth Woodward是指導IBM大規模實施敏捷的ETC成員之一，她如下描述有關他們Sprint長度的經曆。

　　我們用過兩周和四周的Sprinto迄今為止，我們看到最成功的是兩周的Sprint。我相信其中的原因在於其“交付物”展示的良好勢頭和對外可見的進展。我們把各個社區的工作收集到一個簡短的摘要中——封能讓人們在15分鍾內讀完的電子郵件。發起人和産品負責人很多成功的Scrum實施都由一個明確的發起人（sponsor）啓動和推進，發起人是企業中負責成功轉型的資深人士。Salesforce.com非常成功的大規模轉型就由公司的一位共同創始人Parker Harris發起。作為負責技術的執行副總裁，Harris

　　處在一個絕佳的位置，可以支持這樣的變革——它會顯著改變Salesforce.com開發組織中每個人的工作方式。

　　轉型發起人應來自企業正在計劃實施轉型的部門級彆。Salesforce.com需要公司管理層充當發起人，因為其轉型是整個企業範圍的。如果是部門的轉型，那麼部門級彆的領導是閤適的選擇。

　　發起人也是ETC的産品負責人。這意味著，有時ETC的産品負責人是沒什麼Scrum經驗的人。不過沒有關係，如同所有的産品負責人一樣，ETC的發起人能夠通過尋求其他ETC成員的幫助來履行這個職責。作為ETC最資深的成員，發起人將在轉型實施溝通中扮演著重要角色，但他不必是轉型願景中唯一的來源，還有其他人。

　　開始采用Scrum時，Primavera就瞭解到強勢發起人的重要性。BobSchatz和Ibrahim Abdelshafi，當時是Primavera的技術執行官，他們如下描述發起人支持的重要性：

　　實施敏捷或實施任何重大的變革，都需要管理層真誠的支持。事情得到解決前道路是崎嶇不平的，盡管有任何問題或失敗，但管理層的支持都能讓變革之路堅持下來。（2005，38）

　　……

前言/序言

　　這本書不是為那些剛接觸Scrum或敏捷概念的人們而準備的。有其他書籍、課程甚至網站可以幫助他們。如果你在Scrum方麵是新人，可以從其中的一種方式著手。這本書也不是為那些純粹主義者而準備的（譯者注：純粹主義者指特彆執著於完美理論闡述的人）。他們其實可以找到很多這方麵的博客，來爭辯什麼是真正的敏捷或Scrum。這本書為實用主義者而生。寫給那些已經開始嘗試Scrum且可能已經遇到一些問題的人，以及那些雖然沒有開始但已經按捺不住躍躍欲試的人。這些人需要的已經不是關於如何畫一張燃盡圖，或者是在每日站會上如何給齣三個問題的答案等入門介紹。他們需要的是一些更加高階的課題——比如如何在企業或者項目中引入Scrum，並進行推廣，如何幫助人們在項目初期放棄大的設計，如何在每個Sprint交付可以工作的軟件，經理應該做什麼，等等。如果這些課題你似曾相識，本書正好可以滿足你的需要！

　　本書藉助我過去15年的Scrum經驗（特彆是最近四年以來的經驗），來幫助大傢找到這些問題的答案。在最近的四年中，每次我見完一個客戶，就會在晚上迴到酒店後整理和記錄他們麵臨的難題、他們提齣的疑問及我當時所給齣的建議。然後我會通過迴訪或者電子郵件的方式進一步跟蹤這些問題。我隻想通過實踐真切地確認我的哪些建議能最終解決哪些方麵的問題。

Scrum敏捷軟件開發 epub pdf mobi txt 電子書 下載 2024

發貨快，書籍無損壞。內容待評。

評價單詞多的，有京豆送的啊

很好，不貴很便宜。挺好的

內容蠻豐富的，可以推薦一下

超好 性價比超高 推薦購買

書是買給彆人的，所以不知道好不好

拍下第二天就送到瞭，包裝乾淨完好都有塑封，非常好。

閱讀過程中自己對於探索的想法也在不斷滋生，用戶故事的探索和整理其實就是一個凝聚團隊共識的過程，産品應該避免隻是交付齣需求文檔，避免隻是靠自己一個人在思考功能，從用戶故事開始的探索過程就是團隊達成共識的過程。 延伸閱讀：用戶故事與敏捷方法，商業模式新生代

敏捷開發，這本書很經典，很好，很不錯