如何将敏捷应用于涉及复杂处理的应用程序?


12

关于敏捷的大多数文献似乎偏向于CRUD类型的业务应用程序,在该应用程序中,用户非常了解幕后情况。(这很好,因为所编写的大多数代码可能都属于此类。)

对于这种类型的应用程序,用户故事(需求)和开发任务之间的关系通常很简单:只需将用户故事分成几个任务即可。

但是还有另一种类型的应用程序,其中大多数代码必须处理用户不直接可见的复杂处理。例如:

  • 编译器
  • 自动驾驶汽车图像分析系统
  • 流体模拟系统

在这里,将任务和用户案例联系起来确实非常困难。是否有克服这一问题的技术,或者仅仅是我们必须接受并充分利用的技术?


6
不是拒绝投票的人,而是我认为这是因为问题基于错误的前提。IMO复杂的系统更适合敏捷式发展凭借的事实,他们更复杂。系统越复杂,就越有可能出现新的需求。敏捷SwDev的创建是为了更好地处理新兴需求。
RubberDuck

4
@RubberDuck:“我想这是因为问题是基于错误的前提。”:IMO,这会激发出一个答案,其中会解释错误的前提,而不是反对。
Giorgio

用户是否理解逻辑与敏捷过程完全无关。团队需要将用户故事映射到实现并估计将花费多长时间。如果复杂和/或工作量很大,团队可以将故事分解成较小的故事。逻辑类型无关紧要。
马丁·马特

2
“关于敏捷的大多数文献似乎偏向于CRUD类型的业务应用程序” –并且大多数关于Java的文献似乎偏向于在控制台上打印字符串“ Hello World”(或替代计算第n个Fibonacci编号)。这并不意味着这是Java唯一的优点。两种情况下的原因都是相同的:很难在博客文章或教程中解释现实的例子。[注:这是一个双曲线评论试图说明在错误的前提基础。]
约尔格W¯¯米塔格

1
敏捷不需要任务和用户故事。您可以使用所需的任何形式的规范。重点是灵活性。
Frank Hileman '17

Answers:


9

事实证明这比我计划的要长(它开始只是评论),但是我希望增加的长度/详细信息对您有所帮助,您会发现它们是合理的。

敏捷并非特定于CRUD应用程序

关于敏捷的大多数文献似乎偏向于CRUD类型的业务应用程序,在该应用程序中,用户非常了解幕后情况。(这很好,因为所编写的大多数代码可能都属于此类。)

我认为这是因为创建此类易于遵循的示例更加容易,而不是因为该方法针对的是此类系统。如果您创建了一个不太容易理解的示例,则当您认为要向读者教授敏捷概念时,您可能会冒着使读者陷入尝试理解该示例的风险。

用户故事!=要求

对于这种类型的应用程序,用户故事(需求)和开发任务之间的关系通常很简单:只需将用户故事分成几个任务即可。

用户故事是一样的要求。的确,根据需求的“高级”程度可能会有一些重叠,但通常并不相同。我得到的印象是,您遇到了很多我的前任经理都陷入的同样的陷阱:仅将用户故事视为“要求”的同义词来思考,这类似于SVN用户尝试过渡到Git时,但是根据SVN进行思考。(由于糟糕的起步假设,他们随后遇到了问题。)

恕我直言,需求和用户案例之间的主要区别在于需求详细指定了某些系统组件应如何运行;它们是包括输入,输出,假设/前提条件,可能引发的异常等的规范。它们专注于系统的工作。

OTOH,用户故事集中在最终用户的预期结果上,而没有尝试为系统组件创建详细的行为规范。他们专注于预期的用户体验

我曾经做过的事情(这是我的团队采用的一种做法)是将用户故事分解为任务。您的任务可以像您希望/需要的那样具体或模糊,但是它们的目的是作为使故事达到完成状态的实际工作的进度指示器。

我大概回想起几年前在美国工作过的情况,在该情况下,用户需要自行分配测试用例,以便团队中的每个人都知道他们正在研究哪个TC,以避免重复工作。UI是一个内部Web应用程序。用户只看到一个按钮,但是故事被分为几个任务,其中包括一些技术实现细节等。

用户可见度

但是还有另一种类型的应用程序,其中大多数代码必须处理用户不直接可见的复杂处理。

是否可以通过某种方式使其对用户可见?

