2012年8月21日星期二09:33

侵犯

撰写者

擅长–动词

  1. 对失败中痛苦的混合瀑布/敏捷项目的描述。 “哦,不,我们在做傻子”,或“我已经傻了起来,我无法站起来。”

你们中的许多人可能都遇到了被称为“混合”项目的项目。它结合了瀑布技术和敏捷技术来交付软件。结合这两种方法的原理似乎源于对这两种技术的不满:瀑布被认为过于僵化,敏捷被认为不够僵化。尽管许多人已经成功地将这两种方法结合在一起,但是如果在没有足够的理解或谨慎的情况下将瀑布和敏捷结合起来,则采用这两种方法的仅是糟糕的项目都会变成灾难。如果使用瀑布式投递迟到,那么在一个糟糕的混合项目中投递将完全失败。如果开发人员发现很难根据传统的需求规范进行编码,那么他们将完全对一个糟糕的混合项目感到困惑。如果客户不愿花大价钱去做瀑布,那么他们会在糟糕的混合项目上大吃一惊。

那么,不良的混合项目如何开始?它看起来像什么?糟糕的混合项目通常从对瀑布和敏捷的掌握不佳开始,并且加重对伤害的伤害,其中包括瀑布的组成部分,因为没有人信任任何人足以让团队进行自我管理,而敏捷则被采纳,因为有人阅读了一个博客,他说,敏捷将使开发人员的编码速度更快。

因此,根据您的角色,该项目分为不同的实践。开发人员获得的敏捷性最高。这通常需要两周的冲刺和每日站立训练,但没有产品所有者,与客户的联系为零。项目经理的工作不会改变-他们在甘特图上的任务四处移动,直到它们按照与瀑布几乎相同的方式按顺序顺序完成所有任务,只是将其重新标记为“敏捷”(或“迭代”)。

广管局又将如何发展?在试图与敏捷开发团队保持同步的同时,BA处于介于瀑布式计划中交付需求的中间。为了覆盖基础,BA通常要面对比瀑布项目交付更多的文档。

不良的混合项目可能会导致BA编写用例,然后从用例中为开发人员推断用户故事。或者,由于对用户故事的不信任(更不用说看板了),并且认为用例太难了,该项目决定通过制作极其详细的屏幕原型(需要花费数周的时间来制作)来解决所有需求引发的麻烦(更不用说10到每个屏幕30页文档),但包含零业务上下文。

尽管大多数BA都知道工作的全部目的在于以一种可以理解需求的方式传达需求,但是混合项目中的BA会发现他们无法跟上与Sprint保持一致的方式交付需求。 。通常,将这类项目的学士学位推到“刚刚开始”,而对所需的总体功能一无所知。这是基于这样的假设,即敏捷将帮助整个目标和功能自然使自己成为过程的结果。如果团队的任务是提供高保真屏幕原型作为其唯一的需求来源,那么事实恰恰相反。随着超详细原型的开发以及字体和单选按钮的出现,人们的整体设计和用途似乎变得更加晦涩难懂。

随之而来的压力和恐慌只能使用屏幕原型来定义需求,再加上试图与开发团队保持同步,通常会使项目处于持续的焦虑状态。即使客户想要什么,按计划以某种方式变成毫无疑问地做客户想要的任何事情,因为这是一个很糟糕的主意,因为对所有事情说“是”然后将需求推到最后很容易。任何问题都将推给开发团队,最终导致不断增加的产品积压和冲刺,而这些冲刺永远都无法摆脱测试。

如果没有额外的敏捷实践来定期反思迄今完成的工作并根据需要调整方法,那么所有人员都会疲于奔命地站起来,这样项目经理就可以就进度表拖延的原因进行讨价还价。 。

如果您是不良混合项目的学士学位,怎么办?

首先,这取决于您在项目中的位置。如果它已经令人生厌,并且开发人员陷入似乎从未交付的sprint中,那么可能已经为时已晚。您可以尝试向项目经理建议是时候限制来自客户的请求并确定产品待办事项的优先级了。现在可能还应该了解整体功能集,以帮助解决积压的问题。因为人们会坚持认为敏捷就是要在任何阶段接受任何和所有更改,所以这不会使您受欢迎。

您可以尝试与项目经理讨论敏捷是客户与开发团队之间的协作,这意味着,如果客户可以与开发人员和业务分析师在现场呆几个小时,那将是可取的每周一次,以便进行直接和畅通的沟通。而且,如果那不可能,请至少安排定期电话会议和/或Skype会议。您还可以回头看一下给开发团队带来最大麻烦的原型,并确保为每个屏幕做一个快速的用户故事或陈述一个业务目标,以显示各个屏幕之间的相互关系。这至少将为开发人员提供一些环境。

如果正在讨论运行混合项目的想法,但尚未开始,那么您可能有机会帮助项目经理避免迅速出现的问题。这将取决于项目经理对尝试新技术的满意程度。但是,如果从使他们的生活变得更轻松的角度来介绍混合项目,则BA可能会提供一些技巧和窍门,以如何以真正专注于为客户创造价值(确定业务)的方式保持需求流程的运行。目标/需求等),同时每两周与开发人员进行一次跟踪。项目经理可能对大多数敏捷技术感到非常不舒服(据称使开发人员能够更快地进行编码的那些技术除外),但对于BA来说,这仍然可能是一个机会,可以设计一个偷偷摸摸的模板并插入用户故事中的两个或两个。从来没有人说过,用户故事必须要贴在便笺上。

例如,您可以在屏幕原型的顶部添加一小段文字(如果您被迫沿着那条路走),概述了目标以及客户如何从业务角度使用屏幕。

如果您要先编写用例,然后再从用例中推断出用户案例,那么绝对可以通过一开始就考虑用户案例来节省时间。使它们成为用例的一部分,作为附加部分。这有点牺牲,但是您的混合项目不好,因此使用最佳实践或标准技术的任何想法都已经消失了。尽一切可能节省每个人的时间。

我对混合项目的最终想法是,它们已经成为ICT的又一尝试,它找到了灵丹妙药,这将使极其艰苦的软件开发工作像奇迹一样发生。所有的技术,无论是计划驱动还是变更驱动,在正确的团队,正确的态度和大量的务实态度下都趋于成功。

不管使用哪种技术,实践或方法,不良项目都是不良项目。但这是另一篇文章。

不要忘记在下面留下您的评论。

伊冯·哈里森(Yvonne Harrison)

伊冯·哈里森(Yvonne Harrison)CBAP曾担任系统程序员,技术作家,高级业务分析师,项目经理和企业解决方案架构师。伊冯曾经从事过一个糟糕的混合项目,该项目使一家公司破产。

©BA Times.com 2020

麦格雷戈徽标白色网站