Ссылка на оригинал статьи с объяснением принципа Доказательного Планирования (в оригинале Evidence Based Scheduling - далее будет фигурировать как EBS)
- Joel Spolsky Evidence Based Scheduling
- Перевод на русский
Какую проблему удалось решить?
Из опыта работы в "Кровавом Enterprise" плечом к плечу с Менеджером Продукта, перед поступлением очередной задачи в работу, у меня интересовались, сколько на нее уйдет времени (внезапно). Это, можно сказать, напрягало тем, что такая оценка должна затрагивать все возможные факторы "торможения". Вот некоторые из них:
- Неоднократное выяснение деталей до того момента, как задача станет "прозрачной"
- Перерывы в работе по разным причинам
Да, слишком абстрактно, и оба пункта можно детализировать на много факторов, но сама проблема свелась к учету их всех неявным образом. Условно, будем считать, что проблема локализована (Вы удивитесь, но детали, действительно не так важны).
Решение
Чтобы получить прогноз для конкретной задачи по срокам, достаточно иметь статистику по аналогичным задачам, каждая из которых должна иметь: 1) дату старта исполнителем; 2) дату прогноза от исполнителя; 3) дату фактического ее завершения (которую потом можно нужно двигать по мере доработки задачи). Таким образом, процесс планирования сроков фичи перед тем как разработчик возьмет задачу в работу должен основываться на двух вопросах к нему:
- Какова сложность фичи по шкале от 1 до 5?
- Сколько времени тебе нужно для ее выполнения?
Далее следует вопрос самоконтроля эффективного менеджера - зафиксировать даты старта и фактического завершения этой задачи (это важно!). С момента завершения первой задачи, можно предсказывать будущее, с учетом ошибок разработчика, основываясь на предыдущем опыте работы с ним: Чем больше задач набирается в опыт, тем точнее прогноз.
Да, кстати, важный момент! Прогноз исполнителя не должен основываться на аналитически расчитанном прогнозе программы (рекурсия и в этом случае не принесет пользы, если Вы понимаете, о чем я).
Следствие - всегда результат принятых решений (из фильма "Разрабы")
🔥 Демо
Хотел собрать обратную связь насчет работы демо версии.
Пару слов о том, как я использую этот инструмент в своей работе:
- Создаю новую таску, назначенную на исполнителя, который оценивает ее навскидку:
- а) субъективная оценка сложности от 1 до 5 - возможно, эту оценку можно скорректировать по факту выполнения задачи (думаю, по итогам ретроспективы в момент завершения таски - самое время);
- б) субъективные сроки выполнения (первоначальная дата обещания от исполнителя) - ее потом менять нет смысла, т.к. это основа метода;
- в) фиксирую дату старта выполнения - она должна соответствовать факту старта;
⚡ Если такая задача не первая! Получаю прогноз по методике EBS на самый худший вариант развития - это тот самый срок, который следует озвучить Продукт Менеджеру;
Фиксирую фактическую дату завершения задачи - это именно тот параметр, который следует скорректировать в случае, если задача потребовала доработки для более точной статистики и, как следствие, более точной оценки последующих задач.
При наличии статистики, перед постановкой задачи можно прикинуть, насколько "обманет" испытуемый исполнитель:
Теги: теория вероятности, планирование выпуска релизов, joel spolsky, agile, scrum
Хабы: Программирование, Agile, IT-компании
Пройдет ли модерацию v0.0.1 на хабре?