主要优点1第1章在互联网时代,交付速度是当今软件开发的主题。十年前,项目通常要持续好几年,并且项目阶段是以月来衡量的。如今,多数团队的项目周期是按月来衡量的,而项目阶段则减少到几周甚至几天。任何需要长远规划的东西都将被抛弃,比如大量的前期软件设计和详细的需求分析。超过项目阶段平均周期的任务将不复存在。跟代码冻结(CodeFreeze)以及数周的手动回归测试说再见吧!变化频率如此之高,文档很快就会过时。不断更新详细需求说明和测试计划(TestPlan)需要投入大量精力,相当浪费。那些以往在日常工作中依赖于此的人们,如业务分析师或者测试人员,在这个每周迭代的新环境中经常会无所适从。开发人员原本以为不会受到纸质文档缺失的影响,现在却要把时间浪费在不必要的返工与功能维护上。他们不是花时间去制订宏伟的计划,而是要浪费数周的时间去修正有问题的产品。在过去的十年里,软件开发社区致力于使用“正确”的方式来构建软件,关注使用技术实践和思想来确保质量。但是,正确地构建产品和构建正确的产品是两码事。我们要二者兼顾才能取得成功。图1-1 实例化需求说明可以帮助团队构建正确的软件产品,而技术实践可以确保正确地构建产品想要有效地构建正确的产品,软件开发实践必须满足以下几点。第1章主要优点保证所有项目干系人和交付团队的成员都对需要交付哪些东西有一致的理解。有准确的需求说明,这样交付团队才能避免由模棱两可和功能缺失造成的无谓返工。有用来衡量某项工作是否已经完成的客观标准。具有引导软件功能或团队结构变更的文档。传统意义上,构建正确的产品需要庞大的功能需求说明、文档以及漫长的测试阶段。如今,软件每周都要有交付,这一套已经行不通了。我们寻求的方案要能带来如下好处。避免过度说明需求从而产生浪费,避免花时间在开发前会发生改变的细节上。有一种可靠的文档,可以解释系统的行为,据此我们能容易修改系统行为。可以有效地检查系统行为与需求说明的描述是否一致。以最少的维护成本维持文档的相关性与可靠性。适合短迭代和基于流的过程,这样能为即将开展的工作提供即时足够的信息。图1-2 对于敏捷项目,构建正确文档的关键因素乍一看,这些目标似乎互相冲突,但有很多团队已经成功地达成了所有目标。在为本书做调研时,我采访了30个团队,他们完成了大约50个项目。我试图找出一些模式与通用做法,并挖掘出这些方式背后的基本原则。这些项目的共同思想,定义了一种构建正确软件的好方法:实例化需求说明。实例化需求说明是一组过程模式,它帮助团队构建正确的软件产品。使用实例化需求说明,团队编写的文档数量恰到好处,在短迭代或基于流的开发中可以有效地协助变更。实例化需求说明的关键过程模式将在下一章介绍。本章我将阐述实例化需求说明的好处。我将使用实例化需求说明的风格来进行阐述,而不是以理论介绍的方式来构建一个案例,我将展示18个真实的例子,它们都来自于那些大大受益于实例化需求说明的团队。在开始之前,我想强调一下,在一个项目中很难孤立地看待某种思想的影响或作用。本书所描述的实践,可以与已经开展的敏捷软件开发实践[例如测试驱动开发(TDD)、持续集成以及使用用户故事做计划等]共同使用,而且可以增强其他实践的效用。当我们转而去看那些有着不同背景的项目时,很多模式浮现了出来。我采访的团队中,有些在实施实例化需求说明前一直使用敏捷过程,而有些团队则是在过渡到
泛型编程与C标准库-图灵社区 来自淘豆网m.daumloan.com转载请标明出处.
