《C#敏捷开发实践》试读：1.1　Scrum与瀑布

完成本章学习之后，你将学到以下技能。  给项目的主要干系人分配角色。   识别Scrum需要生成的各种文档和其他工件。   监测Scrum项目进度。   诊断Scrum项目的问题并提出补救措施。   高效主持Scrum会议以达成最大的会议成果。   对比Scrum和其他敏捷或严苛方法之间的优劣。  Scrum是一个具体的项目管理方法论。更准确地说，它是敏捷方法的一种。Scrum的核心概念是以迭代的方式为软件产品增加价值。整个Scrum流程是可重复的，也可以迭代多次，一直持续到整个产品完成或者流程被终止。这些迭代被称为冲刺（sprint）。经过若干个冲刺得到的软件是随时可以发布的。整个软件产品的所有工作项都会在产品积压工作（product backlog）上按照优先级排列，在每个冲刺开始时，开发团队会把在这个新的冲刺中承诺要完成的工作项添加到冲刺积压工作（sprint backlog）上。Scrum中工作项的单位是故事（story）。产品积压工作实际上就是一个排好序的候选故事队列，每个冲刺则由要在这一个冲刺中承诺要开发完成的故事组成。图1-1展示了Scrum流程的框架。 Scrum过程中，开发团队内部或外部相关角色人员会产出一些文档工件，此外他们还会一起参加一些会议。只用一章的篇幅当然无法从项目管理的角度完整展示整个Scrum的细节，但是本章会尽量提供足够多的细节，为你进一步深入学习Scrum打下基础，并为后续的每日实践提供一个方向性的指导。 图1-1　Scrum的工作方式看起来就像一条为软件产品逐步添加小特性的生产线 Scrum是一种敏捷方法 敏捷方法论（Agile）包括一组轻量级软件开发方法，它们都允许及时响应客户的需求，即使项目已经在进行过程中了。敏捷是在很多严苛的结构化项目实践失败的教训中应运而生的。敏捷宣言列出了敏捷和严苛方法论之间详细的对比项。大家可以在以下网址查看完整的敏捷宣言：http://www.agilemanifesto.org。 敏捷宣言最初只是由十七位开发人员联名发起的。但是从那一刻起，敏捷方法的影响力就在日益扩展，现在已经成为了敏捷大环境下各个软件开发角色公认的基本约定。Scrum是目前敏捷方法论中应用最广泛、最常见的一个流程实现。 1.1　Scrum与瀑布 根据我多年的软件产品开发经验，敏捷方法比瀑布方法工作的效果要好，而且我也乐于推广各种敏捷流程。瀑布方法论的根本问题在于它过于严苛和僵化。图1-2展示了一个瀑布工程涉及的流程阶段。 从图1-2可以看到，每个阶段的输出都是下一个阶段的输入，而且每个阶段必须在进入下一个阶段前完成。这就要求在一个阶段完成时没有遗留任何错误、问题、难点或者误解，因为整个过程只是单向的。 瀑布流程还要求在任一阶段完成后不允许再发生任何更改，而这与大量的经验和统计数据不符。变化本身就是生活固有的一部分，软件工程也不例外。瀑布方法支持的这种应对变更的僵硬态度是高代价的、不值得的，而且是肯定可以避免的。瀑布方法论认定可以花费更多时间在需求和设计阶段来识别出所有潜在的变更，这样在后续阶段就不会发生变更了。这个观点很不靠谱，因为变更总会发生，不论你愿意与否。 图1-2　瀑布开发流程 为了应对变更，敏捷流程引入了另外一种方法，这个方法主动拥抱变化并且允许每个人都能快速响应任何变更。尽管敏捷（包括Scrum）提供了流程级别上的变更响应机制，但是在现代软件开发的信条里，要在代码级别响应变更是最困难的，也是最重要的。本书的宗旨就是竭力为你展示如何编写出能够灵活地自适应变更的代码。 另外，瀑布方法论是以文档为核心的，会产出大量的文档，而这些文档并不能直接改善软件产品。敏捷则恰恰相反，它认为能工作的软件就是这个软件产品最重要的文档。毕竟真正的软件行为是由软件源代码定义的，而不是由与代码相关的文档决定的。此外，瀑布方法论的文档和代码是完全分开的，所以很容易就会出现文档没有与代码完全同步的情况。 Scrum设置了一些度量标准，用于反映项目进度和整体健康状况，这些标准与产品的说明性文档是不同的。总体而言，敏捷倾向于有适量的文档以避免规避责任的现象，但是它也不强制要求必须撰写这些文档。如果这些文档不是撰写一次就再也不会被查阅的话，那么有些代码肯定能从这些支持文档中获益。出于这个原因，易用的在线文档（比如Wiki）就成为了Scrum团队很常用的工具。 本章的剩余部分将会更深入地讨论Scrum中最重要的方面，其中讨论的不完全是Scrum，也有与Scrum相关的常见变体。Scrum流程的目标不仅仅是通过迭代的方式改进软件产品，而且也包括改进开发流程。在Scrum团队特有的状况和上下文中，Scrum流程鼓励团队持续微调来保证整个流程对所有成员来说是合适的。 本章在讨论过Scrum的基本构成后，还会指出它的一些缺陷。这一章是本书的基础，由于Scrum流程承诺拥抱变更，后续章节就会在此基础上详细讲解如何编写出能够自适应变更的代码。一个声称自己可以优雅地处理变更但很难在代码层次实现的流程是没有意义的。 Scrum的不同形态 任何时候，当一个开发团队声明他们遵循了Scrum方法时，通常是说他们自己遵循了Scrum的某种变体（variant）。纯正的Scrum并不包含很多常见的实践活动，它们来源于诸如极限编程（eXtreme Programming，XP）等其他的一些敏捷方法。Scrum有三个分支，它们的实现都逐渐偏离了纯粹的Scrum理论。 增强的Scrum Scrum并不包含一些常见的实践活动，比如测试先行以及结对编程。但是对于很多团队而言，这些实践活动是对Scrum流程本身很好的补充，因此它们被认为是有辅助作用的实践。当团队从其他敏捷方法（比如极限编程或者看板）引入一些实践活动时候，实际操作的流程应该被称为增强的Scrum。这意味着，Scrum和一些优秀实践活动的组合起到增强而非削弱标准Scrum流程的作用。 弱化的Scrum 一些开发团队声称他们正在实践Scrum，但是却忽略了一些关键点。他们在产品积压工作上按照优先级顺序排列了工作项，在Sprint冲刺中选择了要完成的工作项，而且有追溯会议以及每日站立会议。但是，他们并没有按照故事点估算故事，而是采用真正的时间估算。这种Scrum流程的变体被称为弱化的Scrum。这种情况下，团队尽管在很多方面应用Scrum定义的实践活动，但是实际上却忽视了几个关键的活动。 根本不是Scrum 如果一个开发团队的实践严重偏离了Scrum方法，他们实际上就不是在使用Scrum。这一定会在开发过程中引起问题，特别是当团队成员希望能应用一种敏捷方法而实际的流程却一点都不像Scrum流程时。我发现每日站立会议是最容易被开发团队采纳的Scrum实践活动，但是让团队成员在心中对变更进行相对估算并且积极拥抱变更却很难。当很多Scrum流程的实践活动被团队放弃后，实际运行的流程就根本不是Scrum了。