这里的聚会有点晚了,但这是我根据你写的内容的看法。
现在,Scrum 是一种项目管理方法,而不是一种开发方法。但在我看来,关键是要有适当的开发流程。没有一个,您将大部分时间花在反应而不是构建上。
我是一个测试优先的人。在我的开发过程中,我首先构建测试来执行需求和设计决策。你的团队是如何执行这些的?我在这里要说明的一点是,您根本不能“把东西扔到栅栏上”并期望除了失败之外的任何事情。这种失败要么是由测试团队(由于没有很好地测试,因此让问题溜走),要么是由开发人员(由于没有构建解决问题的产品)。我并不是说你必须先编写测试——我不是激进分子或测试优先的布道者——但我是说你必须有一个流程来生成高质量、经过测试、准备好生产的代码,当你达到迭代的结束。
在我称之为死亡螺旋方法的开发方法中,我一直是正确的。多年来,我以这种模式为政府(美国)开发了软件。它不能很好地工作,它要花很多钱,它会产生迟到的代码,糟糕的代码,并且对士气没有任何帮助。当您将所有时间都花在修复本来可以避免的错误上时,您将无法取得任何进展。我完全被这件事打败了。
您不希望 QA 发现您的问题。你真的想让他们失业。我的目标是让 QA 大吃一惊,因为一切正常。诚然,这是一个目标。在实践中,他们会找到东西。我不是超人。我犯错了。
回到调度...
在我目前的工作中,我们做 Scrum,我们只是不这么称呼它。我们在这里不喜欢标签,但我们喜欢按时生产高质量的代码。每个人都在船上。我们告诉 QA 我们将准备测试什么以及何时测试。如果他们提前两周来敲门,他们可以和手说话。每个人都知道时间表,每个人都知道发布中的内容,每个人都知道产品必须按照宣传的方式工作,然后才能进入 QA。那是什么意思?你告诉 QA “不要费心测试 XYZ - 它已经坏了,直到发布 C 版才会修复”,如果他们去测试,你把他们指向那个声明并告诉他们不要浪费你的时间。苛刻,也许,但有时是必要的。我不是要粗鲁,但每个人都需要知道“规则”
您的管理层必须参与其中。如果他们不是,你就会遇到麻烦。QA 无法运行该节目,开发组也无法完全运行它。所有的组(即使这些组每个组只有一个人或一个戴多个帽子的人)都需要在同一页面上:客户、测试团队、开发人员、管理层和其他任何人。通常,超过一半的战斗是沟通。
也许你在 sprint 中的努力超出了你所能完成的范围。情况可能就是这样。你为什么这样做?满足时间表?如果是这样,那就是管理层需要介入并解决问题的地方。如果您要提供 QA 错误代码,请期望他们将其扔回去。最好给他们 3 件有用的东西,而不是 8 件未完成的东西。目标是产生一些在每次迭代中完全实现的功能,而不是把一堆半途而废的东西放在一起。
我希望收到它的本意——作为鼓励而不是咆哮。就像我提到的那样,我一直在你所在的地方,这并不有趣。但有希望。你可以在一个 sprint 中扭转局面,也许两个。也许您不会在下一个 sprint 中添加任何新功能,而只是修复损坏的部分。你必须作为一个团队来决定。
编写测试代码的另一个小插件:自从采用了“先编写测试”的方法后,我发现自己对我的产品更加放松和自信了。当我所有的测试都通过时,我就有了一种没有它们就无法拥有的自信。
祝你好运!