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

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