Evidence Based scheduling или вопрос от разработчика

Мне тут пришло интересное письмо от читателя с вопросом об использовании Evidence Based Scheduling в проектах (ниже ссылка на статью, она, кстати, довольно интересная). С одной стороны – приятно, что меня читают не только руководители проектов, с другой – я только тут поняла, что достаточно далеко отошла от непосредственного управления разработкой и уже не очень знаю, что происходит в мире. Поэтому публикую нашу переписку (имя заменено), и если у вас есть что добавить по этому подходу – добавляйте!

Спойлер: читать будет интересно только тем, кто управляет разработкой ПО, остальным – вряд ли, пост лучше пропустить и почитать что-то более интересное.

От: Иван

Кому: Юлия

Юлия, спасибо за интересный блог!

Свои вопросы задаю, смотря на мир глазами разработчика.

  • Есть ли у Вас мнение об Evidence Based Scheduling для Agile проектов? Используете ли Вы в ваших проектах статистические поправки, основанные на затраченном разработчиками времени?
  • Как Вы считаете, нужен ли разработчику инструмент, позволяющий закладывать в его индивидуальные оценки отдельных задач историческую поправку?
  • Лучше ли делать эту поправку на всю итерацию, нежели на отдельные задачи?

Заранее благодарен за Ваше мнение

___________

От: Юлия

Кому: Иван

Иван, добрый день.

Спасибо за письмо, приятно, что блог полезен, и что меня читают не только РМы. По поводу EBS – просмотрела статью, в целом, как я понимаю, авторы доработали (и сильно усложнили) классический подход  к оценке velocity из Agile.

Последние несколько лет я нечасто напрямую работаю с разработчиками, как правило, на проекте есть техлид, который обеспечивает адекватный учет velocity, я максимум ради интереса смотрю на его/ее расчеты в джире. Авторы, кстати, предлагают ограничение в 16 часов, я стараюсь не допускать оценок менее 30 минут и более 8 часов, считаю, что это предел, в рамках которого можно реально оценить объем.

На немногих проектах, где в качестве техлида выстую я (это, как правило, проекты оптимизации бизнес-процессов, на которых работает бизнес в качестве разработчиков) мы делаем переоценку по классике – после первого спринта меряем исходный velocity команды, далее на каждой ретроспективе обсуждаем, почему не вписались и в целом и по персоналиям.

Однако в отличие от предлагаемого подхода мы работаем группой, считаю, это полезно и для коммуникации, и для более четкой оценки своих задач.

До той степени “упоротости”, как в статье, никогда не доходила, моделирование работы конкретного разработчика по Монте-Карло – это уж слишком. Допускаю, что применимо в продуктовых компаниях, работающих над одним продуктом, но у меня такого опыта нет, при 8-10 проектах на разных технологиях и с разным бизнесом одновременно это невозможно.

Отвечая на ваш вопрос – да, считаю, что разработчик должен иметь возможность поменять или уточнить оценку на основе предыдущего опыта, главное – не дать ему уйти в padding, бездумную забивку рисков временем.

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

Я за уточнение на уровне конкретной задачи, а не итерации, так как, как справедливо замечают авторы статьи, реальная оценка на задачу может быть как с коэффициентом 0.4, так и 13. хотя при использовании Монте-Карло и 10 000 итераций моделирования, возможно, получится подняться до итерации.

Надеюсь, я ответила на вопрос? Хорошего дня!

___________

От: Иван

Кому: Юлия

Юлия, спасибо за подробный ответ!

Планирование с разрешением до 8 часов выглядит привлекательно, но возникают вопросы.

  1. Я работаю с задачами в Jira. На мой взгляд, это слишком тяжеловесный инструмент, чтобы записывать свои мелкие шаги. Вижу логичным сохранять их в электронной таблице. В идеале, таблица должна поддерживать коэффициенты, основанные на истории. Хотелось бы количественно оценить уровень неопределённости, но к чему его привязать? К интуитивной оценке вроде “Предельно понятная задача”, “Обычная задача”, “Умеренные риски”, “Высокие риски”? К размеру задачи в поинтах?
  2. В моей практике были трудоёмкие задачи, которые я делал более месяца. Декомпозировать их можно было путём описания того, что делал каждый день. Это был итеративный research & troubleshooting. Как лучше планировать подобные задачи?

___________

От: Юлия

Кому: Иван

Иван, согласна с неудобством JIRA для детального планирования. Задачи на 8+ часов мы ведем в MS Project, мельче – в электронной таблице (но некоторые тимлиды – все равно в JIRA, тут мне все равно, если честно). Как я уже писала, я настолько оценку не формализую, но если у вас есть исторический план и факт по задачам – то почему бы и нет, можно то же моделирование простым макросом попробовать сделать, вот и будут исторические коэффициенты.

С точки зрения оценки уровня неопределенности – мне нравится Planning Poker из скрама (у меня есть несколько комплектов карт, но в основном пользуюсь онлайн-ресурсами, т.к. команды распределенные). Так как и оценку и ретроспективу мы делаем вместе – сразу видно, что кто-то задачу переоценил, а кто-то недооценил, и путем обсуждения получаем более-менее реальную оценку, дополнительных коэффициентов не закладываем (кроме менеджерского буфера, но это уже другая история). Никакой интуиции, исключительно закон больших чисел и использование командного опыта.

По поводу трудоемких задач – если совсем смутно понятно, что делать, то я стараюсь организовать такой маленький “waterfall” внутри проекта, типа:

  • а) написать, что ты будешь делать и общий ожидаемый результат (микро-устав);
  • б) уточнить, что будет на выходе и в какой форме и каким критериям должно соответствовать (требования);
  • в) написать план работ и оценить объемы задач в плане;
  • г) идти по нему и корректировать оценку при необходимости;
  • д) если понятно, что за исходную высокоуровневую оценку выезжаем – то как можно быстрее сказать РМу, чтобы потом не получить по голове и не подвести команду.

Как-то так. Дальше было еще несколько писем, но больше “на поболтать”, чем по делу, поэтому их не публикую.

Что думаете? Использовали такой подход? Если нет – то хотели бы попробовать?

Давайте не теряться - подпишитесь прямо сейчас!

Чтобы получать новые практические материалы раз в неделю на вашу почту. Без спама и рекламы, только опыт и мысли практикующего специалиста по управлению проектами

А также
И не забудьте оставить комментарий :) мне важно ваше мнение!

Оставьте комментарий