如果没有测试驱动的开发,scrum是可能的吗?[关闭]

不用考虑scrum的使用,您看到的是从代码所有权方法到公共代码方法的变化。为了让它起作用,必须有一个支持它的过程变更。其中一种可能性是TDD。还有其他的(自动化的单元测试,即使不能驱动与代码评审相结合的设计,强大的设计交流,更大的预先设计,在没有与代码的原始作者首先配对的情况下不能在代码上进行开发,我相信你能想到更多)。

社区方法适用于较小的社区(在较大的社区中,它可能退化为社区的悲剧),成员之间具有高度的凝聚力。

我想详细谈谈丹说的话。

scrum/agile规定了软件工程原则,这是一个非常常见的误解。这是一个谬论,原因有很多。正如丹提到的,scrum是一个软件 管理 过程,而不是软件工程过程。这就是说,您经常会看到许多与scrum相关的工程原理;诸如tdd、xp等方法学倾向于补充scrum所提倡但不是必需的管理方法学。

ci、tdd和其他工程实践经常与scrum一起出现的原因是,一般来说,无论使用什么管理方法,许多都是好的实践。

我想在你的评论中指出另外几个谬误:

然而,对于scrum,开发人员应该:

* to all be able to work on all the bits of the application.
* to only work on one area of the application for a few days at most before 
  moving to the next area
* to mostly work on code they did not write

1. 如上所述,scrum并不规定开发人员从事什么类型或类型的工作。开发人员自己决定要致力于什么工作;如果数据库繁重的开发人员只想处理dal和相关的故事,他们没有理由不这样做。

2. 同样,scrum没有规定如何构建应用程序,所以您的第二点是没有意义的(见第1点)。

3. 这是一个谬论,因为没有任何东西说开发人员应该只处理不属于他们的代码,也没有任何东西说开发人员应该如何开发。如果scrum团队中的开发人员发现自己只处理其他人的代码,那将是巧合,而不是因为scrum流程本身。

见 this 有关开发人员工作scrum中通常期望的质量的更多信息的问题/答案。

是的,scrum描述了软件管理方法。程序和项目管理范式不应该决定您是否使用测试驱动开发。

tdd是一种软件开发实践或技术,虽然它在scrum中运行良好,但我不认为它会在实践中取得或破坏您的成功。

我个人认为scrum在没有测试驱动开发方法的中型项目上运行良好。这并不是说我们没有编写自动化测试,只是它们并不总是首先编写的。

我们在工作中做scrum,但不练习tdd。scrum“指南”中没有任何内容告诉您必须使用tdd。事实上,大多数敏捷实践仅仅是一个建议,因为它们已经证明在敏捷环境(甚至是非敏捷环境)中可以很好地工作,如果你想实现scrum,它们就不是必须的。

我们确实编写了大量的单元和集成测试,以避免大量的手动测试,并确保代码中的后期更改不会导致任何不可预知的副作用。但那不是TDD。这通常是确保良好代码和软件质量的一种明智的方法。

请注意,不执行TDD不是一个“主动”的决定,它只是发生了。我们被鼓励“先写测试”,例如在修复一个bug时,这是一种自愿的情况,不是通过定期应用tdd来获得对tdd的感觉的强制性方式,但它不是强制性的。

正如其他人所说:scrum是一个框架,它可以保存您想要在开发团队中强制执行的任何实践。有些敏捷实践是自然而然的,因为它们通常是有意义的,但是哪些是你想使用的,哪些是你不想使用的取决于你自己。

是的,scrum是完全可能的,而且在大多数情况下,它是在不使用tdd方法的情况下实现的。

然而,tdd提供的灵活性无疑是scrum方法论可以受益的。

我工作的主要项目使用scrum方法,但是我们项目的嵌入式特性使得测试驱动开发(大多数人的方式)不切实际。

我认为你遇到的问题是程序员的期望值改变了,而不是管理过程变成了scrum风格的系统。如果程序员经常被转移到他们不熟悉的部分代码中,那么就要研究任务相对于旧方法如何被委派的过程。任务是分配给最了解该区域的开发人员,还是分配给任务列表最短的开发人员?代码的某一部分有很长的待办事项积压,而另一部分则缺少待办事项吗?如果您想让开发人员专注于他们擅长的领域,那么项目管理人员将希望调整sprint的长度和任务优先级,以确保工作负载可以按需要分布,并且在sprint的时间限制下仍然可行。

scrum框架非常小,它定义了一些会议、理想的迭代长度、产品所有者的职责、scrum管理员……也许再多一点。

然而,一旦我们开始了我们的迭代,scrum中就没有任何东西可以决定开发人员应该如何以及何时开发某些东西。只有在sprint结束时才能“完成”的承诺。

scrum是指团队致力于产生结果,并授权团队决定如何去做。如果这意味着每个用户故事有1个dev,那就太好了。如果这意味着每个用户故事3个开发人员也可以。不管scrum团队认为什么样的方式是做这项工作的最佳方式,都是应该发生的事情。

要回答这个问题,不需要测试驱动的开发,scrum是可能的。

TDD是一个值得/推荐的实践,但结果会因团队/环境而异。例如,TDD是否在项目开始时就已经到位,或者您是否试图在稍后的日期将方法注入。

这里有些关于scrum的困惑。

scrum本身并没有告诉你该怎么做/什么时候做。 技术的 像TDD这样的东西(那是一个永远移动的目标)。scrum告诉您如何/何时管理 人 项目中发生的事情。这是一个 全面项目管理 技术,不是 施工管理 技术。

如果您的经理希望在您的sprint期间完成上面列出的三件事,那很好,但这不是scrum框架的一部分。这些是用于施工管理的,而不是scrum。它可能用于scrum框架限定的项目中,但它不在正式的scrum框架中。

不过,我觉得很容易对此感到困惑。像scrum这样的敏捷技术通常会被“网络上的人所鼓吹,他们总是在推销流行语和“快乐闪亮”的东西,因此并不总是能很好地理解/交流。至少,敏捷技术就是这样被一个敏捷的辩护者介绍给我的。我花了整整6个月的时间才摆脱了那些夸大其词/令人费解的术语,弄明白他们在说什么。

虽然我同意上面的一些部分,但我确实相信,如果没有测试周期,您就不能交付小增量的代码(软件的scrum)。

你怎么知道你的冲刺没有打破最后4个?如果你不知道你过去没有打破任何东西,你怎么能保证交付成果。

我同意scrum是一个管理过程,tdd是一个软件过程。你必须有办法确认你没有向后移动。

scrum教你每天都要交付成果,并且总是以牺牲速度为代价向前推进。

当有人说我想做ci、agile或scrum时,对我来说,这自动意味着需要进行单元测试(不是上面提到的集成测试),而是每个移动的部分都有自己的单元测试。

如果你做了一个集成测试,你并不是以一种独立的方式测试每一个单独的部分。因此,您要证明的是,在一个流中调用的方法有效,而不是在msil中看到的每个可能的分支。