硝烟中的Scrum和XP读书笔记(1)

上一篇 / 下一篇  2014-05-21 13:46:02 / 个人分类:测试

第一章 引论

Scrum不是方法学,他是一个框架,也就是说Scrum不会告诉你到底应该做什么!

Scrum的强大和令人痛苦之处就在于你不得不根据自己的具体情况对它进行调整。

如果公司能保持回顾每个Sprint,那么他们就能够不断的调整,从而更好的引用Scrum。

每个成功的Scrum案例,只是一个典型的应用,不代表符合你的需求。

每个成功的Scrum都是把各种原则讨论,变成了动手去做的过程。

第二章 我们怎么去编写产品的backlog

产品的backlog是Scrum的核心,是一切的起源。

Backlog是一个requreiment,user story或者feature等组成的列表,并按照重要性进行了排序,使用的是能够被客户所能理解的术语进行描述。

Backlog一般包含了如下的基本字段:
1. ID 统一的标识符
2. Name 一个简单描述的requriement/user story/feature的名称
3. 重要性 排序的依据,之所以不用优先级是因为在同等优先级的情况下无法区分顺序。重要性是点数 10/15和50还是很容易区分的
4. 估时 初步的估时,一般都是人/天来做为单位
5. 场景 一个大致实现的步骤。 例如:登录,打开xx界面,输入xx,点击xx,在xx界面看到xx结果。
6. 注释 一些其他的信息。例如:该功能的流程图的位置 P:\\Design\features\HTO.vsd

当然,你会根据你自己的实际应用添加很多其他字段,比如Assigner,Dead Line等等。

一般Backlog不要放到版本控制中,因为它需要给所有的参与者看,修改和补充,所以它也没有一个严格的版本控制,需要大家时时的查看一下。 当然,作出修改后,提醒相关的人,留下修改历史都是有益的。

另一个常见的问题是,当一个有技术背景的人去添加一个新的需求时,使用的是技术术语,例如:给搜索添加一个返回用户名的接口

OK,这个时候,其他人员:产品,测试,客户,需求都完全没明白他要干什么去做这个任务。

所以,添加的时候要从业务角度去添加,上面那个示例实际的需求是:我搜索的结果列表中,应该列出该文章的发布者姓名。

第3章 做sprint计划前,我们需要准备点什么

有了backlog以后,就可以开始做sprint计划了。但是,还是需要有一些提前准备的任务需要去完成。

1. 你要有一个真正存在的backlog文档
2. 一个产品,只能有一个backlog文档和一个产品负责人
3. 所有的backlog的条目都已经被评过分
4. 根据评分和产品计划,进行了重新排序
5. 所有的人都看过了

对于评分,需要多说几句话:
1. 低优先级的条目,可以是一个同样的分数,例如300,意味着短期之内根本不会加入sprint计划
2. 下一个sprint要涉及的条目的分数尽可能的接近
3. 分数只是用来排序,20和200 不代表任何含义,只是为了排序方便
4. 最好分数之间有间隔,以便有紧急的需求加入,例如10和20之间很有可能加入一个15的紧急需求
5. 产品负责人必须清楚的明白这些条目对真正的需求是清楚的描述,而不是稀里糊涂的
6. 估时是开发团队的事,不要在开发接手之前,就硬加个deadline进去,除非非常特殊的时期

backlog放到哪里合适呢,现在很多人是用excel,或者Trello,不管那个,你的团队用起来顺手就行。





TAG: 敏捷

 

评分:0

我来说两句

日历

« 2024-03-27  
     12
3456789
10111213141516
17181920212223
24252627282930
31      

数据统计

  • 访问量: 148854
  • 日志数: 185
  • 文件数: 6
  • 建立时间: 2007-08-06
  • 更新时间: 2015-01-06

RSS订阅

Open Toolbar