敏捷开发介绍ppt课件.ppt

敏捷开发之SCRUM 2012 10 11 导航 敏捷开发的诞生历史 软件团队的不断增大效率确越来越差 概括出了一些可以让软件开发团队具有快速工作 响应变化能力的价值观和原则 并把这些价值观和原则称为敏捷开发 2001年一批业界专家 软件团队 敏捷开发的历史 我们提倡 团队价值 沟通 敏捷开发十年的发展 概念 实践 普及 为什么需要敏捷开发 软件开发面临问题 为什么需要敏捷开发 用户需求总是在变化 传统软件开发周期长 传统软件开发后续难以调整 为什么需要敏捷开发 能快速响应需求的变化 快速 频繁的交付有价值的软件 客户合作 快速交流反馈 快 敏捷开发有什么特性 为什么需要敏捷开发 敏捷开发优势 精确 质量 速度 高效的自我团队 丰厚的投资回报率 最具价值的功能总是被优先开发 这样能给客户带来最大的投资回报率 传统开发一次设计 开发周期很长 而敏捷方法则是通过短周期 设计 开发 交付 有用的软件给用户 并从用户那里得到反馈 再根据用户反馈进行下一个周期的 设计 开发 交付 敏捷开发团队成员在开发过程中都能积极主动 自我管理 每个团队成员的技术能力 交流 社交 表达和领导能力都能得以提高 开发了一年 这不是我需要的软件 不断发布版本给客户 不断提供新的需求 不断改进 传统瀑布开发模型 VS 敏捷开发 为什么需要敏捷开发 相对于 非敏捷 敏捷软件开发具有以人为本 轻载灵活 降低风险 提高质量 减少成本 效率高 见效快等优点 相关统计表明 敏捷开发可以将效率提高3 10倍 软件的质量也有更加可靠的保证 同时 还给团队内的每个成员提供了良好的发展机会 技术和合作水平都能得到相应提高 这么一大堆的优点 所以我们需要敏捷开发 XX 敏捷开发介绍 什么是SCRUM 迭代 增量 大家先弄清楚这两个词的意思 模糊 清晰 迭代 反复求精 增量 逐块构建 每次构建一点点 Scrum是一个敏捷开发框架 是一个增量的 迭代的开发过程 一个迭代开发周期 需求 完成 开发 发布 测试 计划 SCRUM基本流程 迭代 交付后客户重新调整需求 频繁交付给客户 根据客户的新需求 不断完善软件 Scrum基本元素 1 产品Backlog ProductBacklog 2 SprintBacklog3 Sprint燃尽图 SprintBurndownChart 1 产品负责人 ProductOwner 2 ScrumMaster3 Scrum团 1 Sprint计划会议 SprintPlanningMeeting 2 每日站会 DailyScrumMeeting 3 Sprint评审会议 SprintReviewMeeting 4 Sprint回顾会议 SprintRetrospectiveMeeting 三个角色 四个仪式 三个物件 Scrum由三个角色 四个仪式和三个物件 343 三个角色 Scrum角色和职责 确定产品的功能 决定发布的日期和发布内容 为产品的profitabilityoftheproduct ROI 负责 根据市场价值确定功能优先级 每个Sprint 根据需要调整功能和优先级 每个Sprint开始前调整 接受或拒绝接受开发团队的工作成果 保证团队资源完全可被利用并且全部是高产出的 保证各个角色及职责的良好协作 解决团队开发中的障碍 做为团队和外部的接口 屏蔽外界对团队成员的干扰 保证开发过程按计划进行 组织DailyScrum SprintReviewandSprintPlanning 一般情况人数在5 9个左右 团队要跨职能 包括开发人员 测试人员 用户界面设计师等 团队成员需要全职 有些情况例外 比如数据库管理员 在项目向导范围内有权利做任何事情已确保达到Sprint的目标 高度的自我组织能力 向ProductOwner演示产品功能 团队成员构成在sprint内不允许变化 项目经理 项目管理 团队 XX 迭代规划会议SprintPlan一般不超过8小时 前4个小时 产品负责人向团队展示最高优先级的产品 团队则向他询问产品Backlog的内容 目的 含义及意图 后4小时 团队计划本Sprint的安排 评审会议 外部 SprintReview一般4个小时 由团队成员向产品负责人额其他利益相关人展示Sprint周期内的产品开发情况 评审会议 内部 SprintRetrospective一般3个小时 ScrumMaster将鼓励团队在SCRUM过程框架和实践范围内 对开发过程做出修改 使它在下一个Sprint周期中更加有效和令人愉快 每日站立会议DailyScrumMeeting在简会上 每个成员主要回答三个问题 自上次SCRUM简会后的一天了 昨天 你做了什么 从现在到下次SCRUM简会的一天里 今天 你要做什么 在实现SCRUM及项目目标的工作中 你遇到哪些困难吗 开发团队 一个迭代周期 需求转化成任务 每日开发 完成一个迭代周期 四个会议 仪式 回顾会议 团队的定期自我检视 发现什么是好的 什么是不好的 一般控制在15 30分钟 每个Sprint都要做 全体参加Sprint回顾会议上 全体成员讨论有哪些好的做法可以启动 哪些不好的做法不能再继续下去了 哪些好的做法要继续发扬 XX 三个物件 Scrum物件之产品Backlog 一般情况使用用户故事来表示backlog条目 理想情况每个需求项都对产品的客户或用户有价值 Backlog条目按照商业价值排列优先级 优先级由产品负责人来排列 在每个Sprint结束的时候要更新优先级的排列 一个需求的列表 三个物件 Scrum物件之SprintBacklog Sprintbacklog定义了Sprint的目标 明确了Sprint过程中具体需要完成的任务 三个物件 Scrum物件之SprintBacklog 如何管理sprintBacklog 团队成员自己挑选任务 而不是指派任务 对每一个任务 每天要更新剩余的工作量估算 每个团队成员都可以修改Sprintbacklog 增加 删除或者修改任务 三个物件 Scrum物件之燃尽图 随着时间的消耗工作量逐渐减少 在开始的时候 由于估算上的误差或者遗漏工作量有可能呈上升态势 燃尽图直观的反映了Sprint过程中 剩余的工作量情况 腾讯企鹅帝国的敏捷开发 敏捷测试 我是开发 我是测试 敏捷开发正快速跑步前进中 我们测试从头到尾一直参与 设计文档转换成用例 开发中 全面测试重点测试 开发用例编写者一起讨论完善功能测试点 完成诺干个功能点 测试用例 设计文档 自由测试 敏捷测试工程师的十条法则 需求转换成测试 完成测试提供有意义的反馈 对会影响核心功能的花俏功能 可以质疑这些功能影响大局 优先关注核心功能 敏捷测试人员对某个隐藏的假设或者误解的需求产生怀疑时 她会与客户和开发人员讨论 1 提供持续反馈 2 为用户创造价值 3 促进面对面的沟通 敏捷测试工程师的十条法则 我们需要勇气允许自己失败 至少我们会短暂失败 并从中学习教训 在由于构建版本不稳定导致一次迭代失败之后 我们开始寻找方法以确保这种事情不再发生 找到合适的方法 简单的方法进行测试 反馈问题给团队 问题持续解决 4 勇气 5 简单化 6 持续改进 敏捷测试工程师的十条法则 敏捷开发项目在持续开发 持续变化 测试也在持续不停进行 多学习