методология agile что это такое простыми словами
Что такое Agile: методология, команда, оценка эффективности
Рассказываем, что представляет собой лежащая в основе методология, раскрываем основные понятия, объясняем, как устроена agile-команда и как оценивается ее эффективность.
Agile — это целое семейство методологий гибкого управления проектами. Интересно, что само понятие управления здесь оказывается не вполне верным. Было бы более точным употреблять формулу «Agile — это способ командного взаимодействия, позволяющий совместно создавать продукты». Однако мы слишком привыкли к силе вертикальных, иерархических связей, поэтому и здесь устойчивым стало употребление слова «управление».
Неудобные вопросы
Управленцы самого разного уровня, от менеджеров низшего звена до директоров корпораций и государственных чиновников, бились над этим десятилетиями. Но до тех пор, пока единственным известным способом более-менее контролируемого создания продуктов и разработки проектов оставался поэтапный — шаг за шагом, одно за другим, — ничего с этими вызовами было не сделать.
Для того чтобы перейти на качественно новый уровень проектной работы, потребовалось коренное изменение парадигмы.
Оказалось, что искать ответы на большинство этих больных вопросов просто незачем. Их нужно снять, а понятия, их породившие, по возможности упразднить. Так на месте поэтапной waterfall-разработки возникли гибкие методологии.
Делай сразу!
Главное мерило эффективности, принятое в гибкой методологии, — продукт. Пока другие только готовят документацию, agile-команды стремятся представить работоспособный прототип. Это как в знаменитой мотивирующей формуле: «„Сделано“ — это лучше, чем „идеально“». Реализуйте первую функцию и начните тестировать её, создавая следующую, и так раз за разом — вот главное правило.
Этап разработки в Agile, это самое «раз за разом», называется итерацией. Итерации имеют одинаковую длительность на протяжении всего проекта и в среднем составляют две недели. В рамках отдельной итерации выполняется конкретная задача, главным свойством которой является то, что ее решение должно обновлять продукт до новой версии или увеличивать его эффективность. Именно по этому признаку такие задачи и отбираются.
Как итеративный подход обеспечивает гибкость? Благодаря тому, что отдельные процессы могут идти параллельно и независимо друг от друга. Да, надо признать, что это может увеличить конечный срок разработки от идеи до полностью готового продукта. Но в том-то и дело, что рабочий, функциональный и уже способный встретиться с конкурентами и порадовать пользователей продукт создаётся в Agile гораздо раньше, а цикличность доработок позволяет добиться куда лучшей проработки таких функций и возможностей, до которых при плановой работе руки бы не дошли никогда.
Горизонтальная организация
Agile-команда строится на принципах самоорганизации и относительного равенства всех участников. Даже человек, которого многие представляют главой проекта, product owner, на самом деле — лишь персонификация требований к продукту. Он выполняет роль носителя знаний о том, каким ожидается конечный результат, но отнюдь не является управляющим в стандартном понимании. Поскольку привычка к иерархичности трудноискоренима, во многих командах ему, увы, приходится брать на себя и контролирующие функции. Но идеалом гибкой разработки является коллективная ответственность членов команды друг перед другом.
Принципы формирования agile-команд разнятся в зависимости от конкретного проекта. Например, в музыкальном сервисе Spotify они строятся вот так:
Ещё одна важная ценность agile-команд — взаимопроникновение знаний. Член команды не должен замыкаться в своей узкой области, ему следует стремиться к кросс-дисциплинарности. Это не значит, что программист должен быть и продавцом, а дизайнер — маркетологом.
Важно!
Но иметь базовые знания о смежных специализациях в гибкой разработке необходимо.
Изначально предполагалось, что это просто будет повышать эффективность работы и уровень взаимопонимания в команде, но сегодня, с развитием нейронаук, стало понятно, что такой подход вдобавок обеспечивает поддержание мозга в тонусе и динамичное создание новых нейронных связей. Такое «перекрёстное опыление» знаниями в Agile называется t-shape. Иллюстрация ниже объяснит, почему так, лучше всяких слов.
Как внедрить Agile?
Переход от каскадной разработки, до сих пор привычной для многих организаций, к гибким методам работы над проектами может быть довольно болезненным.
Во-первых, вам предстоит упразднить иерархичность и при этом добиться того, чтобы все участники процессов смогли на равных разделить ответственность за результат.
Во-вторых, переход к итеративной разработке заставит сосредоточиться на том, чтобы каждый из этапов гарантированно привносил в продукт что-то новое. Это непросто, инерция плановой разработки будет преследовать вас первые несколько месяцев.
Третий вызов — если вы ведёте заказную разработку, будет непросто объяснить клиентам принципы работы, а если входите в состав крупной организации, та же проблема может возникнуть при обосновании перехода на Agile перед вышестоящими руководителями.
Если вам удастся справиться, процессы станут заметно эффективнее, а качество работы — выше. Главное, никогда не забывайте четыре основных ценности Agile, с которых начинается Манифест гибкой разработки:
Следование им и поможет на этапе внедрения, и будет подспорьем в процессе работы.
Лучше познакомиться с Agile и другими современными методологиями, применяемыми в сферах от IT до медиа и маркетинга, а также погрузиться в построенные на их основе процессы вы сможете, пройдя курс «Руководитель digital-проектов» от Skillbox.
Охотник за авторским контентом — ищет спикеров, помогает им делать авторские колонки, берёт интервью. Писал тексты для TJournal, vc.ru, Reed.media, Apparat, «Секрета фирмы», Accent.
Курс «Управление Digital-проектами»
Курс поможет вам оценить себя как менеджера: разобраться и понять, почему у вас что-то не получается. Определить, какие навыки и знания нужно подтянуть. И сделать это, выполняя практические задания.
Методология Agile в двух словах
Agile также является типом современного SDLC. В этой статье вы познакомитесь с базовой концепцией методологии Agile, ее принципами и философией, различными приемами и способами их использования на работе. Сфера применения Agile не ограничена разработчиками программного обеспечения, но и распространяется на технических руководителей, инженеров, менеджеров по продуктам, тестировщиков и всех, кто связан с разработкой программного обеспечения. Agile процесс является гибким, быстрым и способствует непрерывной разработке и улучшению качества продукта.
Потребность в гибкой методологии
Прежде чем вы адаптируетесь к Agile процессу, вы должны сначала признать, что у устаревшего способа разработки программного обеспечения «Waterfall» было много пробелов, которые нужно заполнить. Последовательность «Планировать, Проектировать, Выполнять, Проверять, Выкладывать» может работать для создания мобильных приложений или инфраструктурных проектов, но не для создания Программных приложений. В динамичной бизнес-среде, где затраты и конкуренция ведут к изменениям, методология Agile успешно смогла найти тонкий баланс между ожиданиями и исполнением.
Что такое Agile методология?
Успех гибкого процесса зависит от команды и каждого участника, который будет работать напрямую с клиентом, чтобы понять реальную картину и предложить решения. Ниже приведены важные факторы методологии Agile.
Короткие итерации
Унаследованные процессы разработки программного обеспечения, такие как Waterfall, имели такие фазы, как сбор требований, планирование, проектирование, кодирование, тестирование и выпуск.
Методология Agile, напротив направлена на предоставление всего выпуска в виде приращений за пару недель и полностью функциональной версии за несколько месяцев.
Коммуникация, общение внутри команды
В Agile, команды ежедневно встречаются, обмениваются информацией, обсуждают препятствия на каждом этапе проекта. Такое сотрудничество и обмен идеями гарантируют, что релиз останется на ходу, даже если требования немного изменится.
Обратная связь
Так как команда предоставляет функциональность небольшими порциями, они получают быструю обратную связь от Dev, QA, PO и клиентов. Именно так методология Agile помогает регулярно отслеживать ход цикла разработки.
Доверие
В Agile команде, каждый участник самоорганизуется. Процесс, поддерживаемый руководством, дает им возможность понять цели и определить их соответствующие пути для достижения успеха.
Согласование
Сроки разработки гибкого программного обеспечения
Индустрия программного обеспечения пережила небольшой кризис в начале 1990-х годов. Некоторые назвали это «кризисом разработки приложений», а некоторые назвали его «задержкой доставки приложений». Проблема заключалась в неспособности удовлетворить потребности клиентов. Кроме того, процессы в то время занимали много времени. Они использовали подход, основанный на временной шкале, когда процесс разработки был последовательным, и клиентам приходилось ждать до самого последнего шага. Чем больше время доставки, тем больше у клиентов шансов изменить свои потребности. Таким образом, к тому времени, когда заявка была готова, первоначальные требования утратили бы актуальность.
Следовательно, профессиональные лидеры индустрии программного обеспечения должны были придумать новый подход к решению вышеуказанных проблем. В 2001 году некоторые из этих лидеров встретились в Юте и составили концепцию идеи Agile. Все они были синхронизированы, чтобы материализовать этот процесс и признали его на отраслевом уровне. Они также разработали основные гибкие принципы и назвали документ Agile манифестом.
Что такое Agile манифест?
Он включает в себя четыре основополагающие ценности и двенадцать принципов. У каждого есть цель, чтобы помочь исследовать лучшие способы разработки программного обеспечения.
Agile манифест подразумевает четкую и измеримую структуру и поощряет итеративную разработку, совместную работу и принятие изменений.
Вы можете прочитать о ценностях и принципах Agile манифеста ниже:
Люди, следующие методологии Agile, должны соответствовать этим ценностям и принципам. Agile манифест дает общее понимание о методах жизненного цикла гибкой разработки.
Agile Управление проектами
Он использует шесть основных «результатов» для мониторинга прогресса и выпуска продукта.
Видение продукта
Резюме, которое определяет цели продукта.
Дорожная карта продукта
Общий обзор требований к реализации.
Backlog продукта
Полный список возможностей, которые будут добавлены в проект.
План выпуска
Графический документ, показывающий ход релиза.
Backlog cпринта
Список пользовательских историй, выбранных в последнем спринте.
Инкремент
Рабочий продукт с функциями, реализованными в текущем цикле спринта.
Существует множество платформ для управления Agile-проектами, которые вы можете выбрать и начать разработку продукта. Каждый из них имеет уникальный набор функций и терминологию. Но все они следуют одним и тем же принципам и практикам.
Подводя итоги
Agile: что это такое и где используется, принципы и методология
В больших проектах, где работает много участников, организовать работу сложно без подготовки и единой системы. Чтобы повысить показатели при ведении проектов, научиться управлять командой, стоит присмотреться к системе гибкого управления Agile.
Что такое Agile
Agile – это набор методов для управления проектами в областях, требующих прикладной работы. Методология применяется для увеличения скорости создания продуктов, уменьшения рисков при разработке, увеличения уровня взаимодействия между членами команды. Она обеспечивает оперативную реакцию на происходящие изменения и позволяет корректировать отклонения.
Чем отличается от других методологий
Она не похожа на предыдущие подходы, описывающие создание продукта в деталях. Agile краток, в нем 4 ценности и 12 принципов. RUP в отличие от Agile – менее гибкая методология, при этом более объемная, описывает процесс работы на десятках страниц. RUP не подходит для небольших задач, состоит из итераций с продолжительностью от 2 до 6 недель.
OpenUP – преемница RUP. В этой методологии проект делится на четыре фазы: начальная фаза, фазы уточнения, конструирования и передачи. Методология недостаточно гибкая в сравнении с Agile, применима больше в IT-сфере.
Где используется Agile
Методика применялась в IT-индустрии и использовалась для разработки ПО. Суть сводилась к внедрению адаптивных методов, которые ускоряют создание продуктов через микропланирование и короткие производственные циклы. Однако впоследствии Agile стала использоваться и в других прикладных областях. Agile сейчас применяют компании: Netflix, Spotify, Magna International, General Electric, Accenture, М.Видео.
Подобные технологии стали достоянием команд, работающих над созданием клиентских продуктов.
Плюсы и минусы Agile
Манифест Agile
Идеи Agile
Ценности Agile говорят, что:
Гибкость методологии
Методы организации работы основаны на каскадной модели, в которой процессы реализуются поэтапно. Если требования к разработке продукта, конечной цели изменяются, нужно переделывать выполненную часть работы. На это готовы не все сотрудники: некоторые до последнего не сообщают начальству о необходимости корректировок в уже неработающем плане. Agile методология решает эту проблему с помощью имеющейся гибкости и адаптивности.
Принципы методологии
При выборе этой системы организация быстрее работает, мобильнее, разделяет сотрудников на небольшие команды. Принципы Agile выражают так: разделение задач на небольшие блоки, автономность сотрудников, прозрачность работы, обработка обратной связи от клиентов.
Работа над мини-блоками
Сложные проекты разделяют на маленькие задачи, каждая из которых помещается в отдельный блок. Целей достигают за короткий цикл, поэтому даже в многоступенчатом проекте виден прогресс в работе.
Маленькие кросс-функциональные команды
Сотрудники работают в небольших командах. Задача каждой в реализации одной из функций, которая важна для клиента. Численность и состав команд отличаются в зависимости от их задач. Число сотрудников в одной команде до 12 человек.
Ограничение объема незавершенной работы
Agile помогает командам концентрироваться на задачах, которые можно решить за небольшой промежуток времени. Уменьшение объема работы помогает быстрее справиться с мини-задачами, что сказывается на общей продуктивности.
Автономность команд
Перед началом работы над задачей составляют план. Затем каждая команда решает, как приступить к его выполнению. Задача руководителя ― определить базовые правила, сотрудники самостоятельно выбирают темп работы, условия, координируют действия.
Достижение стадии готовности
Проверка методологии – завершение задачи, итоги которой подводятся в конце каждого цикла. Благодаря разделению на небольшие блоки команды могут полностью завершить задачу, а не отмечать ее как «практически законченную». Причина медлительности в крупных проектах – задания, которые завершены частично, но в них еще ряд проблем. В результате они тянут время, ресурсы, внимание и отвлекают сотрудников от обязательств.
Беспрерывная работа
Задачи, поделенные на короткие циклы, имеют приоритеты, к которым нужно стремиться на каждом этапе. Благодаря чему работа беспрерывна, и сотрудники не отвлекаются на смежные задачи.
А чтобы не отвлекаться на рутинные отчеты, подключите сквозную аналитику Calltouch для вашего бизнеса и уделяйте время важным стратегическим задачам.
Полная прозрачность и использование досок со стикерами
Это помогает кратко, но емко описать работу, зафиксировать актуальную стадию, на которой находится команда, посмотреть на процесс глазами сотрудников, при необходимости определить источник проблем.
Обратная связь от пользователей на каждом цикле
Команды получают обратную связь от клиентов в конце каждого цикла. На основе сведений оценивают достижения, реализацию задачи. Информация учитывается в дальнейшем для планирования.
Ключевые моменты в применении
Методы Agile используются для решения разных бизнес-процессов. Поэтому перед их внедрением важно разобраться, как выглядит методология на практике.
Какие существуют роли по Agile
Иерархия компетенции в Agile
Структура команды горизонтальна, но в ней есть иерархия. Руководитель задает вектор, по которому сотрудники реализуют задачи. Особенность системы – иерархия построена на компетенции, а не власти, что определяет взаимодействие сотрудников с начальством.
Что такое пропускная способность
Пропускная способность – реализованное количество «пользовательских историй». Это пожелания клиентов, которые формируются в задачи. Например, установка фильтров поиска в приложении, улучшение обратной связи с клиентами, работа над службой техподдержки. Пропускная способность измеряется количеством отработанных пользовательских историй в неделю.
Как определить последовательность и приоритетность задач
Приоритетность задач зависит от направления компании. Например:
Как составить график решения задач
Для составления графика используют приложения с шаблонами для планирования проектов. Например, GanttPRO – сервис для постановки задач и их контроля. Он содержит шаблоны графиков, отслеживает цели по степени продвижения, отмечает слабые места.
Внедрение Agile
Для внедрения методологии выполняют комплекс мероприятий. Он основан на выборе главного метода в системе, после чего устанавливаются задачи, цели, сроки, численность команды. Сотрудники должны быть обучены применению методов на практике, а руководство должно понимать, что внедрение системы станет новым поворотом в развитии бизнеса.
Важно использовать опыт специалистов, которые уже работали с системой и знают, как реализовать ее. Их опыт помогает в формировании команды, подборе инструментов, аналитике.
Распространенные проблемы при реализации
Основные проблемы при внедрении Agile:
Популярные методы и средства управления проектами
Scrum
Здесь упор на контроль рабочего процесса, что разделяет разработку проекта на стадии. Эти стадии длятся от 2 до 4 недель. Процесс начинается с оценки масштабов работы, предполагает корректировку действий и планов с учетом промежуточных итогов. Скрам повышает производительность и ориентируется на сокращение времени для достижения цели.
Kanban
Метод основан на прозрачности процесса. Он функционально распределяет нагрузку на сотрудников, мотивирует членов команды на сотрудничество и обучение. Принципы строятся на:
Заключение
«Гибкая разработка»: кратко о методологиях Agile
Разработка программного обеспечения — это труд, который требует своевременного принятия правильных решений. CTO, архитекторы, тимлиды и сами разработчики регулярно делают выбор в пользу тех или иных инструментов, платформ и фреймворков.
Но все принимаемые решения нужно как-то «синхронизировать». Один из резидентов Hacker News отметил, что ему приходилось наблюдать за тем, как пяти сотням разработчиков в одной крупной компании разрешили самостоятельно принимать некоторые решения в «отрыве» от команды. По его словам, это был хаос. И хотя команда начала работать быстрее, она двигалась в никуда, потому что позднее возникали проблемы на этапах поддержки ПО.
Чтобы избежать подобных ситуаций, используется семейство процессов гибкой разработки. Их внедрение позволяет руководству компании повысить заинтересованность и мотивацию сотрудников, а также ускорить доставку продукта заказчику. В последнее время эта тема приобретает все большую популярность, потому что на некоторые методологии Agile обращают внимание общественности главы крупнейших корпораций.
Поэтому мы решили начать серию постов о «гибких» методологиях, чтобы еще раз рассмотреть их особенности, сравнить варианты и помочь вашим компаниям оптимизировать процессы. Сегодня мы говорим о Scrum, канбан и экстремальном программировании.
Scrum
Scrum — это фреймворк гибкой разработки ПО, который считается методологией «по умолчанию». Для многих является синонимом Agile. По статистике за 2016 год, предоставленной VersionOne, Scrum используют 58% «гибких» компаний. При этом её поддерживают многие SaaS-платформы. Например, решение ServiceNow, частью которого является инструмент Agile Development.
Методология была разработана в конце 80-х — начале 90-х годов. Процесс управления состоит из фиксированных коротких итераций — спринтов (sprints).
Используя методологию Scrum, представитель заказчика плотно работает с командой разработки, расставляя приоритеты в списке требований к продукту (Product Backlog). Этот список состоит из баг-фиксов, функциональных и нефункциональных требований — из всего, что нужно сделать для реализации рабочего приложения.
Функциональные элементы, добавляемые в бэклог, называют историями. Каждая задача оценивается в определенное количество очков. Очки являются абстрактной метрикой и для её оценки могут использоваться самые разные шкалы (например, ряд Фибоначчи или степени двойки).
На основании списка требований заказчика команда определяет функции, которые хочет реализовать, и начинает свой спринт. Обычно он длится 30 дней. В конце подсчитывается общее количество очков, набранных командой за спринт (скорость). Это позволяет более четко планировать следующие спринты.
За последние десять лет программисты Кен Швабер (Ken Schwaber), Майк Бидл (Mike Beedle) и Джефф Сазерленд (Jeff Sutherland) приложили множество усилий для развития Scrum. Кен Швабер — наиболее активный сторонник фреймворка, и его сайт — хорошее место, чтобы начать свое знакомство с методологией. Он также выпустил книгу.
Scrum за все время существования приобрел огромную популярность и используется командами разработчиков даже в крупных компаниях. Однако сообщество за это время выявило и определенные её недостатки.
Например, среди них отмечают чрезмерную ориентированность на набор очков. При планировании, команда отбирает истории, которые она сможет завершить к концу спринта, руководствуясь скоростью предыдущего этапа. Основная цель этих очков — сделать планирование более надежным и предоставить четкую перспективу.
Однако здесь скрывается проблема: поскольку работа разработчиков оценивается в баллах, они будут стараться заработать их побольше и оптимизировать под это свою деятельность. Что не приводит к улучшению кодовой базы, не делает её проще.
Другая проблема — длительные митапы. Причем совещания проводятся синхронно со всеми участниками разработки, что становится проблемой для специалистов, работающих удаленно. Людям приходится встраивать многочасовые совещания в свое расписание для обмена информацией, которую можно передавать иным способом.
Что касается неизменности историй во время спринта, то в больших масштабах это также приводит к проблемам. У программистов нет возможности перераспределить работу при обнаружении новых особенностей. Scrum не позволяет перестраивать корабль прямо во время плавания, поэтому приходится ждать окончания сессии, чтобы внести изменения.
Extreme Programming
Особенность Scrum заключается в том, что этот фреймворк уделяет мало внимания практикам разработки. Поэтому некоторые agile-компании (порядка 10%) комбинируют его с экстремальным программированием (XP).
Экстремальное программирование привлекло к себе внимание в конце 90-х. Концепция зародилась в сообществе Smalltalk, а её авторами считаются разработчики Кент Бек (Kent Beck) и Уорд Каннингем (Ward Cunningham), которые хотели сформировать новые практики в разработке ПО, сделанные для людей.
Первым проектом, созданным по методологии Extreme Programming, стала система контроля платежей Chrysler Comprehensive Compensation (C3) в середине девяностых. Сам термин «экстремальное программирование» появился в 1997 году.
Концепция строится на основании двенадцати приёмов:
Однако Extreme Programming делает сильный упор на тестирование, что отличает её от Scrum. Методология гласит, что разработчик не может сказать, что код написан правильно до тех пор, пока не пройдут все модульные тесты. Поэтому часто XP идет рука об руку с техникой разработки Test Driven Development (TDD), когда сперва пишется тест, а затем логика для его прохождения.
Но такая «тестоориентированность» одновременно и недостаток подхода. Чтобы адаптировать XP, нужно инвестировать в создание инфраструктуры автоматизированных тестов и непрерывного развертывания ПО.
При этом, если в случае Scrum компания может послать менеджеров проектов на двухдневные курсы, то в случае с экстремальным программированием приходится тренировать всю команду разработчиков. Что гораздо более затратно. Нужно менять культуру в организации, объединяя несколько отделов: XP требует, чтобы тестировщики, UI-дизайнеры, программисты, архитекторы и пользователи работали сообща.
/ Flickr / U.S. Army / CC
Канбан
Scrum по-прежнему остается эффективной методологией, которая пользуется популярностью. Особенно в комбинации с экстремальным программированием. Вместе их процент использования среди Agile-команд достигает 68%.
Однако сегодня многие команды рассматривают иные варианты и обращают внимание на другие методологии. Одной из них стал канбан. CTO ConvertKit Грант Аммонс (Grant Ammons) говорит, что компании сперва адаптируют Scrum, который учит их необходимым дисциплинам для разработки ПО, а затем ищут более удобную альтернативу и обращаются к канбану.
Канбан — это техника для управления разработкой, где процесс разработки рассматривается как конвейер с запросами на реализацию функций, с которого сходит улучшенное программное обеспечение.
Канбан зародился как часть системы производства Тойоты «точно вовремя», поэтому методология исключает излишнее накопление задач. Например, если тестировщики проверяют пять функций за неделю, а разработчики и аналитики реализуют десять, то «общая пропускная способность конвейера» ограничивается до пяти функций. Это нужно, чтобы избежать накопления работы у QA-команды, иначе они могут начать «срезать углы» и случайно пропустить на рынок некачественный продукт.
В этом случае также можно провести перераспределение ресурсов: когда программисты и аналитики выполнили свою норму, они могут помочь с тестированием и написанием автоматизированных тестов. В будущем это позволяет повысить пропускную способность конвейера.
И канбан легко выявляет такие узкие места. В своей простейшей реализации — это большая доска с расчерченными столбцами, в которых размещаются стикеры-карточки. Столбики — это этапы процесса разработки, а стикеры — рабочие задачи. Цифры вверху каждого столбика показывают, сколько карточек разрешено в нем «копить».
Однако, как отмечают в сообществе HN, у такого подхода тоже есть определённые недостатки. В том же Scrum короткие спринты положительно сказываются на мотивации разработчиков. Программисты знают, что работа над продуктом закончится, когда весь список требований на 30 дней будет выполнен. В случае с канбаном — это постоянный и нескончаемый поток заданий. Однако есть выход — краткое обсуждение списков задач на неделю (или две).
Также ввиду своей специфики, канбан плохо подходит для долгосрочного планирования и неудобен в работе для крупных команд разработки (больше пяти человек).
Напоследок отметим, что использование Agile-методологий накладывает серьезные требования на опыт членов команды и их способность эффективно взаимодействовать друг с другом. При этом каждая более или менее распространенная методология имеет свои сильные и слабые стороны, а также области применения. По этой причине появляются новые фреймворки и дорабатываются «старые».