«У самурая нет цели, только путь»…
На самом деле, путь — не единственное, что важно в Agile, потому что всегда в фокусе главная цель, но все же этот метод выглядит самураем среди других методик, потому что сосредоточивается не только на цели, но и на пути, гибкости и скорости принятия решений.
Наверное, у каждого бывали следующие моменты: есть задача, которая включает много подзадач, сложных операций и подготовки, и она кажется непреодолимой. Мудрые люди говорят, что в таком случае следует «есть слона по частям». Именно это предлагает гибкая методология Agile. Она предназначена для разработки программного обеспечения, но вполне может использоваться для управления различными проектами.
Если кратко описывать, что такое Agile, то это первоначально методология разработки программного обеспечения, которая проходит не по жесткому плану, а многими итерациями, на которые разбит долгий процесс. Между итерациями проходят встречи-пересмотры, на которых определяются дальнейшие действия. Это позволяет постоянно пересматривать результат, дает дополнительную мотивацию как разработчикам, так и клиенту, который более прозрачно видит процесс, и легко изменять план, если возникли дополнительные обстоятельства.
Agile улучшает командную работу, создавая атмосферу сотрудничества, доверия и взаимопонимания. Благодаря регулярным встречам члены команды всегда знают, на каком этапе находится проект, и могут быстро реагировать на изменения. Самоорганизация и равномерное распределение ответственности мотивируют каждого участника работать более эффективно, а постоянная обратная связь помогает быстро находить и исправлять ошибки. Это не только повышает производительность, но и создает здоровую рабочую среду, где каждый чувствует себя ценным и вовлеченным в общую цель.
Кстати, для совместной командной работы и тестирования продукта может потребоваться VPS или выделенный сервер — для экономии средств рекомендуем рассмотреть вариант аренды сервера, а не его покупки. Такое решение достаточно бюджетно с точки зрения не только денег, но и времени, ведь обслуживание оборудования также требует ресурсов — в случае аренды этим занимается провайдер.
Кроме того, у нас на хостинге реализованы NODE.JS и NEXT.JS, благодаря чему можно легко и просто настраивать программную среду и быстро запускать проект.
Но вернемся к нашему Agile. Если в классическом управлении проектом нужно составить план, разработать детально пути работы на каждом этапе, оценить риски и четко двигаться, то в эджайл мы имеем генеральную цель, но без жесткого плана, только постепенные шаги к ее достижению, которые могут меняться.
Все происходит частями: частями делается продукт, частями оценивается прогресс, частями получается обратная связь, работа постоянно корректируется. Не проблема, если вместо одного следующего шага мы будем выполнять другой, например, будем добавлять какую-то новую кнопку на сайт, потому что пользователи сказали, что им ее не хватает, а затем вернемся к разработке других функций.
12 принципов Agile
Основной принцип Agile — цель превалирует над планом. Отсюда вытекают все последующие особенности методологии.
В общем методология Agile опирается на четыре главные идеи:
- люди и их сотрудничество важнее процессов и инструментов;
- функциональный рабочий продукт важнее документации;
- сотрудничество с клиентом, его удовлетворение важнее контракта;
- гибкость важнее плана.
Методология постоянно работает на психологический комфорт каждого участника. Исполнителям проще добиваться небольших ежедневных целей. Клиенту или работодателю проще и комфортнее видеть прогресс на маленьких этапах и понимать, что процесс двигается.
Более подробно четыре главные идеи эджайла изложены в его 12 принципах, собранных в так называемом «Манифесте гибкой разработки», первая редакция которого была принята в 2001 году в Соединенных штатах семнадцатью разработчиками.
Ключевые принципы Agile:
- Удовлетворение клиента: самое главное — постоянно давать клиенту ценность, value, на каждом этапе понемногу, а не один раз в финале.
- Принятие изменений: гибкость — это основа Agile, так что если требования меняются даже на поздних этапах, это нормально.
- Частые апдейты: продукт поставляется не раз в конце процесса, а много раз, в рабочем состоянии, но, например, с меньшим количеством функционала.
- Сотрудничество: бизнес и исполнители постоянно взаимодействуют, встречаются, дают друг другу обратную связь.
- Мотивация людей: эта методология постоянно фокусируется на том, чтобы создать людям условия для качественной и крепкой мотивации.
- Общение и контакт: наиболее эффективная коммуникация происходит между людьми с глазу на глаз, во время митапов, без посредников, которые носят требования туда-сюда.
- Рабочий продукт — главная метрика: прогресс определяется наличием рабочего программного обеспечения.
- Постоянство: команды должны работать в устойчивом темпе, с возможностью поддерживать его в течение длительного времени.
- Техническое совершенство: постоянное усовершенствование технических аспектов и дизайна.
- Простота: для того чтобы выполнить как можно больше задач и как можно быстрее, из решений выбирают максимально простые.
- Самоорганизация: чтобы держаться в темпе эджайла и постоянно двигаться вперед, команда должна быть организована.
- Регулярный пересмотр: постоянные встречи позволяют каждому члену команды понимать, что происходит, и корректировать свою работу в соответствии с ситуацией.
Читайте также: ТОП-5 таск-менеджеров для организации командной работы
Популярные методики Agile
Если держать в уме предварительную информацию, можно заметить, что все популярные методики, которые используются в agile, просто дают инструменты для реализации принципов гибкости, постепенного прогресса и изменений.
Scrum
Хороший скрам-мастер важен для проекта не меньше разработчиков. Scrum — это разделение работы на очень короткие циклы или спринты, которые длятся от 15 до 30 дней. В начале и конце каждого спринта происходит пересмотр и дальнейшее планирование. Вместо генерального плана существует план на спринт, где участники и заказчики четко понимают, с чего все начинается, и чем должно завершиться в конце спринта.
В рамках scrum в команде выделяют роли владельца продукта (Product owner), который представляет заказчиков и постоянно удерживает в фокусе внимания генеральную цель — рабочий продукт, и скрам-мастера, то есть того, кто отвечает за процессы в соответствии с методикой.
Чтобы продвигаться, команда внедряет регулярные митинги-отчеты, на которых показывает прогресс и обсуждает все возникшие проблемы.
Канбан
Это визуализация процесса на доске таким образом, чтобы было видно, какие задачи еще в стадии реализации, какие из-за чего-то тормозят, а что уже сделано. Это не обязательно настоящая доска. Существуют канбан-шаблоны в таких популярных рабочих системах как Jira, но можно использовать и другие виртуальные доски.
Но суть в том, чтобы каждый из команды представлял весь объем работ, видел, что и где тормозит, и таким образом, все вместе быстро решали поставленные задачи. Для того чтобы двигаться быстрее, ограничивается количество задач в текущем исполнении. Кроме того, доска позволяет наглядно и быстро менять приоритет задач в соответствии с изменениями в общем процессе.
Читайте также: Как научиться делегировать и перестать все делать самому
Lean
Название методики происходит от японского понятия, которое переводится как «экономное производство», то есть уменьшение затрат за счет концентрации на главном. Зародившись в цехах «Тойоты», эта методика пригодится и гибким командам, которые выбирают эджайл.
Lean концентрируется на том, чтобы определить, что будет ценно потребителю продукта, и развивать именно это. Методика допускает постоянные переработки и усовершенствования, если в результате клиент будет более доволен. Lean вносит в гибкость Agile определенную четкость и порядок, так как эта методика требует неизменной оптимизации действий.
Extreme programming
Эта методика подразумевает очень частые быстрые релизы с обновлениями. Каждый раз от клиентов собирается обратная связь, чтобы быстро корректировать работу. Особенности методики:
- непрерывное тестирование, чтобы улучшить качество кода или выполнения задач;
- работа в паре, чтобы обсуждать сложности и вопросы, которые возникли в процессе выполнения задачи, и проверять друг друга;
- избегание создания функций до тех пор, пока они не станут реально необходимыми;
- упрощение кода.
Так же, как и все предыдущие методики и agile в целом, экстремальное программирование нуждается в частом общении с заказчиком, а также команде между собой.
Недостатки Agile
Основным недостатком эджайла специалисты называют то же самое, что и его основное преимущество: Agile предполагает короткий горизонт планирования. На каждом этапе задачи решаются максимально быстро и удовлетворительно для всех участников образом, показатели проекта остаются высокими, но возможны проблемы, связанные с длительными последствиями. То, что выглядит эффективным для заказчика прямо сейчас, может в будущем стать помехой для развития проекта. Может оказаться, что для следующего шага развития нужно переделать все, что сделано на предыдущих.
Что с этим делать: использовать подход правильно. По сути, agile — это методология, инструмент, который подходит для одних задач и не годится для других.
Если эджайл внедряет большая организация, для этого существует SAFe (Scaled agile framework). Эта методика позволяет масштабировать гибкий процесс на большом количестве эджайл-команд. Таким образом, до определенной степени гибкую разработку можно применять даже в финансах, банках, крупных корпорациях.
Читайте также: Договор на создание веб-сайта – как обезопасить себя во время разработки
Кому подходит Agile
Agile методология подходит небольшим гибким командам. Ее можно использовать как в IT, так и в малом бизнесе, образовании, разработке разных проектов. Однако она лучше совместима с той деятельностью, где речь идет о создании чего-то нового (учебного курса, информационного продукта, дизайн помещения и тому подобное), чем где преобладают процессы, которые должны быть хорошо отлажены и постоянно работать одинаково (торговля в магазине, работа колл-центра, поддержка клиентов или поддержка приложения).
Также методика скорее подходит проектам, где требуется результат и хорошее функционирование, чем жесткая регламентация. Имеет значение и опыт команды: чем участники опытнее, чем лучше самоорганизуются, тем проще добиваться результатов с помощью agile.
Если же проект жестко регламентирован, если нет возможности регулярно встречаться хотя бы на короткие митапы, смысла начинать работать в эджайле нет.
Понравилась статья? Расскажите о ней друзьям: 
