经验分享---敏捷开发流程.ppt

敏捷开发流程介绍 目录 什么是软件开发方法什么是敏捷开发方法我们该采用什么方法 什么是软件开发方法 软件开发定义根据用户需求建造出软件系统的产品开发过程 包括需求获取 开发规划 需求分析和设计 编程实现 软件测试 版本控制 维基百科 常见种类瀑布式开发迭代式开发敏捷式开发 瀑布式开发 最典型的预见性方法 严格遵循预先计划按照需求分析 设计 编码 集成 测试 维护的步骤顺序进行 步骤成果用以衡量进度 例如需求规格 设计文档 测试计划等 方便定义里程碑主要问题是严格分级导致自由度降低 早期承诺导致对后期需求变化难以调整 代价高昂 迭代式开发 弥补传统开发方式的一些弱点 具有更高的成功率和生产率开发被分为一系列的小的 固定长度的小项目 称为一系列的迭代 每次都包括需求分析 设计 实现与测试 开发工作可在需求被完全确定前启动 并在一次迭代中完成部分功能 再通过客户反馈来细化需求 开始新一轮迭代 Agilesoftwaredevelopment 什么是敏捷开发方法 主要原则 个体和互动 高于流程和工具工作的软件 高于详尽的文档客户合作 高于合同谈判响应变化 高于遵循计划 vs迭代 都强调在短的开发周期提交软件 敏捷的周期可能更短 更强调人的高度协作 vs瀑布 敏捷强调尽早将小的可用功能交付使用 在项目周期中持续改善 自由度高 主要方法 极限编程测试驱动开发Scrum机制看板文化 极限编程 Extremeprogramming 缩写为XP 强调可适应性而不是可预测性认为软件需求变化是自然现象在项目周期的任何阶段去适应变化 降低因需求变更而带来的成本 快速反馈 对客户反馈做到及时 迅速 重视单元测试假设简单 认为任何问题都可以 极度简单 地解决 拒绝预测需求 拒绝为了未来而考虑重用增量变化 一次完成大的改造是不可能的 采用增量变化 小步前进包容变化 强调不反抗变化 应该包容变化 测试驱动开发 Test DrivenDevelopment 简称TDD 它要求在编写代码之前先写测试代码 只编写使测试通过的功能代码 通过测试来推动整个开发的进行 编写简洁可用和高质量的代码 并加速开发过程 FDD DDD 根据客户需求编写测试用例 从使用者角度设计代码易测试和测试独立性的要求使设计松耦合频繁地运行测试 尽早地发现错误 提高代码质量持续的回归测试 持续地跟踪整个系统的状态单元测试代码可作为文档 展示所有的API该如何使用和运作 主要角色 ScrumMaster Scrum教练和团队带头人 确保团队合理的运作Scrum产品负责人 ProductOwner 确定产品方向 定义产品内容 优先级及交付时间开发团队 Team 跨职能的小团队 5 9人 拥有交付软件需要的各种技能 一种迭代式增量软件开发过程 包括了一系列实践和预定义角色的过程骨架 通常用于敏捷软件开发 英语是橄榄球中争球的意思 Scrum Scrum过程总览 Scrum阶段1 制定产品Backlog 产品backlog是Scrum的核心由需求或特性等组成的列表用客户的术语加以描述按照重要性的级别进行排序backlog条目称为故事 story 每个故事包括如下字段 ID 统一标识符 Name 名称 Importance 重要性 Initialestimate 初始估算工作量 Howtodemo 如何做演示 Notes 注解 BugtrackingID Bug跟踪ID 独立基本相当于一个feature对客户有价值易于评估时间和难度不易太大或太小可测试 Story的准则 Value Risk Low High High 优先级评估 工作量的估算 最小单位为一个故事点 storypoint 相当于一个理想的人天投入最适合的人员 完全没有打扰 需要几天给出一个经过验证 可以交付的完整实现不需要绝对无误 保证相对准确 即 两个点的时间应该是四个点的一半 估算全部工作 而不只是自己的部分把故事分拆成更小的故事以达到更精确最小值是0 5 太小的任务要么被移除 要么就给0 5 Scrum阶段2 制定SprintBacklog sprint目标团队成员名单 以及投入程度 确定sprintbacklog 即故事列表 确定好sprint演示日期确定每日scrum会议时间地点协商sprint的时间长度 召开Sprint会议 Sprint计划会议 13 00 17 00 每小时休息10分钟 13 00 13 30产品负责人对sprint目标进行总体介绍 概括产品backlog 定下演示的时间地点 13 30 15 00团队估算时间 在必要的情况下拆分backlog条目 产品负责人在必要时修改重要性评分 理清每个条目的含义 所有重要性高的backlog条目都要填写 如何演示 15 00 16 00团队选择要放入sprint中的故事 计算生产率 用作核查工作安排的基础 16 00 17 00为每日scrum会议安排固定的时间地点 把故事进一步拆分成任务 确定Sprint生产力 如果没有参考怎么办 随便猜一个 只会在第一个sprint里面使用 以后有了历史数据然后做改进 新团队中使用的 默认 投入程度通常是70 大多数团队都能达到的数值 Scrum阶段3 每天站会 看板和站会 用户体验比投影仪好 大家保持清醒 并留心会议进展 更多的参与感多个故事可以同时编辑重新划分优先级变得易如反掌 挪动索引卡就行互相看到 所有人都可以看到彼此 都能看到任务板例会结束时算出剩余工作量之和 在sprint燃尽图上画上一个新的点处理迟到 惩罚机制 看板 燃尽图 Scrum阶段4 Sprint演示 清晰阐述sprint目标不要花太多时间准备演示 集中精力演示实际工作的代码节奏要快 保持演示的快节奏关注业务层次 不要管技术细节 注意力放在 我们做了什么 而不是 我们怎么做的 可能的话 让观众自己试一下产品不要演示一大堆细碎的bug修复和微不足道的特性 Scrum阶段5 Sprint总结 设定时间为1至3个小时参与者 产品负责人 整个团队向大家展示sprintbacklog 对sprint做总结每个人轮流发言 讲出自己的想法 什么是好的