考虑一个GPS。当您错过转弯时,您将不会看到实际的路线重新计算过程,但是用户确实会收到一些有用的反馈(例如“重新计算...”)。

编译器可能会显示警告或错误,或者在GUI中包含新的设置/选项,以使用户看到已添加的新内容。我认为编译器的用户将是程序员,对吗?他们不会看到对新标准的支持吗?

虽然支持新标准可能是在功能级别,并且需要分解为用户故事,但是您是否确保至少在某些情况下在使用功能时不尝试使用故事? ?

汽车中的图像分析可以用一种措辞来表达,即让用户知道减少了撞车事故的可能性。例如:

作为自动驾驶汽车上的乘客,我需要使车辆因撞到无法识别的物体而导致事故的可能性尽可能接近零,以便我可以更安全地行驶。

美国在较高级别上捕获了通常需要结合功能和非功能要求(包括安全性,安全性等)指定的事项。

但是,对系统的要求可能更多。例如:

abc组件的功能A必须在图像比较算法中降低公差阈值,以更好地检测缓慢移动的对象。

对我来说,这很容易成为我上面提到的用户故事中的一项任务,标题为:降低功能的容忍度A.abc,然后在其中包含其他相关细节。

对于流体模拟系统,您甚至可以使用进度条,如果有必要,它会提供有关系统正在执行的后台任务的反馈。(尽管您可能想避免成为垃圾邮件,但总有一种方法可以通知用户某些内容。)

对于所提到的特定领域,我还不够了解,无法提供更好和/或更现实的示例,但是如果这里有个收获,那就是您可以使用不同的方式向用户提供有关不可见内容的反馈信息系统可能正在做,即可能有办法使不可见的事物更加可见。(即使归结为编写一组发行说明,这些发行说明记录了由于您的努力等原因导致系统性能现在提高了多少)。

故事与任务之间的关系

在这里,将任务和用户案例联系起来确实非常困难。

我们的做法是保持用户的故事集中在哪些请求是,为什么有人做,并且是有什么事情需要真正考虑美国的“完成”。该怎么总是被排除在美国和留给开发人员(一个或多个)。

开发人员可以将在美国描述的问题分解为他们可以处理的一组任务。

我的意思是说,大多数情况下,他们都进行了后端服务器端编程,这对于最终用户来说可能是“隐形的”。

根据我需要执行的操作,有时我会使用AJAX来显示一个简单的“正在加载...”动画/ gif,以便用户知道他们需要稍等片刻才能完成其他操作,而不会得到错误的印象。有时就是这么简单。为此的任务将是适当的。

不同的范式,实践和经验

是否有克服这一问题的技术,或者仅仅是我们必须接受并充分利用的技术?

除了接受范式转换,实践和积累的经验外,也许还不多说。我经常看到人们试图在整个过程中采取捷径。我建议您不要这样做,尤其是在您入门时。随着您获得更多的经验,您可以允许一些灵活性,但要避免损害自己。

考虑到您之前的措辞,您仍在考虑将故事视为“重命名的需求”,我认为这是错误的假设。我认为这是关于敏捷方法和非敏捷方法之间的根本差异的更深层问题的征兆

其次,我认为您应该接受敏捷性相对于瀑布式的范式转变,这意味着尽管流程具有相似的目标,但实现方式却截然不同。(如果有帮助,请考虑SVN vs Git。)

尝试提高您对需求和用户案例之间的概念差异的当前理解,并接受它们不是一回事。

向冲刺学习-回顾

我不足以强调的是,每次冲刺结束时Scrum Master和Developers之间的回顾。在那儿,他们以诚实/透明的方式讨论“做得好”或“做得不好”的事情,接下来的冲刺将实施哪些可行的更改以解决“做得不好”的要点。

这使我们能够适应甚至借鉴彼此的经验,而在我们不了解之前,以我们团队速度的总体一致性来衡量,我们已经取得了显着进步。


“用户故事!=要求”:我并不是说这两个是同义词。并非每个需求都是用户故事。但是我确实认为所有用户故事都是必需的。我将需求视为一种层次结构,其中用户故事是一个特定的细节级别。你同意吗?
Frank Puffer

@FrankPuffer我认为查看用户故事就像它们是需求层次结构中的不同级别一样,基本上是在混合不同的概念。在敏捷方面,层次结构看起来更像是:主题>>史诗>>功能>>用户案例>>任务。在更传统的Waterfall方法中,需求通常分为功能性需求和非功能性需求,但是我并没有遇到实际的层次结构。也就是说,如果有人将需求递归分解为较小的“子”需求,我不会感到惊讶。无论如何,您正在混合使用不同的概念。
code_dredd

