Аналитика и декомпозиция задач. Как определяется время разработки

Всем привет! Сегодня хотелось бы поговорить про такую тему, как оценка времени разработки. Тема достаточно интересная т.к. нет какого-то обобщенного стандарта оценки.

Когда-то это было одной из первых моих задач на работе, и когда мне впервые дали требования и сказали «Оцени сколько нужно времени». Естественно первый мой вопрос был «А как ?». Я тогда и представить не могла, как можно оценить то, что не сделано и непонятно, как будет реализовано…

Какие есть подходы и как аналитику оценить задачу? На этот вопрос постараюсь ответить дальше

Матрица оценок

Я как раз в тот момент работала в компании, которая занимается заказной разработкой и там для оценки применялась определенная матрица.
Сама матрица представляет собой специальный файл, в котором расписаны типовые задачи по уровням сложности и то, сколько такая задача занимает у команды времени.

Например, спроектировать простой CRUD-сервис, без особой логики — 1 человекодень для аналитика, 1 для бэка, 0,5 для фронта и 2 для тестировщика.

Или спроектировать сложный орекструющий микросервис, с нетривиальной логикой — 4 дня для аналитика, 5 дней для разработки и 10 для тестировщика.

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

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

Субъективная оценка

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

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

Тут всё зависит от опыта аналитика, количества решенных аналогичных задач и точности изначальной постановки задачи заказчиком. Далее на основе декомпозиции от аналитика — оценку делает остальная команда.

Груминг

Новый для меня процесс, который происходит на моем текущем месте работы, и смысл которого мне понравился.

Сам груминг проходит еженедельно:

• Аналитик приносит туда свои завершенные задачи и презентует их команде, т.е. рассказывает их смысл, демонстрирует своё ТЗ и объясняет свое видение решения этой задачи.

• Вся остальная команда может высказывать свои комментарии (зачастую очень дельные, и это помогает найти какие-то недочеты или даже логические дыры в твоем ТЗ) и делиться своим мнением относительно задачи, предлагать свои варианты решения.

• Аналитик в процессе груминга может править ТЗ, если это не занимает много времени, и получается такая «экстремальная аналитика» в онлайн-формате.

• После того, как все вопросы\предложения закончились,
  начинается оценка задачи командой разработки и тестирования, уже по написанному ТЗ, что заметно увеличивает точность оценки, чем если оценивать задачи по предварительному мини-анализу.