当我刚刚学习 Scrum 时，在我看来，在迭代的一部分中，你可能是一只鸡，但到了该做你的部分时，你就会变成一头猪。然后回去做一只鸡。这是正确的想法吗？您在迭代中的股份会在迭代期间发生变化吗？如果不是，那是如何工作的？因为当软件被构建时，它被计划、编码、测试、改进，然后它就完成了。我的想法有问题吗？谢谢！
Tad
问问题
9027 次
9 回答
13
除非您既是团队成员又是项目的利益相关者，否则您不能两者兼而有之。
猪是 Scrum 团队的成员——产品负责人、Scrum 主管、开发人员、测试人员等等。
鸡是想要产品的人——客户、管理层。
只有当产品是为团队服务时，我才能看到一个人在哪里。然后，团队不仅是猪（做工作，把它全部上线），也是想要产品的客户。
于 2009-08-10T19:14:30.357 回答
3
如果您对项目的成功或失败处于危险之中，那么您就是一头猪。
于 2009-08-10T19:12:22.310 回答
2
在迭代期间，你要么是猪，要么是鸡——你不能两者兼而有之。由于团队成员是 sprint 的参与者，他们应该始终致力于迭代积压工作。
假设“迭代”是指团队为生产潜在可交付产品增量（也称为“冲刺”）设置的时间段。
于 2009-08-10T19:12:56.273 回答
2
根据我对 SCRUM 的经验和理解，您的角色不应该在冲刺期间发生变化。不管你是鸡还是猪。
猪是完成工作的人（例如开发人员），而鸡是通过猪的工作而有所收获的人（例如产品所有者）。
编辑：刚刚找到了鸡和猪的这个“定义”：猪和鸡的经典故事
于 2009-08-10T19:15:01.293 回答
1
在我看来，您要么是鸡，要么是猪，它在迭代/冲刺期间不会改变。
如果你经历了这样的角色变化，你的 sprint 可能太长了，或者这个人一直都是个小鸡。
于 2009-08-10T19:10:30.223 回答
1
总结：在 Sprint 期间交换猪和鸡角色可能会危及在它开始之前签订的初始合同，从而危及成功交付。
猪和鸡的概念只是一个 Scrum 隐喻，用于在项目管理领域中被称为产品开发周期的直接和间接利益相关者。
猪和鸡开餐馆的简短、令人难忘和有趣的故事是一个很好的隐喻，有助于解释利益相关者的概念，而无需诉诸管理术语。
Scrum的一大优点是它使非管理者可以使用当前的管理技术。就像我们对软件系统所说的那样，使其成为消费者级或用户友好的。
那么在开发周期中，鸡（间接利益相关者）是否可以变成猪（直接利益相关者），反之亦然？一个人可以同时是鸡和猪吗？
回答后者是肯定的“不”：在单个项目的上下文中，一个人只能是鸡或猪，以更大的赌注为准。整个鸡猪分工的想法是在项目阶段将更大的决策权和责任赋予直接参与并对积极成果感兴趣的人（猪），限制来自有时强大的外部参与者（鸡）的干扰。
项目期间角色可以改变吗？是的，它可以，但不是在Sprint期间。Scrum 是一种敏捷开发方法，旨在让整个团队对结果承担集体责任。敏捷（尤其是 Scrum）提倡“一劳永逸”的态度。并非所有结构化方法都这样做，例如，瀑布式的弱点之一是，一旦接受了临时可交付成果（即功能规范），一些团队成员的责任就结束了，这将任何在项目中进一步浮出水面的问题转移到不幸的团队成员的肩膀，他们有责任在后期开发阶段使项目成功（通常是开发人员）。
Scrum 迭代，称为 Sprint，旨在提供从规范到现成产品的完整变化，而不是某种临时可交付成果。团队为决定 Sprint 中的内容提供了大量输入，随后必须集体致力于交付变更。这在团队和外部世界之间建立了合同。
在 Sprint 期间更改角色可能会危及此合同。如果一头猪变成了一只鸡，他或她不再负责看到 Sprint 完成，而将处理工作中任何缺点的重担推到其余团队成员的肩上。当在 Sprint 中鸡变成猪时，他们无法切实地致力于在加入之前就已达成共识的事情。因此，最好在 Sprint 期间角色保持不变。
于 2009-08-19T12:27:13.907 回答
0
我主要与初创公司合作，包括我自己的一家。在所有情况下，我都扮演精益开发称为“首席工程师”或“产品总监”的角色。我是首席技术专家，也是产品经理和客户的代言人。如果你的组织中有这样的人，那么你可能不需要像 Scrum 正统建议那样严格地划分角色，你可以开始利用不需要被锁定的方法论传统和方法就像 Scrum 经常做的那样。
于 2010-07-13T04:09:20.860 回答
0
在一个按规定进行 Scrum 的团队中，你在 sprint 中只能是鸡或猪。并且可能大多数 Scrum 专家会告诉你，团队也不应该在 Sprint 之间改变。
如果您是团队的一员，那么您的股份在 Sprint 期间不会发生变化——因为您承诺自己生成的一段潜在可交付代码是由整个团队负责的。如果您以“我只负责该功能的后端部分，它将在 sprint 的前半部分构建”之类的方式思考，那么您就走错了路。
然而，按照书本上的 Scrum 而不考虑什么对你来说是正确的可能是错误的决定——你可能有一些非常有价值但也有其他责任的团队成员（在我看来不是很好）。
于 2009-08-10T19:23:10.510 回答