诸如PTC Integrity之类的需求管理系统将需求视为层次结构。将需求映射到规范文档时,这可能是一个优势。
Frank Puffer

@FrankPuffer是的,这就是为什么我说我不会感到惊讶。就是说,我想知道我的回答为您澄清了什么。SVN vs Git类比对您有帮助吗?(假定您熟悉这两个系统,这在软件开发环境中似乎是合理的。)
code_dredd

好的,我误读了“不会”为“会”。是的,我发现您的回答很有帮助,并且可能会接受。我可能只需要一些时间就习惯了不将用户故事视为要求的想法。
Frank Puffer

4

在这些情况下,可以肯定采用敏捷原则。怎么样?

  • 编译器可以在以后的单独用户故事中添加新的语言功能
  • 图像分析系统可以添加新功能,作为不同的图像分类
  • 流体模拟系统可以在模拟中考虑不同的模型方面

您不必一口气吃掉整个大象。敏捷只要求您证明您在下一份大象之前就已经清洁了盘子。


我仍然认为仍然存在一个或多个需要大量所谓基本功能的用户故事。它们通常不会适合单个冲刺。应该如何处理?
Frank Puffer

1
您使用客户可以测试,查看或触摸的可运行应用程序来衡量成功与否。如果是这样,请给他们一个玩具,以这种方式产生进步感。例如,您可能无法在第一次冲刺中释放无人驾驶汽车,但可以演示算法如何侦察人员。后来,它如何侦察信号和动物。后来它如何测量距离,大小等。自动驾驶汽车在遥远的冲刺中距离很远,谁知道它是否会发生。
Laiv

2
@Laiv:很好,但是我不确定是否可行。在前几次冲刺之后,该软件将无法执行与客户相关的任何事情。您将获得技术进步,但很难(即使不是不可能)将其传达给客户。
Frank Puffer

2
为什么?因为它是由对您的项目陌生的人写在Stone上的?我希望敏捷能够适应我的需求,而不是其他。如果我说我可以在4周内教您滑冰,而在5日一次,您仍然无法站立,这是否意味着您没有学会滑冰?还是仅仅需要一点时间?敏捷宣言不是写在石头上,也不是Scrum的规则是趋向诫命。
Laiv

2
冲刺的目的是使客户成为迭代的一部分。使用提供的代码与他们交流。没有计划和承诺。它要求您集中精力解决问题。不需要将交付的第一件事牢记在心。它要求您证明自己值得付出每一次冲刺。
candied_orange

1

我发现严格遵守用户故事的人们要么只是愚蠢地提出了一些牵强附会的方法,这些方法以后端技术变更影响用户(当然,这对于用户来说是天真的,这对用户而言并不为人所知)用户,而您正在谈论的是数据分析管道中的复杂变更或类似的变更),否则,他们将完全为“我们如何组织这项工作!

我认为显而易见的解决方案是更加务实。如果这项工作本质上是非常技术性的,并且对用户没有特别明显的影响,请不要因为试图解释它的工作而昏昏欲睡。只需选择一种显而易见的简单方法即可使用户受益,然后围绕开发人员完成工作所需的细节定位故事。当PO绝对必要时坚持不提供故事中的技术信息时,我会感到非常沮丧。对于那个工件(故事)的真实情况,这不是一个非常全面的看法。就像他们认为它只是为他们而存在一样,在大多数情况下,它对工程师也很重要。

对于这些技术任务中的大多数,在影响用户方面是否有一些悬而未决的成果,无论这是否正在提高效率,因此未来的交付将更快,性能,可靠性等得到提高。它们并不是人们在想到“用户故事”时通常会想到的东西,但是如果企业想了解您为什么承担技术债务或类似的事情,那么这些解释通常是最简单的。

tl; dr不要仅仅因为它们太大而无法适应,所以不要让乱序使您的生活更加困难。适应性毕竟是敏捷的核心概念。严格遵守Scrum或敏捷通常会面子苍白或实用主义和实用性(实际上最有效的方法)。


