混合敏捷-实施业务应用程序时的瀑布式方法(又称敏捷)

在现代IT技术的世界中,当Google Play和Appstore每天都有大量的应用程序通知更新时,项目团队就ERP系统的实施听取了“该项目需要9(乐观)至12个月(现实)的时间”是相当普遍的。 此外,还有更复杂的项目。 在我朋友工作过的一家公司中,只有创建和签署流程设计的阶段才持续了6个月。 设计文件的数量真是令人印象深刻,并且以印刷形式可以很好地挽救中国古代武士的生命(他们说他们使用纸作为装甲材料)。 古代中国的时代已经过去,但是今天,这叠纸继续挽救了生命,甚至挽救了生命,至少在系统投入运行的阶段,顾问们的神经系统得以保存。 但是,设计文件不能避免的是项目启动时间的变化以及商业运行时系统质量的问题。 让我们尝试弄清楚为什么会发生这种情况,以及是否有可能以其他方式有所不同。

想象一下,您要订购新公寓的修理。 在开始工作之前,承包商团队会要求您签署一份文本文件(通常没有插图),说明您的公寓在维修后的外观,包括所有详细信息:插座,开关,家具等。团队负责人警告说,在验收阶段可能会发生变化总计将导致额外费用。 因此,您负责任地完成任务,花费大量时间,最后签署文件。 好吧,假设您要离开该国六个月。 并且完全信任实施团队自行进行维修,而无需您进行任何控制和监视。 六个月后,返回,进入公寓,看看完成的公寓不能完全满足您的期望。 然后,您要求项目团队重做一些细节,例如,将插座移近冰箱。 项目团队说,转移插座并花费大量时间会非常昂贵,因为您必须将墙上的墙壁挖空,并铺有瓷砖等。您进入卧室,打开已经安装的空调,并了解它将在晚上吹到您身上。 要求团队将其移动,但您得到的答案与使用插座的答案大致相同。 不过,这对您来说是个原则问题,您说在空调需要的地方就不会开始住在公寓里,因为在您当前的公寓里正是您需要的地方,如果有的话,您看不到搬家的意义。会恶化您的日常生活舒适度。 结果,您比原计划晚了三个月致电公寓,预算超出了20%。

我认为主要的问题是在开始工作之前,我们试图在设计阶段预见并修复所有细节。 设计阶段被延迟,因为 业务用户很少能够完全专注于该项目,他们必须处理其日常业务流程。 到设计签名时,他们已经积累了相当多的待处理任务积压,直到测试阶段,他们才准备好参与项目。 他们已经花了很多时间来计划所有细节,并希望看到一个完整且经过调整的系统。 但是,最终结果不符合预期。 原因如下:


在我们公司,我们正在成功地尝试一种新的项目实施方法,以实施和复制ERP系统。 此外,在复制项目中,该方法使您可以比通常的计划更快地完成设计,开发和测试的连续阶段(又称瀑布)的项目。

我们从此出发:



对此:



我们称这种方法为混合(瀑布-敏捷),因为我们同时使用了敏捷元素(冲刺工作)和瀑布(商业运作仅在整个项目完成后才开始)。 加速是由于以下事实:首先,我们与业务用户并行工作(设计未来的冲刺和定制,开发当前的冲刺),其次,我们在瓷砖铺好之前将插座“转移”到了未来的冰箱附近和厨房套装组装。 与经典的Waterfall方法相比,项目量越大,时间和质量收益就越大。

使用混合方法的火星样本项目




该项目的主要特点:

  • 从开始到启动有5½个周期(22周)
  • 完整的项目团队-40人(业务用户和IT顾问,开发人员)
  • 项目团队中的4个职能团队-财务,采购,物流和销售,质量控制部
  • 首次尝试时有4个业务测试周期,其中93%的成功脚本是成功的。 5个全职工作坊

在项目前阶段,我们估计我们将在30周内完成该项目。 实际上,使用敏捷方法,我们在22周内完成了所有工作。 发布后的4个月内,我们收到了来自该企业的1项更改请求。

关键成功因素


内部IT团队。 尽快与实施中涉及的关键IT团队进行安排。 争取管理支持以与外部承包商进行对话。

外部承包商。 承包商的项目团队应包括对系统本身和敏捷实施原则非常了解的专业人员。 初学者不应该。 签订合同之前,与团队进行选择性采访。
业务团队应该有机会和愿望在开发的所有阶段中定期参与项目。 这并不意味着企业将不得不开展更多工作。 我们将他们的时间从通常的设计和测试阶段重新分配到开发的每个部分。

一些常见问题


问题1:商业部门要求在开始开发之前与固定价值承包商签订合同。 但是,如果没有完整且未签名的设计,如何评估成本?

答案1:我们与承包商签订了固定团队合同-我们确定团队和项目实施时间,例如8个月。 这与时间材料不同,因为 我们记录工期和工作总量。 同时,如果项目和团队的工期不增加,我们在更改/添加业务需求方面仍然保持灵活。

问题2:如果业务用户在每个Sprint的审查和计划期间不断添加新要求,该怎么办?

答案2:在这种情况下,我们要求您对需求进行优先排序,并删除优先级最低且不适合项目期限的需求。 即 添加一个新的而不是现有的东西。 无论采用哪种方法,无论在哪种情况下,所有这些更改/新要求都将在验收阶段等待着我们。 但是在每次冲刺结束时进行中间验收的情况下,我们会有更多机会来管理这些要求,而当在即将发布前接受时,我们会冒着启动时间和系统质量的风险(按定义,质量是最终结果与用户期望的对应,而不是文字设计)。

如果您对本文感兴趣,有任何疑问,或者只是想对以上内容发表意见,那么,如果您在出版物或个人信息中分享反馈,我将不胜感激。 Angelina Abdullaeva angelina .abdullayeva参与其中的插图和思想内容。

Source: https://habr.com/ru/post/zh-CN477378/


All Articles