Толпа - действительно ли Вы - цыпленок или свинья? [закрытый]

На мой взгляд, вы либо цыпленок, либо свинья, это не меняется во время итерации / спринта.

Если вы испытываете такую ​​смену ролей, ваши спринты, вероятно, слишком длинные, или этот человек все время был пьяным.

В команде, которая выполняет Scrum по правилам, вы можете быть только цыпленком или свиньей во время спринта. И, вероятно, большинство Scrum Gurus скажут вам, что команды не должны меняться между спринтами.

Если вы являетесь частью команды, ваша ставка не может измениться во время спринта, потому что это вся команда, которая несет ответственность за часть потенциально готового к отправке кода, которую вы взяли на себя обязательство создать. Если вы думаете так: «Я отвечаю только за внутреннюю часть этой функции, которая будет построена в первой половине спринта», вы ошибаетесь.

Однако, выполняя Scrum по инструкции, не задумываясь. Решение о том, что для вас правильно, может быть неправильным - у вас могут быть очень ценные члены команды, но у них есть и другие обязанности (на мой взгляд, не очень хорошо).

Если вы не входите одновременно в команду и не участвуете в проекте, тогда вы не оба.

Свиньи - члены команды Scrum: владелец продукта, мастер Scrum, разработчики, тестировщики, и т. д.

Цыплята - это люди, которым нужен продукт - клиенты, менеджмент.

Единственный раз, когда я могу увидеть, где находятся оба человека, - это когда продукт предназначен для команды. Тогда в команду входят не только свиньи (выполняющие работу, ставящие все на карту), но и покупатели, которым нужен продукт.

Ты свинья, если твоя задница зависит от успеха или провала проекта.

Здесь есть статья о свиньях и цыплятах , в которой частично говорится:

Википедия говорит , что владелец продукта, мастер Scrum и команда - это «свиньи» роли, а заинтересованные стороны (клиенты, поставщики) и менеджеры - «куриные» роли.

Исходя из этого, Я бы сказал, что обычно вы не меняете со свиньи на курицу.

Исходя из моего опыта и понимания SCRUM, ваша роль не должна меняться во время спринта. Либо вы курица, либо свинья.

Свинья - это тот, кто выполняет работу (например, разработчик), а курица - это тот, кто получает что-то от свиней, выполняющих свою работу (например, владелец продукта) .

РЕДАКТИРОВАТЬ: Только что нашел это «определение» курицы и свиней: Классическая история свиньи и курицы

На протяжении итерации вы либо свинья, либо курица - вы не можете быть обоими. Поскольку члены команды являются участниками спринта, они всегда должны работать над невыполненной итерацией.

Предполагая, что под «Итерацией» вы подразумеваете период времени, установленный командой для производства потенциально готового к поставке приращения продукта (также известного как «спринт»).

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.

Я работаю в основном со стартапами, в том числе и со своим. Во всех случаях я выступаю в роли, которую Lean Development называет «главным инженером» или «директором по продукту». Я ведущий технолог, а также менеджер по продукту и голос клиента. Если у вас есть такой человек в вашей организации, то вам, возможно, не потребуется разделять роли на отделы так строго, как предлагает ортодоксия Scrum, и вы можете начать использовать методологические традиции и подходы, которые не должны быть столь жесткими. как это часто бывает в Scrum.