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

如上所述，Scrum没有规定开发人员的工作类型或类型。开发人员自己决定要做出哪些工作;如果一个数据库密集的开发人员想要只处理DAL和相关的故事，那么他们没有理由不这样做。
同样，Scrum没有规定如何构建应用程序，所以你的第二点是没有实际意义的（见第1点）。
这是一个谬论，因为没有任何内容表明开发人员应该只处理不属于他们的代码，或者任何关于开发人员应该如何开发的代码。如果Scrum团队中的开发人员发现他/她自己只处理其他人的代码，那将是巧合，而不是因为scrum流程本身。

有关使用Scrum的开发人员通常期望的质量的详细信息，请参阅this问题/答案。

Answer 2

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

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

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

Answer 3

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

社区方法适用于较小的社区（大型社区可以沦为公地悲剧），成员之间具有高度凝聚力。

Answer 4

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

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

请注意，未实施TDD并非“积极”决定，它刚刚发生。我们鼓励“首先编写测试”，例如在修复bug时，这是一种自愿的情境驱动的非强制性方式，通过定期应用来获得TDD的感觉，但这不是强制性的。

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

Answer 5

是的，Scrum是完全可能的，并且在大多数情况下是在不使用TDD方法的情况下实现的。

然而，TDD提供的灵活性肯定是Scrum方法可以从中受益的。

Answer 6

我工作的主要项目使用Scrum方法，但我们项目的嵌入式特性使得测试驱动开发（大多数人这样做的方式）不切实际。

我认为您遇到的问题是程序员的期望发生了变化，而不是管理流程进入了Scrum风格的系统。如果程序员不断地对他们不熟悉的部分代码进行调整，请调查相对于旧方法委派任务的过程。是否将任务分配给知道该区域最佳的开发人员，或者他们是否使用最短的待办事项列表前往开发人员？代码的一部分是否有很长的积压待办事项，而另一部分的待办事项是否稀缺？如果您希望让开发人员专注于他们擅长的领域，那么项目管理人员将需要调整sprint长度和任务优先级，以确保工作负载可以按照需要进行分配，并且考虑到sprint的时间限制仍然可行。 / p>

Answer 7

Scrum框架非常小，它定义了一些会议，理想的迭代长度，产品所有者的责任，scrum master ......以及可能更多。

但是，一旦我们开始迭代，Scrum中就没有任何内容可以决定开发人员应该如何以及何时开发某些东西。只有承诺才能在冲刺结束时“完成”。

Scrum是关于团队承诺产生结果的，并且团队有权决定如何这样做。如果这意味着每个用户故事1个开发者，那很好。如果这意味着每个用户故事的3个开发也很好。无论Scrum团队认为哪种方式是最好的工作方式，都应该发生。

要回答这个问题，是的，没有测试驱动的开发，Scrum是可能的。

TDD是值得/推荐的做法，但结果会因团队/背景而异。例如，在项目开始时是TDD还是你想在以后注入方法。

Answer 8

这里有一些关于Scrum的混淆。

Scrum本身并没有告诉你如何/何时做像TDD这样的技术事情（这是一个永远不断变化的目标）。 Scrum告诉您如何/何时管理项目中发生的 people 事情。它是整体项目管理技术，而不是施工管理技术。

如果你的经理希望在短跑期间做上面列出的三件事，那很好，但这不是Scrum框架的一部分。那些是建筑管理，而不是Scrum。它可以在你的Scrum框架有限的项目中使用，但它不在官方的Scrum框架中。

我认为很容易对此感到困惑。像Scrum这样的敏捷技术通常被网络上的人传播，他们都是关于推动流行语和'快乐闪亮'的事情，因此并不总能理解/沟通。至少，这就是敏捷技术人员如何向我介绍敏捷技术。我花了6个月的时间才通过炒作/混淆的术语，弄清楚他们在谈论什么。

Answer 9

虽然上面有一些我同意的部分，但我真的相信，如果没有测试期，你就无法提供少量代码（Scrum for software）。

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

虽然我同意SCRUM是一个管理流程，而TDD是一个软件流程。您必须有某种方法可以验证您没有向后移动。

SCRUM告诉您每日可交付成果，并始终以牺牲速度为代价向前发展。

当有人说我想做CI或Agile或Scrum时，对我来说这自动意味着需要进行单元测试（不是上面提到的集成测试），而是每个单独的移动部件都有自己的单元测试

如果您进行集成测试，则不会以自包含的方式测试每个单独的部分。因此，您所证明的是，在一个流程中调用的方法是有效的，而不是您在MSIL中看到的每个可能的分支

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

9 个答案: