针对专家团队的Scrum

Scrum最适合具有通才成员的团队，即，至少2人可以完成相同任务的团队。我的主要关注点是为由专家组建的团队找到合适的解决方案以适应混乱（保持什么，删除什么，改进什么）？

假设您有一个由5个开发人员组成的团队（不是真正的，仅作为示例）：

1. 一位在C语言方面很强的数学家；
2. 一名数据库开发人员；
3. 一名Web开发人员；
4. 一位UX / GUI开发人员；
5. 一位软件架构师；

在这里，所有人都是专家，没有人可以替代其他人（我不在乎建立这样一个团队的风险，我想专注于Scrum）。因此，在混乱的情况下，这是我的想法：

1. 毫无用处的春季计划：的确，当数学家说某项特定任务的价值为2分时，没人会投票反对他。
2. 无用的团队速度指标：由于每个人都可以为自己的任务分配任意数量的点，因此计算速度是没有意义的；
3. 用每周一次（较长）的Scrum会议代替每天的Scrum会议：由于团队中的每个成员都在按自己的任务进行工作，因此，每天的Scrum会议对于保持“团队合作精神”非常重要。但是，每天的Scrum会议应该持续15分钟左右。显然这不足以了解其他人正在做和将要做的事情。而且，数学家在大多数时候会回答相同的问题：“我仍在做％＆Lo（+？$$ ++＆）” ...每周的会议会花更多的时间。为了在“初始” Scrum会议和“每周” Scrum会议之间保持相同的会议时间，每个每周的Scrum会议应持续（每周5天，有4个星期的冲刺，其中Sprint会议持续4个小时，每日会议持续15分钟）： （4 * 60 + 20 * 15）/ 4 =>

还是Scrum仍然可用？也许应该使用另一种敏捷技术？

Scrum不是灵丹妙药。并非每个项目都必须使用Scrum才能成功。但是，您所描述的情况听起来非常适合精益/看板。您不妨检查一下。

看板基本上只要求您做几件事情，这些都不与您描述的团队类型相矛盾：

• 可视化价值流，即看板。Scrum板是看板的特定应用；可以对其进行修改以实现专业化。
• 限制进行中的工作（WIP），以便分配给团队的工作量足以使工作不断进行-即在流的开始（设计）或结束（部署）中均不存在“障碍” 。

您可能想查看有关看板的一些参考：

• 看板乐园一日游
• 入门看板（免费电子书）

您过多地关注了Scrum /敏捷的机制，而没有考虑敏捷应该提供什么。您说如果数学专家估计得到2分，没有人可以说他错了。这不是目标。目标是为即将到来的冲刺达成一组可实现的目标。作为完成这项任务的专家，他将最清楚地知道需要多长时间。

“那么，如果他说谎或只是弄错了怎么办？” 你说。根据我的经验，人们估计不足，因为他们担心会因为给出准确的猜测而被枪杀。然后，其他处于估计状态的人会添加一个安全余量，以平衡所有内容，而奇特的懒惰人会过高估计，因此他们不必着急。在这三个中，第一个将在速度跟踪上进行拾取，第二个在听起来不正确时正在运行，第三个是您必须在Scrum之外处理的事情。

日常会议仍然有好处。即使团队成员都是专家，他们之间也存在依赖性。UI家伙可能正在等待服务器家伙来修复通知错误。服务器人员可能正在等待数学人员来弄清楚为什么计算错误。这还不仅仅是他们的工作如何影响您。如果团队成员由于“原因X”而经常被延迟，但他们没有花时间减轻将来发生的“原因X”的发生，那将是一个挑战。

如果您拥有像您描述的那样的资格的专家，那么您认为每个人都在完成自己的任务，而很少需要与其他人进行沟通的假设是恕我直言的。实际上，要实现一项新功能（“用户故事”），您通常必须

• 改变你的数据库
• 添加或更改GUI或Web界面
• 结合正确的业务逻辑（也许您是“数学家”来了）
• 确保所有这些更改协同工作

因此，我想他们将需要像通才团队中那样交流更多，通才团队中的每个人都可以处理不同的应用程序/用户故事，从而自己对所有应用程序层进行所有必要的更改。因此，上面列出的来自Scrum的所有团队活动对于这样的团队都非常有意义。

当然，Scrum仍然适合您的情况，但其他框架也是如此。

要提供新功能，您可能需要全部或许多这些技能。为了使团队做出相互影响并共同努力的决策，他们需要进行沟通。Scrum会议之间的时间越长，否定计划会使团队流失的时间越长。通过每天开会，团队可以快速解决这些情况并提出新的计划。

我还要解决您提出的一些特定主题：

跨职能团队 如果一个团队具有实现sprint目标和/或产品积压项目所需的全部技能，则将被视为跨职能团队。但这并不意味着有2人每一项工作。

调整大小 重要的是要记住，我们正在调整业务问题或需求的大小，而不是解决方案或解决方案的一部分。例如，将社交媒体/ Twitter集成到我们的电子商务网站中是一个问题，需要UX，UI设计，编程，数据库以及Twitter API的知识。团队应该将其作为一个整体确定大小，因为他们将作为一个团队来交付此功能。此大小不会100％准确，但是总的来说，我们发现基于相对大小的预测更准确。这意味着有些会很高，有些会很低，并且总的来说，计算出的预测比估计的持续时间更准确。

毫无用处的春季计划 Sprint计划是时候与Scrum团队（开发团队+产品所有者+ Scrum负责人）合作，确定应该生产什么，并提出如何开始的计划。有些团队会将选择的产品积压项目分解为任务，而另一些团队则提出自己的进度方式，例如必须通过的测试（例如XP）。

这是两种方式的协作。为团队分配一组PBI并说“去”是独裁者的角色。团队正在与产品负责人进行谈判，以最大限度地缩短冲刺时间。

无用的团队速度度量标准 利用团队确定问题和业务需求的能力，这些问题和需求贯穿了体系结构/系统，过去的经验告诉我们在一致的时间范围内（冲刺）已经交付了多少团队，我们现在可以提供团队预测在剩余的积压中。

同样，没有两个冲刺会是相同的，并且您使用的产品积压项目的样本集越小，估计误差的分布就越小。像股票市场一样思考；它一直在上升，但这并不意味着我们就不会失望。总的来说，您可以赚钱，但是在任何给定的月，季度，年，您都会猜错。

用每周一次（更长）的Scrum会议代替每日Scrum会议。DailyScrum 可以为团队提供24小时的反馈周期，并为接下来的24小时进行计划提供机会。仅此而已。“三个问题”旨在帮助促进这一努力。

如果您有5天没有任何反馈，我认为您的任务不够细致。这只是我的观点，但这是基于我作为教练和团队成员的经验。团队应该更经常地讨论，计划和整合他们的工作。

结论 Scrum旨在促进学习并在交付与学习之间取得平衡（发生真正学习的地方）。随着时间的流逝，尝试使用您的流程和工具，并使用Scrum来检查影响。尝试从每日Scrum转移到每周Scrum，看看它是否有助于或损害团队提供正确功能的能力。那可能对您有用。