Comments 19
Разделение одной задачи на подзадачи обычно занимает в районе 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 или нет.
Существует множество способов оценить пользовательские истории. Мы используем собственную методологию, чтобы оценить и проработать задачи перед тем, как писать код. Как мы до этого дошли и почему наш подход лучше, чем 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 спринта вперед, остальной хвост бэклога детально не прорабатывается.
Ну я так понял детально проработанные истории на следующий спринт — это уже Sprint Backlog (http://www.scrumguides.org/scrum-guide.html#artifacts-sprintbacklog). Но это уже нюансы, конечно.

Ни слова не увидел о том как учитываются риски в этом подходе.

Вместо экспертной оценки рисков, мы разбиваем истории на подзадачи настолько мелко, чтобы нивелировать риски. Они, конечно, все равно остаются, но в среднем мы не учитываем только 20% подзадач.
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 часа, что 4 часа, а что день — довольно похожее у разных людей с более-менее неплохим бэкграундом. Проблемы возникают только если задача больше 5 пойнтов.

В целом, одна из рабочих практик — 1 пойнт это 1 час, в день человек работает 5 часов, 3 теряются на коммуникации, чтение форумов, статей и прочие отвлечения. 5 пойнтов могут в итоге получиться за 3 часа, в другой раз 3 пойнта в день работы (если сработали риски). В течение итерации флуктуации всегда бывают, но в итоге они компенсируются и получаются неплохие и достаточно точные графики прогресса.
Один разработчик может слишком много упустить, разбивая историю на подзадачи. Даже тимлид от этого не застрахован. Команда на оценке может увидеть, что что-то не учтено или планируется сделать неправильно. Командная оценка — это в первую очередь ревью того, как спроектировано решение. Можно сократить этап совместной оценки оценки так: вместо Planning Poker'а команда просто указывает, какие задачи точно нельзя сделать за день и нужно разбить. Оценку каждой задачи уже дает один человек. Но такая оценка будет не качественной. Более самоуверенный программист будет недооценивать, а осторожные — переоценивать. Полноценная оценка всей командой помогает решить эту проблему.

Для удобства при оценке можно считать, что 1 story point — это 1 час. Важно помнить, что это не реальный час и не путать этим клиентов или менеджеров. Реальный размер story point'а надо вычислять исходя из статистики. У кого-то это будет 2 рабочих часа, а у кого-то и все 4. Мы разбиваем до подзадач, которые по нашей оценке занимают 3-4 часа. Но с учетом рисков, приемки, ревью и отвлечений на общение с менеджерами, один программист делает только 3 story point'а в неделю.
Only those users with full accounts are able to leave comments. Log in, please.
Information
Location

Россия

Employees

101–200 employees

Registered

2 March 2015