Comments 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 или нет.
UFO just landed and posted this here
Посмотрите в Scrum Guide: Product Backlog refinement (http://www.scrumguides.org/scrum-guide.html#artifacts-productbacklog) — в статье вы описываете вашу реализацию этого процесса.Не совсем. Наш способ оценки слишком дорогой, чтобы использовать его для оценки бэклога. Хотя и Planning Poker для этого мне кажется слишком затратным. Для оценки задач в бэклоге мы используем экспертную оценку одного-двух человек. Этого достаточно для приоритезации и при этом мы не тратим много времени на поддержку бэклога.
Делим историю на подзадачи и оцениваем мы непосредственно перед тем как брать их в спринт.
UFO just landed and posted this here
Полностью согласен с 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'а в неделю.
Sign up to leave a comment.
Как оценивать большие задачи