Мое определение оценки:
“Процесс в рамках которого, мы разбираемся, что от нас ждут, что нам для этого надо сделать и в каких частях нашего приложения, какие у нас зависимости, готовы ли они к нашим задачам, какие риски и тдтп. А "оценка времени" - это лишь один из артефактов процесса оценки.”
Я тут не хочу писать подробности про сторипойнты (попугаев, слоников, чашки кофе, размеры маек), планинг-покер и тд. Очень много инфы по этой теме.
Тут будут просто советы и немного про собственно процесс, как я его вижу.
1. У всех, кто участвует в процессе, должно быть одинаковое понимание того, что именно они оценивают и с какой точностью эта оценка делается (подробнее смотри совет 1 отсюда)
2. Важно понимать, что ошибки оценки все равно будут. И поэтому должны быть:
• процесс работы над этими ошибками (расширяем базу знаний и подходы для следующих оценок) с тем, чтобы в следующий раз оценка была точнее
• процесс информирования о возникающих из-за ошибок рисках (не тянем до последнего)
3. При запуске/перестройке процесса оценки очень помогают эталонные (референтные) задачи, сравнивая с которыми мы пытаемся оценить наши текущие задачи
4. Оценка в сторипойнтах - это в том числе способ избежать необходимости точной оценки: когда оценивается, например, в часах, сразу возникает ситуация, когда было запланировано например 3 часа, а задача сделана за 3.5. Это хорошая оценка или продолб? А 4 часа? А как это время измерялось и что в него входило?
5. Не бывает “копеечных” задач. Вообще не используйте это обозначение. Оно мешает запускать в голове комплексный процесс оценки задачи, зато очень помогает забыть про важные вещи.
6. БОльшая декомпозиция помогает точности оценки
7. Постепенный уход в сторону простого кол-ва задач, тогда можно просто считать кол-во задач и меньше думать про их оценивание.
Кстати, в очередной раз “эффект инфополя”: пишу заметку, а в недавней рассылке пришла хорошая статья по теме оценки.
И еще тут у меня было про этой теме.
Теперь про простой способ организации процесса оценки, чтобы она начиналась хоть с какими-то артефактами на входе.
Если оценку задач делает не "специально обученный быть крайним человек" а-ка лид, а решение принимается на командной встрече, то предлагаю такой вполне рабочий процесс:
Работу над оценкой задач на следующий спринт начинаем в текущем спринте.
Встреча 1 (30-45 мин):
• смотрим на ожидаемый список историй/задач (формирует PO исходя из целей спринта, но возможно участие команды, особенно по техническим задачам)
• определяем задачи, по которым недостаточно информации для их оценки (по остальным сразу делаем оценку)
• у каждой такой задачи появляется ответственный, который до проведения следующей встречи собирает нужную для оценки информацию (корректность проработки, место(-а) в коде, которые надо изменить/дописать, синхронизация со смежной командой и тд) и делает на базе этого предварительную оценку* (см дальше пояснения)
Встреча 2 (30-45 мин), лучше через неделю после первой:
• каждый ответственный рассказывает про свою задачу
• информация обсуждается
• делаются итоговые оценки
• обсуждаются вновь прилетевшие (с момента встречи 1) задачи, которые хочется затащить в спринт. Если нужно, то по ним тоже запускается работа по их оценке
Встреча планирования спринта (15 мин**):
• если за время после 2й встречи ничего нового не прилетело, то в спринт просто берутся задачи согласно текущей “скорости прожевывания сторипойнтов” (ака velocity) и их приоритетов
• если что-то прилетело и оно важно, то это обсуждается уже на планировании. Но лучше бы конечно это все же сделать предварительно, иначе оценка будет скорее “пальцем в небо”.
Все, запускаем спринт и пошли работать. На финише, на спринт-ревью анализируем сделанные оценки и выясняем, поменялась бы оценка, исходя из того, что мы сейчас знаем про задачу.
*По опыту, самая холиварная тема - это “а как я буду что-то ресечить, если у меня куча задач по текущему спринту?”. Все просто - время на ресеч “закладывается” при планировании через анализ текущей скорости прожевывания сторипойнтов командой. Речь не про то, что этим надо заниматься по ночам. Для трепетно относящихся к учету времени для такие ресечей на оценку можно заводить задачи с фиксированными значениям сторипойнтов.
** вторая по популярности тема "это ж нафига столько встреч?"
Ну, во-первых, суммарно по времени получается не больше, чем одна большая встреча планинга (где большей частью все "играют в покер", а не планируют). Во-вторых, обычно в этом случае мы получаем более осознанную и точную оценку, часто выясняются неочевидные вещи, требующие дополнительного ресеча и задача в этом случае просто не берется в работу в текущий спринт. Что, в конечном итоге, тоже экономит время. Ну и в третьих, первую встречу вполне можно проводить "заочно" и асинхронно, если речь про встречу для распределения задач, а не их оценки.
Почему такой процесс редко можно встретить в реале? :)
Да фиг его знает, я ставлю на "лень-матушка раньше нас родилась...". Всегда ведь проще погадать на планинге не делая предварительного исследования.
Подключайтесь к комментам в телеге
Комментарии
Отправить комментарий