事实证明这比我计划的要长(它开始只是评论),但是我希望增加的长度/详细信息对您有所帮助,您会发现它们是合理的。
敏捷并非特定于CRUD应用程序
关于敏捷的大多数文献似乎偏向于CRUD类型的业务应用程序,在该应用程序中,用户非常了解幕后情况。(这很好,因为所编写的大多数代码可能都属于此类。)
我认为这是因为创建此类易于遵循的示例更加容易,而不是因为该方法针对的是此类系统。如果您创建了一个不太容易理解的示例,则当您认为要向读者教授敏捷概念时,您可能会冒着使读者陷入尝试理解该示例的风险。
用户故事!=要求
对于这种类型的应用程序,用户故事(需求)和开发任务之间的关系通常很简单:只需将用户故事分成几个任务即可。
用户故事是不一样的要求。的确,根据需求的“高级”程度可能会有一些重叠,但通常并不相同。我得到的印象是,您遇到了很多我的前任经理都陷入的同样的陷阱:仅将用户故事视为“要求”的同义词来思考,这类似于SVN用户尝试过渡到Git时,但是根据SVN进行思考。(由于糟糕的起步假设,他们随后遇到了问题。)
恕我直言,需求和用户案例之间的主要区别在于需求详细指定了某些系统组件应如何运行;它们是包括输入,输出,假设/前提条件,可能引发的异常等的规范。它们专注于系统的工作。
OTOH,用户故事集中在最终用户的预期结果上,而没有尝试为系统组件创建详细的行为规范。他们专注于预期的用户体验。
我曾经做过的事情(这是我的团队采用的一种做法)是将用户故事分解为任务。您的任务可以像您希望/需要的那样具体或模糊,但是它们的目的是作为使故事达到完成状态的实际工作的进度指示器。
例
我大概回想起几年前在美国工作过的情况,在该情况下,用户需要自行分配测试用例,以便团队中的每个人都知道他们正在研究哪个TC,以避免重复工作。UI是一个内部Web应用程序。用户只看到一个按钮,但是故事被分为几个任务,其中包括一些技术实现细节等。
用户可见度
但是还有另一种类型的应用程序,其中大多数代码必须处理用户不直接可见的复杂处理。
是否可以通过某种方式使其对用户可见?
考虑一个GPS。当您错过转弯时,您将不会看到实际的路线重新计算过程,但是用户确实会收到一些有用的反馈(例如“重新计算...”)。
编译器可能会显示警告或错误,或者在GUI中包含新的设置/选项,以使用户看到已添加的新内容。我认为编译器的用户将是程序员,对吗?他们不会看到对新标准的支持吗?
虽然支持新标准可能是在功能级别,并且需要分解为用户故事,但是您是否确保至少在某些情况下在使用功能时不尝试使用故事? ?
汽车中的图像分析可以用一种措辞来表达,即让用户知道减少了撞车事故的可能性。例如:
作为自动驾驶汽车上的乘客,我需要使车辆因撞到无法识别的物体而导致事故的可能性尽可能接近零,以便我可以更安全地行驶。
美国在较高级别上捕获了通常需要结合功能和非功能要求(包括安全性,安全性等)指定的事项。
但是,对系统的要求可能更多。例如:
abc
组件的功能A
必须在图像比较算法中降低公差阈值,以更好地检测缓慢移动的对象。
对我来说,这很容易成为我上面提到的用户故事中的一项任务,标题为:降低功能的容忍度A.abc
,然后在其中包含其他相关细节。
对于流体模拟系统,您甚至可以使用进度条,如果有必要,它会提供有关系统正在执行的后台任务的反馈。(尽管您可能想避免成为垃圾邮件,但总有一种方法可以通知用户某些内容。)
对于所提到的特定领域,我还不够了解,无法提供更好和/或更现实的示例,但是如果这里有个收获,那就是您可以使用不同的方式向用户提供有关不可见内容的反馈信息系统可能正在做,即可能有办法使不可见的事物更加可见。(即使归结为编写一组发行说明,这些发行说明记录了由于您的努力等原因导致系统性能现在提高了多少)。
故事与任务之间的关系
在这里,将任务和用户案例联系起来确实非常困难。
我们的做法是保持用户的故事集中在哪些请求是,为什么有人做,并且是有什么事情需要真正考虑美国的“完成”。该怎么总是被排除在美国和留给开发人员(一个或多个)。
开发人员可以将在美国描述的问题分解为他们可以处理的一组任务。
我的意思是说,大多数情况下,他们都进行了后端服务器端编程,这对于最终用户来说可能是“隐形的”。
根据我需要执行的操作,有时我会使用AJAX来显示一个简单的“正在加载...”动画/ gif,以便用户知道他们需要稍等片刻才能完成其他操作,而不会得到错误的印象。有时就是这么简单。为此的任务将是适当的。
不同的范式,实践和经验
是否有克服这一问题的技术,或者仅仅是我们必须接受并充分利用的技术?
除了接受范式转换,实践和积累的经验外,也许还不多说。我经常看到人们试图在整个过程中采取捷径。我建议您不要这样做,尤其是在您入门时。随着您获得更多的经验,您可以允许一些灵活性,但要避免损害自己。
考虑到您之前的措辞,您仍在考虑将故事视为“重命名的需求”,我认为这是错误的假设。我认为这是关于敏捷方法和非敏捷方法之间的根本差异的更深层问题的征兆。
其次,我认为您应该接受敏捷性相对于瀑布式的范式转变,这意味着尽管流程具有相似的目标,但实现方式却截然不同。(如果有帮助,请考虑SVN vs Git。)
尝试提高您对需求和用户案例之间的概念差异的当前理解,并接受它们不是一回事。
向冲刺学习-回顾
我不足以强调的是,每次冲刺结束时Scrum Master和Developers之间的回顾。在那儿,他们以诚实/透明的方式讨论“做得好”或“做得不好”的事情,接下来的冲刺将实施哪些可行的更改以解决“做得不好”的要点。
这使我们能够适应甚至借鉴彼此的经验,而在我们不了解之前,以我们团队速度的总体一致性来衡量,我们已经取得了显着进步。