我全力以赴,但坦率地说,只要他们的故事满意,用户就不会特别在意技术细节。您不必“严格地敏捷”即可拥有良好的需求;所谓“好的要求”,是指每项要求都附带有明确证明满足要求的验收测试。那些“从事非常愚蠢的练习”的人显然做错了,但这并不意味着他们遵循“严格的混乱”的概念。
罗伯特·哈维

@RobertHarvey我同意技术细节与用户无关,但我的观点是,包含用户故事的工件具有比仅仅传达事物如何对用户有效(或至少应该如此)更广泛的目的。如果它们仅编写用户案例,那么如何执行与体系结构,可扩展性,性能等相关的要求?采用纯粹的“用户故事”方法会激励开发人员编写质量低劣的代码。并不是用户阅读开发人员和质量检查人员的“用户故事”,故意排除相关信息是愚蠢的,因为这是技术性的。
evanmcdonnal

0

我认为问题在于给用户故事一个他们没有的含义。Scrum使用术语PBI或Product Backlog Item,我认为这是更好的选择。所涉方案经常跟随用户故事的格式,例如,你可能有一个PBI像“订户应该能够查看他们的订阅范围”,但你也可以很容易地有PBI像“创建一个存储过程来获得用户的详细信息”。

用户故事是一种工具。它们帮助您根据自己的习惯来形成功能描述和要求。但是,就像当您需要悬挂图片时用扳手没用一样,有时您可能不需要用户故事。

就是说,许多团队实际上只是在“用户”部分进行松散的比赛。他们可能有“用户故事”,例如“作为开发人员,我需要能够调用存储过程以获取订户详细信息”,本质上就是“开发人员故事”。这是一个同样有效的选择,但就我个人而言,我想说的是,只要您能描述需要完成的工作并提出一套接受标准,那么是否有实际的用户故事就无关紧要。


1
除了非常奇怪和罕见的情况外,我不同意这一点。在Scrum中,HOW是开发团队的职责,而不是产品所有者。但是,产品所有者应负责PBI。因此,像“创建存储过程”这样的PBI剥夺了开发团队选择HOW的权利。PBI,无论是否具有用户背景,都应说明进行PBI的业务价值。创建存储过程与业务价值无关,而与实现细节有关。
RibaldEddie '17

那不是重点。那只是一个例子。您可以将“存储过程”更改为诸如“ a way”之类的通用名称。关键是它不必一定是用户故事。
克里斯·普拉特

一个例子的全部要点是作为一个例子。如果您的示例“不是重点”,那么示例的重点是什么?
RibaldEddie '17

-3

这些类型的应用程序正是具有不同专业知识的应用程序,并将进一步发展。由于不同的教育,不同的业余爱好项目以及不同的过去工作经验,团队成员将具有不同的技能。此外,如果有人开发特定代码,则可以期望开发人员是最了解该代码的人。因此,将涉及同一段代码的更多开发任务分配给同一开发人员可能是有意义的。

在最流行的敏捷流程Scrum中,有计划的扑克,其中为每个任务分配了一个难度级别。难度级别不取决于根据流程执行任务的人员。然后在冲刺期间,人们被认为是同质的,因此希望每个人都能选择并执行每个任务。在像项目这样的简单CRUD中,此假设成立。但是在非常复杂和困难的项目中,肯定没有。

对于这类项目,我不会使用敏捷过程。最好的选择是避免任何正式流程,而要使用良好的项目管理。在决定谁实现特定功能时,请考虑谁具有此功能所需的最佳技能以及对现有代码的最佳了解。不需要任何处理。您可能希望为所有功能编写好的设计文档并保持最新。请注意,我不是在这里推广类似瀑布的模型:设计文档不会在项目开始时就全部编写;您将根据需要的新功能编写新的设计文档。


5
与我的问题并没有真正的关系,但是始终让技能最好的人实施一项功能可能很危险。它阻碍了团队内部知识的传播。如果需要维护并且专家已经离开团队或暂时无法使用,您将遇到麻烦。
Frank Puffer

@FrankPuffer对于您列出的某些类型的系统,例如自动驾驶汽车,如果专家离开了团队,您将有麻烦。期。尽管可能不是应该对编码进行集中化,但是假设有足够的“知识传播”以允许专家在任何较短的时间内进行替换也是完全不合理的。这些人将花费超过十年的时间来研究该问题,并且大概在其研究领域中处于领先地位。这样您可能需要多个具有不同技能的人。这样的项目具有固有的风险。
德里克·埃尔金斯
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.