敏捷开发(项目实施)课题.ppt

软件公司敏捷开发材料（项目实施参考） 目录 敏捷简介 实施和管理敏捷项目 敏捷宣言 个体和交互 胜过 过程和工具 可以工作的软件 胜过 面面俱到的文档 客户合作 胜过 合同谈判 响应变化 胜过 遵循计划 敏捷规则 最高目标是能持续地、及早地向客户交付软件； 拥抱变化； 频繁地发布可运行的软件； 客户和开发人员在一起工作； 以人为本； 最重要的衡量开发过程的手段，是可工作的软件； 稳定的开发速度； 敏捷高效的设计； 简单有效； 重视Teamwork； 积极的调整 XP实践洋葱图 SCRUM的过程图 目录 敏捷简介 实施和管理敏捷项目 组建敏捷项目团队 敏捷项目团队由三种角色组成 1、Product Owner—由系统分析人员担任。负责收集和描述待开发产品的信息，并转换成待开发列表。解释和描述每一项任务的要求,项目开发过程中关注每个Story是否实现，解释其要求细节。 2、开发团队成员－由来自开发、测试、资料共同组成的多功能团队，负责构建产品。 3、Scrum Master－由熟悉敏捷的成员，负责帮助和指导团队按照敏捷方式操作。 除此之外，还有一个项目经理，负责整个团队的管理。 项目启动－搭建项目环境 搭建持续集成环境 敏捷项目需要维护一套唯一的持续集成环境，能够实现自动的从配置库获取代码、编译、静态检查和测试。 持续集成环境搭建，可采用ICP持续集成系统，联系软件工程部进行技术支持。 持续集成至少做到每天固定执行一次，也可根据配置库代码变化触发执行。 搭建开发环境 包含项目的编译等环境的配置等 搭建测试环境 尤其是自动化测试的环境，能够为持续集成系统调用执行 项目启动－准备及制订Product Backlog Product Owner分析待开发需求任务列表，形成产品Product Backlog，并按照商业价值排序。 Product Backlog是产品唯一的待开发任务列表（如示例），是对开发任务的初步简要描述，并附带工作量的初步估计。Backlog既可以包含新增需求、功能，也可以包含待解决的问题等（有点类似传统的AR列表） Product Backlog随项目进行，根据外部环境的变化，可能会不断调整，但是已经在迭代内实施的任务项将不受影响。 Product Backlog通常使用User Story形式分析描述。 用户故事 User Story User Story- User Story是站在外部的用户角度来描述系统所具有的功能/特性，并且此功能/特性能为客户感知。 User和Story的识别： 用户Users-使用到待开发系统的任何角色（包含人、也包含其他软件或程序），一般可以采用头脑风暴形式识别所有的Users. Story识别及描述： As a Role,I want function,so thatreason 做为一个XXX角色,我希望YYY功能，以便解决什么问题/原因 User Story通常是最小的用户感知粒度。 注意： 1、项目所有成员都可参与分析制作User Story（含开发、测试人员,资料人员也从使用资料的对象分析，形成资料User Story)，这时候并不需要太多的系统实现内部细节。 2、User Story分析结果记录在《User Story模板》中，虽然敏捷可以记录在白板、卡片等形式上，但在公司内部实施的特定环境下，用文档记录还是比较好的。 划分迭代和开工会议 敏捷计划和开工会议包含： 1、Product Owner向开发团队介绍待开发任务Product Backlog,讨论各项需求任务的目标和背景，提供所有成员深入理解需求的机会。 2、开发团队集体从Product Backlog根据优先级，选择任务，初步划分迭代，设定迭代周期（迭代周期通常是固定周期，比如1-4周都是常见的迭代周期）。划分迭代时，通常从Backlog的优先级开始，结合需要的工作量进行划分。 3、完成迭代划分后，启动第一次迭代的分析工作,分解成任务，形成本迭代的Sprint Backlog. Backlog列举任务的大小不同，可能分解为一到多个任务项Task.各Task也可以用User Story形式进行描述。这时候会涉及到部分的实现细节。 敏捷中的迭代实施过程 敏捷项目中程序员的一天 每日晨会（站立式会议） 15分钟的站立式会议，通常在早上进行。 每个成员介绍三个事情： 从上次会议结束后，完成了哪些工作？ 到下次会议前，将准备完成哪些工作？ 工作中还存在哪些障碍？ Product Owner和所有项目成员必须参与会议。 每日晨会后，项目经理负责更新每项任务的进展情况。 迭代评估和回顾会议 在每次迭代结束时，进行迭代评估，团队展示他们所构造出的产品。 参加人员：所有项目成员，以及项目的客户。 不需要准备P