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