敏捷开发——硝烟中的Scrum和XP

第二章 我们怎样编写产品backlog

  • backlog包括:ID、名称、重要性、初始估算、如何演示、注解(额外的故事字段:类别、组件、请求者、Bug跟踪ID)

产品Backlog(示例)

ID名称重要性初始估算如何演示注解
1存款305登录,打开存款界面,存入10欧元.需要UML顺序图。目前不需要考虑加密。
  • backlog停留在业务层次上

    开发团队:如何解决问题;

    产品负责人:关注业务目标;

    示例:

    故事——“给Events表添加索引”[错误,可以加进注解],目标也许是“提高在后台系统中搜索时间表单的响应速度”[正确]。

第三章 我们怎样准备sprint计划

确保backlog井然有序(产品的backlog必须存在)

标准

  • 只能有一个产品的backlog和一个产品负责人
  • 所有重要的backlog都根据重要性被评过分
  • 产品负责人理解每个故事的含义
  • 使用Jira(Bug跟踪系统)存放产品backlog
  • 使用VersionOne、ScrumWroks这种敏捷过程工具

第四章 我们怎样制定sprint计划

计划会议产生的效果:

  • sprint目标
  • 团队成员名单
  • sprint backlog
  • 确定好sprint演示日期
  • 确定每日Scrum会议的时间和地点

每个故事有三个变量:范围(包含哪些故事)、重要性、估算

产品负责人必须参加

产品负责人设置:范围和重要性

团队设置:估算

不能在质量上让步

如果sprint会议超出了计划时间,直接打断会议。

sprint会议日程

  • 13:00——17:00(每小时休息10分钟)
  • 13:00——13:30 产品负责人对sprint目标进行总体介绍,概括产品backlog
  • 13:30——15:00 团队估算时间,必要时可以拆分backlog
  • 15:00——16:00 团队选择放入sprint的故事
  • 16:00——17:00 为每日scrum会议安排固定时间和地点

确定sprint长度,3周不错

确定sprint目标,可以在wiki上列出来,方便大让所有人都知道我们在干什么

产品负责人可以通过更改backlog的重要性来影响sprint

通过估算生产率来决定把哪些故事放到sprint里面

明确故事内容

把故事拆分成任务:

  • sprint计划会议要足够长,保证有时间进行任务拆分

定下每日例会的时间地点 ?讨论什么,多长时间

  • 技术故事

第5章 我们怎样让别人了解我们的sprint

第6章 我们怎样编写sprint backlog

燃尽图

  • y轴故事数量
  • x轴时间

当每日的点连到一起的曲线在x轴y轴的斜线之上,表示放到sprint中的故事多了。反正表示少了。

第7章 我们怎样布置团队房间

让团队坐到一起

第8章 我们怎样进行每日例会

  • 不超过15分钟
  • 更新任务版
  • 处理迟到的家伙
  • 处理不知道干什么的家伙

第9章 我们怎样进行sprint演示

  • 必须做
  • 团队成果得到认可
  • 得到重要反馈
  • 讨论
  • 迫使去完成一些真正的工作
  • 确保清晰阐述sprint目标
  • 节奏要快
  • 关注业务层次

第10张 我们怎样做sprint回顾

  • 1到3小时
  • 哪些做得好
  • 哪些可以做的更好
  • 那些需要改进

在团队间传播经验

第11章 sprint之间的休整时刻

最好的安排

周四周五周六周日周一
09-10:Sprint 1 demo实验日9-13:Sprint 1 demo

第12章 怎样制定发布计划,处理固定价格的合同

  • 定义你的验收标准
  • 对重要的条目进行时间估算
  • 估算生产率
  • 统计一切因素,生成发布计划
  • 调整发布计划

第13章 我们怎样结合使用Scrum和XP

  • 结对编程
  • 测试驱动开发
  • 增量设计:一开始保持设计简化,不断改进
  • 持续集成:每天晚上,持续构建服务器都会从头构建产品,并且向我们的内部文档门户上发布二进制文件、文档、测试报告、测试覆盖率报告和依赖性分析等等
  • 集体代码所有权
  • 代码标准
  • 充满信息的工作空间:需要里有个人管理任务版和“怎样布置团队空间”
  • 可持续的开发速度/精力充沛地工作:正常上下班

第14章 我们怎样做测试

  • 把验收测试阶段缩到最短
    • 提高代码质量
    • 提高测试效率
    • 把测试人员放到Scrum中(除了测试还要做,搭建测试环境、明确需求等等)
    • 减少sprint工作

别把最慢的一环逼得太紧(开发、测试等)

第15章 我们怎样管理多个Scrum团队

  • 创建多少个团队
    • 分拆成彼此不干扰的小团队
    • 宁可团队数量少,人数多
  • 最佳的团队规模
    • 3到8个人最佳,人多把最差的排除
  • 几个团队做一个sprint
  • 团队中分配人手:指定一个人分配和团队自己决定

第16章 我们怎样管理分布式团队

  • 能够一起结对编程
  • 能够在每日例会上面对面交流
  • 在任何时候都能够面对面讨论
  • 可以真正的碰面与交往
  • 整个团队可以主动举行会议
  • 团队对sprint backlog、sprint燃尽图、产品backlog和其他信息传递设备有相同的理解

第17章 ScrumMaster检查列表

  • sprint开始阶段
    • sprint计划会议之后,创建sprint信息页面
    • 给每个人发邮件,声明新的sprint启动
    • 更新sprint数据文档:估算生产率、团队大小和sprint长度
  • 每一天
    • 确保每日scrum会议可以按时开始结束
    • 为了保证sprint可以如期完成,适当的增删故事
    • 团队了解backlog和燃尽图
    • 确保存在的问题和障碍都能被解决。
  • 在sprint结束时
    • 开放式sprint演示
    • 演示前一天告知所有人
    • 整个团队一起开sprint回顾会议
    • 更新sprint数据文档
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值