Мне тут пришло интересное письмо от читателя с вопросом об использовании Evidence Based Scheduling в проектах (ниже ссылка на статью, она, кстати, довольно интересная). С одной стороны – приятно, что меня читают не только руководители проектов, с другой – я только тут поняла, что достаточно далеко отошла от непосредственного управления разработкой и уже не очень знаю, что происходит в мире. Поэтому публикую нашу переписку (имя заменено), и если у вас есть что добавить по этому подходу – добавляйте!
Спойлер: читать будет интересно только тем, кто управляет разработкой ПО, остальным – вряд ли, пост лучше пропустить и почитать что-то более интересное.
От: Иван
Кому: Юлия
Юлия, спасибо за интересный блог!
Свои вопросы задаю, смотря на мир глазами разработчика.
- Есть ли у Вас мнение об Evidence Based Scheduling для Agile проектов? Используете ли Вы в ваших проектах статистические поправки, основанные на затраченном разработчиками времени?
- Как Вы считаете, нужен ли разработчику инструмент, позволяющий закладывать в его индивидуальные оценки отдельных задач историческую поправку?
- Лучше ли делать эту поправку на всю итерацию, нежели на отдельные задачи?
Заранее благодарен за Ваше мнение
___________
От: Юлия
Кому: Иван
Иван, добрый день.
Спасибо за письмо, приятно, что блог полезен, и что меня читают не только РМы. По поводу EBS – просмотрела статью, в целом, как я понимаю, авторы доработали (и сильно усложнили) классический подход к оценке velocity из Agile.
Последние несколько лет я нечасто напрямую работаю с разработчиками, как правило, на проекте есть техлид, который обеспечивает адекватный учет velocity, я максимум ради интереса смотрю на его/ее расчеты в джире. Авторы, кстати, предлагают ограничение в 16 часов, я стараюсь не допускать оценок менее 30 минут и более 8 часов, считаю, что это предел, в рамках которого можно реально оценить объем.
На немногих проектах, где в качестве техлида выстую я (это, как правило, проекты оптимизации бизнес-процессов, на которых работает бизнес в качестве разработчиков) мы делаем переоценку по классике – после первого спринта меряем исходный velocity команды, далее на каждой ретроспективе обсуждаем, почему не вписались и в целом и по персоналиям.
Однако в отличие от предлагаемого подхода мы работаем группой, считаю, это полезно и для коммуникации, и для более четкой оценки своих задач.
До той степени “упоротости”, как в статье, никогда не доходила, моделирование работы конкретного разработчика по Монте-Карло – это уж слишком. Допускаю, что применимо в продуктовых компаниях, работающих над одним продуктом, но у меня такого опыта нет, при 8-10 проектах на разных технологиях и с разным бизнесом одновременно это невозможно.
Отвечая на ваш вопрос – да, считаю, что разработчик должен иметь возможность поменять или уточнить оценку на основе предыдущего опыта, главное – не дать ему уйти в padding, бездумную забивку рисков временем.
Как раз тут грамотный и мотивированный техлид бесценен, т.к. мой опыт разработки давно устарел, я не всегда могу аргументированно надавить, даже если понимаю, что меня обманывают.
Я за уточнение на уровне конкретной задачи, а не итерации, так как, как справедливо замечают авторы статьи, реальная оценка на задачу может быть как с коэффициентом 0.4, так и 13. хотя при использовании Монте-Карло и 10 000 итераций моделирования, возможно, получится подняться до итерации.
Надеюсь, я ответила на вопрос? Хорошего дня!
___________
От: Иван
Кому: Юлия
Юлия, спасибо за подробный ответ!
Планирование с разрешением до 8 часов выглядит привлекательно, но возникают вопросы.
- Я работаю с задачами в Jira. На мой взгляд, это слишком тяжеловесный инструмент, чтобы записывать свои мелкие шаги. Вижу логичным сохранять их в электронной таблице. В идеале, таблица должна поддерживать коэффициенты, основанные на истории. Хотелось бы количественно оценить уровень неопределённости, но к чему его привязать? К интуитивной оценке вроде “Предельно понятная задача”, “Обычная задача”, “Умеренные риски”, “Высокие риски”? К размеру задачи в поинтах?
- В моей практике были трудоёмкие задачи, которые я делал более месяца. Декомпозировать их можно было путём описания того, что делал каждый день. Это был итеративный research & troubleshooting. Как лучше планировать подобные задачи?
___________
От: Юлия
Кому: Иван
Иван, согласна с неудобством JIRA для детального планирования. Задачи на 8+ часов мы ведем в MS Project, мельче – в электронной таблице (но некоторые тимлиды – все равно в JIRA, тут мне все равно, если честно). Как я уже писала, я настолько оценку не формализую, но если у вас есть исторический план и факт по задачам – то почему бы и нет, можно то же моделирование простым макросом попробовать сделать, вот и будут исторические коэффициенты.
С точки зрения оценки уровня неопределенности – мне нравится Planning Poker из скрама (у меня есть несколько комплектов карт, но в основном пользуюсь онлайн-ресурсами, т.к. команды распределенные). Так как и оценку и ретроспективу мы делаем вместе – сразу видно, что кто-то задачу переоценил, а кто-то недооценил, и путем обсуждения получаем более-менее реальную оценку, дополнительных коэффициентов не закладываем (кроме менеджерского буфера, но это уже другая история). Никакой интуиции, исключительно закон больших чисел и использование командного опыта.
По поводу трудоемких задач – если совсем смутно понятно, что делать, то я стараюсь организовать такой маленький “waterfall” внутри проекта, типа:
- а) написать, что ты будешь делать и общий ожидаемый результат (микро-устав);
- б) уточнить, что будет на выходе и в какой форме и каким критериям должно соответствовать (требования);
- в) написать план работ и оценить объемы задач в плане;
- г) идти по нему и корректировать оценку при необходимости;
- д) если понятно, что за исходную высокоуровневую оценку выезжаем – то как можно быстрее сказать РМу, чтобы потом не получить по голове и не подвести команду.
Как-то так. Дальше было еще несколько писем, но больше “на поболтать”, чем по делу, поэтому их не публикую.
Что думаете? Использовали такой подход? Если нет – то хотели бы попробовать?
Добавить комментарий