下面是一个合适的规则集：
任何针对优先级最高的故事开发的人都是“国王”。
团队其他的任何人都是“仆人”。
要是你想成为“国王”，就试着找路子帮助完成最高优先级故事的相关工作吧。
“国王”任何时候需要帮助，“仆人”就必须马上提供相应的服务。
“仆人”不能打扰“国王”的工作。
“仆人”不能向工作分支中检入不可发布的代码。“国王”可以检入任何他想要检入的东西（当然，只要他不违反分支方针即可）。
目前优先级最高的故事一“完成”，任何开始下一个最高优先级的团队成员就成为了“国王”。
你甚至还能为团队争取到一些王冠饰品呢。
总体来说，很多团队都会过高评价同时实现多个用户故事的效果。这样做从开发速度上说感觉好像不错，但却只是一个幻象；因为它将有风险和消耗实践的编码工作推到了最后——包括合并、集成与测试等工作。
这就是Scrum团队应该保持小规模的原因（少于9个人）——这样他们就可以紧密协作而且将注意力集中于自己的工作成果之上。如果任何人都在独立开发自己负责的用户故事，那大概就不会有多少协作的情形发生了。当然可以有人为将来做计划，为下一个故事做准备并做一些实现工作。但是在任何时候，团队的主要工作努力都要放在优先级最高的故事上。
多个团队就是不同的情况了。如果很想并行实现多个故事，那就不妨创建多个团队。我们不久后就会看到如何具体操作。首先我想讨论下关于回归测试，以及分叉代码的相关话题。
此文章共有2页 上一页 1 2
文章来源：中国项目管理资源网
|
Leadge.com首页 > 知识库 
