Scrum - 你是鸡还是猪？
当我刚刚学习 Scrum 时，在我看来，在迭代的一部分中，你可能是一只鸡，但当需要尽自己的一份力量时，你就变成了一头猪。 然后又变回鸡了。 这是正确的想法吗？ 您在迭代中的利益会在迭代期间发生变化吗？ 如果不是，那是如何工作的？ 因为当软件被构建时，它会被规划、编码、测试、完善，然后就完成了。 我的想法有错吗？ 谢谢！
As I am just learning about Scrum, it seems to me that for part of an iteration you may be a chicken but then become a pig when it comes time to do your part. Then go back to being a chicken. Is this correct thinking? That your stake in the iteration will change during an iteration? if not how does that work? because when software is built it gets planned,coded, tested, refined, then it is done. I'm a wrong in my thinking?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
除非你们既是团队成员又是项目的利益相关者，那么你们就不是两者兼而有之。
猪是 Scrum 团队成员——产品负责人、Scrum Master、开发人员、测试人员等。
鸡是想要产品的人——顾客、管理层。
我唯一能看到一个人两者兼而有之的时候是当产品是为团队服务的时候。 那么，团队不仅是猪（做工作，把一切都放在线上），而且是想要产品的客户。
Unless you are both on the team and a stakeholder in the project, then you are not both.
Pigs are the Scrum team members - product owner, scrum master, developers, testers, and so on.
Chickens are the people who want the product - customers, management.
The only time I can see where a person is both is when the product is for the team. Then, the team are not only the pigs (doing the work, putting it all on the line), but also the customers who want the product.
如果你的屁股与项目的成功或失败有关，那么你就是一头猪。
You are a pig if your ass is on the line with regard to the project's success or failure.
根据我的经验和对 SCRUM 的理解，您的角色在冲刺期间不应改变。 要么你是鸡，要么你是猪。
猪是完成工作的人（例如开发人员），鸡是通过猪完成工作而获得某些东西的人（例如产品负责人）。
编辑：刚刚找到了鸡和猪的“定义”：猪和鸡的经典故事
Based on my experience and understanding of SCRUM your role shouldn't change during a sprint. Either you're a chicken or a pig.
A pig is the one who gets the work done (e.g. a developer), and a chicken is the one who gains something by the pigs doing their work (e.g. the product owner).
EDIT: Just found this "definition" of chicken and pigs: The Classic Story of the Pig and Chicken
在迭代期间，你要么是猪，要么是鸡——你不能两者兼而有之。 由于团队成员是冲刺的参与者，他们应该始终处理迭代积压工作。
假设“迭代”是指团队为生产可能可交付的产品增量而设置的时间段（也称为“冲刺”）。
For the duration of the iteration you're either a pig or chicken - you can't be both. As the team members are the particiapants of the sprint they should always be working on the iteration backlog.
Assuming that by "Iteration" you mean a time period set by the team for producing a potentially shippable product increment (also known as a "sprint").
在我看来，你要么是鸡，要么是猪，它在迭代/冲刺期间不会改变。
如果你经历过这样的角色变化，你的冲刺可能太长了，或者这个人一直都是个小鸡。
In my opinion you are either a chicken or a pig, it does not change during an iteration / sprint.
If you experiance roles changing like that your sprints are probably too long, or the person was really a chicked the whole time.
有一篇关于猪和鸡的文章 这里部分内容如下：
维基百科说产品负责人、Scrum Master 和团队是“猪”角色利益相关者（客户、供应商）和管理者是“鸡”角色。
基于此，我想说一般来说你不会在猪和鸡之间进行转换。
There's a pig and chicken article here that says in part:
Wikipedia says that Product Owner, Scrum Master, and Team are "pig" roles and Stakeholders (customers, vendors) and Managers are "chicken" roles.
Based on that, I'd say generally you're not changing between pig and chicken.
总结：在 Sprint 期间交换猪和鸡的角色可能会危及开始前签订的初始合同，从而危及成功交付。
猪和鸡的概念只是 Scrum 的一个比喻，它在项目管理领域被称为 产品开发周期的直接和间接利益相关者。
这个简短、令人难忘且有趣的猪和鸡开办餐馆的故事是一个很好的比喻，有助于解释利益相关者的概念，而无需诉诸管理术语。
Scrum 的一大优点是，它使非人员可以访问当前的管理技术。 -经理们。 正如我们所说的软件系统一样，使其成为消费者级或用户友好型。
那么，在开发周期中，鸡（间接利益相关者）是否可以变成猪（直接利益相关者），反之亦然？ 一个人可以同时是鸡和猪吗？
对于后者的回答是明确的“不”：在单个项目的背景下，一个人只能是鸡或猪，以赌注较大者为准。 整个鸡和猪部门的想法是在项目阶段给予直接参与并对积极结果感兴趣的人（猪）更大的决策权和责任，限制来自有时强大的外部参与者（鸡）的干扰。
项目期间角色可以改变吗？ 是的，可以，但不能在 Sprint 期间。 Scrum 是一种敏捷开发方法，旨在让整个团队对结果承担集体责任。 敏捷（尤其是 Scrum）提倡“一为所有、一为一”的态度。 并非所有结构化方法都这样做，例如 瀑布 的弱点之一是某些团队成员的责任一旦临时交付成果被接受（即功能规范），项目就结束了，这将把项目中进一步出现的任何问题的重量转移到不幸的团队成员的肩上，他们有责任在后期的开发阶段使项目取得成功（通常是开发商）。
Scrum 迭代（称为 Sprint）旨在提供从规范到即用产品的完整变更，而不是某种临时可交付成果。 团队提供了大量的意见来决定冲刺的内容，随后必须共同致力于交付变革。 这在团队和外界之间建立了契约。
在 Sprint 期间更改角色可能会危及此合同。 如果猪变成了鸡，他或她就不再负责完成冲刺，而将处理工作中任何缺陷的重担转移到了其余团队成员的肩上。 当鸡在冲刺期间变成猪时，他们无法真正致力于在加入之前达成一致的事情。 因此，最好角色在 Sprint 期间保持不变。
Summary: swapping pig and chicken roles during Sprint can endanger initial contract made prior to it's start, thus endangering successful delivery.
The concept of pig and chicken is just a Scrum metaphor for what is otherwise known in project management field as direct and indirect stakeholders of the product development cycle.
The short, memorable and funny story of pig and chicken starting up an eatery makes a great metaphor and helps explaining the stakeholder concept without resorting to management lingo.
One of the great things about Scrum is that it makes current management technology accessible to non-managers. Making it consumer-grade or user-friendly as we would say about software systems.
So can a chicken (indirect stakeholder) turn into pig (direct stakeholder) and vice versa during the development cycle? Can a person be both a chicken and a pig at the same time?
Answering the latter it’s a definite “no”: a person can only be either a chicken or a pig in the context of a single project, whichever stake is greater. The whole chicken and pig division idea is about giving greater decision making power and responsibility during a project stage to the people who are directly involved and interested in the positive outcome (pigs), limiting interference coming from sometimes powerful external players (chickens).
Can the role change during the project? Yes it can, but not during Sprint. Scrum being an Agile development methodology it aims at putting collective responsibility for the outcome on the entire team. Agile (and especially Scrum) promotes “one-for-all and all-for-one” attitude. Not all structured methods do that, for instance one of Waterfall weaknesses is that some team members’ responsibility ends as soon as an interim deliverable is accepted (i.e. functional spec) which shifts the weight of any issues that surface much further into the project onto the shoulders of unfortunate team members who have the responsibility to make the project successful during the later development stages (usually developers).
Scrum iteration, called Sprint is aimed at delivering a complete change from spec to ready-to-use product, instead of some sort of interim deliverable. The team provides a lot of input into deciding what goes into the Sprint and subsequently has to collectively commit itself to delivering the change. That creates a contract between the team and outside world.
Changing the roles during the Sprint can endanger this contract. If a pig becomes a chicken, he or she is no longer responsible for seeing the Sprint to completion putting the burden of dealing with any shortcomings in their work onto the shoulders of remaining team members. When a chicken becomes a pig during a Sprint they cannot realistically commit themselves to something that has been agreed before they came on board. Hence it’s best when the roles stay unchanged for the duration of Sprint.
在一个按规矩进行 Scrum 的团队中，你在冲刺期间只能是鸡或猪。 也许大多数 Scrum 专家都会告诉您，团队也不应该在 Sprint 之间进行更改。
如果您是团队的一员，您的权益在 Sprint 期间不能改变 - 因为整个团队负责您承诺自己生成的那段可能可交付的代码。 如果您以“我只负责该功能的后端部分，该功能将在冲刺的前半段构建”之类的方式思考，那么您就走错了路。
然而，按照书本进行 Scrum 而不考虑什么对你来说是正确的可能是错误的决定 - 你可能有一些非常有价值的团队成员，但也有其他责任（在我看来不是很好）。
In a Team that does Scrum by the book, you can only be a chicken or a pig during a sprint. And probably most Scrum Gurus will tell you that Teams should not change in between Sprints either.
If you are part of the Team, your stake cannot change during the Sprint - because it is the whole Team that is responsible for the piece of potentially shippable code that you commited yourself to produce. If you think in ways like "I am only responsible for the backend part of that feature, which will be built in the first half of the sprint" you are on the wrong track.
However, doing Scrum by the book without thinking about what is right for you may be the wrong decision - you might have some team members who are very valuable but also have other responsibilities (not very good in my opinion).
我主要与初创公司合作，包括我自己的一家。 在所有情况下，我扮演的角色被精益开发称为“首席工程师”或“产品总监”。 我是首席技术专家、产品经理和客户的代言人。 如果您的组织中有这样的人，那么您可能不需要像 Scrum 正统观念所建议的那样严格划分角色，并且您可以开始利用不需要被锁定的方法传统和方法就像 Scrum 经常做的那样。
I work primarly with startups, including one of my own. In all cases I act in a role that Lean Development calls "Chief Engineer" or "Product Director". I'm the lead technologist as well as the product manager and the voice of the customer. If you've got someone like this in your organization, then you might not need to departmentalize roles as strictly as Scrum orthodoxy suggests, and you can start to make use of methodological traditions and approaches that don't need to be as locked-down as Scrum often is.