2025/09/29 09:00:20

Agile Software Development
Гибкая методология разработки

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

Содержание

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

Agile-методы делают упор на непосредственное общение лицом к лицу. Большинство agile-команд расположены в одном офисе иногда называемом bullpen. Как минимум она включает и «заказчиков» (заказчики которые определяют продукт, также это могут быть менеджеры продукта, бизнес-аналитики или клиенты). Офис может также включать тестировщиков, дизайнеров интерфейса, технических писателей и менеджеров.

Основной метрикой agile-методов является рабочий продукт. Отдавая предпочтение непосредственному общению, agile-методы уменьшают объем письменной документации, по сравнению с другими методами.

Внедрение в России

2025: Agile теряет популярность в России. Что теперь выбирают разработчики ПО - TA мнения

Методика Agile, предлагающая упорядоченные и простые процессы и помещающая людей в центр разработки, в свое время стала революционной в ИТ-отрасли. Однако экономические вызовы, включая санкции и импортозамещение, а также технологические сдвиги, такие внедрение ИИ и DevOps, порождают вопросы о будущем Agile. В сентябре 2025 года TAdviser опросил участников рынка, чтобы понять, что происходит с Agile и какое будущее у этой методологии.

По словам коммерческого директора ИТ-компании Purrweb Сергея Никоненко, в 2022-2023 гг. шел настоящий бум импортозамещения: бюджеты щедро выделялись сверху, команды могли позволить себе гибкие методологии, эксперименты и быстрые развороты. Но к 2025 году большинство крупных проектов уже реализовано, а денег было потрачено больше, чем планировалось, рассуждает Никоненко. Теперь ситуация изменилась: заказчики ждут от подрядчиков не свободы и креатива, а жесткого контроля, соблюдения сроков и прозрачности бюджетов. В этой логике, как считает эксперт, классический Agile с его ставкой на доверие и свободу начинает работать против системы: он про гибкость, а реальность — про дисциплину и отчетность.

Методология Agile теряет позиции на российском ИТ-рынке. На что переходят разработчики и почему - мнения экспертов

ИТ-архитектор Евгений Фроликов (руководил проектами разработки ПО в ряде крупных российских страховых компаний) уверен, что Agile теряет популярность как «бренд и набор ритуалов».

«
Причины: усталость от Agile-театра и сертификаций, копирование SAFe/Spotify без культуры, рост регуляторики и фикс-контрактов, акцент на безопасность и предсказуемость при импортозамещении. Принципы (итеративность, обратная связь, фокус на ценности) живут — мы просто уходим от церемоний к измеримым результатам, - сказал Фроликов.
»

Технический директор «АЛМИ Партнер» Станислав Орлов также считает, что Agile теряет популярность в российской разработке ПО. Но это не связано с уменьшением самой популярности, а с изменением контекста и задач, которые стоят перед командами. Методологии, включая Agile, существуют для синхронизации заказчиков и исполнителей в конкретных условиях, уточнил эксперт. По его мнению, в России приоритет смещён в сторону строгих правил, документов, чёткого функционала и жёстких сроков. Российское законодательство и особенно закупочные процедуры требуют точного соблюдения технического задания и нормативных документов. Это противоречит принципам Agile, где изменения — основа методологии, добавил Орлов.

Антон Захаров, заместитель технического директора разработчика Forward, в свою очередь считает, что вопрос именно в том, как именно набор принципов Agile внедряется на практике: «У многих это происходит своеобразно: мы словно «по диагонали» читаем манифест и практики, выбираем удобные элементы и отбрасываем всё остальное. Но изначально ценность Agile была именно в целостности подхода. При выборочном использовании теряется сама суть: прозрачность процессов, быстрая обратная связь и возможность адаптации к изменениям. В итоге компании получают не гибкую модель разработки, а некий гибрид, который часто не приносит ожидаемого результата. Отсюда и ощущение, что Agile не взлетел».

Руководитель проектов ООО «Оператор Газпром ИД» Ахрор Асилходжаев утверждает, что в российских компаниях все чаще применяется подход JTBD (Jobs to Be Done), при котором команды фокусируются на понимании задач, которые пользователи пытаются решить с помощью продукта. Впрочем, JTBD - это скорее способ постановки задач, чем полноценная методология, уточнил он.

