阅读笔记八敏捷软件需求

研究表明，80%~85%的项目失败归咎于需求不正确。这也是为什么管理软件需求成为现在整个软件工程行业十分重要的研究方向。

　　   在开发过程中，环境不断在变，竞争对手引入新的产品，客户需求发生演变。

　　　　这也就说明在开始设计之前开发实际需求工件不可行，那么也就证明了过去常用的甚至现在仍有人在使用的瀑布模型不可取.

　　　瀑布模型指的是从需求——设计——实现——验证——部署一条线，

　　　　“固定需求范围”这种假设导致项目失败

　　

完整定义需求，之后经过较长时间才交付这些需求,不再合乎时宜。

　　业务需求的频繁变更表明，需求一旦形成文档就不会有重大变动，任何这样的假定都是有根本缺陷的。

    软件行业必须认真考虑本质上截然不同的过程模型。

　　由于瀑布模型的失败，在上个世纪八九十年代出现了迭代式过程，一般情况下，我们可以把这些过程视为一个包括多种迭代式方法的渐进连续体。

　　　　这些方法包括：螺旋模型、快速应用开发（RAD）、统一软件过程（RUP）。

　　　　　　在螺旋模型中，需求仍占据早期的强势地位，在螺旋最开始的周期中，主要是理解需求，并且要在正式开发之前验证需求。在此之后，螺旋模型开始一个更大的"螺旋".

　　　　　　　　RUP主要来源于螺旋模型，适用于对健壮性、伸缩性和可扩展性有严格要求的大规模应用，它是一种广泛采用的增量式软件过程模型。

　　　　　　　　　　RUP认为各种活动有必要在生命中周期各阶段（导入、细化、构建、移交）交叉进行，需求细化和需求变更是一个贯穿生命周期的持续性过程。

　　　　　　在迭代模型中，采用“基于发现”的方式，采用更轻量的文档和模型。迭代式过程能够通过早期迭代更快地发现“真正的用户需求”，从而大大降低项目的总体风险。

　　 从20世纪90年代后期开始直到最近，更轻量、适应性更强的软件过程模型激增，这是因为软件开发范式发生的一些基础性演进，如面向对象、第三代编程语言和测试驱动开发。

　　　　这样的方法包括：动态系统开发方式（DSDM）、特性驱动开发（FDD）、适应性软件开发、Scrum、极限编程（XP）、开放统一过程（Open UP）、Agile RUP、看板、精益、水晶方法等。这些方法都属于敏捷开发方法。其中，目前最广泛使用的是Scrum和XP.

       敏捷过程对需求的处理与以往的方式都有着根本的差异。敏捷原则中明确指出了最重要的目标是通过持续不断地及早交付有价值的软件使客户满意；欣然面对需求变化，即使在开发后期也一样。采用敏捷方法将使两个方面固定下来：进度与资源，使其他方面——包括范围（需求）——保持浮动。现在，完善的软件工程周期：以固定的质量，在固定的时间盒中交付小的增量，重复进行。

　　与敏捷方式同时其发展的还有精益软件运动，现在精益思想正被广泛研究和传播着，作者称，随着时间的推移，精益的影响将比现在介绍的敏捷软件开发方法更大、更广。

　　在这本书中，作者着重介绍了精益软件思想的框架，以此为前提，支持着本书中介绍的方式，即团队、项目集和企业的精益需求实践。

　　在团队项目、项目集或企业层面对需求管理成功实施一套精益&敏捷的原则与实践，是一个不小的壮举，它的使用的词汇很有特点，而且显得古灵精怪（用户、故事、Sprint、速率、故事点、篇章、待办事项）。

　　　　此外，为了更“精益”，经常要求消除或减少需求说明书、设计说明书、分阶段管理模型（包括现有的各种需求评审）、签字（包括在所难免的延迟）、实施在制品限制等。

在团队层面，由包括7+-2名成员组成的敏捷团队，通过一系列的迭代和发布，定义、构建并测试用户故事。

　　针对用户故事待办事项和团队需要完成的其它工作事项的管理，则是由团队中的产品负责人承担。

在项目集层面，大规模的系统功能开发由多个团队在一个同步的敏捷发布火车（ART）中完成。

　　ART按标准节拍有序迭代并有相应的里程碑，该里程碑有其固定日期和明确质量，但其范围可变（不是铁三角）。

　　　　典型的ART经常在固定为60到120天的时间边界内进行产品发布或产生潜在可交付增量。

在项目组合层面，讨论的是投资主题。

　　投资主题可以用来确定企业的优先投资级。

　　　　投资主题驱动项目组合愿景，而项目组合愿景则通过一系列较大的、篇章（epic）级别的倡议来表述。篇章将随时间推移而被划分到各个ART中。

在敏捷方式中，团队是实体，他们负责编写和测试所有代码，成员身兼定义/构建/测试软件特性活组建所需要的所有角色。

　　这些角色包括Scrum Master、产品负责人、几名专属的开发/测试人员以及（理想情况下）自动化测试专家，可能还有一名技术领导。

　　　　在日常工作中，敏捷团队受到的支持来自架构师、外部QA资源、文档专员、数据库专员、源代码管理（SCM）/构建/基础设施支持人员、内部IT和其他人员，这使得核心团队完全有能力定义、开发、测试并交付可工作、已测试的软件，形成系统基线。

全景图中项目集层面，发现了一些组织性的结构、角色、过程和需求工作，它们适用于构建大规模的系统、应用、产品和产品套件。

　　　　主要过程和事项概括为：发布和潜在可交付增量（PSI），愿景、特性与项目集1待办事项，制定发布计划，路线图、产品管理。

全景图的项目组合层面，顶部是项目组合管理职能，在这一层面，包括致力于根据企业商业战略管理投资的个人、团队和组织。还有两种新的工作，即投资主题和篇章，他们结合起来形成项目组合远景。