Управление проектами.РУ

Управление проектами.РУ
Сообщество тех, кто умеет или хочет научиться
хорошо управлять проектами
11 сентября 2017 Вопросы из зала Из жизни РМа
427 0

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

Юлия Бажанова
Редактор проекта, РМР, РМЕ, PRIME

Мне тут пришло интересное письмо от читателя с вопросом об использовании 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” внутри проекта, типа:

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

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

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

комментарии

Добавить комментарий

Такой e-mail уже зарегистрирован. Воспользуйтесь формой входа или введите другой.

Вы ввели некорректные логин или пароль

Sorry that something went wrong, repeat again!

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: