Agile подход — что из себя представляет, как появился, плюсы и минусы
В этой статье мы расскажем про главные принципы Agile методологии, плюсы и минусы этой философии, основные варианты реализации.
Термин Agile часто связывают с методологией разработки программного обеспечения. Появился этот подход действительно в IT-среде и активно в ней используется. Однако модель Agile оказалась довольно универсальной и применимой к рабочим процессам в сферах, которые не связаны с производством IT-продукта.
Что такое Agile — базовые идеи
Аджайл это и методология, и набор практик, и свод правил. Каждое из подобных описаний будет справедливо. Но на более высоком абстрактном уровне Agile — это философия или подход, который призван повысить эффективность определенных рабочих процессов.
В переводе c английского “agile” — гибкий. Погружаясь в принципы этой методологии, становится очевидным, что более подходящее название для нее сложно подобрать.
В основе гибкой методологии разработки лежит 4 основных приоритета:
Эти четыре идеи считаются важнее, чем инструменты, написание подробной документации, согласование условий контракта, четкое следование плану. Естественно, все эти моменты также имеют право на существование. Речь идет о градации приоритетов.
В чем суть подхода
Agile методология кроме ключевых идей также базируется на 12 принципах. Они, как и четыре главные ценности, описаны в специальном документе — Аджайл Манифест.
Какие основные мысли заложены в Agile принципах:
Выполнение рекомендаций, описанных в Agile Manifesto, должно обеспечить проекту возможность постоянного тестирования и трансформации. Требования к продукту могут изменяться на фоне исследования пользовательского опыта, тенденций на рынке и т.д. Аджайл учитывает этот фактор и в своей философии закладывает вероятность постоянных обновлений функционала и других составляющих.
Придерживаясь гибкой методологии, невозможно разрабатывать компоненты в автономном режиме, а потом их связывать между собой. Во главу угла ставится постоянное общение команд и тесное взаимодействие между всеми участниками процесса. Как правило, работа разбивается на короткие итерации продолжительностью в 1-4 недели. Результатом каждого такого цикла должен быть рабочий продукт с намеченным приростом функционала.
Причины появления методологии Agile
Гибкий подход к разработке стал логичной реакцией на преобразование рынка IT. Высокая конкуренция и необходимость быстро выдавать работающий продукт поставили под сомнения устои, которые были актуальными долгие годы. По своей сути подход Аджайл является антиподом модели Waterfall, которая базируется на таких принципах:
Долгое время эти постулаты были незыблемы в сфере IT. Но когда бизнесу стали важны такие аспекты, как скорость получения продукта и возможность его быстрой адаптации под текущие потребности рынка, “закостенелая” и неповоротливая методика Waterfall начала резко терять позиции.
Документ Agile Manifesto был создан и опубликован в 2001 году. Именно это событие принято считать стартовым этапом становления гибкой методики разработки в качестве базовой модели. Тем не менее до этого момента уже существовали подходы к разработке (например, XP — экстремальное программирование), которые не укладывались в устойчивую парадигму Waterfall.
Стоит отметить, что принципы “жесткой” методологии разработки до сих пор актуальны для некоторых видов проектов. Waterfall может оказаться более выгодным выбором, если:
Плюсы и минусы гибкого подхода
При использовании Agile уже на начальных этапах есть работающий продукт. Это дает следующие преимущества:
Методология Agile учитывает реалии рабочих процессов, не идеализируя их. Заказчики регулярно меняют свои требования, подстраиваясь под конъюнктуру рынка и потребности конечного пользователя. Адаптивный подход Аджайл предполагает изменения на любой стадии разработки, что позволяет получить более конкурентоспособный продукт. Гибкая система также является хорошим решением в условиях неизвестности (сколько будет выделено финансирования, какие специалисты будут работать, сколько понадобится времени и т.д.)
При всех своих положительных качествах гибкая модель выстраивания рабочих процессов не гарантирует хороших результатов. Эффективный инструмент важно правильно использовать. Если же “перегнуть” с гибкостью, то итог может быть плачевным.
Главные риски при использовании модели Agile:
При работе по гибкой системе разработчикам тяжело найти мотивацию для поддержания высокого уровня качества продукта на каждом этапе. Если есть вероятность, что много чего может измениться на следующих итерациях, то нет смысла доводить до идеала текущую версию проекта. Это вполне логичные рассуждения, однако “не нужно доводить до идеала” часто легко трансформируется в “работает и хорошо”.
Основные реализации Agile
Самыми распространенными реализациями гибкой методологии Аджайл являются Scrum и Kanban. Обе эти методики придерживаются главных принципов Agile-философии, но имеют свои отличительные особенности.
Scrum предполагает наличие профильных специалистов, которые работают над своими задачами в рамках спринта (определенный промежуток времени от 1 до 4 недель). Активное участие принимает Product Owner, обеспечивающий постоянную связь заказчика с командой разработчиков. Координирует все процессы Скрам-мастер. Для философии Agile Scrum является одной из самых популярных реализаций.
Kanban-подход также активно используется аджайл-командами. Основные принципы методики — это прозрачность рабочего процесса и отслеживание выполнения задач в реальном времени. Каждое задание располагается на виртуальной или физической Kanban-доске. По мере изменения статуса задачи она продвигается дальше в соответствующий столбец.
Например, жизненный цикл задачи может состоять из таких этапов: в рассмотрении, в работе, сделано, на проверке, принята. За каждым статусом закреплен свой столбец. Можно наглядно оценить текущее состояние конкретной задачи и всего рабочего процесса в целом.
Agile — гибкий инструмент в умелых руках
Подход к работе, основанный на философии Аджайл, на сегодняшний день является базовым для IT-отрасли и не только. Однако не стоит воспринимать эту методологию, как “волшебную палочку”, которая самостоятельно отлаживает рабочие процессы в компании. Необходимо грамотно использовать Agile подход и стараться соблюдать баланс скорости работы, уровня качества и вовлеченности заказчика. Слишком большой упор на быструю выдачу продукта или принятие изменений, которые противоречат архитектуре проекта, могут негативно сказаться на результате.
Понимание гибкой методологии разработки продукта является хорошим подспорьем для эффективной деятельности в IT-сфере и смежных отраслях. Существует большое количество книг по Agile, разнообразных видеоматериалов и курсов, которые помогут освоить этот подход. Квалифицированные аджайл-специалисты (например, Scrum-мастеры) играют важную роль в создании продукта и являются желанными сотрудниками в IT-компаниях.
Стремитесь вывести бизнес на новый уровень, достигать целей быстрее и эффективнее? Apix-Drive — ваш надежный помощник для этих задач. Онлайн-коннектор сервисов и приложений поможет вам автоматизировать ключевые бизнес-процессы и избавиться от рутины. Вы и ваши сотрудники освободите время для выполнения важных профильных задач. Попробуйте возможности Apix-Drive бесплатно, чтобы убедиться в эффективности онлайн-коннектора лично.
Что такое Agile и подойдет ли он вашей компании
Что такое Agile
Agile, или Agile software development — гибкий подход к разработке программного обеспечения (ПО), который часто применяют в небольших командах.
Весь процесс работы над проектом делится на итерации — короткие циклы по две-три недели. Каждая итерация решает серию задач: анализ требований, проектирование, программирование, тестирование и документирование. По итогам каждой итерации команда анализирует результаты и меняет приоритеты для следующего цикла. В итоге за каждый цикл создается мини-продукт или отдельная часть, которая готова к самостоятельному запуску.
Термин Agile употребляют в двух основных значениях:
Как правило, agile-команды включают разработчиков, тестировщиков, менеджеров проектов, дизайнеров интерфейсов, технических (UX) писателей. Все они равноценны в иерархии и работают в одном офисе или коворкинге. За счет личного общения они экономят время на обсуждении текущих процессов. Сторону заказчика представляет менеджер или руководитель — product owner, от которого команда регулярно получает обратную связь.
Agile возник в противовес устаревшим подходам и излишней бюрократии в сфере ИТ. Резиденты Кремниевой долины (и не только) поняли, что невозможно создавать инновационные продукты в консервативной среде. Поэтому в феврале 2001 года в штате Юта (США) 17 разработчиков из разных стран мира создали свой манифест, в котором объединили самые передовые подходы и принципы.
«Манифест Agile» и основные принципы
Agile-манифест базируется на четырех главных ценностях:
1. Люди и их взаимодействие важнее процессов и инструментов.
Нужно создать такие условия, чтобы инструменты и процессы не ограничивали команду, а позволяли ей работать как можно эффективнее. Каждый может сам решать, какие инструменты и процессы ему подходят.
В процессе работы все общаются друг с другом и заказчиком лично и напрямую, минуя бюрократические процедуры и регламенты. Если без онлайн-связи не обойтись, то предпочтение отдают видеочатам и интерактивным доскам, а не рабочей почте и мессенджерам.
2. Работающий продукт важнее документации и отчетности.
Клиенту, в первую очередь, нужен рабочий продукт, а не красивые презентации. Поэтому в рамках Agile фокусируются на том, чтобы продукт как можно быстрее был готов к использованию, пренебрегая технической документацией и отчетностью.
3. Сотрудничество с заказчиком важнее соблюдения формальных условий.
Даже если перед проектом подписан договор с жесткими условиями и характеристиками, в процессе работы они могут меняться. Например, если некоторые детали окажутся не такими значимыми, и задачу можно решить гораздо проще и эффективнее. Это делается в интересах клиента, которому важен рабочий продукт, а не формальные требования. При этом важно постоянно быть на связи и обсуждать каждое изменение, принимая решение совместно.
4. Готовность к изменениям важнее, чем следование плану.
Изменения можно и нужно вносить на каждой стадии — или итерации, — чтобы не откладывать их на конец, когда сроки и ресурсы уже поджимают. Ради этого вполне можно пожертвовать чем-то из запланированного, если основные задачи будут решены.
Agile не исчерпывается четырьмя ценностями [1]. В манифесте есть также 12 принципов, которые уточняют и дополняют их. Их можно свести к следующему:
Agile, таким образом, — это система ценностей или даже философия ведения бизнеса. Она помогает сосредоточиться на главном, избавиться от ненужных формальностей и создавать рабочий продукт быстрее и эффективнее. Чтобы воплотить эти ценности на практике, используют конкретные методы. Согласно исследованию Agile в России [2], самые популярные из них — Scrum и Kanban.
Что такое Scrum и Kanban
Scrum, или «подход структуры» — метод на основе Agile, при котором работа над проектами разбивается на спринты — короткие, одинаковые по времени итерации. Команда тоже небольшая — до десяти человек. В нее входят разработчики, product owner (владелец продукта) и scrum-мастер. Product owner — куратор группы, который следит за тем, чтобы конечный продукт отвечал его целям и задачам. Scrum-мастер — человек, который отвечает за правильное применение scrum-метода: организует встречи и обмен сообщениями между всеми участниками. В процессе работы все участники ежедневно обсуждают каждое решение, планы и приоритеты, а также распределяют задачи.
Kanban, или «подход баланса» — метод, который нацелен на повышение качества сервиса: когда все усилия направлены на то, чтобы сделать продукт лучше и удобнее для пользователей, с помощью равномерного распределения задач между всеми участниками. Здесь команда представляет собой единой целое, без кураторов и неформальных лидеров. Процесс делится не на спринты, а на стадии проекта: планирование, разработка, тестирование, запуск. Главный показатель эффективности — максимально быстрое завершение каждого из этапов, без простоев и переработок. Если они все же возникают, команда совместно решает, как оптимизировать процесс.
В отличие от scrum, kanban:
В kanban принято визуализировать все детали процесса. Обычно это доска со стикерами, надписями или task-менеджер вроде Trello, где указаны все задачи, этапы и их статус. Часто задачи помечают разными цветами, чтобы обозначить, к какому этапу они относятся или на какой стадии исполнения находятся. Это помогает каждому участнику проекта видеть всю картину целиком, вовремя замечая, если что-то провисает или кому-то нужна помощь.
Пример доски Trello, созданной по принципам agile.
Если вы только подступаетесь к философии Agile и хотите попробовать отдельные элементы, проще начать с kanban. Небольшим стартапам и командам, которые только планируют запуск проекта, подойдет scrum.
В каких компаниях используют Agile
Когда Agile только появился, его использовали, в основном, разработчики ПО, игр и интерфейсов. Среди них — Google, Netflix, Microsoft, Spotify, Ericsson, Dell, Adobe, Accenture, WordPress, Riot Games, CH Robinson, Magna International, Scrum Alliance, Intronis.
Теперь же сфера применения расширилась: Agile используют, например, Saab для производства новых истребителей, General Electric и John Deere — ведущий американский производитель сельхозтехники.
Существует ли Agile в России
В Россию Agile пришел на несколько лет позже, но уже сегодня его активно используют в ИТ-секторе, ретейле, банках, онлайн-сервисах, промышленных предприятиях. Среди них — ПО-разработчик First Line Software, гипермаркет электроники «М.Видео», служба доставки Dostаевский, онлайн-кинотеатр ivi, бренд одежды 12 Storeez, металлургический концерн НМЛК.
ScrumTrek проводит ежегодное исследование Agile в России. В прошлом году в нем приняло участие более 1 тыс. компаний из 80 городов. Вот главные цифры за 2020 год [3]:
Нужен ли вашей команде Agile
Сегодня принципы Agile распространяются во многих сферах, хотя на первом месте по-прежнему остается ИТ-разработка. Однако гибкие подходы применимы далеко не везде. Эффективнее всего они работают там, где:
Другими словами, Agile идеален для инновационных стартапов, но мало подходит корпорациям с отлаженными процессами и сложной структурой. Для таких компаний лучше работают методы с отдельными элементами Agile, которые проще масштабировать — SAFe (Scaled Agile Framework) и LeSS (Large-Scale Scrum).
Но и в ИТ-сфере Agile — далеко не единственный способ сделать процесс эффективнее. Здесь хорошо работают такие инженерные практики, как DevOps — метод работы, при котором все участники активно взаимодействуют друг с другом, а рабочие процессы взаимно интегрированы.
Чтобы протестировать новую идею, не проходя все этапы разработки, подойдут Customer Development, Design Thinking и другие продуктовые методики.
Наконец, есть более широкий подход, который включает в себя agile-методики — Business Agility («гибкость в бизнесе»). Он распространился позже — два-три года назад — и включает не только ускорение разработки и выпуска продукта, но и быструю реакцию на внешние изменения, гибкое целеполагание и распределение ресурсов.
Обзор методов agile
Я назову этот текст обзором методов agile, расскажу как выбирать между agile и каскадной методологией разработки, дам ссылки на подробные статьи и книги о методах, так как каждую часть этого обзора можно писать как отдельную статью. Буду писать иногда сумбурно, иногда субъективно. Я не журналист, который стремится показать разные точки зрения. А мудрый читатель с высокоразвитым критическим мышлением придет к своему «правильному» ответу. Поэтому, точка зрения авторская. Любые совпадения считать верными, додумки и стереотипы точными. Шутка.) Главной задачей ставлю себе написать простым языком для начинающих знакомиться с миром Agile. Тем более я сейчас сам начинающий продакт-менеджер, учусь в product University. Когда буду давать ссылки на разную литературу и источники, увы много на английском. Зато прокачаете язык. Для будущего продакт-менеджера — это хороший навык.
Начнем с истории методов. Я привык читать и слышать бизнес истории о том, как много работали и придумывали методы. Много табличек, экспериментов, компаний пилотников. После всего, через 100500 лет, появилась методика, которую внедряли, через жуткое сопротивление сотрудников, полусуициидальные настроения топов и т.д. История про Agile, по-моему, вообще не про это. В начале стоит сказать, что Agile — это не метод, а группа методов управления проектами. Что самое крутое, большинство методов появилось раньше самого семейства agile.
Оговорочка: то, что в себя включает Agile не всегда именно метод, это может быть подгруппа, свод правил, набор инструментов и, Боже упаси, фреймворк.
Все методы раскрывать не буду. Если вдруг сюда попадут спецы, есть ссылки на литературу, можно зачитаться. Мне важно раскрыть самые распространенные из них и показать хронологию событий.
1. 1992 – Crystal Methods. Позже в 1997 году упростили до Crystal. Скажем спасибо Алистеру Коберну, за его идеи в своём подходе, потому что именно они легли в основу начала движения Agile. В его методе мы также можем увидеть основы agile-манифеста, о нем чуть позже. Его подход базировался на принципах разумного улучшения, частой поставке кода и работа в группах 6-8 человек, активной коммуникации в группе разработчиков.
2. 1993 – Refactoring. Об этом методе можно прочитать в оригинале жми сюда
3. 1994 – Dynamic Systems Development Method (DSDM). Разработан консорциумом и отличнно раскрыт здесь
4. 1995 – Scrum and Pair Development. Вот он мой любимчик. Основан Джефом Сазерлендом и Кеном Швабером. Но здесь важно еще упомянуть одного человека — Майк Бидл (Mike Beedleв оригинале), который продвинул идеи SCRUM в массы. И по сути именно этот метод больше всего ассоциируется с Agile, а иногда даже считается синонимом.
5. 1997 – Feature Driven Development (FDD). Под эту методологию есть целая книга ссылочка.
6. 1999 – Adaptive Software Development и снова книга
7. 1999 (или 1996, по разным источникам) — XP (экстремальное программирование) книга и сайт. Этот метод дал нам User Stories и релизы.
8. 1999 — The Pragmatic Programmer — опять книга. Эта методология нам дала понимание early adopters (ранних последователей)
9. 2001 — Выпуск agile-manifesto. Вот ссылка на сайт, где опубликован сам манифест и история его создания. А также, воспоминания Мартина Фаулера, одного из соавторов о создании манифеста. Были еще несколько публичных заметок участников, но что-то пошло не так и теперь домены не доступны.
10. 2002 — Test Driven Development (TDD). Книга, как же без нее. Спасибо, за то что это методология дала нам сначала тест, потом уже в боевую версию.
11. 2003 – Lean Software Development (интересная аббревиатура получится). Бережливая разработка ПО. Прекрасная книга ссылка.
Каждый из этих подходов имеет своего автора или группу авторов. Каждый из них творил что хотел, но в целом они все очень умные и классные парни.
1. Люди и взаимодействие важнее процессов и инструментов.
2. Работающий продукт важнее исчерпывающей документации.
3. Сотрудничество с клиентом важнее согласования условий контракта.
4. Готовность к изменениям важнее следования первоначальному плану.
1. Наивысшим приоритетом является удовлетворение потребностей клиента, благодаря регулярной и ранней поставке ценного программного обеспечения.
2. Изменение требований приветствуется, даже на поздних стадиях разработки.
3. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
5. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
6. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
7. Работающий продукт — основной показатель прогресса.
8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно.
9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
10. Простота — искусство минимизации лишней работы — крайне необходима. 11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы
Классная инфографика на эту тему от scrumteck
Хотя авторы под ценностями подписали, что считают важнее то, что слева, но не стоит забывать о том, что с права. Я же писал, что они умные. Некоторые эти принципы и ценности трактуют буквально. Я сталкивался с тем, что ПО работает, все хотелки клиента удовлетворены, никто не следил за документацией и все счастливы, мы в agile.
Интересно наблюдать баталии в комментариях к статьям последователей и противников Agile. Одни считают это заповедями на скрижалях, другие покушением на инженерную святыню, к которой притронулись садомиты.
Что же круче? Agile — как единственный метод разработки ПО и новый метод работы любого бизнеса в современном мире. Или whaterfalls — как фундамент и единственный метод правильного построения бизнеса и ПО. Я расскажу чуть позже.
Пока писал эту статью узнал о том, что оказывается гуляет в интернетах версия манифеста 2.1. Но это тема отдельного трактата.
Как мы видим широко прижились scrum, kanban, lean. Даже есть scrumban, дитя любви scrum и kanban. Симпатичный получился метод.
Как писал выше, ассоциируется с agile, почти что синонимы. Scrum — это регбийный термин, обозначающий борьбу за мяч.
Коротко о методе. Разработка делится на спринты, короткие дистанции разработки фиксированной длительностью 1-4 недели, наверняка есть и другие. У спринта есть стадии: 1. ежедневные короткие встречи, где обсуждается что сделано, что будет сделано, какие проблемы. Эти встречи не должны длиться часами. Как правило это 15-20 минут. 2. процесс разработки, 3. демонстрация, 4. ретроспектива — переосмысление того, что можно сделать лучше. Важно знать. Есть backlog — список требований к продукту. Есть роли, нет должностей. У srumteck есть классная инфографикана эту тему
Эти два метода имеют общую ДНК. Уходит все корнями в Японию, философию бизнеса Кайдзен и Тойоту.
Про Канбан я нашел упоминания от 1959 года. Этим методом стремились повысить прозрачность процессов производства, вовлеченность сотрудников и их мотивацию, организовать таким образом процесс непрерывного улучшения. Главный момент в Канбане — визуализация процесса, канбан-доска. Где есть шаги, статусы, коридоры и задачи. Принципы: вовлеченность всей команды, строгий контроль времени выполнения.
Ну, и конечно классная инфографика для наглядного примера и резюме.
Lean. Мне трудно его описать как метод, для меня это больше способ мышления, свод правил и рекомендаций. Эта философия бизнеса и подхода к разработке описана в двух книгах Эрик Рис Lean startup и Масааки Имаи Кайдзен.
Характерным для Lean будет:
1. Устранять в продукте все, что не приносит ценности клиенту.
2. Самый эффективный инструмент решения задач — постоянное обучение команды
3. Принятие решения как можно позже.
4. Быстрая доставка изменений.
5. Основа успеха в сильной команде.
6. Экономия ресурсов достигается через изначально качественный продукт.
7. Важна целостная картина. Придание ее частям целей, контроль статусов и видение общей стратегии развития ПО.
Scrumban. Совмещение Kanban и Scrum. Это когда в процессе спринта используется канбан-доска для визуализации работы над задачами.
Мы разобрали некоторые методы agile. А что такое watrefalls или каскадный метод разработки ПО, пока нет. Исправим это. Это последовательная разработка ПО, где компетентные и умные сотрудники все делают без привлечения клиентов. Только полностью завершив производство показывают продукт. Как автомобиль демонстрируют и продают клиенту только после того, как он готов. Кузов без обшивки и покраски ведь не показывают, и если что-то не так, не вносят корректировки. Каскадный метод был предложен в 1970 году Уинстоном Ройсом. Некоторые наметки agile были и раньше предложенного Ройсом метода. В тоже время каскадный метод стал гораздо более распространенным, чем agile. Это связано с тем, что раньше порог входа в любой бизнес и в разработку в частности был очень высок. Нужно было быть терминатором на каждом этапе. Соответсвенно, и мания величия участников высокая — как так допустить неучей-клиентов к инженерному производству. Сейчас огромные скорости обучения и выхода новых продуктов. Пользователь имеет большой опыт и требования, сценарии взаимодействия другие, код проще писать, колоссальный массив знаний в открытом доступе. Да и многие поняли, что команда сильнее самого крутого терминатора (даже если отдельно это не самые лучшие специалисты). Спасибо Аристотелю с его Метафизикой, спустя столько веков въехали, что он имел ввиду.
Ранее упоминал, что забавно наблюдать баталии сторонников и противников обоих методов. Каждый приводит убедительные аргументы и не слышит другого. Все правы и никто не прав. Хвала вселенной, которая послала нам модель cynefin.
Согласно изречению Эдварда Деминга, потребитель – самый главный элемент производственного процесса.
И что? Потребитель есть разный, где-то он знает что хочет, где-то не знает. Есть производитель, который близок к своему потребителю или далек. Знает как удовлетворить потребность или не знает. Много всяких условий и контекста.
И у нас возникает определенный конфликт. Waterfalls — традиционный подход к проектам с длительным планированием или Agile — где все быстро и все меняется со скоростью света.
Товарищ Сноуден, не тот о котором можно подумать, а Дейв, в начале 2000х разработал удобную управленческую модель для работы с проектами. Эта модель успокоила фанатов традиционных способов управления проектами и сбила спеси с любителей agile. В эту модель укладывается всё, уживаются рядом и waterfalls и agile.
В модели описываются 4 вида систем с разной степенью неопределенности:
