没有测试驱动开发,Scrum是否可行？

Question

我现在目睹了两家公司采用Scrum进行敏捷开发.

在这两种情况下,当应用程序的每个部分仅由一个或两个开发人员处理时,编码标准足够好,开发人员在转移到下一个任务之前花费合理的时间在应用程序的一部分上工作.缺陷率也合理.

但是对于Scrum,开发人员应该是:

• 所有人都能够处理应用程序的所有部分.
• 在移动到下一个区域之前,最多只能在应用程序的一个区域工作几天
• 主要处理他们没有编写的代码

代码质量在两个Scrum项目中都成了问题.

那么有没有办法在不首先让所有开发人员进行测试驱动开发的情况下做Scrum而不会导致这些问题？

您是否看过Scrum在没有测试驱动开发的大型项目上运行良好？(如果是这样的话？)

Answer 1

我想扩展Dan说的话.

这是一个非常普遍的误解,Scrum/Agile决定了软件工程原理.出于多种原因,这是一种谬误.正如Dan所说,Scrum是一个软件管理过程,而不是软件工程过程.话虽如此,您经常会看到许多与Scrum相关的工程原理; 诸如TDD,XP等方法倾向于补充Scrum推广的管理方法,但不是必需的.

CI,TDD和其他工程实践经常与Scrum一起发现的原因在于,无论使用何种管理方法,许多都是很好的实践.

我想在你的OP中解决其他几个谬误:

但是对于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进程本身.

有关使用Scrum的开发人员通常期望的质量的更多信息,请参阅此问题/答案.

Answer 2

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

TDD是一种软件开发实践或技术,虽然它与Scrum配合得很好,但我认为它不会成功或破坏你的成功.

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

Answer 3

无论使用Scrum,您所看到的是从代码所有权方法到公共代码方法的转变.为了使其工作,必须有一个支持它的流程变更.一种可能性是TDD.还有其他(自动单元测试,即使没有驱动设计加上代码评论,强大的设计沟通,更大的设计预先,没有开发代码而没有首先与代码上的原作者配对,更多我相信你可以想到).

社区方法适用于较小的社区(大型社区可以沦为公地悲剧),成员之间具有高度的凝聚力.

Answer 4

我们在工作中做Scrum,但我们不实践TDD.Scrum"指南"中没有任何内容告诉您必须使用TDD.实际上,大多数敏捷实践仅仅是一种建议,只要它们已经证明在敏捷环境(甚至非敏捷环境)中运行良好,如果你想实现Scrum,它们就不是必须的.

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

请注意,没有实施TDD并不是一个"积极"的决定,它只是发生了.我们被鼓励"首先编写测试",例如在修复错误时,所以这是一种自愿的情境驱动的非强制性方式,通过定期应用来获得TDD的感觉,但这不是强制性的.

像其他人一样说:Scrum是一个框架,它可以包含您希望在开发团队中执行的任何实践.一些敏捷实践自然而然地存在,因为它们通常是有意义的,但是您想要使用哪些以及您不想要哪些敏感实践取决于您.