提供客户价值而非故事点
您是否厌倦了将Scrum团队视为将用户故事转换为代码的香肠机?您的软件开发人员能否仅谈论将花费多长时间或将精确构建多少?
您是否厌倦了将Scrum团队视为将用户故事转换为代码的香肠机?您的软件开发人员能否仅谈论将花费多长时间或将精确构建多少?
《五十个改善用户故事的快速构想》是Gojko Adzic的另一本书,他是顾问兼作家,已经就敏捷需求制作了一些非常好的书,例如《影响映射》和《示例规范》。目的是帮助涉及敏捷需求的人员改善与利益相关者的讨论以及与用户案例相关的计划活动。对于初学者来说,这显然不是一本有关如何编写用户故事的书。
您是否发现用户故事不断增长和繁殖,直到您无法使其适应Scrum冲刺为止?您是否正在努力查看全局?您是否迷失在用户故事的地狱?本演示文稿检查了OOPSI(结果,输出,过程,方案,输入)技术,并通过确保您始终在做正确的事情并能看到更大的图景,演示了它如何加速交付。
在将用户故事包含在Scrum冲刺中之前,弄清并确认其接受标准很重要。近年来,许多敏捷软件开发团队一直在使用一种名为Example Mapping的简单协作技术来分解用户故事。它是黄瓜的共同创始人马特·怀恩(Matt Wynne)的构想,他撰写了介绍该实践的开创性文章。“介绍示例映射“.
用户故事可以被认为是管理敏捷中需求的最常用形式。但是,就像通常在理论上看起来很简单的敏捷概念一样,在实践中使用它们会产生许多问题:用户故事应包含哪些内容?它们何时应准备好开发?最佳积压量是多少?艾伦·凯利(Allan Kelly)在他的有趣的《关于需求和用户故事的小书》中讨论了这类问题。
许多敏捷教练都是前软件开发人员,有些则不是。但是,随着技术的发展,众所周知的敏捷方法可能会面临挑战。这样的例子就是在微服务上应用垂直故事切片的敏捷方法。这篇演讲解释了作为敏捷教练,我们如何在技术可能会继续发展的技术领域进行教练,从而挑战了帮助团队自我组织的公认教练方法。
用户故事是记录敏捷世界中用户需求的主要格式之一。但是,在开始冲刺之前,Scrum团队应该就可用的信息量进行辩论。在本文中,ZuziŠochová建议尽量减少用户故事的大小,并定义简单的满足条件,而不是编写接受标准。
版权所有©2009-2020 马丁尼& Associates