Перейти к основному содержимому

Планирование и оценка

Как превратить «нам нужна вот эта возможность» в работу, которую можно начать, отследить и довести до конца, — и дать людям вне команды внятный ответ на вопрос «когда».

Почему это важно. Оценка сроков — та часть инженерной работы, которая чаще всего разрушает доверие. Не потому, что оценки неверны — они неверны всегда, — а потому, что о неопределённости не говорят вслух: догадку слышат как обещание, и сорванный срок выглядит провалом, а не арифметикой.

Что нужно понимать​

  • Что значит «готово» для этого куска работы — и договориться об этом до начала
  • Что действительно неизвестно и можно ли выяснить это дёшево
  • Что входит в оценку: code review, тестирование, релиз — вся неинтересная часть
  • Кто ждёт этого ответа и какое решение на нём держится
  • Что говорить, когда оценка оказалась неверной, и когда именно это говорить

Основные темы​

Декомпозиция​

  • Куски, каждый из которых что-то даёт, вместо слоёв, не дающих ничего, пока не готовы все
  • Достаточно мелкие, чтобы закончить за дни: задача на неделю ровно неделю и остаётся «готовой на девяносто процентов»
  • Зависимости, видимые заранее
  • Исследовательские задачи (spike) на настоящие неизвестные — с жёстким лимитом времени

Оценка​

  • Относительный размер против времени: для чего годится то и другое
  • Диапазон и степень уверенности вместо одного числа
  • Ошибка планирования: почему стоит опираться на собственную историю, а не на оптимизм
  • О чём забывают систематически: code review, QA, развёртывание, встречи
  • Запас в оценке и почему скрытый запас хуже честно названной неопределённости

Отслеживание​

  • Доска, которая показывает реальность, а не доска, которая опрятно выглядит
  • Лимиты на количество задач в работе и почему «начал» не значит «продвинулся»
  • «Заблокировано» как состояние, которое должно быть видно всем и длиться недолго
  • Заметить отставание рано, пока разговор о нём ещё короткий

Как об этом говорить​

  • Обязательство по дате против прогноза даты
  • Ранняя эскалация — это услуга команде, а не признание вины
  • Когда срок зафиксирован, торговаться объёмом, а не качеством
  • Уметь сказать «нет» — или сказать, чем придётся пожертвовать

Сам процесс​

  • Ритуалы — инструмент; их держат ровно до тех пор, пока они окупают потраченное время
  • Ретроспективы, после которых что-то меняется
  • Процесс подстраивают под команду, а не команду под процесс

Уровни​

УровеньКак это выглядит
JuniorОценивает собственные задачи, сообщает, когда застрял, не даёт доске врать.
MiddleРазбивает функциональность на куски, каждый из которых можно поставить, оценивает диапазонами, рано поднимает тему отставания, договаривается об объёме.
SeniorПланирует работу на уровне команды, делает неопределённость явной для заказчиков и смежников и выстраивает процесс вокруг того, как команда работает на самом деле.

Практика​

Для начала​

  • Оцените, потом измерьте Запишите свою оценку и фактическое время по десяти задачам и посмотрите на соотношение.

  • Режьте вертикально Возьмите функциональность, запланированную как «сначала backend, потом frontend», и перережьте её так, чтобы каждый кусок что-то поставлял.

  • Определите «готово» Прежде чем взяться за текущую задачу, напишите, что для неё значит «готово».

Глубже​

  • Назовите диапазон Дайте следующую оценку диапазоном и укажите свою уверенность — посмотрите, как изменится разговор.

  • Эскалируйте рано Говорите о съезжающей оценке в тот день, когда вы это поняли, а не в день срока.

  • Убейте один ритуал Найдите регулярную встречу, которая перестала окупать своё время, и измените её или отмените.

Проверьте себя​

  • Насколько в среднем ошибаются ваши оценки и в какую сторону?
  • Что вы регулярно забываете включить в оценку?
  • Когда вы не успеваете — в какой момент вы об этом говорите?
  • Что в вашей команде значит «готово» и все ли понимают это одинаково?
  • Какие ваши задачи дольше всех висят в работе и почему?
  • Что на самом деле изменила ваша последняя ретроспектива?

Материалы​

  • Shape Up — подход Basecamp, бесплатно доступный онлайн. Главный его приём — фиксировать время и менять объём, а не наоборот — стоит понять, даже если всё остальное вы не возьмёте.
  • The Planning Fallacy — исследования о том, почему оценки систематически оптимистичны и почему собственная история точнее любых рассуждений о задаче.
  • Software Estimation: Demystifying the Black Art — Стив Макконнелл о неопределённости, конусе неопределённости и о том, как сообщать диапазоны. До сих пор самый полный разбор темы.
  • Story Points and Velocity — Мартин Фаулер о том, для чего нужны story points и как их начинают использовать как меру производительности, хотя они ею не являются.
  • Agile Manifesto — шестьдесят восемь слов. Их полезно время от времени перечитывать, сравнивая с тем, во что превратился ваш процесс.