|
|
5 回复 | 直到 12 年前
|
1
1
我想我知道你在找什么,但如果我弄错了,请随时澄清。我觉得你在找一个能显示团队在使用用户故事时实现细节的灵活性的练习。 如果是这样,尝试这样的练习。 将团队分成两个组,并在两个组之间拥有相同的产品所有者(或者,如果两个采购订单都知道练习,您可以为每个组拥有一个产品所有者)。 PO提出了一个虚构的故事,比如“作为BigSaleCo的一名高管,我希望能够一目了然地看到哪些销售人员在表演,而哪些不是,这样我就可以将表演者与表现不佳的人配对,以提高整体团队绩效。” 像上面这样的一个故事很容易理解实现细节,但是有一个非常清晰的业务问题需要解决(正如用户故事应该解决的那样)。使用这样一个故事,给团队30分钟的时间来制作一个能够满足用户故事的纸质原型。在此时间段内,他们可以与采购订单进行任意交互。执行采购订单的人应该小心,不要向他们提供实施细节,而是让团队决定,同时表达和澄清业务需求。 在30分钟结束时,让每个团队展示他们的解决方案,并解释它如何满足用户的故事。 这里重要的是,一旦两个团队都进行了演示,很可能两个演示会完全不同,但都是有效的。这表明了团队必须提供他们认为是最佳解决方案的灵活性,而无需明确告诉他们要做什么。 希望这有帮助。 |
|
|
2
2
我不认为由团队来定义一个故事的范围和复杂性。定义验收条件是采购订单的工作,然后根据采购订单的描述估计规模是团队的工作。如果故事的大小合适,那么条件通常是非常严格的。这可能就是为什么你看不到太多东西的原因…… 编辑 : 我认为你的例子不会改变我的答案。如果采购订单想要这个“附加功能”,比如排序等,他们会在故事或另一个故事中定义它。建造不需要的东西是浪费。将时间花在积压工作中优先级较低的故事上效率很低。敏捷是建立在所需要的基础上的,并且只建立在重要性顺序所需要的基础上。因此,我不赞成开发人员仅仅因为在特定的屏幕上工作而添加“额外的好东西”。 这并不意味着你不应该查看积压工作中的所有故事,并根据将来需要的内容制定架构计划。 |
|
|
3
0
为了估计故事成本,团队将期望与采购订单合作,至少从广义上定义该功能的需求。在您给出的示例中,团队可以明确地询问采购订单是否需要排序和分组功能。如果他们说不,因为采购订单在那个阶段看不到它的用途,那么就在这个基础上给出估计值,并根据这个估计值执行。在雅格尼原理中,没有考虑这些附加特性。如果排序和分组的需求随后是由于人们使用了产品的早期版本而产生的,那么,这是另一个情况,并且会相应地被估计和安排到积压工作中。一个故事的实现范围不会仅仅因为你在迭代中还有一些时间而改变——相反,你只需要从积压工作中抽出下一个优先项目并继续进行。 当然,在实现这个故事时,团队可以自由地使用他们认为最适合不断发展的产品的时间/成本效益最高的方法。如果这意味着使用具有附加功能的组件,即功能的超集,那么只要通过验收标准,他们就可以这样做(除非这违反了非功能性需求),但他们不应该故意添加未请求的功能,因为他们在迭代中有一些空闲时间。 |
|
|
4
0
我的观点介于你描述的适应时代的特征,剩下的,和其他两位评论员的“仅仅满足验收标准,就这样”之间…… 在我看来,你们都应该回忆起用户故事的正式设置:
考虑到所需功能的目的,开发人员可以更好地理解采购订单真正想要什么。然后他可以提出其他想法并询问采购订单,例如:
采购订单可能会同意并执行该故事。 如上所述 但在另一种解释中,或者故事可能被改编。对我来说很重要的几点:
我希望你能和我分享我的观点;—) |
|
|
5
0
一个好的训练练习和一个有趣的团队建设练习是做 XP Planning game . 前提是产品所有者提供了对视觉效果的要求(如咖啡机、机器人),并且所有的要求都必须是可绘制的。开发人员必须绘制需求。 有几个简短的迭代(整个练习需要一个小时到90分钟,这取决于设置时间),并且有趣的是,随着游戏的进行,交流是如何改进和权衡的。我自己在项目启动和将团队转化为敏捷实践的过程中也做过这样的工作,并且团队始终发现这很有用,也很有趣。 |
