zc_888
- 浏览: 19858 次
- 性别:
- 来自: 苏州
-
最新评论
文章列表
例会应该控制在10分钟以内，做到这一点，只需在例会中问三个问题：
1.昨天做了什么？
2.今天计划做什么？
3.有什么困难或是否需要他人协助？
例会中除了以上三个问题外，scrum master还要做如下的事情：
1.更新任务板（根据以上三个问题）2.处理迟到的家伙3.处理“我不知道今天干什么”的情况
2和3没有固定的答案，可以根据团队的实际情况进行制定，比如2可以罚款，3可以增加任务或安排结对编程等等。
- 2009-11-16 18:29
- 浏览 180
- 评论(0)
1.怎样布置团队房间？
最好独立，封闭，不受外界干扰，总之要使团队感到舒服。
任务板：每日进行更新
设计板：用于团队讨论设计流程
2.团队为何要坐在一起？
便于交流，交流很重要。
“一起”意味着：• 互相听到 ...
- 2009-11-16 18:16
- 浏览 263
- 评论(0)
任务板分为四列：
第一列：尚未开始的backlog及其任务，每个任务要有预估并制定负责人；
第二列：已经开始的backlog及其任务；
第三列：已经完成的backlog及其任务；
第四列：燃尽图和未计划任务及可编入任务。
未计划任务：在计划中没有包含的任务，有可能是在分解backlog时没有分解完全，也有可能是一些突发任务，亦或是技术任务。这部分在做回顾时要重点讨论发生的原因，因为它有可能毁掉这次sprint，总之，这部分任务越少越好。
可编入任务：如果在sprint周期结束前就完成的所有的backlog，可以新编入计划的backlog及其任务。
燃尽图：
...
- 2009-11-15 21:36
- 浏览 283
- 评论(0)
我们怎样让别人了解我们的sprint呢？
我们要让整个公司了解我们在做些什么，这件事情至关重要。否则其他人就会发出抱怨，甚或对我们的工作做出臆断。
可以使用wiki记录下当前的sprint信息，然后使用邮件告知相关人员。
sprint信息应该至少包含如下信息:
- 2009-11-15 20:43
- 浏览 200
- 评论(0)
我们采用jira来做bug跟踪系统，同时会将backlog与拆分的任务维护在jira上。
我们每一次sprint都会经历需求确认，开发，测试，部署上线的完整流程。
如果在到达发布日期时仍有没有修复的bug该如何处理呢？
一般来说应该对每一个bug进行分析，如果不属于严重bug，则可以结束当前的sprint，
否则当前的sprint宣告失败，需要重新进行评估。
如果在下一次sprint中包含bug，则应该在进行计划时由项目负责人对bug进行评级，由他挑选出优先级高的bug，放到这次的sprint backlog中。
有一些方法供尝试：
1) 产品负责人打印出Jir ...
- 2009-11-15 20:02
- 浏览 187
- 评论(0)
技术故事：或者叫做非功能性条目，或者你想叫它什么都行。
是需要完成但又不属于可交付物的东西，跟任何故事都没有直接关联，不会给产品负责人带来直接的价值。
比如系统的公共组件，代码重构等等，这些并不能给项目负责人带来之际的可交付物，但会对项目的稳定性和提高效率有很大的作用，
这些技术故事往往容易被项目负责人所忽视，因为他们更注重实际上看得到摸得着的东西。
作为一个技术经理，必须要保证系统的开发效率和稳定性，那么，该如何让项目负责人同意在sprint中加入技术故事呢？
1) 试着避免技术故事。努力找到一种方式，把技术故事变成可以衡量业务价值的普通故事。这样有助于产品负责人做出 ...
- 2009-11-15 19:06
- 浏览 271
- 评论(0)
优先级1：sprint目标和演示日期。
这是启动sprint最起码应该有的东西。团队有一个目标，一个结束日期，然后就可以马上根据产品backlog开始工作。没错，这是不像话，你应该认真考虑一下明天再开个新的sprint 计划会议。不过如果确实需要马上启动sprint，不妨先这么着吧。认真说来，只有这么点儿信息就开始sprint，我还从来没有试过。
优先级2：经过团队认可、要添加到这个sprint中的故事列表。
优先级3：Sprint中每个故事的估算值。
优先级4：Sprint中每个故事的“如何演示”。
优先级5：生产率和资源计算，用作sprint计划的现实核查。包括团队成员的名单及 ...
- 2009-11-15 15:39
- 浏览 513
- 评论(0)
“任务”和“故事”的区别是什么呢？嗯，这个问题问得不错。
区别很简单。故事是可以交付的东西，是产品负责人所关心的。任务是不可交付的东西，产品负责人对它也不关心。
故事如果太大就应该进行拆分，力求保证故事的大小在2至8个人-天之间。否则不好控制。
例子：
故事拆分为多个故事
故事拆分为任务
我们会看到一些很有趣的现象：• 新组建的Scrum团队不愿意花时间来预先把故事拆分成任务。有些人觉得这像是瀑布式的做法。• 有些故事，大家都理解得很清楚，那么预先拆分还是随后拆分都一样简单。• 这种类型的拆分常常可以发现一些会导致时间估算增加的工作，最后得出的sp ...
- 2009-11-15 15:27
- 浏览 519
- 评论(0)
在明确故事内容时一定要向产品负责人如何进行演示，因为这很可能会决定你开发的方式，也间接的影响到了你对故事的时间估算。
例1：团队和产品负责人都对sprint计划很满意，打算结束会议。这时Scrum master问了一个问题，“等一下，还有个‘添加用户’的故事没有估算时间呢，把它解决了吧！”几轮计划纸牌以后，团队意见达成一致，认为这个故事需要20个故事点；产品负责人却站了起来，说话因为生气也走了调：“什、什、什么？！”经过几分钟的激烈争吵，最后发现是团队错误理解了“增加用户”这个故事的范围，他们以为这表示“要有个漂亮的web界面来添加、删除、移除和查询用户”，但是产品负责人只是想“通过手写S ...
- 2009-11-15 15:18
- 浏览 206
- 评论(0)
单独用一篇文章介绍足以说明它的重要性。
一定要在完成sprint计划会议前定义好每个故事的完成含义，并在项目团队中达成共识。
比如说测试通过，或者部署上线，总之要有一个完成的定义。
- 2009-11-15 14:52
- 浏览 205
- 评论(0)
在大多数sprint 计划会议上，大家都会讨论产品 backlog中的故事细节。对故事进行估算、重定优先级、进一步确认细节、拆分，等等都会在会议上完成。
那么该如何实际操作呢？
推荐使用索引卡，把它们贴在墙上或摆放在桌子上。示例如下：
这种用户体验比计算机和投影仪好得多。原因是：
- 2009-11-15 14:06
- 浏览 213
- 评论(0)
1.一般来说使用故事点（story points）来作为估算的依据，一个故事点就是一个理想的人/天；
2.由开发团队对每个backlog条目进行预估，比如backlogA需要3个story points，backlogB需要4个story points，等等；
3.由项目负责人制定每个backlog的优先级，并排序；
4.由开发团队从中选择能够完成的backlog加入到sprint backlog中；
5.开发团队选择的方式可以使用“直觉估算”或“用生产率计算来估算”
用生产率计算来估算这项技术包括两步：1. 得出估算生产率2. 计算在不超出估算生产率的情况下可以加入多少故事。生产 ...
- 2009-11-14 17:52
- 浏览 182
- 评论(0)
出于某些原因，制定sprint目标确实很困难。
但我发现即使是像挤牙膏一样把它挤出来，那也是值得的。半死不活的目标也比啥都没有强。
这个目标可以是“挣更多的钱”，或者“完成优先级排到最前面的三个故事”，或“打动CEO”，或“把系统做的足够好，可以作为beta版发布给真正的用户使用”，或“添加基本的后台系统支持”等等。
它必须用业务术语表达，而不是技术词汇，让团队以外的人也能够理解。
Sprint目标需要回答这个根本的问题，“我们为什么要进行这个sprint？为什么我们不直接放假算了？”要想从产品负责人的口中哄骗出sprint目标，你不妨一字不差的问他这个问题看看。
- 2009-11-14 17:31
- 浏览 168
- 评论(0)