图书前言

前    言

本书涵盖的内容

虽然市面上存在一些有关Scrum的优秀图书,但是我们相信没有一本涵盖了软件项目团队在企业约束下启动和完成Scrum软件项目所需的全部必要知识(对于企业约束,我们指的是Scrum或者敏捷还没有在整个企业范围内成功实施的公司)。

为了帮助这些团队成功,在公司的约束中生存,我们决定利用实践中学到的知识编写一本有关Scrum的实用书籍。

为此,本书的15章内容将为你提供所需的全部知识,就像是一个经验丰富的ScrumMaster在亲自提供咨询。此外,你还会在附录A中学到两个案例,它们是采用本书所说的方法和建议成功构建和部署的两个软件产品。

第1章:敏捷和Scrum的基础知识

第1章的重点在于敏捷特别是Scrum的基础知识。该章同时纠正了有关Scrum的一些不准确的信息,类似于Lean-Agile Software Development Achieving Enterprise Agility一书中 Alan Shalloway和他的团队所做的事情。这可以使你和我们在进一步讨论之前处在同一起跑线上。

第2章: 关于财务

无论是否对敏捷或者Scrum感兴趣,你都需要记住业务管理层的交流语言是财务术语。

在第2章中,你会学到财务的基础知识,这样可以更好地与业务管理层合作,帮助他们选择项目、评估项目预算、预估项目需要花费的金钱和时间。

第3章 :如何与各层管理者沟通

虽然获得业务高层的支持非常重要,但是与中层管理者保持日常合作更加重要,因为中层管理者对项目有着直接的影响。第3章的目标是让你有足够的知识来达到这两个目的。

第4章: 针对产品积压工作的直观的需求收集方法

一旦项目团队得到了启动的许可,那么正确地获取需求就变得至关重要。第4章提供了一种简单、直观的方法来为Scrum项目收集需求。

第5章 :让故事点评估具有可比性

随着敏捷和Scrum得到越来越广泛的普及,目前的故事点评估系统(也是团队生产率构建的依据)面临的一个问题是跨团队无法比较故事点数。这阻碍了许多IT部门想要全面实施Scrum的想法,特别是在涉及整个资源分配和重新分配的情况下。像第4章一样,我们提供了一种应用于许多项目的成功方案。它会帮助你评估故事并有所依据,不是仅凭你的主观感受,而是客观的可视数据,从而支持在同一个公司内部跨不同团队进行生产率比较。

第6章:架构愿景对团队生产率和软件质量的影响

对于任何参与过Scrum项目的人来说,你都应该遇见过团队的生产率起伏波动,经常降低了团队的生产力和交付能力。本章会讨论团队生产率波动的原因,并建议通过架构愿景(又名架构意图)来解决这个问题。

第7章:从架构愿景到发布和冲刺规划再到并行软件开发

除了能够帮助维持甚至提高团队生产率,良好的架构愿景还有其他的好处。这其中包括对发布和冲刺规划的积极影响。

第8章:关于产品负责人

Scrum项目中的每个人都很重要,但是产品负责人可以帮助团队交付最大的业务价值。第8章讨论了成功的产品负责人应该具备的个人和专业特质。

第9章:自动化测试和持续集成测试的重要性

不是所有测试都是生来平等的。在本章中,我们会深入地讨论一些对Scrum项目最重要的测试,并解释为什么对Scrum项目团队的成功至关重要。

第10章:团队合作的重要性

我们每个人都知道团队合作非常重要。虽然看起来老生常谈,第10章还是强调了团队合作对Scrum团队交付价值特别是在自组织的情况下至关重要。该章还讨论了人的心理和气质类型,这可以帮助合作者互相了解。此外,这一章还提供了一些方法用于冲突解决,并考虑了冲突发生的不同阶段。

第11章:Scrum项目中管理和领导的新特质

虽然Scrum团队是自组织的,但是仍然需要项目管理和团队领导。我们将讨论在Scrum环境中项目管理的变化。这里需要记住的是服务型领导替代了过去的命令和控制式风格。第11章讨论了一些有用的培训和领导方法,ScrumMaster和产品负责人可以借此来帮助团队实现最终交付。

第12章:如何使Scrum适应环境

如果有人能够发明一种方法或者过程适用于所有公司和所有问题,那么我们可以不用进行调整。现实是,我们必须在约束条件下调整某种过程来使它发挥作用。Scrum也是如此。

