Тогда более-менее логично, что таска на фронтенд прилетит скорее фронтендеру, верно? А с кем он тогда играет в planning poker?
верно. для небольших команд, где каждый занимается своей областью, планинг покер не работает. Как правило, оценка скорее нужна для того, чтобы заказчик, допустим, в лице продакт оунера, мог планировать какие-либо действия. Допустим, очередность выпуска фич, или же включения оных в релиз. Когда, например, фронтендер всего один, то его задача дать свою оценку, и обосновать ее.
Ну, во-первых непонятно, откуда вы взяли "унижать". Во-вторых при "традиционном" менеджменте проблемы нет. Собственно в посте написано, как это решается. Судя по тому, что в скраме эту проблему с разной степенью элегантностью пытаются проигнорировать, решения нет, верно?
ну, у вас был написан пример с "Я старше, делаем как я сказал". Если бы я в своей команде услышал от кого-то нечто подобное, потом бы состоялся не самый приятный диалог с таким разработчиком.
Суть оценки через планнинг покер - не упустить часть работы. Я никогда не сталкивался на практике, что кто-то оценивает задачу в 3, а другой в 13. Обычно разбежка в пределе одного шага. И в любом случае, несопадение мнений лишь призывает к обсуждению. Если никак не удается сойтись на одной цифре, обычно берут более высокую.
Заказчик хочет пообщаться с ответственным.
ни в коем случае. если приведенный вами диалог произойдет в присутствии заказчика, велик шанс, что пойдут гулять все вместе с Ермолаем.
давайте так. в скраме есть понятие velocity. это отношение выполненных задач к запланированным. velocity > 70% - это хорошо. Если Петя зафакапил одну таску из 5-6 запланированных - это в принципе, обычная ситуация, и тут либо нужно общаться с заказчиком о том, что нужно снижать кол-во запланированных сторипоинтов на спринт, потому что бла-бла-бла(много времени на митинги/планирование/etc), либо, если он этого не понимает, искусственно завышать оценку задачи, закладывая в нее риски. В свободное время всегда можно дописать тестов или отрефакторить что-либо.
Если же таска оказалась реально слишком большой, то виноваты все, и в частности Петя со скрам-мастером. Не потратили время на планирование, не разбили на мелкие подзадачи. Скрам мастер бакланил весь спринт и не видел, что у Пети проблемы? или Петя ссал всем в уши, что все хорошо, а на деле нет? Нужно разбираться, для этого есть ретроспектива.
Леша - баклан. У стори есть Acceptance Criteria, которых придерживаются и qa, и разработчики. Поэтому, либо кто-то невнимательно их читал, либо виноваты те, кто эту стори писали(как правило, продакт оунер), а потом виноваты те, кто оценивал стори без внятных критериев.
В скраме есть проджект менеджер и деливери менеджер? А какие у них функции?
в скраме таких ролей нет. в проджект менеджменте есть. если у вас проект не уровня "онлайн магазин за 2 месяца", а что-то серьезное, или аутсорс, прости господи, то без таких людей не обойтись. кто-то же должен контролировать весть проект/продукт, людей, оборудование, риски, релизы и т.д. мы же sales отдел тоже в скрам не включаем, а они есть :)
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
верно. для небольших команд, где каждый занимается своей областью, планинг покер не работает. Как правило, оценка скорее нужна для того, чтобы заказчик, допустим, в лице продакт оунера, мог планировать какие-либо действия. Допустим, очередность выпуска фич, или же включения оных в релиз. Когда, например, фронтендер всего один, то его задача дать свою оценку, и обосновать ее.
ну, у вас был написан пример с "Я старше, делаем как я сказал". Если бы я в своей команде услышал от кого-то нечто подобное, потом бы состоялся не самый приятный диалог с таким разработчиком.
Суть оценки через планнинг покер - не упустить часть работы. Я никогда не сталкивался на практике, что кто-то оценивает задачу в 3, а другой в 13. Обычно разбежка в пределе одного шага. И в любом случае, несопадение мнений лишь призывает к обсуждению. Если никак не удается сойтись на одной цифре, обычно берут более высокую.
ни в коем случае. если приведенный вами диалог произойдет в присутствии заказчика, велик шанс, что пойдут гулять все вместе с Ермолаем.
давайте так. в скраме есть понятие velocity. это отношение выполненных задач к запланированным. velocity > 70% - это хорошо. Если Петя зафакапил одну таску из 5-6 запланированных - это в принципе, обычная ситуация, и тут либо нужно общаться с заказчиком о том, что нужно снижать кол-во запланированных сторипоинтов на спринт, потому что бла-бла-бла(много времени на митинги/планирование/etc), либо, если он этого не понимает, искусственно завышать оценку задачи, закладывая в нее риски. В свободное время всегда можно дописать тестов или отрефакторить что-либо.
Если же таска оказалась реально слишком большой, то виноваты все, и в частности Петя со скрам-мастером. Не потратили время на планирование, не разбили на мелкие подзадачи. Скрам мастер бакланил весь спринт и не видел, что у Пети проблемы? или Петя ссал всем в уши, что все хорошо, а на деле нет? Нужно разбираться, для этого есть ретроспектива.
Леша - баклан. У стори есть Acceptance Criteria, которых придерживаются и qa, и разработчики. Поэтому, либо кто-то невнимательно их читал, либо виноваты те, кто эту стори писали(как правило, продакт оунер), а потом виноваты те, кто оценивал стори без внятных критериев.
в скраме таких ролей нет. в проджект менеджменте есть. если у вас проект не уровня "онлайн магазин за 2 месяца", а что-то серьезное, или аутсорс, прости господи, то без таких людей не обойтись. кто-то же должен контролировать весть проект/продукт, людей, оборудование, риски, релизы и т.д. мы же sales отдел тоже в скрам не включаем, а они есть :)