Комментарии 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 или нет.
Посмотрите в Scrum Guide: Product Backlog refinement (http://www.scrumguides.org/scrum-guide.html#artifacts-productbacklog) — в статье вы описываете вашу реализацию этого процесса.Не совсем. Наш способ оценки слишком дорогой, чтобы использовать его для оценки бэклога. Хотя и Planning Poker для этого мне кажется слишком затратным. Для оценки задач в бэклоге мы используем экспертную оценку одного-двух человек. Этого достаточно для приоритезации и при этом мы не тратим много времени на поддержку бэклога.
Делим историю на подзадачи и оцениваем мы непосредственно перед тем как брать их в спринт.
Полностью согласен с rsn81
Одним из самых важных критериев Agile / Scrum является зрелость команды.
В приведенных выше ссылках на доки описывается несколько методик оценки.
Если у вас в «попугаях» получается плохо — цените в часах.
Там даже лимит описан — не более 16 на таску.
Одним из самых важных критериев Agile / Scrum является зрелость команды.
В приведенных выше ссылках на доки описывается несколько методик оценки.
Если у вас в «попугаях» получается плохо — цените в часах.
Там даже лимит описан — не более 16 на таску.
Ни слова не увидел о том как учитываются риски в этом подходе.
Да, такой подход тоже можно использовать. Так проще разбивать истории на подзадачи и точно не будет возникать эффекта привязки. Но тогда надо будет оценивать каждую подзадачу с помощью Planning Poker и это достаточно долго.
Важный момент: 1 день, пол дня и 2 часа стоит использовать только для того, чтобы программистам было проще прийти к одинаковому пониманию размер story point'а. Здесь 5 story point'ов — это 1 идеальный день. Чаще всего люди не укладываются в оценку, которую они дали в абсолютных величинах. С относительной оценкой получается лучше. Реальный размер story point'а нужно определять исходя из статистики.
На скачки графика такой подход не повлияет. График скачет в основном из-за того, что по окончании месяца остаются наполовину сделанные большие истории. Их в скорости мы не учитываем. Учитываем только принятые. Можно по другому учитывать, чтобы график меньше скакал, но это спорный вопрос.
Важный момент: 1 день, пол дня и 2 часа стоит использовать только для того, чтобы программистам было проще прийти к одинаковому пониманию размер story point'а. Здесь 5 story point'ов — это 1 идеальный день. Чаще всего люди не укладываются в оценку, которую они дали в абсолютных величинах. С относительной оценкой получается лучше. Реальный размер story point'а нужно определять исходя из статистики.
На скачки графика такой подход не повлияет. График скачет в основном из-за того, что по окончании месяца остаются наполовину сделанные большие истории. Их в скорости мы не учитываем. Учитываем только принятые. Можно по другому учитывать, чтобы график меньше скакал, но это спорный вопрос.
Один разработчик может слишком много упустить, разбивая историю на подзадачи. Даже тимлид от этого не застрахован. Команда на оценке может увидеть, что что-то не учтено или планируется сделать неправильно. Командная оценка — это в первую очередь ревью того, как спроектировано решение. Можно сократить этап совместной оценки оценки так: вместо 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'а в неделю.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как оценивать большие задачи