---

Оценка трудоёмкости в Scrum: руководство по лучшим методам оценки для Agile- и Scrum-команд

Оценка трудоёмкости в Scrum предполагает назначение задаче меры размера или времени. Это позволяет заранее сделать обоснованную приблизительную оценку работы, необходимой для её завершения. Для этого команды могут применять Planning Poker, стори-пойнты и идеальные дни. За оценку размера отвечают Разработчики, которые будут выполнять работу; Scrum-мастер может помочь им улучшить процесс. Опытным Agile-командам эти методы вскоре могут стать привычными, а новичкам они порой кажутся сложными загадками. В следующем поиске сокровищ на пути к мастерству Scrum ваша первая подсказка скрыта в разделе «Относительная оценка размера и стори-пойнты».

Оценивая трудоёмкость в Scrum, команды часто используют такие методы, как Planning Poker®, чтобы совместно назначать пользовательским историям относительные размеры. Это помогает точнее понять объём работы и достичь согласия в команде относительно сложности задач. Помните: цель оценки трудоёмкости — не точность сама по себе, а поддержка планирования и принятия решений.

Оценка трудоёмкости в Scrum-команде

Оценка трудоёмкости — важнейшая часть планирования Scrum-команды. Она помогает сформировать реалистичные ожидания об объёме работы для завершения пользовательских историй или задач. Назначая каждой задаче относительный размер или временную оценку, команда может принимать обоснованные решения о своих возможностях и эффективнее планировать Спринты.

Один из популярных методов оценки трудоёмкости в Scrum-командах — Покер планирования. Этот увлекательный метод позволяет участникам совместно оценивать сложность задачи. Каждый выбирает карту с числом, отражающим его оценку на основе собственного понимания задачи. Обсуждая различия в оценках, команда может получить ценные выводы и достичь согласия о необходимых усилиях.

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

Ещё один эффективный метод оценки трудоёмкости использует Стори-пойнты. Он предполагает назначение пользовательским историям баллов в зависимости от их сложности и усилий, необходимых для реализации. Для назначения стори-пойнтов часто используют последовательность Фибоначчи (1, 2, 3, 5, 8, 13 и так далее), где каждое следующее число отражает более высокий уровень сложности.

Стори-пойнты дают относительную меру трудоёмкости и помогают сравнивать работу, необходимую для разных пользовательских историй. Этот метод побуждает команды сосредоточиваться на относительной сложности задач, а не на точных временных оценках, обеспечивая большую гибкость и адаптивность при планировании и выполнении.

Помимо этих методов, Scrum-команды также используют Идеальные дни для оценки трудоёмкости. Этот метод предполагает оценку того, сколько «идеальных» дней потребуется для выполнения задачи без перерывов и внешних факторов, влияющих на продуктивность. Идеальные дни дают осязаемое представление о необходимых усилиях, позволяя командам эффективнее оценивать свои возможности.

Разбивая задачи на управляемые единицы и оценивая необходимые для их выполнения идеальные дни, команды могут яснее понимать трудоёмкость и точнее определять обязательства на Спринт.

В целом эффективная оценка трудоёмкости позволяет Scrum-командам планировать и выполнять проекты с ясностью и уверенностью. Она поддерживает прозрачность, сотрудничество и адаптивность внутри команды, способствуя успеху инициатив гибкого управления проектами.

Рассмотрев разные методы оценки трудоёмкости в Scrum-проектах, теперь подробнее изучим относительную оценку размера и стори-пойнты.

Как оценивать трудоёмкость историй во фреймворке Scrum?

Полезные оценки помогают Владельцу продукта упорядочивать элементы бэклога продукта и прогнозировать выпуски. Достаточно уточняйте ближайшие элементы, чтобы поддержать принятие решений; отдалённые или неопределённые идеи могут оставаться более крупными и менее подробными, пока не появятся новые знания. Оценка помогает прогнозировать, а не гарантирует срок поставки.

При этом Владелец продукта предоставляет контекст и обсуждает компромиссы, не оказывая давления на Разработчиков ради получения желаемого числа. Разработчики, выполняющие работу, сохраняют ответственность за оценку её размера.

Сам фреймворк Scrum не предписывает способ оценки работы Scrum-команд. Команды могут применять временные оценки, например идеальные дни, или более абстрактные относительные единицы, например стори-пойнты, чтобы сравнивать необходимую работу. Scrum не требует ни Planning Poker, ни определённой единицы оценки.

Распространённые методы оценки включают:

• Числовую оценку размера (от 1 до 10),
• Размеры футболок (XS, S, M, L, XL, XXL, XXXL) или
• последовательность Фибоначчи (0, 1, 2, 3, 5, 8, 13, 21, 34 и так далее)

Пример пользовательской истории

Участники Scrum-команды должны одинаково понимать используемую единицу оценки и быть с ней согласны, чтобы каждый чувствовал себя уверенно при её применении.

Planning Poker® / Scrum-покер

Один из распространённых способов оценки — игра Planning Poker®: Покер планирования Scrum

В Planning Poker® независимый выбор карт и их одновременное раскрытие помогают уменьшить привязку к первой озвученной оценке. Обсуждение разных оценок может улучшить понимание, хотя и не гарантирует точного прогноза.

Для игры в Planning Poker® нужно совсем немного:

• Список функций, которые предстоит оценить
• Колоды карт с числами.

Типичная колода содержит карты со значениями на основе последовательности Фибоначчи, включая ноль: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89. Возможны и другие похожие последовательности. Последовательность Фибоначчи используется, чтобы отражать неопределённость при оценке крупных элементов. Было бы пустой тратой времени обсуждать, какой размер назначить пользовательской истории — 19, 20 или 21. При этом относительно легко решить, какой размер лучше подходит пользовательской истории — 13 или 21.

Высокая оценка может означать, что участники Scrum-команды ещё недостаточно хорошо поняли пользовательскую историю. Поэтому перед тем, как взять её в работу, они могут попытаться заложить дополнительный резерв возможностей на непредвиденные обстоятельства. В качестве альтернативы это может означать, что пользовательскую историю нужно разбить на несколько меньших историй. Обычно Scrum-команды могут с большей уверенностью оценивать меньшие и более понятные пользовательские истории.

Наконец, Scrum-команда играет в Planning Poker®, следуя таким шагам:

• Владелец продукта представляет историю, которую предстоит оценить. Scrum-команда задаёт вопросы, а Владелец продукта подробнее объясняет пользовательскую историю. Если нужно оценить много историй, можно ограничить время так, чтобы на каждую уходило не больше нескольких минут. Если команда всё же не может оценить историю за отведённое время, это может быть сигналом для Владельца продукта: требование конечного пользователя, пользовательская история или и то и другое недостаточно ясны и нуждаются в переформулировке.
• Каждый Разработчик, который будет выполнять работу, самостоятельно и не раскрывая выбора выбирает карту со своей оценкой. Владелец продукта отвечает на вопросы и предоставляет контекст.
• Когда все выбрали карты, все оценки раскрывают одновременно.
• Участников с высокими и низкими оценками просят объяснить свой выбор: возможно, они учли то, чего большинство участников Scrum-команды не заметило.
• Эту пользовательскую историю оценивают повторно, пока команда не достигнет согласия об оценке.
• Участники оценки повторяют игру для историй, выбранных для этой встречи. Неясный элемент можно отложить для дальнейшего уточнения вместо того, чтобы любой ценой назначать ему число.

Planning Poker® — зарегистрированный товарный знак Mountain Goat Software, LLC.

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

В мире гибкого управления проектами относительная оценка размера похожа на собственный секретный код команды: с её помощью команда понимает сложность и трудоёмкость задач. Идея проста: задача с оценкой 5 стори-пойнтов считается более крупной, чем задача с оценкой 2 стори-пойнта. Эти относительные значения выражают суждение команды о работе; они не гарантируют точную продолжительность или точное соотношение сложности.

Относительная оценка размера в стори-пойнтах даёт Scrum-командам общий язык для понимания и обсуждения размера и сложности работы. Например, команда может договориться, что создание простого пользовательского интерфейса соответствует 3 стори-пойнтам, а более сложная функция — 8 стори-пойнтам. Метод учитывает не только время выполнения задачи, но и другие факторы: риск, неопределённость и общую сложность. Понимая эти меры в контексте относительной оценки размера, команды могут точнее оценивать и распределять усилия между задачами. Оценка каждой команды служит ориентиром того, сколько работы можно взять в течение Спринта.

Представьте две задачи: первая — реализовать простую функцию с небольшим риском, трудоёмкостью или сложностью; вторая — переработать целый модуль с высоким риском и значительными усилиями. Здесь и полезна относительная оценка размера. Меньшая оценка в стори-пойнтах для первой задачи и большая для второй помогают команде наглядно сравнивать и классифицировать их по сложности и трудоёмкости. Затем это влияет на планирование Спринтов, улучшая распределение ресурсов и времени.

Для назначения стори-пойнтов команды часто используют такие методы, как Planning Poker®: каждый участник самостоятельно и не раскрывая выбора определяет число стори-пойнтов, которое, по его мнению, соответствует конкретной задаче. Затем следует общее обсуждение до достижения согласия. Это поддерживает сотрудничество и позволяет использовать коллективные знания для более точной оценки.

Понимание относительной оценки размера и стори-пойнтов необходимо Scrum-командам для эффективного планирования Спринтов, распределения усилий и, в конечном счёте, улучшения результатов проектов на основе точных оценок.

Преимущества точной оценки трудоёмкости

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

1. Эффективная расстановка приоритетов и планирование: Точные оценки трудоёмкости позволяют командам эффективно расставлять приоритеты и планировать работу. Зная, сколько усилий требует каждая задача, можно лучше распределять ресурсы и время, сначала заниматься критически важными элементами и обеспечивать плавное продвижение проекта.
2. Управление ожиданиями заинтересованных сторон: Точные оценки дают заинтересованным сторонам реалистичное представление о сроках и результатах проекта. Такая прозрачность помогает выстраивать доверие и понимание между командой и заинтересованными сторонами, уменьшая разочарование из-за пропущенных сроков.
3. Повышение прозрачности: Точные оценки поддерживают прозрачность проекта: участники понимают, каких усилий требует каждая задача, и принимают обоснованные решения о рабочем процессе, зависимостях и потенциальных узких местах.
4. Улучшение сотрудничества и доверия: Эффективные оценки трудоёмкости улучшают сотрудничество и доверие между участниками команды и заинтересованными сторонами. Уверенность в оценках помогает принимать более качественные решения, положительно влияет на общий настрой команды и согласовывает ожидания всех участников с реалистичными требованиями проекта.
5. Успешная поставка результатов проекта: Точные оценки трудоёмкости существенно способствуют успешной поставке результатов проекта, давая ясное понимание того, что необходимо и сколько времени это займёт. Они позволяют командам управлять рисками, заранее выявлять проблемы и обеспечивать слаженное выполнение на всём жизненном цикле проекта.

По сути, точные оценки трудоёмкости играют важнейшую роль в упорядочении процессов управления проектом, поддержке сотрудничества и достижении успешных результатов. Надёжная система оценки действительно является основой эффективного гибкого управления проектами.

Разобравшись в важности точной оценки трудоёмкости в Agile-проектах, теперь перейдём к обзору процесса оценки в Scrum.

Обзор процесса оценки в Scrum

Планирование Спринта открывает Спринт. Оценка и уточнение могли быть проведены заранее; на Планировании Спринта Scrum-команда обсуждает ценность Спринта, а Разработчики выбирают работу, которую, по их прогнозу, смогут завершить. При оценке их задача — совместно определить усилия, необходимые для каждой задачи. Это предотвращает неожиданные сюрпризы в последний момент или нереалистичные ожидания и обеспечивает общее понимание у всех — участников команды, заинтересованных сторон и клиентов — того, что реально достижимо за заданное время.

На этих встречах Scrum-команды используют разные методы оценки, например Покер планирования или Стори-пойнты, чтобы определить усилия для каждой задачи. Это крайне важно, поскольку позволяет разбивать сложные задачи на меньшие и более управляемые единицы. Такие методы учитывают разные взгляды участников команды, помогая точнее оценить общий объём работы.

Допустим, у нас большой проект с множеством задач разной сложности. Используя эти методы оценки, команда разбивает каждую крупную задачу на меньшие и назначает соответствующие стори-пойнты. Это помогает понять, сколько времени и усилий может потребовать каждая небольшая задача. Это похоже на решение большого пазла: разделение его на маленькие части даёт более ясное представление о том, с чего начать и сколько времени может занять завершение каждой части.

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

Когда все привержены достижению целей Спринта, а задачи распределены с учётом сильных сторон и компетенций участников, процесс оценки в Scrum поддерживает преданность команды делу. Рассмотрев, как этот процесс создаёт условия для успешного выполнения проекта, перейдём к его дополнительным преимуществам.

Как совершенствовать оценки трудоёмкости со временем

Ключ к совершенствованию оценок трудоёмкости в гибком управлении проектами — непрерывное улучшение. Один из способов уточнять оценки со временем — использовать исторические данные и обратную связь по завершённым проектам.

Если вы отслеживаете прошедшие Спринты Scrum и завершённую в них работу, эти данные можно использовать для улучшения будущих оценок. Такой подход помогает выявлять закономерности и тенденции в работе команды и лучше оценивать предстоящую работу.

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

Важно, чтобы этот процесс не превращался в поиск виноватых. Его следует воспринимать как возможность для обучения и роста. Понимание причин ошибочной оценки даёт ценные выводы, которые можно использовать для совершенствования будущей работы.

Например, если задача заняла больше времени, чем ожидалось, важно выяснить причины. Изменились требования? Команда столкнулась с непредвиденными техническими трудностями? Собирая эту информацию, команды могут корректировать будущие оценки с учётом похожих ситуаций.

Это похоже на обучение на собственном опыте в других сферах жизни. Как повар использует прежний опыт работы с рецептами для совершенствования кулинарного мастерства, так и Scrum-команда использует данные прошлых проектов для повышения точности оценок.

Более зрелые команды могут применять статистические методы, например моделирование Монте-Карло или байесовский анализ, чтобы со временем уточнять оценки. Эти методы учитывают исторические данные, разброс и неопределённость для более точных прогнозов.

Постоянно анализируя данные прошлой работы, проверяя точность прежних оценок и учитывая новые выводы в последующих оценках, Scrum-команды улучшают свои способности прогнозировать и поставляют ценность более предсказуемо.

Основательно разобравшись в совершенствовании оценок трудоёмкости со временем, теперь рассмотрим важность определения и адаптации базовой скорости команды в гибком управлении проектами.

Важность определения и адаптации базовой скорости команды

Представьте, что отправляетесь в долгое путешествие. Вам хотелось бы знать среднюю скорость, необходимую, чтобы добраться до места вовремя, верно? Базовая скорость команды работает по похожему принципу в гибком управлении проектами. Она даёт эмпирический ориентир для прогноза вероятных возможностей команды с учётом Цели Спринта и качества. Это не обязательный темп и не норма выработки.

Базовая скорость определяется по историческим результатам команды. Это не просто число: она отражает уникальный ритм, в котором обычно работает ваша команда. Понимая этот ритм, вы получаете ценные сведения о том, сколько работы команда реально может завершить за Спринт. Это важно для эффективного планирования проекта и постановки достижимых целей Спринта.

Пример расчёта базовой скорости команды:

Например, по данным прошлой работы команда разработки успешно завершает в среднем 25 стори-пойнтов за Спринт. Это среднее становится её базовой скоростью — ориентиром для будущих оценок и Планирования Спринтов.

Однако важно понимать, что команды со временем меняются. Могут присоединяться новые участники, расширяться навыки или возникать внешние факторы, влияющие на продуктивность. Поэтому адаптация базовой скорости к меняющимся возможностям и способностям команды необходима, чтобы оценки оставались актуальными и соответствовали фактической продуктивности.

Адаптация базовой скорости похожа на перенастройку компаса при движении по меняющейся местности. Учитывая изменения командной динамики и уровня навыков, вы можете пересматривать ожидания в соответствии с текущими возможностями команды. Такой упреждающий подход предотвращает нереалистичные оценки и позволяет стабильно поставлять ценность.

Определение и адаптация базовой скорости нужны для согласования прогнозов с тем, что эта команда действительно завершала, и с её предстоящими возможностями. Скорость не должна становиться целью, которую нужно завышать, мерой индивидуальной продуктивности или способом сравнивать команды с разными шкалами оценки.

Определяя и адаптируя базовую скорость, Agile-команды могут лучше планировать Спринты с учётом своих возможностей и обеспечивать успешную поставку результатов. Если хотите подробнее узнать о гибком управлении проектами, ознакомьтесь с разделом Бесплатные ресурсы International Scrum Institute.

Каких распространённых трудностей и ошибок следует избегать при оценке трудоёмкости в Scrum-проекте?

Ответ: среди распространённых трудностей и ошибок при оценке трудоёмкости в Scrum-проекте — недооценка сложности задач, чрезмерная опора на исторические данные без учёта контекста конкретного проекта и игнорирование возможностей команды или индивидуальных навыков. Согласно исследованию McKinsey, неточные оценки могут приводить к задержкам проектов или перерасходу бюджета, поэтому эти трудности важно учитывать уже в начале оценки. Регулярный пересмотр и корректировка оценок на основе фактического прогресса и обратной связи помогают снизить эти риски.

Какие факторы следует учитывать при оценке трудоёмкости в Scrum-проекте?

Ответ: при оценке трудоёмкости в Scrum-проекте следует учитывать несколько факторов: сложность задач, уровень навыков участвующих специалистов, доступность и стабильность ресурсов, зависимости и ограничения. Для повышения точности также можно использовать исторические данные прежних Спринтов. Исследование McKinsey показало, что точная оценка трудоёмкости может повысить долю успешных проектов на величину до 70%. Поэтому тщательный учёт этих факторов крайне важен для эффективного планирования и успешного выполнения Scrum-проектов.

Какие методы оценки трудоёмкости существуют в Scrum?

Ответ: в книге рассматриваются разные методы оценки трудоёмкости в Scrum, включая Planning Poker, размеры футболок и последовательность Фибоначчи. Planning Poker — совместный подход, помогающий командам оценивать усилия, назначая пользовательским историям баллы. Размеры футболок дают быстрый и простой способ оценки: задачи относят к малому, среднему, большому или очень большому размеру. Последовательность Фибоначчи назначает историям относительные значения по сложности, помогая точнее оценивать работу. Эти методы широко применяются в гибком управлении проектами и показали способность повышать точность оценки трудоёмкости проектов.

Можно ли со временем повысить точность оценок трудоёмкости в Scrum?

Ответ: да, точность оценок трудоёмкости в Scrum можно повышать со временем. По мере накопления опыта и знаний о своей работе Scrum-команды лучше оценивают усилия для разных задач. Согласно опросу Agile Alliance, команды, практиковавшие Scrum два года или дольше, сообщили о значительном повышении точности: 75% из них достигали оценок в пределах +/- 10% от фактически затраченных усилий. Это улучшение связано с непрерывным обучением, ретроспективным анализом и совершенствованием методов оценки внутри команды.

Насколько точны оценки трудоёмкости в Scrum на практике?

Ответ: точность оценок трудоёмкости в Scrum на практике зависит от нескольких факторов. Один из важных факторов — опыт и компетентность участников оценки. Оценки обычно улучшаются по мере знакомства команды со сложностями проекта. Кроме того, точность можно повысить с помощью исторических данных прошлых проектов и учёта фактически затраченных усилий. Однако важно понимать, что оценки всё равно подвержены неопределённости и неожиданным трудностям, поэтому по своей природе несовершенны. Согласно исследованию Li и соавторов, точность оценок Agile-команд составляет от 60% до 83%, что показывает и возможности, и ограничения оценки трудоёмкости в Scrum на практике.

Что такое оценка трудоёмкости в Agile?

