SCRUM应该用于仅由一个人参与的项目吗？

在我们公司，我们有一个团队同时处理3个不同的项目，每个项目通常只有一个或两个人参与。项目工作通常涉及掌握新技术和/或解决错误，而这两种情况都会导致难以估计的任务。在这种情况下，管理层仍然坚持使用SCRUM，并且不允许在sprint的末尾为意外情况分配安全缓冲区。尽管几乎每个人都从事不相关的软件组件或不同软件项目的工作，但整个团队都举行了站立会议。

• 我想知道是否有人看到SCRUM对于具有单个开发人员和模糊任务的项目是否运作良好，您如何使过程正常进行？

• 如何估算涉及研究/掌握新技术的任务（这涉及学习新的编程语言，平台和开发工具）？

• 有没有人成功说服管理层不要在特定项目中使用SCRUM？如果是，哪种论点最成功？

谢谢！

查找“个人Scrum” ...我已经看到两三篇有关此操作的博客文章。Full Scrum的某些概念无法完美地转化为单人团队。（我的经验-大约4个人的“临界数量”似乎使团队工作正常。）

例如http://blog.jgpruitt.com/tag/personal-scrum/。

但是像任务估计，速度和时间限制冲刺这样的任务列表受“保护”的方法即使对于1也能很好地工作。

当然不是。您的日常工作非常短暂，而且令人无聊！

您可以挑选自己认为会帮助您的位，尽管不必完全填满卡片，还是有意义的。在一定时间后停止检查您的进度也很有意义。但是，如果您要这样做，还可以查看看板，Crystal和所有其他敏捷方法，以找到有助于您的知识。

不，没有团队，您无法做混乱。SCRUM定义的团队是“负责管理自己以开发产品的跨职能人员小组”，这是SCRUM中的重要角色。

根据http://www.scrum.org/storage/scrumguides/Scrum_Guide%202011.pdf

开发团队的规模 最佳开发团队的规模要小到足以保持敏捷，大到足以完成重要的工作。少于三个开发团队成员的成员会减少互动并导致生产率提高。较小的开发团队可能会在Sprint期间遇到技能限制，从而导致开发团队无法交付可能发布的增量。拥有超过九名成员需要太多的协调。大型开发团队会为经验过程的管理带来太多的复杂性。产品所有者和Scrum主角色不包括在此计数中，除非它们还执行Sprint Backlog的工作

但是，您仍然可以保持敏捷，并可以使用SCRUM的其他特征，例如维护产品/冲刺积压，计划和在冲刺/迭代下进行工作，查看并从所有涉众那里获得反馈以及重新规划等等。请阅读有关scrum的更多信息，因为这里介绍的内容更多。

我在类似的商店工作。正如这里的其他人所指出的，您所描述的可能是敏捷的，但并非混乱。我还要补充一点，后备日志和冲刺是否有意义取决于它是新工作还是维护以及持续的支持。如果是前者，那么瀑布式方法对于单人团队来说更有意义。如果不是，从项目经理的角度来看，如果他们的投资组合中有多个项目，那么他们正在做的事情似乎是一个好方法。

对于敏捷爱好者来说，仅提及使用瀑布就是牺牲。但是人们需要使用常识。

让我举一个我最近的项目中的例子。我领导着一个由3个开发人员组成的团队，在一个为期5个月的时间表上重新设计了两个主要网站。我们每天都有站立会议。但这是一个瀑布式项目，因为这是一个很小的团队，生命周期有限，并且开发人员都是致力于该项目的短期承包商，直到启动为止。该项目遵循非常传统的瀑布生命周期。绝对没有错。除了我们以“敏捷”的方式工作外，我们还会举行独立会议，并保持敏捷开发的最佳实践。我们的小团队免于参加大团队的每周冲刺计划会议。为什么？因为我们没有每周部署。而且我们的团队没有依赖或影响任何其他团队正在完成的工作。实际上，我们几乎是自主地工作。网站启动后，我们便过渡到敏捷过程，以进行持续的维护和支持。其他开发人员现在正在其他地方工作。所有增强功能均根据定期部署进行规划。

关键是，最好使用对每个项目的规模，复杂性和成熟度最有意义的过程。如果您正在做大量研究，那么很难对接下来的五个月进行估算，因此敏捷可能是比瀑布更好的方法。

问题的部分原因是有些人似乎认为您能够提前计划下五个冲刺。我以前就是这种情况。您不应该计划两个以上的Sprint，因为如果您这样做的话，那么您将无法实现Sprint的全部目的。冲刺被认为是在一定时间内提供切合实际的增强效果的承诺。您不应该承诺自己不确定的事情。Sprint计划本质上是短期计划，但这就是重点。如果您的计划很长，请考虑将其分解为较小的交付项。或根据您在SDLC中的位置设置检查点会议。

Sprint计划被认为是对在一定时间内完成的保证的现实承诺。如果您发现计划没有考虑未知变量，那么也许您应该开始给出范围或悲观的估计。或如其他建议那样，使用故事点。冲刺也不应完全预订，以免出现打滑和其他重要任务。

您的团队中不应只有一个人，我怀疑确实存在。SCRUM中的“团队”不仅仅是开发人员。您是客户代表，Scrum管理员，开发人员等吗？您真的是唯一从事与此产品相关的任何事情，做出决定或试图出售该产品的人吗？

至于评估研究，您可以将其作为一个故事进行。您专门为“ Research XXX”制作了一个故事，并为其提供了故事要点（请记住，您不是在这里估计时间，而是在估计难度）。即使您需要研究技术，您也应该能够相当充分地估计实现某些功能的难度。有时后一个事实只是将一个故事变成“最大难度”。

不，您确实不应该与所有开发人员见面。您应该与您的团队见面，而团队又不仅仅是开发人员。

祝好运。希望你们能弄清楚。

假设您确实有产品所有者和Scrum管理员（如果不是，则不是Scrum），Scrum可以为一个团队工作。就像在多人团队中使用Scrum工件（积压，分解图表）一样。现在关于会议：

每日站立：您将使用每日站立来更新每个人，例如产品所有者，scrum管理员或对进度感兴趣的其他人。Scrum管理员将使用此会议来了解您遇到的任何障碍。产品负责人可以在需要时帮助您重新评估范围。

Sprint审查：在每个Sprint结束时，您将把软件的工作增量移交给产品所有者或客户。如果冲刺的目标是学习“某些东西”，您将演示可以由管理层（即PoC的客户）使用的PoC。