不像消极的ScrumBut(Scrum的错误应用),我们将讨论一些积极的ScrumBut例子(好的Scrum适应行为),就像荷兰ISM eCompany公司的CIO Jurgen Appelo在“ScrumButs are the best part of Scrum”中所做的那样。

第13章:Scrum项目准备程度的自我评估

第13章提供了一个Scrum项目准备程度自我评估的例子,你应该在项目一开始的时候就做这份测试,它会帮助你确定哪些问题会阻碍你的项目交付能力。

依据得分,你会知道你的团队在当前环境下工作的难易程度,并努力改进以提高胜算。

第14章:何时需要ScrumMaster

除非你或者你的团队非常熟悉Scrum,否则需要一名ScrumMaster来指导你处理一些初次尝试Scrum时遇到的困难。

虽然本书希望为你承担ScrumMaster的角色,但是第14章还是讨论了一名成功的ScrumMaster所需要具备的个人和专业特质。

第15章:临别赠言

我们不会让你一个人孤独前行,第15章提供了一些建议,如从不同章节里可以提取出的主要应用措施,以及在项目条件下使用的顺序。

附录A:两个真实的软件产品开发案例

在附录A中,我们展示了两个成功的软件产品,它们的构建和部署过程都采用了本书提到的建议,从需求收集到架构愿景再到发布和冲刺规划及测试。

第一个案例提供了一个垂直开发的应用例子,而第二个案例则是水平开发。

附录B:关于提前终止冲刺

通常,如果采用了本书所给的建议,Scrum项目应该运行顺利。虽说如此,可能也会出现冲刺异常终止的情况,有时可能是因为低估了团队的生产率或者用户故事的复杂程度。

为了帮助你处理这样的情况,本书的附录B讨论了冲刺的异常终止,包括起因、如何避免、如何处理和如何重启工作。

术语表

为了便于理解关键的Scrum术语,本书末尾提供了术语表。

本书的读者对象

根据你目前在公司的职位或者角色,这里有一些建议,有关于应该按何种顺序读哪些章节的建议。有两种人会发现本书十分有用:Scrum新手和Scrum老手。

Scrum新手

如果是管理团队的成员

作为管理层,应该首先阅读第1章来熟悉敏捷的演变、Scrum的起源和基础知识。接下来,应该阅读第3章来看看Scrum团队与管理层合作的建议,包括高层和中层。再接下来,应该分别阅读第8章和第14章,这两章分别讲述了产品负责人与ScrumMaster的特质和角色。

无论是否实施Scrum,我们猜想你想知道你或者你的团队应该如何为产品积压工作收集需求。如果是这样,接下来应该阅读第4章,了解如何识别用户目标和使用直观的方法为Scrum项目收集需求。你可能还听说过利用规划扑克衡量每个团队的生产率,每个冲刺能够交付的用户故事数目在跨团队时是不同的。如果你知道这些并且想了解如何在大规模实施Scrum时让故事点数变得跨平台可比较,那么可以阅读第5章。第5章展示了一种评估需求的直接方法,每个团队成员都可以以数据支持自己的评估并使团队生成率具有可比性。毫无疑问,后者是在企业范围跨团队成功实施Scrum的关键条件。

如果有更多的时间,我们建议你阅读全书,从头到尾,包括附录A。附录A中介绍了两个软件产品,其构建和部署过程都采用了本书倡导的建议。你会惊讶地发现自己学到了不少有关敏捷和Scrum的知识。

如果是技术管理团队的成员

作为管理层,应该首先阅读第1章来熟悉敏捷的演变、Scrum的起源和基础知识。接下来,应该阅读第3章来看看Scrum团队与管理层合作的建议,包括高层和中层。再接下来,应该分别阅读第8章和第14章,这两章分别讲述了产品负责人与ScrumMaster的特质和角色。

无论是否实施Scrum,我们猜想你想知道你或者你的团队应该如何为产品积压工作收集需求。如果是这样,接下来应该阅读第4章,了解如何识别用户目标和使用直观的方法为Scrum项目收集需求。你可能还听说过利用规划扑克衡量每个团队的生产率,每个冲刺能够交付的用户故事数目在跨团队时是不同的。如果你知道这些并且想了解如何在大规模实施Scrum时让故事点数变得跨平台可比较,那么可以阅读第5章。第5章展示了一种评估需求的直接方法,每个团队成员都可以以数据支持自己的评估并使团队生成率具有可比性。毫无疑问,后者是在企业范围跨团队成功实施Scrum的关键条件。

