敏捷开发Scrum

Initial estimate(初始估算

为了便于产品负责人判断优先级别，我们也会在产品当前故事的大致分类，例如Requestor(请求者计划会议成果：

范围质量分为内部质量和外部质量

是系统用户可以感知的。运行缓慢、让人迷糊的用户界面就属于外部质量低劣。

指用户开不到的要素，它们对系统的可维护性有深远影响。可维护性有深远影响。可维护性包括系统设计的一致性、测试覆盖率、代码可读性和重构等等。

一般来说，系统内部质量优秀，外部质量仍有可能很差。而内部质量差的系统，外部质量肯定也不怎么样。牺牲内部质量是一个糟糕透顶的想法。现在节省下来一点时间，接下来的日子里你就要一直为它付出代价。一旦我们放松要求，允许代码库中暗藏问题，后面就很难恢复质量了。

用生产率计算来估算：

下图中，左边是投入程度生产率计算：

大家站起来四处走动多个故事可以同时编辑。

挪动索引卡就行。

把需求拆分成任务后，时间估算就变得更容易不要让任务拆分出现在产品产品负责人不需要关心这种程度的细节。

使用计划纸牌做时间估算

通常每个成员都会参与所有需求的估算。为啥要每个人都参加/p>

重要的是，我们必须提醒团队成员，他们要对这个故事中所包含的全部工作进行估算。而不是或者我一点概念都没有，没想法。我太累了，先歇会吧把需求拆分成任务

需求拆分成更小的需求

需求拆分成任务

最后界限在哪里

 

燃尽图

 

让团队坐在一起：

产品负责人应该离团队很近，既方便团队成员走过来讨论问题，他也能随时踱到任务版前面去。但是他不应该跟团队坐在一起。为什么为这样他就无法控制自己不去关注具体细节，团队也无法怎样更新任务版

无论

怎样进行

回顾组织：

向大家展示定义你的验收标准

除了普通的产品统计一切因素，生成发布计划

有了时间估算和生产率，可以很容易的把产品调整发布计划

每个

组合使用Scrum来源：benxiaohai529

声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！