Всем привет! Сегодня хотелось бы поговорить про такую тему, как оценка времени разработки. Тема достаточно интересная т.к. нет какого-то обобщенного стандарта оценки.
Когда-то это было одной из первых моих задач на работе, и когда мне впервые дали требования и сказали "Оцени сколько нужно времени". Естественно первый мой вопрос был "А как ?". Я тогда и представить не могла, как можно оценить то, что не сделано и непонятно, как будет реализовано...
Какие есть подходы и как аналитику оценить задачу? На этот вопрос постараюсь ответить дальше
Матрица оценок
Я как раз в тот момент работала в компании, которая занимается заказной разработкой и там для оценки применялась определенная матрица.
Сама матрица представляет собой специальный файл, в котором расписаны типовые задачи по уровням сложности и то, сколько такая задача занимает у команды времени.
Например, спроектировать простой CRUD-сервис, без особой логики - 1 человекодень для аналитика, 1 для бэка, 0,5 для фронта и 2 для тестировщика.
Или спроектировать сложный орекструющий микросервис, с нетривиальной логикой - 4 дня для аналитика, 5 дней для разработки и 10 для тестировщика.
Как правило, в эти цифры уже заложены дополнительное время на риски, возможные интеграции и различные непредвиденные ситуации.
Чтобы реализовать такой подход и заранее оценить все типы задач, должна быть сильная команда с достаточно большим наработанным опытом разработки, чтобы:
разработать такой шаблон оценки;
успешно применять и оценивать по этому шаблону, с учетом того, что некоторые задачи не всегда просто уложить в определенные рамки.
Субъективная оценка
Субъективная оценка специалиста (будь то аналитик или кто либо другой).
До старта аналитики релиза к команде приходит заказчик, приносит какие-то постановки задач (в зависимости от процесса, перед тем как такую задачу должен оценить системный аналитик и другие члены команды - она уже декомпозирована и оценена бизнес аналитикой и архитектором.
Далее системный аналитик берет эту постановку - декомпозирует ее - оценивает каждую декомпозированную историю, субъективно прикидывая, сколько это времени займет у него.
Тут всё зависит от опыта аналитика, количества решенных аналогичных задач и точности изначальной постановки задачи заказчиком. Далее на основе декомпозиции от аналитика - оценку делает остальная команда.
Груминг
Новый для меня процесс, который происходит на моем текущем месте работы, и смысл которого мне понравился.
Сам груминг проходит еженедельно:
Аналитик приносит туда свои завершенные задачи и презентует их команде, т.е. рассказывает их смысл, демонстрирует своё ТЗ и объясняет свое видение решения этой задачи.
Вся остальная команда может высказывать свои комментарии (зачастую очень дельные, и это помогает найти какие-то недочеты или даже логические дыры в твоем ТЗ) и делиться своим мнением относительно задачи, предлагать свои варианты решения.
Аналитик в процессе груминга может править ТЗ, если это не занимает много времени, и получается такая "экстремальная аналитика" в онлайн-формате.
После того, как все вопросы\предложения закончились, начинается оценка задачи командой разработки и тестирования, уже по написанному ТЗ, что заметно увеличивает точность оценки, чем если оценивать задачи по предварительному мини-анализу.