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