Как рассказал руководитель направления Java-разработки «Рексофта» Зураб Белый, «Agile-бум» в РФ закончился: те, кто хотел внедрить – внедрили, те, кто хотел рассказать – рассказали. Agile перестал быть просто «новомодной фичей» и перешел в разряд рабочих инструментов. Теперь его применяют более осознанно: когда требования на старте не определены и будут меняться — выбирают чистый Agile или его фреймворки (Scrum, Kanban), продолжает собеседник TAdviser. В противовес все чаще появляется «водопадная модель» (Waterfall) с фиксированными требованиями, но и она редко используется в чистом виде. Чаще встречаются гибриды: например, аналитику проводят по Waterfall, формируют технические задания, а разработку ведут короткими итерациями по Agile, сочетая тщательное планирование с гибкостью исполнения.

«
Agile перестал быть единственно верным ответом на все вызовы. Рынок стал более зрелым и осознанным — мы начали подходить к выбору методологии управления исходя из конкретного проекта, его контекста, сроков, задач и команды. Вот подход „Agile ради Agile`, просто для галочки, действительно отживает свое. Его заменяет более прагматичный и взвешенный выбор, - отметил Зураб Белый.
»

Директор департамента проектирования и разработки IBS Максим Ковтун согласен, что в ближайшем будущем самой распростраенной в России останется гибридная модель разрабтки. В условиях ускорения разработки за счет ИИ-инструментов повышается важность DevSecOps как дополнения к Agile. Важны не только процессы управления разработкой, но и технологическая основа для еще более быстрых поставок, безопасность программного кода и среды разработки, в которой используется искусственный интеллект, уточнил эксперт.

Советник руководителя ГКУ ЦОДД Правительства Москвы Мстислав Исаков заявил, что Agile в России не исчезает, а эволюционирует. По его словам, в госсекторе обязательны стадии и артефакты по ГОСТ 34/59793, что формирует «Agile-по-ГОСТу» с жёсткой дисциплиной. Исаков приводит данные, согласно которым порядка 42% компаний в России используют собственные схемы масштабирования, 18% — SAFe, 21% — другие методологии, 19% — гибриды.

Agile действительно эволюционирует, говорит директор проектов заказной разработки ГК «УльтимаТек» Эдуард Степанов. Например, эта методология используется на уровне команд разработки, а на уровне управления портфелем проектов или взаимодействия с нефтех-заказчиком может использоваться более предсказуемый традиционный Waterfall-like подход.

«
Мы наблюдаем, как растет популярность других фреймворков, таких как OKR (Objectives and Key Results) для стратегического целеполагания и DevOps для культурной и технической практики. Они не заменяют Agile, а прекрасно дополняют его, создавая более целостную картину, - уточнил Степанов.
»

Руководитель продвижения продукта Directum Projects Никита Аксянов утверждает, что компании отходят от «чистого» Scrum или Kanban в пользу гибридных моделей, адаптированных под масштаб, регулятивные требования и зрелость команд. Agile становится частью общей культуры управления: его используют не только в разработке, но и в проектах цифровой трансформации, управлении инициативами и портфелями, добавил он.

Сергей Никоненко из Purrweb полагает, что Agile никуда не денется, но его «вольность» останется внутри командной реализации: свободы станет меньше, зато бизнес получит то, чего сейчас ждёт больше всего, — предсказуемость. В 2026 году на первый план, скорее всего, выйдет так называемый FFF-подход (Fixed budget, Fixed time, Flexible scope) — фиксированные сроки и бюджеты при адаптивном управлении объемом задач, прогнозирует он.

«
Agile не новое изобретение, - комментирует генеральный директор АНО "Национальный центр компетенций по информационным системам управления холдингом" (НЦК ИСУ) Кирилл Семион сомневается. - Просто раньше внутренние разработчики за зарплату работали точно так же, но это никто не называл таким красивым словом. Так что ничего не изменится. Это не очень удобно в случае с контрактными заказными разработками, так как тяжело планировать ресурсы и человеческие, и финансовые.
»

2023: От Agile к гибкости: как в Magora Systems помогают российскому бизнесу расти

Алексей Чернега, старший менеджер проектов Magora Systems, в интервью рассказал о том, как преодолеть скептическое отношение к Agile, гибридным подходам, основным навыкам менеджера проектов и особенностям управления проектами в сфере финансовых технологий и здравоохранения. Подробнее здесь.

2021: Анализ разных сфер экономики на предмет применения Agile

Компания Перфоманс Лаб анализировала разные сферы экономики на предмет популярности и понимания компаниями методик Agile и сделала прогнозы на 2021 год относительно внедрения и успешности этого подхода на российском рынке. Результаты анализа компания сообщила 9 марта 2021 года.

В банках гибкие методологии разработки (Agile) использует большинство (91%) опрошенных банковских организаций. Хотя по опросам некоторые банковские организаций еще не готовы использовать Agile по полной. Например, Илья Кучугин, директор блока информационных технологий банка "Зенит" согласен, что Agile-технологии все активнее проникают в банковскую деятельность. По его словам, со стороны может показаться, что речь идет исключительно о техническом моменте, но на практике эта тенденция влечет за собой коренные изменения на всем ИТ-рынке. С внедрением гибких методологий будут скорректированы подходы к набору и управлению персоналом, придется переосмыслить роль менеджмента.

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

»

Из исследования RQR 2020-2021 (Russia Quality Report) Перфоманс Лаб, в котором было опрошено более 350 организаций из телекома, ИТ, финансовой сферы, ритейла, ТЭК, промышленности о ситуации на рынке обеспечения качества ИТ-систем и тестирования рынка ПО в России следует, что гибкие методологии разработки (Agile) популярны не во всех областях экономики, кто-то не знает, что с ними делать, обладаем небольшим опытом или просто пока не готов к использованию. Несмотря на это, гибкие методологии разработки (Agile) продолжают завоевывать симпатии российских компаний и организаций. По данным прошлых отчетов компании, еще четыре года назад такой подход применяли всего 43% опрошенных игроков рынка. В 2020 году их количество увеличилось до 80%.

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

В ритейле популярность Agile продолжает расти в России. Опрос торговых компаний показал, что большая их часть (60%) использует этот подход. За 2019-2020 года данный показатель вырос на 7%.

Организации, которые работают на рынках ритейла и электронной коммерции, назвали недостаток понимания подходов к тестированию по методологии Agile основной проблемой в 2020 году. Об этом говорили 57% респондентов.

Гибкие методологии разработки (Agile) применяют только 25% опрошенных организаций государственного сектора. Выбор в пользу этого подхода респонденты объясняют повышением прозрачности, управляемости и быстроты разработки продукта.

Основными сложностями при использовании Agile для респондентов являются: недостаток тестовых сред и данных, а также отсутствие опыта тестирования в команде (по 33%). Еще 67% участников опроса не могут назвать актуальные для них проблемы применения Agile, так как не используют эту методологию.

На рынке системной интеграции около 90% системных интеграторов, принявших участие в опросе, применяет Agile.

В телекоме большинство опрошенных телекоммуникационных компаний (80%) применяют гибкие методологии разработки (Agile).

2017: Компании быстро осваивают Agile — исследование

В конце октября 2017 года компания ScrumTrek (Скрамтрек), специализирующаяся на внедрении agile-подходов, опубликовала результаты исследования, показавшие быстрое внедрение Agile в России. При этом технология выходит за пределы ИТ.

В ScrumTrek опросили почти 800 представителей малого, среднего и крупного бизнеса в 50 городах. 61% респондентов — это менеджеры проектов, миддл-менеджеры, скрам-мастера и другие руководители; 21 % от этого сегмента — топ-менеджеры и владельцы предприятий. 

Насколько Agile развита в России

Согласно опросу, 40% респондентов, начавших применять Agile не более 1,5 лет назад, уже внедрили гибкие методологии во всей или почти во всей компании. Лишь 20% организаций, применяющих Agile 2-3 года, продолжают пилотные проекты на уровне отдельных команд, но многие успели пойти дальше локальных экспериментов.

Около 50% компаний начали использовать Agile примерно назад. Около 41% организаций познакомились с гибкими методологиями около полутора лет назад.

Чаще всего российский бизнес внедряет Agile для ускорения поставок и вывода продуктов на рынок. Добиться этой цели благодаря использованию гибких методологий на момент составления исследования удалось менее чем половине респондентов (мировой показатель — 81%), говорится в докладе ScrumTrek.

Зачем российские компании внедряют Agile

Больше двух третей участников опроса (68%), работающих в компаниях с опытом внедрения Agile, либо представляют ИТ-бизнес, либо активно вовлечены в процесс разработки программного обеспечения. Вместе с тем доля респондентов, никак не связанных с информационными технологиями, достаточно велики и составляет 32%.

Почти половина этих опрошенных (40%) работают в страховых и финансовых компаниях, в том числе в банках, которые часто называют главным драйвером применения agile-подходов в последние несколько лет. 

SAFe - Scaled Agile Framework

SAFe (ScaledAgile Framework) – база знаний проверенных, интегрированных принципов, практик и компетенций для Lean,Agile, DevOps в масштабе

Преимущества SAFe

  • Спроектирован для крупных Enterprise-организаций
  • Основан на реальном опыте мировых компаний
  • Базируется на близких нам принципах
  • Включает в себя выравнивание на всех уровнях от стратегии, сохраняя гибкость организации
  • Есть практический опыт в России
  • Уделяет внимание техническому долгу, архитектуре и DevOps

4 базовые концепции Agile

Agile, гибкая методология разработки ПО, предоставляет ряд преимуществ перед более консервативной и менее подходящей для производителей софтов системы Waterfall, однако некоторые организации не спешат с переходом. IТ-эксперт Боб Ронан (Bob Ronan) в своей статье перечисляет преимущества, которые следует учесть директорам по информационным технологиям (CIO), рассматривающим возможность перехода на Agile[1].

1. Технические и бизнес-подразделения совместно располагаются в открытой зоне

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

2. Сценарии тестирования разрабатываются до начала этапа программирования

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

3. Утренние планерки проводятся каждый день

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

4. Процесс состоит из рабочих циклов продолжительностью от одной до четырех недель, которые называют «спринтами»

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

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

Распределенная гибкая модель

Большинство организаций не могут позволить себе роскошь собрать всех разработчиков в одном физическом месте, поэтому сомневаются, подойдет ли им agile-модель. Она подойдет, но это потребует инвестиций в технологии и командировки.

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

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

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

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

10 преимуществ Agile

1. Быстрое выявление неправильных подходов

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

2. Быстрое принятие решений

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

3. Сотрудничество выливается в множество преимуществ

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

4. Изменения признаются неизбежными и приветствуются

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

5. Конечный продукт содержит наиболее полезные функции

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

6. Более привлекательная среда для поколения Y

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

7. Более высокое качество кода готового продукта

"Однажды я провел семилетний анализ наших количественных показателей. Оказалось, что проекты, основанные на гибкой модели разработки, отличались существенно меньшим количеством дефектов в производственной среде", – говорит Боб.

8. Бизнес-группа испытывает большее удовлетворение итоговыми результатами

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

9. Составление технической документации занимает меньше времени и содержит меньше ошибок

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

10. Более простое обслуживание приложения

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

Методологии

Философия Agile сформировала класс методологий управления проектами, который включает в себя:

  • Scrum,
  • Kanban,
  • XP (eXtreme Programming),
  • Lean,
  • FDD (Feature Driven Development),
  • DevOps и другие.

Направления использования

Agile в управлении госпроектами

Основная статья: Agile в управлении государственными проектами

Если Agile настолько хорош, почему он используется не всеми организациями?

«Во-первых, многие ИТ-руководители не любят рисковать, а изменение процесса разработки связано с резкими переменами. Во-вторых, гибкая модель иногда не срабатывает, после чего от нее отказываются. В основе этих двух причин лежит риск неудачи, но его можно снизить, если избежать двух типичных ошибок применения гибкой модели. По опыту могу сказать, что Agile не срабатывает, когда инициатива по ее внедрению спускается сверху – проектным группам говорят, что теперь они будут использовать гибкую модель разработки и говорят, как именно им с ней работать. Строгая методология противоречит самой сущности Agile. Весь ее смысл заключается в том, чтобы попробовать как можно больше идей и использовать те, которые будут работать.

Чтобы agile-метод заработал, необходимо найти группу, которая не против ее опробовать, и затем предоставить им полную свободу в выборе методов, подходящих для этой конкретной организации. Вы получите результат, проектная группа станет приверженцем метода, и вскоре к вам будут приходить руководители других групп и спрашивать, почему Agile не работает в их проектах», – подчеркивает эксперт.

Agile в банках

Опыт применения

Основное отличие методологии Agile от прошлых методов разработки состоит в понимании того, что в ходе проекта все может изменяться. Поэтому важно и нужно учитывать эти изменения, чтобы результат проекта наиболее полно удовлетворял его бизнес-цели и выполнял поставленные задачи. О самых популярных гибких методологиях разработки и опыте их применения в рубрике TADетали рассказали эксперты ГКС (АО «Группа Систематика»). См. Суперсеты, эстафеты и гонки на скоростных спорткарах – спортивный agile подход к процессу выполнения проекта

Смотрите также

Примечания