当前位置:  开发笔记 > 程序员 > 正文

关于Scrum的两个问题

如何解决《关于Scrum的两个问题》经验,为你挑选了0个好方法。

我有两个关于Scrum的相关问题.

我们公司正在努力实施它,并确定我们正在跳过篮球.

这两个问题都是关于"完成手段完成!"

1)很容易为任务定义"完成" - 明确的测试验收标准 - 完全独立 - 最后由测试人员测试

应该如何完成以下任务: - 架构设计 - 重构 - 一些实用程序类开发

它的主要问题是,它几乎完全是内部实体,无法从外部检查/测试它.

作为示例,功能实现是一种二进制 - 它已完成(并通过所有测试用例)或未完成(不通过一些测试用例).

我想到的最好的事情是要求另一位开发人员审查该任务.但是,它的任何方式都没有提供一个明确的方法来确定它是否完全完成.

那么,问题是你如何为这些内部任务定义"完成"?

2)调试/错误修复任务

我知道敏捷方法不建议做大任务.至少如果任务很大,它应该分成较小的任务.

假设我们有一些相当大的问题 - 一些大模块重新设计(用新的替换新的过时架构).当然,这项任务分为几十个小任务.但是,我知道最后我们将有相当长的调试/修复会话.

我知道这通常是瀑布模型的问题.但是,我认为很难摆脱它(特别是对于相当大的变化).

我应该为调试/修复/系统集成等分配特殊任务吗?

在这种情况下,如果我这样做,通常这个任务与其他一切相比都是巨大的,并且很难将它划分为较小的任务.

我不喜欢这种方式,因为这个庞大的巨型任务.

还有另一种方式.我可以创建较小的任务(与bug相关联),将它们放在积压中,确定优先级并在活动结束时将它们添加到迭代中,然后我将知道错误是什么.

我不喜欢这种方式,因为在这种情况下,整个估计将变成假的.我们估计任务,标记它随时要求完成.我们将使用新估计打开bug的新任务.因此,我们最终会得到实际时间=估计时间,这绝对不是好事.

你怎么解决这个问题?

此致,Victor

推荐阅读
echo7111436
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有