《Scrum敏捷软件开发》是敏捷联盟及Scrum联盟创始人之一、敏捷估算及计划的鼻祖Mike  Cohn三大经典著作中影响最为深厚的扛鼎之作，也是全球敏捷社区中获得广泛肯定的企业敏捷转型权威参考。作者花四年时间，把自己近十五年的敏捷实践经验，特别是近四年中针对各种敏捷转型企业的咨询和指导工作，并结合旁征博引的方式，从更高的思想层次对敏捷与Scrum多年来的经验和教训进行深入而前面的梳理和总结，最终集大成者便是这本令人醍醐灌顶的佳作。
    《Scrum敏捷软件开发》是软件企业及其管理团队成功进行敏捷转型战略及实施的必备参考书，适合经理、开发人员、教练、ScrumMaster、产品负责人、分析师、团队领导或项目领导，是帮助他们成功完成项目，甚至造就敏捷企业的重要参考。

　　
前 言
　　这本书不是为那些刚接触Scrum或敏捷概念的人们而准备的。有其他书籍、课程甚至网站可以帮助他们。如果你在Scrum方面是新人，可以从其中的一种方式着手。这本书也不是为那些纯粹主义者而准备的(译者注：纯粹主义者指特别执着于完美理论阐述的人)。他们其实可以找到很多这方面的博客，来争辩什么是真正的敏捷或Scrum。这本书为实用主义者而生。写给那些已经开始尝试Scrum且可能已经遇到一些问题的人，以及那些虽然没有开始但已经按捺不住跃跃欲试的人。这些人需要的已经不是关于如何画一张燃尽图，或者是在每日站会上如何给出三个问题的答案等入门介绍。他们需要的是一些更加高阶的课题--比如如何在企业或者项目中引入Scrum，并进行推广，如何帮助人们在项目初期放弃大的设计，如何在每个Sprint交付可以工作的软件，经理应该做什么，等等。如果这些课题你似曾相识，本书正好可以满足你的需要！
　　本书借助我过去15年的Scrum经验(特别是最近四年以来的经验)，来帮助大家找到这些问题的答案。在最近的四年中，每次我见完一个客户，就会在晚上回到酒店后整理和记录他们面临的难题、他们提出的疑问及我当时所给出的建议。然后我会通过回访或者电子邮件的方式进一步跟踪这些问题。我只想通过实践真切地确认我的哪些建议能最终解决哪些方面的问题。
　　在不断收集这些难题、疑问及建议后，我整理出一些共通的主题。有一些困难是个别客户及团队所特有的。其他的则是大家普遍遇到的。这些普遍的共通问题及我所给出的克服这些困难的建议构成了本书的基础。这个思路清楚体现在两个方面：首先，大部分章节都包含一个特色小节"试一试"。它们是我最常用的建议或者是我认为在某些场景下非常有益的实践。其次，大多数章节也包含另一个小节"反对"。我试着在这个小节中重现我曾经在一些与客户的对话中遇到的典型的反对的意见。当你读到这些反对的声音时，试着听听你的伙伴的意见。我猜你一定曾经听到过很多类似的反对意见。在这些小节中，你会看到我常用的解决办法。
关于读者的其他假设
　　除了假设你已了解Scrum基础知识，并且现在打算在公司内引入Scrum，或者期望精通Scrum，我还假设你在公司中有一定的影响力。这当然不是说本书只是为总监、副总裁和CEO而准备的。我所假设的影响力指的只是你在你所在的工作岗位上，不管它具体是什么岗位，你所具有的个人魅力和个人信用所带来的对同事的影响力。当然，一个好的职位会有所帮助。但是我们会看到，成功的Scrum执行所需要的影响力通常来自于意见领袖。
本书的结构
　　四年前当我开始写作本书的时候，我所使用的副标题是"起步与优化"，它们正是我希望能提供帮助的两个方面。在收集素材及给出建议时，我意识到起步和优化Scrum其实是同一件事情。起步所需要的技巧与优化所需要的技巧并没有什么差别。
　　第I部分是关于起步的，它包括是选择小团队试点还是全面转型，如何帮助人们从意识到需要新的流程逐步转变到渴望变革、再转变到有能力去做这样的变革，以及如何挑选试点项目和团队。你不仅可以用本章这部分介绍的基本原理作为起步，也可以用它们来进行优化。在这个过程中，涉及到的改进社区和改进Backlog在第4章介绍。
　　在第II部分中，我关注个体及其在导入Scrum的过程中需要做出的改变。第6章描述一些人有可能存在的抵触情绪。我对这些抵触的根源进行了分析，对如何帮助人们克服抵触给出了指导性的意见。第7章和第8章讲述了在使用Scrum的项目中存在的新的角色，以及在传统项目中定义的角色所需要做出的必要的改变，如程序员、测试人员、项目经理等。第9章介绍一些技术实践，包括持续集成、结对编程、测试驱动开发等，这些技术实践应该使用，至少也要做一些尝试，它们会使每个人的日常工作方式有很多变化。
　　在第III部分中，我们向外扩展到团队的话题。我们首先关注如何设计Scrum团队的结构，以充分体现Scrum的优势。然后，第11章阐述在Scrum项目中团队协作的本质。第12章将一起来看在Scrum中领导一个自组织团队意味着什么。在这一章，我具体针对ScrumMaster、职能经理和其他领导者给出一些建议。第13章至第15章通过对Sprint、计划和质量的讨论完成第III部分内容。
　　第IV部分，我们进一步扩展到企业级别的话题。在第17章，我们将进一步研究如何把Scrum扩展到更大的工作范围，跨团队的项目中必须要做哪些事等。第18章考虑分布式团队的更多的复杂性。然后，在第19章进行更加复杂的讨论，谈谈如何在一个部分使用瀑布式流程的项目中使用Scrum，在有监管需求时如何处理。第IV部分以第20章作为结尾，这一章特别讨论Scrum对公司的人力资源、后勤及PMO等部门的影响。
　　第V部分包含两章。第21章归纳企业敏捷转型的各种度量方法。第22章对全书进行小结，并且再次阐明只有持续改善才能做到真正的敏捷。不论你今天已经做得有多好，为了保持敏捷，你下个月必须做得更好！
关 于 术 语
　　像大多数情况一样，笔论Scrum比仅仅口头讨论它要难一些。读者在阅读时，一不小心就会误读一个句子或者脱离语境去理解它。为了避免这样的问题，我在使用一些术语时尽量小心并且精确。比如，我使用"开发人员"这个词时，我是指在项目中参与开发的任何一个人。它包括程序员、测试员、分析师、用户体验设计师、数据库管理员等。
　　术语"团队"也有它自己的问题。它当然包括开发人员，但是"团队"包括ScrumMaster和产品负责人吗？自然，它也取决于语境。当我需要精确表达时，我使用"整个团队"来指所有的人：开发人员，产品负责人和ScrumMaster。然而盲目地使用"整个团队"会降低本书的可读性。所以有时你还是会看到"团队"，通常是在所指含义非常明确的地方。
　　除Scrum及敏捷团队外，我也需要一个术语来专指那些两者都不是的团队。在不同的地方，我曾使用"顺序式团队"、"传统型团队"和"非敏捷团队"等术语，它们每一个之间有细微的含义差别并恰如其分地用在不同的地方。
本书使用说明
　　很多书的前言都有这样的小节标题。但是这些标题通常是在说"如何阅读本书"。阅读这本书最好的办法是使用它。不只是停留于阅读。当你遇到"试一试"时，停下来试一下。或者在我有特别建议的地方，记住它们然后在下一次回顾会议或者计划会议的时候尝试用一用。
　　不必按照章节的顺序阅读本书。事实上有可能有些章节你根本没有必要读。如果你在计划方面已经没有问题，或者是没有分布式团队，你只是应公司的期望要求做得更好而已，尽可以把相关的章节全部跳过。但是，我建议每个人都至少通读前4章并且按照顺序阅读--它们是后面所有章节的基础。
　　第4章介绍"改进社区"和"改进Backlog"想法。改进社区是指一组志同道合的个体，他们热衷于推动企业的在某一个方面的改进。改进社区可能由这样三种人组成：他们热衷于改进产品Backlog；决定收集相关的最佳实践；在团队间共享。另外的改进社区有可能包括几百个热衷于改进公司测试活动的人。改进Backlog正如其名，是一个排好序的、改进社区的任务列表。
　　我希望改进社区能使用本书来实施他们的改进Backlog，包括指导及推动转型的企业转型社区(ETC)。事实上有些章节的标题被特意地命名以使其能直接进入改进Backlog。例如，第13章的"把文档转化成讨论"，第14章的"在当前的Sprint中为下一个Sprint做准备"，第16章的"在不同层次上进行自动化"，等等。
　　作为一个有多年经验的Scrum培训师和顾问，我曾服务于几百个团队和公司，我相信Scrum可成功适用于每个公司。有些公司比其他公司可能难一些。有些公司会因为强势的公司文化而面临挑战，还有的会因一些顽固的难以变通的人而造成人员损失。在一些幸运的公司，会得到管理层的支持并积极鼓动员工参与。但是，所有这些公司的共同点是，他们都需要实用的、经过证明的建议。我写作本书的目的就是为他们提供这样的建议。




　　
　　
　　
　　

　　
　　
　　

    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）
    ……