因为你有技术背景,所以我们建议阅读第6章,了解架构愿景和它如何帮助团队维护良好的生产率,甚至做好发布和冲刺规划(第7章)。

如果想知道谁会在Scrum中驱动需求和业务需要,那么第8章的有关产品负责人的内容适合你。类似地,如果你想知道谁负责帮助团队和产品负责人理解和恰当地实施Scrum,那么应该阅读第14章。

因为你是管理者,当然不希望手动做一些麻烦事,所以应该阅读第9章来了解最重要的两种测试以及如何组织它们来帮助团队交付。作为一名管理团队的成员,我们猜想你应该好奇在自组织的Scrum环境中如何管理团队,那么第10章适合你。同时,我们建议你阅读第11章,了解项目管理和团队领导。作为管理者,你应该知道没有哪个过程或者过程框架可以在不进行调整的情况下轻松地适用某个公司,所以应该阅读第12章。此外,如果你想知道Scrum项目的准备程度,那么应该阅读第13章,做问卷调查。

最后,如果有更多的时间,我们建议你阅读全书,从头到尾,包括附录A。附录A中介绍了两个软件产品,其构建和部署过程都采用了本书倡导的建议。你会惊讶地发现自己学到了不少有关敏捷和Scrum的知识。

如果是项目经理

因为你可能在担任ScrumMaster的同时又作为管理者,所以应该阅读全书。

你会惊讶地发现自己学到了不少有关敏捷和Scrum的知识,可以理解专家的见解,并知道如何前进。

如果是开发人员

作为技术团队成员,我们认为你会对大部分章节感兴趣,它们会帮助你理解如何把开发工作搞定。为此,请阅读:

● 第1章

● 第5章

● 第6章

● 第7章

● 第8章

● 第9章

● 第10章

● 第14章

最后,如果有更多的时间,我们建议你阅读全书,从头到尾,包括附录A。附录A中介绍了两个软件产品,其构建和部署过程都采用了本书倡导的建议。你会惊讶地发现自己学到了不少有关敏捷和Scrum的知识,可以理解专家的见解,并知道如何前进。

如果是业务分析师

像开发人员一样,我们相信你会对非技术的章节比较感兴趣,它们会帮助你了解Scrum是什么以及如何搞定工作。为此,请阅读:

● 第1章

● 第2章

● 第4章

● 第5章

● 第8章

● 第10章

● 第11章

● 第14章

如果你有一些技术背景或者时间,我们推荐也阅读第6章和第7章,了解架构愿景的内容。我们编写的内容对非技术团队的成员来说也是易于理解的。它们会让你拥有和技术人员一样的理解,从而可以和技术人员愉快合作。

最后,如果有更多的时间,我们建议你阅读全书,从头到尾,包括附录A。附录A中介绍了两个软件产品,其构建和部署过程都采用了本书倡导的建议。你会惊讶地发现自己学到了不少有关敏捷和Scrum的知识。

如果是测试人员

像开发人员和业务分析师一样,我们认为你会对大部分章节感兴趣,它们会帮助你了解Scrum是什么以及如何搞定工作。为此,请阅读:

● 第1章

● 第4章

● 第9章

● 第10章

● 第11章

如果你想知道同事是如何收集需求和评估故事的,请阅读第4章和第5章。如果你有一些技术背景,我们推荐也阅读有关架构愿景的第6章和第7章。我们编写的内容对非技术团队的成员来说也是易于理解的。尝试阅读它们,你不会后悔的,因为它们会让你拥有和技术人员一样的理解,从而可以和技术人员愉快合作。

最后,如果有更多的时间,我们建议你阅读全书,从头到尾,包括附录A。附录A中介绍了两个软件产品,其构建和部署过程都采用了本书倡导的建议。你会惊讶地发现自己学到了不少有关敏捷和Scrum的知识。

如果是应用架构师

像开发人员和业务分析师一样,我们认为你会对大部分章节感兴趣,它们会帮助你了解Scrum是什么以及如何搞定工作。为此,请阅读:

● 第1章

● 第4章

● 第6章

● 第7章

● 第10章

