在我们公司,我们在每个Sprint结束时进行可用性测试.很多时候我们发现用户不喜欢已实现的功能,因此我们要么完全更改它,要么在下一个Sprint中将其废弃.
但是,如果我们开始做可能的可交付产品,从而修复所有错误,运行大量测试,为FDA和用户准备文档,修复很少的UI问题 - 如果用户不喜欢这个功能,所有这些工作将会浪费.在我们确定用户真的喜欢这个功能之前,不是最好不要做所有这些额外的可能发送的东西吗？
如果您认为用户不喜欢您的上一次增量,那是因为您错过了一个关键点.在冲刺期间,您应该拥有更高的客户参与度,从而确保您真正做出客户想要看到的东西.
如果您有一位客户代表帮助您完成所有冲刺,那么您不太可能实施他们不喜欢的东西.如果您已经这样做了,也许您应该改善沟通.您应该让您的客户一路指导您,帮助他们找到喜欢的方式.
所以,答案是肯定的.你应该确保用户真的想要这个,这样,但是在sprint和用户故事定义期间,你应该更早地获得反馈,而不是等待sprint的结束.最大限度地减少浪费并最大化未完成的词
我建议你一本关于敏捷的好书:
如果您在开发过程中无法访问客户代表(根据评论情况就是这种情况),您应该确保您的客户很好地理解了为什么需要它.确保他们了解他们是否不会指导您,您将无法提供优质的,字级的软件.
作为敏捷团队的一部分,作为一个整体团队,您应该为更高的客户参与而奋斗.
还有一件事,人们往往会忘记.走自己的路.敏捷只是分享一些为人们工作的好习惯,并愿意分享.有些人这样做,所以他们分享知识.如果它对你来说有点不同,那就没关系.
正如你所写的那样,一条路可能适合你:向客户展示新功能,更多次,更多参与,更好.向他们展示用户故事,向他们展示模拟,向他们展示半工作解决方案,与他们沟通; 充分利用这种情况,以及有关他们期望的最多信息.确保您及时得到必要的反馈,这样您就可以确保不会再次结束,在冲刺审查期间站在那里并且有一些他们不喜欢的东西.