是否需要最小的团队规模才能从敏捷中获益？

Question

我在一家公司工作，该公司多次削减其开发团队的规模，以至于以前的10人团队现在每个产品只有一个开发人员(以及5个产品之间共享的几个测试人员)。我们曾经是一个相当重的过程，是从一家大公司剥离出来的，并继承了它的多级瀑布过程。

从执行团队那里可以看出，我们发布软件的速度不够快，这很可能是这个过程的错误(这可能是原因之一，尽管90%的人力流失可能没有帮助)。人们一直在推动我们转向敏捷过程，以避免花费时间编写设计文档等等。

我想我只是好奇转向敏捷是否会对单一团队有所帮助。我的理解是，很多好处来自于团队成员之间更高的知名度和更多的沟通，但我知道我在做什么，我的经理也知道。我已经做了TDD，因为我们没有人来测试这个产品。

TL;DR版本:我想我真正想问的是，你能用一个人的“团队”来实现敏捷吗?你认为这样做有什么好处吗?或者它通常对大型团队更有效吗？

Answer 1

查看https://groups.google.com/forum/#!forum/solo-scrum

和https://stackoverflow.com/questions/829497/agile-methods-specifically-taylored-to-working-solo

更新：

第一个链接是到Solo Scrum Google Group。这里讨论的最明显的好处是使用时间限制的冲刺来管理范围和确定项目的速度--这都是非常好的事情。

第二个链接指向之前关于Stackoverflow的讨论，这可能表明这是一个重复的问题，但我认为链接到它会更有用。它反过来链接到http://c2.com/xp/ExtremeProgrammingForOne.html，它有很多关于XP的链接和信息(sans对编程)。

Answer 2

one

团队的最小规模是一个

敏捷是原则和实践的集合，您可以选择这些原则和实践来调整工作流程。如果你是一人一人的节目，你可以选择适合你的。

XP/TDD非常适合一人团队。你可以跳过日常的站立会议和配对编程的潜在浪费时间的做法。

Answer 3

您的主要问题不是“走向敏捷”，而是文档。这篇关于斯科特·安布勒的敏捷/精益文档的文章对你和你的同事来说可能是个有趣的读物。

敏捷并不是不记录下来的。您仍然需要文档，这只是您选择了什么和如何文档，以便最大限度地发挥价值，同时尽量减少在创建它上花费的时间。您仍然捕获需求，执行设计，记录您的实现决策，并在整个生命周期中根据需要具有完全的可跟踪性，但只能在项目需要的范围内进行。不捕获关键项目信息和决策是项目失败的肯定方法。

为了获得一点乐趣，以下是我对个人敏捷的看法：

敏捷方法是为团队设计的。Scrum通常需要3-9个开发人员以及一个产品负责人和Scrum (并且产品负责人和Scrum不应该是同一个人)。极端编程通常需要4-7人。

原因是在主流敏捷方法中，许多常用的实践并没有缩小到单个开发人员。这方面的一个主要例子是在XP中强调对编程和代码评审--对于一个单独的开发人员来说，你真的不能这样做。

一个开发人员可以是敏捷的，但它必须是一个定制的过程。大多数敏捷方法都需要结合持续集成、单元测试、测试驱动开发、重构、接吻和YAGNI原则等等。其中许多已经成为“最佳实践”，甚至在更多计划驱动的方法上也是如此。一个单独的开发人员没有理由不能利用其中的一些，只要他们不干预软件的生产和交付。