● 第11章

接下来,阅读第3章,特别是3.3节。

最后,如果有更多的时间,我们建议你阅读全书,从头到尾,包括附录A。附录A中介绍了两个软件产品,其构建和部署过程都采用了本书倡导的建议。你会惊讶地发现自己学到了不少有关敏捷和Scrum的知识。

如果是企业架构师

企业架构师不像开发人员、测试人员和业务分析师,你可能会对Scrum项目架构适应整个企业架构这方面感兴趣。为此,请阅读:

● 第1章

● 第4章

● 第6章

● 第7章

● 第8章

● 第10章

● 第11章

● 第14章

接下来,阅读第3章,特别是3.3节。

最后,如果有更多的时间,我们建议你阅读全书,从头到尾,包括附录A。附录A中介绍了两个软件产品,其构建和部署过程都采用了本书倡导的建议。你会惊讶地发现自己学到了不少有关敏捷和Scrum的知识。

如果是PMO的成员

因为你的团队主要关心IT适应业务需求和IT绩效,所以请阅读:

● 第1章

● 第2章

● 第3章

● 第4章

● 第5章

● 第6章

● 第7章

● 第8章

● 第11章

● 第12章

● 第13章

● 第14章

如果有更多的时间,我们建议你阅读全书,从头到尾,包括附录A。附录A中介绍了两个软件产品,其构建和部署过程都采用了本书倡导的建议。你会惊讶地发现自己学到了不少有关敏捷和Scrum的知识。

如果是运维团队的成员

因为你的团队负责公司的软件应用程序的每日运行,所以请阅读:

● 第1章

● 第3章

● 第6章

● 第7章

● 第8章

● 第9章

● 第14章

如果有更多的时间,我们建议你阅读全书,从头到尾,包括附录A。附录A中介绍了两个软件产品,其构建和部署过程都采用了本书倡导的建议。你会惊讶地发现自己学到了不少有关敏捷和Scrum的知识。

如果是产品负责人

因为你负责项目的业务价值,所以请阅读:

● 第8章

● 第2章

● 第3章

● 第4章

● 第5章

● 第9章

● 第11章

● 第14章

如果你想让团队构建健壮的应用程序,我们推荐阅读:

● 第6章

● 第7章

如果有更多的时间,我们建议你阅读全书,从头到尾。你会惊讶地发现自己学到了不少有关敏捷和Scrum的知识。

如果是业务发起人

作为项目业务需求的幕后支持者和资金提供者,你会对下面几章感兴趣:

● 第1章

● 第8章

● 第2章

● 第3章

● 第11章

● 第14章

如果有更多的时间,我们建议你阅读全书,从头到尾,包括附录A。附录A中介绍了两个软件产品,其构建和部署过程都采用了本书倡导的建议。你会惊讶地发现自己学到了不少有关敏捷和Scrum的知识。

Scrum老手

如果是ScrumMaster

作为经验丰富的ScrumMaster,你应该阅读:

● 第14章

● 第2章

● 第3章

● 第4章

● 第5章

● 第6章

● 第7章

● 第11章

● 第12章

● 第13章

如果有更多的时间,我们建议你阅读全书,从头到尾,包括附录A。附录A中介绍了两个软件产品,其构建和部署过程都采用了本书倡导的建议。你会惊讶地发现自己学到了不少有关敏捷和Scrum的知识。

如果是产品负责人

作为经验丰富的产品负责人,你应该阅读:

● 第8章

● 第2章

● 第4章

● 第5章

● 第6章

● 第7章

● 第11章

● 第13章

● 第12章

● 第14章

如果有更多的时间,我们建议你阅读全书,从头到尾,包括附录A。附录A中介绍了两个软件产品,其构建和部署过程都采用了本书倡导的建议。你会惊讶地发现自己学到了不少有关敏捷和Scrum的知识。

如果是(开发)团队的成员

即使你的Scrum经验比较丰富,我们仍推荐阅读:

● 第3章

● 第4章

● 第5章

● 第6章

● 第7章

● 第8章

● 第9章

● 第10章

● 第13章

● 第14章

如果有更多的时间,我们建议你阅读全书,从头到尾,包括附录A。附录A中介绍了两个软件产品,其构建和部署过程都采用了本书倡导的建议。你会惊讶地发现自己学到了不少有关敏捷和Scrum的知识。