Комментарии 20
Разделение одной задачи на подзадачи обычно занимает в районе 5-30 минут, но на некоторые истории, состоящие из нескольких задач, в сложных случаях может уходить пара дней.
Вы за 30 минут должны весь объём спринта оценить, добрый вечер.
Посередине выполнения задачи размера 20, менеджер спрашивает у разработчика, когда тот закончит.
Интересный у вас agile и тамада весёлый :)
Вы за 30 минут должны весь объём спринта оценить, добрый вечер.
Когда мы оценивали с помощью Planning Poker на оценку 2-ух недельного спринта уходило не меньше полутора часа. Слишком много возникает вопросов к реализации и требованиям клиента. Пара дней уходит на большие истории, чтобы разобраться в том, что нужно делать и спроектировать решение. Так что это выходит за рамки оценки.
А сколько тикетов вы успеваете за пол часа оценить? Какого размера? Как часто во время работы над тикетом оказывается, что тикет сильно недооценен?
Хе-хе, если задаться целью, то и за пять минут можно весь спринт оценить. Если в постановке задачи > 10 букв, то два часа, если > 20, то четыре и так далее. Чем не метод оценки? Правда, грубоват, зато рррраз — и в работу сразу, команда не тратит время зря, лол.
Слишком много возникает вопросов к реализации и требованиям клиента.
Вы это у клиента выясняете прямо на PP?
Раньше на Planing Poker звали менеджера, который общался с клиентом. Иногда оказывалось, что менеджер тоже до конца не знает, чего хочет клиент. Тогда оценку задачи откладывали.
Потом стали выделять разработчика на проработку истории. Это сильно помогло, к моменту оценки командой все нюансы успевали выяснить с менеджером и клиентом.
Сейчас за любой историей закрепляются продукт оунер и архитектор, которые выясняют все требования и продумывают решение в общих чертах. Так что команде приходит задача, по которой уже нет вопросов к клиентам. Но все равно остаются нюансы, которые полезно продумать до оценки, и разбиение истории на части помогает их выявить.
Потом стали выделять разработчика на проработку истории. Это сильно помогло, к моменту оценки командой все нюансы успевали выяснить с менеджером и клиентом.
Сейчас за любой историей закрепляются продукт оунер и архитектор, которые выясняют все требования и продумывают решение в общих чертах. Так что команде приходит задача, по которой уже нет вопросов к клиентам. Но все равно остаются нюансы, которые полезно продумать до оценки, и разбиение истории на части помогает их выявить.
разбивать большие задачи на мелкие, и потом оценить их… выглядит как аджайл и планинг покер.
чем этот метод не планиг покер?
чем этот метод не планиг покер?
В Planning Poker историям дают относительные оценки. Например, от 0,5 до 40.
Можно разбивать истории до задач поменьше и оценивать их с помощью Planning Poker.
Мы же разбиваем истории до подзадач размером 1. Каждую подзадачу мы не оцениваем по какой-то шкале. Просто отвечаем на вопрос — она занимает ровно 1 story point или нет.
Можно разбивать истории до задач поменьше и оценивать их с помощью Planning Poker.
Мы же разбиваем истории до подзадач размером 1. Каждую подзадачу мы не оцениваем по какой-то шкале. Просто отвечаем на вопрос — она занимает ровно 1 story point или нет.
Существует множество способов оценить пользовательские истории. Мы используем собственную методологию, чтобы оценить и проработать задачи перед тем, как писать код. Как мы до этого дошли и почему наш подход лучше, чем Planing Poker, читайте под катом.Это не так. Посмотрите в Scrum Guide: Product Backlog refinement (http://www.scrumguides.org/scrum-guide.html#artifacts-productbacklog) — в статье вы описываете вашу реализацию этого процесса.
Это же не агильно
И исправьте везде по тексту статьи Definition of Done (критерии готовности) на Acceptance criteria (критерии приемки). Критерии готовности (http://www.scrumguides.org/scrum-guide.html#artifact-transparency-done) описывают общие условия готовности любых элементов бэклога, а частные критерии готовности конкретной работы — это критерии приемки.
Посмотрите в Scrum Guide: Product Backlog refinement (http://www.scrumguides.org/scrum-guide.html#artifacts-productbacklog) — в статье вы описываете вашу реализацию этого процесса.Не совсем. Наш способ оценки слишком дорогой, чтобы использовать его для оценки бэклога. Хотя и Planning Poker для этого мне кажется слишком затратным. Для оценки задач в бэклоге мы используем экспертную оценку одного-двух человек. Этого достаточно для приоритезации и при этом мы не тратим много времени на поддержку бэклога.
Делим историю на подзадачи и оцениваем мы непосредственно перед тем как брать их в спринт.
Прочитайте все-таки, что такое Product Backlog refinement:
Желательно, чтобы элементы Бэклога Продукта, расположенные сверху, были более детализированными и понятными по сравнению с расположенными ниже элементами. Чем детальнее описание элементов Бэклога Продукта, тем точнее может быть их оценка. В свою очередь, чем ниже находятся элементы в Бэклоге Продукта, тем меньше они детализированы.Обычно максимально детально прорабатываются истории на следующий спринт, достаточно детально на 2-3 спринта вперед, остальной хвост бэклога детально не прорабатывается.
Детализация же элементов Бэклога Продукта, над которыми Команда Разработки будет работать во время следующего Спринта, предполагает, что каждый из элементов может быть потенциального готов в течение Спринта так, что не остается никакой другой работы, чтобы подготовить продукт к выпуску.
Полностью согласен с rsn81
Одним из самых важных критериев Agile / Scrum является зрелость команды.
В приведенных выше ссылках на доки описывается несколько методик оценки.
Если у вас в «попугаях» получается плохо — цените в часах.
Там даже лимит описан — не более 16 на таску.
Одним из самых важных критериев Agile / Scrum является зрелость команды.
В приведенных выше ссылках на доки описывается несколько методик оценки.
Если у вас в «попугаях» получается плохо — цените в часах.
Там даже лимит описан — не более 16 на таску.
Ни слова не увидел о том как учитываются риски в этом подходе.
1 пойнт — прокрустово ложе. Можно вполне использовать 1/3/5 пойнтов. Допустим, 5 пойнтов — это условно 1 день, 3 пойнта — полдня, 1 пойнт — 1-2 часа или хотфикс. В неделю 25 и график будет не такой скачущий.
Да, такой подход тоже можно использовать. Так проще разбивать истории на подзадачи и точно не будет возникать эффекта привязки. Но тогда надо будет оценивать каждую подзадачу с помощью Planning Poker и это достаточно долго.
Важный момент: 1 день, пол дня и 2 часа стоит использовать только для того, чтобы программистам было проще прийти к одинаковому пониманию размер story point'а. Здесь 5 story point'ов — это 1 идеальный день. Чаще всего люди не укладываются в оценку, которую они дали в абсолютных величинах. С относительной оценкой получается лучше. Реальный размер story point'а нужно определять исходя из статистики.
На скачки графика такой подход не повлияет. График скачет в основном из-за того, что по окончании месяца остаются наполовину сделанные большие истории. Их в скорости мы не учитываем. Учитываем только принятые. Можно по другому учитывать, чтобы график меньше скакал, но это спорный вопрос.
Важный момент: 1 день, пол дня и 2 часа стоит использовать только для того, чтобы программистам было проще прийти к одинаковому пониманию размер story point'а. Здесь 5 story point'ов — это 1 идеальный день. Чаще всего люди не укладываются в оценку, которую они дали в абсолютных величинах. С относительной оценкой получается лучше. Реальный размер story point'а нужно определять исходя из статистики.
На скачки графика такой подход не повлияет. График скачет в основном из-за того, что по окончании месяца остаются наполовину сделанные большие истории. Их в скорости мы не учитываем. Учитываем только принятые. Можно по другому учитывать, чтобы график меньше скакал, но это спорный вопрос.
Зачем оценивать покером? Такие задачи каждый разработчик обычно вполне в состоянии сам оценить, обычно достаточно точно. Разбил, оценил сам (неопытным может помогать тимлид). Все же понимание, что займет 1-2 часа, что 4 часа, а что день — довольно похожее у разных людей с более-менее неплохим бэкграундом. Проблемы возникают только если задача больше 5 пойнтов.
В целом, одна из рабочих практик — 1 пойнт это 1 час, в день человек работает 5 часов, 3 теряются на коммуникации, чтение форумов, статей и прочие отвлечения. 5 пойнтов могут в итоге получиться за 3 часа, в другой раз 3 пойнта в день работы (если сработали риски). В течение итерации флуктуации всегда бывают, но в итоге они компенсируются и получаются неплохие и достаточно точные графики прогресса.
В целом, одна из рабочих практик — 1 пойнт это 1 час, в день человек работает 5 часов, 3 теряются на коммуникации, чтение форумов, статей и прочие отвлечения. 5 пойнтов могут в итоге получиться за 3 часа, в другой раз 3 пойнта в день работы (если сработали риски). В течение итерации флуктуации всегда бывают, но в итоге они компенсируются и получаются неплохие и достаточно точные графики прогресса.
Один разработчик может слишком много упустить, разбивая историю на подзадачи. Даже тимлид от этого не застрахован. Команда на оценке может увидеть, что что-то не учтено или планируется сделать неправильно. Командная оценка — это в первую очередь ревью того, как спроектировано решение. Можно сократить этап совместной оценки оценки так: вместо Planning Poker'а команда просто указывает, какие задачи точно нельзя сделать за день и нужно разбить. Оценку каждой задачи уже дает один человек. Но такая оценка будет не качественной. Более самоуверенный программист будет недооценивать, а осторожные — переоценивать. Полноценная оценка всей командой помогает решить эту проблему.
Для удобства при оценке можно считать, что 1 story point — это 1 час. Важно помнить, что это не реальный час и не путать этим клиентов или менеджеров. Реальный размер story point'а надо вычислять исходя из статистики. У кого-то это будет 2 рабочих часа, а у кого-то и все 4. Мы разбиваем до подзадач, которые по нашей оценке занимают 3-4 часа. Но с учетом рисков, приемки, ревью и отвлечений на общение с менеджерами, один программист делает только 3 story point'а в неделю.
Для удобства при оценке можно считать, что 1 story point — это 1 час. Важно помнить, что это не реальный час и не путать этим клиентов или менеджеров. Реальный размер story point'а надо вычислять исходя из статистики. У кого-то это будет 2 рабочих часа, а у кого-то и все 4. Мы разбиваем до подзадач, которые по нашей оценке занимают 3-4 часа. Но с учетом рисков, приемки, ревью и отвлечений на общение с менеджерами, один программист делает только 3 story point'а в неделю.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Как оценивать большие задачи