Ответ: оценка трудоёмкости в Agile — это определение объёма работы, необходимой для завершения элемента бэклога продукта, часто в стори-пойнтах или часах. Это важная часть гибкого управления проектами, соответствующая таким принципам Agile, как готовность к изменениям, сотрудничество и поставка ценности клиенту.

При Agile-планировании команды разбивают бэклог продукта на меньшие, управляемые элементы. Универсального способа оценки нет: разные команды могут применять разные методы, включая стори-пойнты и часы. Стори-пойнты — относительная мера, отражающая сложность и трудоёмкость конкретного элемента и дающая более абстрактный показатель, чем часы.

Один из распространённых способов оценки — встреча Planning Poker. На ней Разработчики совместно обсуждают каждый элемент бэклога, учитывая технические тонкости, зависимости и возможные трудности. Они назначают стори-пойнты или оценивают часы на основе своих компетенций и общего понимания. Такое экспертное суждение помогает учитывать нюансы, которые могут быть незаметны с первого взгляда.

Agile-команды ставят гибкость в приоритет, и оценка трудоёмкости соответствует этому принципу, позволяя корректировать её по мере продвижения проекта. Исходные оценки служат ориентиром; команды уточняют их по мере появления новых знаний и развития бэклога продукта.

Оценка трудоёмкости масштабируется в зависимости от размера и сложности проекта. Крупным проектам могут потребоваться более подробные оценки с разбиением элементов бэклога на ещё меньшие задачи. Постоянное общение участников необходимо, чтобы все одинаково понимали детали и избегали недоразумений, способных повлиять на общий срок проекта.

Одни Agile-команды предпочитают относительные стори-пойнты, другие оценивают непосредственно в часах или идеальных днях. Если команда использует завершённую работу для прогноза календарного времени, нужно указывать допущения и неопределённость: универсального фиксированного пересчёта стори-пойнтов в часы не существует. Команды могут выбрать подходящий способ и со временем проверять его полезность.

Таким образом, оценка трудоёмкости в Agile — совместный процесс, в котором участники используют экспертные суждения, чтобы назначать элементам бэклога продукта стори-пойнты или часы на встречах Planning Poker. Процесс соответствует принципам Agile, подчёркивая гибкость, постоянное общение и сосредоточенность на поставке ценности клиенту.

Обзор оценки трудоёмкости в Scrum

Статья об оценке трудоёмкости в Scrum подробно рассматривает важнейшие аспекты оценки работы в среде Agile-разработки. Она подчёркивает важность соблюдения принципов Scrum и итеративный характер оценки: команда постоянно уточняет своё понимание и прогнозы. На Планировании Спринта команда обсуждает элементы бэклога продукта, разбивает их на меньшие задачи или истории, назначает стори-пойнты и оценивает необходимые усилия в часах или днях. Эти оценки не фиксированы и могут меняться по мере появления новых знаний; экспертное суждение играет ключевую роль в уточнении чисел.

Многие Scrum-команды оценивают трудоёмкость в стори-пойнтах — относительной шкале, которая даёт более абстрактный и гибкий подход, чем традиционная оценка в часах. Каждому элементу бэклога продукта назначают число стори-пойнтов, отражающее предполагаемую сложность и необходимые усилия. Подход поддерживает совместную работу: Разработчики объединяют свои выводы и компетенции, чтобы достичь согласия. Статья подчёркивает важность учёта разных факторов, например зависимостей, неопределённости и скорости команды, для точной оценки трудоёмкости. Так Scrum-команда избегает зацикливания на конкретном количестве часов и использует более адаптивный, итеративный подход, соответствующий динамичной природе разработки программного обеспечения.

При масштабировании оценок трудоёмкости в Scrum статья рекомендует учитывать общую картину, оценивая работу над элементом бэклога продукта. Командам предлагается смотреть дальше непосредственных деталей и оценивать, как предполагаемые усилия соотносятся с общими сроками и целями проекта. Итеративный и совместный характер оценки в Scrum позволяет непрерывно совершенствоваться и учиться на прошлых оценках. Следуя принципам прозрачности и инспекции, Scrum-команды могут улучшать процессы оценки, учиться у других и развивать способность поставлять высококачественные продукты в установленные сроки.