软件项目管理与案例分析第3章.pptVIP

所示的增量模型表明，必须在开始实现各个构件之前就全部完成需求分析、规格说明和概要设计的工作。由于在开始构建第一个构件之前已经有了总体设计，因此风险较小 描绘了一种风险更大的增量模型：一旦确定了用户需求之后，就着手拟定第一个构件的规格说明文档，完成后规格说明组将转向第二个构件的规格说明，与此同时设计组开始设计第一个构件……用这种方式开发软件，不同的构件将并行地构建，因此有可能加快工程进度。但是，使用这种方法将冒构件无法集成到一起的风险，除非密切地监控整个开发过程，否则整个工程可能毁于一旦。 探索阶段 探索阶段的主要工作是开发初始的用户故事（User Stories ）和体系结构骨架（architecture spike）。 用户故事描述了系统高层的需求，它是制订发布计划的输入。 在探索阶段，试探找到系统中固定不变的部分（体系结构骨架），并找出一种形象的比喻，这种比喻描述了你打算如何构建系统，起到概念框架的作用。 探索阶段还应根据用户故事编制相应的测试用例，供以后验收测试时使用。 计划阶段 计划阶段的任务是根据用户故事描述的需求、系统体系结构骨架和系统比喻来制订迭代计划和发布计划。 使用你最熟悉的形式为用户故事建模，这个模型描述了用户故事的任务以及这些任务之间的关系。 通常图形方式（可以是草图）比文字描述更直观。 尽可能精确地估算工作量，这是制订计划的重要依据。对于那些不能确切估算其工作量的难点部分，要进一步作分析，直至能确定其工作量估算。 迭代到发布阶段 迭代到发布阶段根据迭代和发布计划，开发满足指定用户故事需求的软件，并与前面已完成的软件版本集成，得到软件的一个新版本。 根据在探索阶段编写的测试用例，进行验收测试。一旦发现错误或者通过验收测试想进入下一轮迭代时，就重复迭代开发的工作。 在这一阶段当客户提出新的用户故事，或者根据项目的进展情况认为有必要时，可以回到计划阶段，对迭代和发布计划做出修改或调整。 产品化阶段 产品化阶段的工作主要是确认迭代开发的软件已经做好进入产品化的准备。 在此阶段可进行更多的测试，如系统测试、负载测试、安装测试等。 另一个工作就是整理文档。虽然敏捷软件开发的价值观中强调“可运行软件高于详尽的文档”，但是，必要的文档仍是需要的。 可能要写的文档： 系统文档 系统文档的目的在于为系统提供一个总览，来帮助人们理解它。主要包括：系统技术体系结构和业务体系结构的总览、高层次的系统需求、关键设计决策的总结、体系结构图以及重要的设计模型（如果有的话）等。 操作文档 操作文档的内容包括：系统涉及的依赖关系，与其他系统、数据库以及文件文互的特性，对备份流程的参考引用，系统的联系人列表以及联系方法，系统的适用性及可靠性需求的总结，系统预期负载情况概况，以及排错指导原则。 支持文档 支持文档的内容包括：支持人员专用的培训教材，解决问题时作为参考的用户文档，排错指导原则，解决疑难问题时的上报流程，以及维护团队的联系列表。 用户文档 参考手册用于快速查询；用户指南用于指明系统的工作方式；支持指南用于指导如何获取其他的帮助；培训资料则主要用于培训。 维护阶段 维护阶段涵盖了计划阶段、迭代到发布阶段和产品化阶段 通常这个阶段主要包括面向产品的活动，如系统的运行和支持。 交流（Communication） 实践表明，项目失败的重要原因之一是交流不畅，使得客户的需求不能准确地传递给开发人员，造成开发人员不能充分理解需求；模型或设计的变动未能及时告知相关人员，造成系统的不一致和集成的困难 所有项目相关人员之间充分的有效的交流是软件开发成功所必不可少的 XP方法提倡面对面的交流，这是一种有效的也是效率最高的交流方式 简单（Simplicity） 指在确保得到客户满意的软件的前提下，做最简洁的工作（简单的过程、模型、文档、设计和实现） 在开发中不断优化设计，时刻保持代码简洁、无冗余 体现了敏捷开发的“刚刚好(Just enough)”思想，即开发中的活动及制品既不要太多也不要太少，刚好即可 反馈（Feedback） 及时有效的反馈能确定开发工作是否正确，及时发现开发工作的偏差并加以纠正。 强调各种形式的反馈，如非正式的评审（走查，Walkthrough）、小发布等 进取 信任合作的同事，也相信自己 做能做到的最简单的事 只有在绝对需要的时候才创建文档 让业务人员制定业务决策，技术人员制定技术决策 用可能的最简单的工具，例如白板和纸，只有在复杂建模工具能提供可能的最好价值时才去使用它们 相信程序员能制定设计决策，不需要给他们提供过多的细节 需要勇气来承认自己是会犯错误的，需要勇气来相信自己明天能克服明天出现的问题。 XP方法的12个核心实践 1.完整的团队（Whole Team） 所有的小组成