Scrum是否对所有成员都是业余爱好者的团队有效？

Question

我们建议在我们的IT项目中使用Scrum，我们的顾问会问我们是否适合我们，因为我们仍然是业余爱好者。

即使我们是业余爱好者，对我们Scrum是否合适？

Answer 1

讨论通常是对瀑布的敏捷，对吧？我正在链接article，但它是葡萄牙语，所以我会尝试传达它的一些想法：

瀑布就像国际象棋。你思考和计划很多，尽快预见每一个可能的问题。有很多计划，但只有在稳定和知名的领域才有意义，而这些领域的变化并不多。

敏捷就像足球（或许多集体运动）：决策是在游戏中完成的，应该快速完成。没有太多时间分析每一个后果。对于动态和不稳定的域而言，它是“理想的”，在这些域中，始终需要进行更改（例如，Web应用程序往往属于此类别）。需要注意的另一点是：即使你拥有最好的球员，如果他们不能成为一支球队，你就不会成为胜利者。

恕我直言，Scrum会很有用，因为：

• 每两周（或每个月，根据迭代时间），您将能够看到什么在起作用。这是非常有价值的，特别是作为一个“业余”团队，预计将更多地学习和发现事物。
• 作为业余爱好者，你可能无法预见到一切（这是敏捷的拥抱）
• 有更多的分享经验空间（站立式会议，回顾会议，甚至是计划会议）。并且您分享真实的经验（您必须每周编写代码而不仅仅是计划）

Answer 2

这就是问题。我认为Scrum会变得棘手，不是因为你的团队是一群业余开发人员，而是因为你的团队是一群Scrum业余爱好者。如果您拥有经验丰富的Scrum Master，您的团队可以获得Scrum的好处。然而，如果没有一个具有Scrum经验的专家，那么随着学习的进行，学习成本将会很高，而且很可能会很快离开Scrum路径。最好的情况是，你将采用一种改进的Scrum方法（这不一定是坏事。）我并不是说听起来很消极或怀疑你的团队练习Scrum的能力，最好先聘请具有Scrum经验的人。你的团队潜水。祝你好运。

Answer 3

我不同意。

的情况下Scrum更好

1. 你可以依靠“玩家”;和，
2. 要求可能会在你下面发生变化。

大学型项目通常有很好的要求和片状队员的潜力。

此外，您必须考虑在该环境中进行项目的目的。学生们在开始潜水之前需要思考，计划和讨论事情是如何发挥作用的。最后，scrum在紧密结合，快节奏的环境中持续沟通，效果最佳。这不太可能发生在学校作业上。

Scrum鼓励“让我们刚刚开始”的编程态度，再次，当你有经验丰富的专业人士通过经验知道预先避免的陷阱时，这是很好的。

Answer 4

没有人说你必须完全实现SCRUM。

我可以从个人经验中说，SCRUM非常适合'业余爱好者':)。在我的第四学期，我们必须在4个月的范围内完成一个项目。我们这个由4人管理的“半SCRUM”小组是这样的：

• 冲刺时间为2周
• 没有每日站立会议（我们身体接近，所以我们就把所有东西都拿走了）
• 从项目一开始，所有冲刺都有一个标题。这些是我们的里程碑。
• 我们有2周的缓冲时间，因为我们预计会延迟：）

SCRUM本身相当复杂，但冲刺，部分删除，领导和喜欢的想法都很棒。每个人理解这些概念并不需要超过一天的时间。对于我们来说，SCRUM确保我们在截止日期前准备好了一个顶级项目，并在开发过程中提供了大量反馈。也是最高级的：）

Answer 5

Scrum以及其他agile methodologies不适合由学生或其他缺乏经验的人组成的团队。

维基百科在the suitability of agile software development上有一个很好的部分。 Barry Bohem和Richard Turner，领先的软件工程师wrote a book，其中包括有助于确定计划驱动或敏捷方法在特定项目中是否更好的因素。计划驱动方法脱颖而出的案例之一是初级开发人员，其中包括学生和业余爱好者。

现在，这并不意味着您只需要使用计划驱动的方法。我个人认为，你能做的最重要的事情就是找到适合你团队的流程。您可以将敏捷方法（测试驱动开发，持续集成，结对编程）整合到一个计划驱动的环境中，该环境可以访问每个生命周期阶段一次。

Answer 6

总会有一些团队动力来解决日常站立，故事板和其他敏捷实践在团队中成熟的问题。我想到的最大问题是，你是否有足够的时间来获得一些冲刺和一些节奏在一组内形成后带来的好处。我建议在某些时候召集更有经验的Scrum来提供有关如何改进你所拥有的方法的反馈，作为方法的一部分，随着时间的推移，IMO会发展和演变。

所以，你可以使用Scrum，看看它是如何发展的。毕竟，每个人都必须在某个地方开始，我对这种方法的各种修改是很常见的。对于你将如何走路而言，有一些事情要说，这可能比你想象的更容易或更难。祝你好运，我确实意识到这很好地回应了Ben的很多答案。

Answer 7

我认为你的主要问题在于估计并跟踪计划的冲刺持续时间。在过去，我发现当资源不熟悉他们将要工作的编码环境时（这可能发生在采用新技术的专业人员身上），冲刺很容易脱轨。任务突破估计变得猜测，因此运行冲刺计划变得非常困难。

话虽如此，Scrum的元素在这种环境中非常有用;每日站立会议和迭代发布会立即浮现在脑海中。就个人而言，我不赞成“做所有的Scrum，或者你没有做Scrum”的口头禅。在您的方法中务实，并选择适合您的方法的元素。确保你加入了进行冲刺回顾的持续改进组件，这样你就可以继续进行精炼和增强，并且你将朝着正确的方向前进。