Про оценки и календарь — метод аналогий и зримое представление

Продолжаю делиться опытом в работе по модели с предварительной точной оценкой обязательств. Временно-материальным будет, наверно, неинтересно ;)

Верифицирую оценки в команде, оценка на интеграцию кода в рамках одной фичи явно с потолка и явно недооценена — стоит одинокая такая задача по слиянию кода с некоей оценкой в человеко-часах и очень общими критериями успеха разряда «чтобы все было зашибись». Становится вопрос — как правильно оценить интеграцию со всеми её возможными сюрпризами-рисками? Особенно если фича — в составе плагина к третьестороннему решению. Как обычно, в целях объяснения подходов, даю ребятам пример из области, не относящейся к разработке софта :) Вот он:

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

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

В результате, после непродолжительной игры в аналогии, одинокая задача в ToDo по слиянию кода превращается в перечень работ:
— Перекрестная проверка полноты описания интерфейсов.
— Заглушки.
— Ранняя интеграция.
— Промежуточные чекпойнты + ретро.
— Запас на перекрестное тестирование и рефакторинг.
— Отказ от предварительного «вылизывания» шероховатостей до финальной интеграции.
— и т.д.

По итогу, недооценка оказалась небольшой — всего в полтора-два раза :) Но, как говорится в одном вестерне: «там пятерка, сям четвертак — скоро я стану богатым человеком». Ну и осязаемые риски превратились просто в задачи, что не может не.

Собственно, один из методов оценки задач заключается в том, чтобы зримо представить работы, которые нужно выполнить, чтобы эта фича была готова в том смысле, в котором понимают «готово» заказчики. Если нет возможности представить — ищем аналогии в других сферах: техника, ремонт, покупка в магазине, военная область и т.д. :) Аналогия — самый простой и очень эффективный метод анализа, но его, к сожалению, мало применяют, ищут сложные решения.

Удачи в анализах анализе и оценках :)

Ссылки по теме

• Заметки: Про оценки и календарь. Введение

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU