Блог

Agile-разработка: преимущества и «подводные камни»

16.05.2019

Вопросы, рассмотренные в материале:

  • Какова история возникновения Agile-разработки
  • В чем идеи и принципы Agile-разработки
  • В чем особенности применения Agile-разработки
  • Какие есть альтернативные методы управления

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

История возникновения Agile-разработки

Немногие знают, что целенаправленно заниматься созданием программного обеспечения и управлять проектами начали еще в 1970-х годах. Так, в 1970 году в Америке программист Уинстон Ройс написал работу, которая получила название «Управление развитием крупных программных систем». В своих трудах Ройс раскритиковал последовательный принцип разработки программного обеспечения, указывая на то, что процесс разработки ПО не следует отождествлять с работой сборочной линии на заводе, где новые детали поочередно добавляются в общую конструкцию.

Agile-разработка

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

В 1990-х годах идеи Ройса легли в основу создания комплекса гибких методов разработки программного обеспечения, которые постепенно вытеснили использование более сложных и трудоемких методов.

Перечислим несколько ключевых открытий:

  • В 1991 году создан метод быстрой разработки приложений RAD.
  • В 1994 году создан метод разработки динамических систем DSDM.
  • В 1995 году создана платформа гибкой разработки Scrum.
  • В 1996 году создана методология разработки Crystal Clear и экстремальное программирование XP.
  • В 1997 году создана итеративная методология разработки ПО FDD.

После этого в 2001 году на американском курорте произошла встреча ведущих разработчиков программного обеспечения. В качестве итогов обсуждения методов разработки был напечатан «Манифест о гибкой разработке ПО Agile» (в переводе с английского слово «agile» означает «подвижный», «быстрый» или «гибкий»). Данный документ и стал базовым руководством в деле дальнейшей разработки программного обеспечения.

Идеи и принципы Agile-разработки

«Манифест о гибкой разработке ПО Agile» позволяет понять, что такое Agile-разработка и включает в себя четыре ключевых установки и 12 принципов эффективного управления проектами. Именно поэтому все системы управления по методологии Agile основываются на одинаковых установках и принципах (несмотря на то, что вариации их использования могут быть разными).

Приведем основные установки методологии разработки Agile:

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

Далее перейдем к принципам гибкой Agile-разработки:

  1. Поставлять программное обеспечение клиентам заблаговременно и с одинаковой периодичностью.
  2. Вносить коррективы на протяжении всего процесса разработки, изменяя требования к итоговому продукту (если можно сделать более совершенный проект, не следует ориентироваться исключительно на первоначальную цель).
  3. Поставлять программное обеспечение как можно чаще.
  4. Взаимодействовать с клиентом на протяжении всего рабочего процесса.
  5. Задать правильную мотивацию всем членам рабочей команды (сотрудники, удовлетворенные условиями труда и мотивированные дополнительными бонусами, гораздо лучше выполняют свою работу).
  6. Наладить систему непосредственного взаимодействия между разработчиками (это способствует более успешной и продуктивной коммуникации).
  7. Измерять прогресс исключительно посредством рабочего программного обеспечения (заказчикам следует поставлять только функциональное и рабочее ПО).
  8. Постоянно работать в едином темпе (поддерживать оптимальную скорость работы в целях сохранения продуктивности).
  9. Обращать внимание на дизайн и технические детали (это является неотъемлемой частью регулярного совершенствования выпускаемого продукта).
  10. Прилагать максимальные усилия для упрощения рабочего процесса и к тому, чтобы создать понятное большинству программное обеспечение.
  11. Позволять участникам процесса разработки самим принимать решения в ходе работ (самоорганизация, чувство ответственности и беспрепятственное общение с коллегами значительно увеличивает вероятность создания качественного продукта).
  12. Постоянно следить за техническим прогрессом и новыми тенденциями (без этого продукт навряд ли сможет участвовать в конкурентной борьбе).

Особенности применения Agile-разработки

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

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

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

Agile-разработка

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

Разработка по методологии Agile чаще всего начинается с разделения всего объема работ на небольшие составные части. Это значительно упрощает рабочий процесс и позволяет каждой группе сфокусироваться на порученной ей задаче.

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

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

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

При этом длительность одной встречи не должна быть больше четверти часа. Во время таких встреч каждый специалист должен ответить себе на три основных вопроса:

  • Чем я был занят вчера?
  • Что я буду делать сегодня?
  • Что препятствует моей работе?

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

  • четкое обозначение общей цели и следование ей;
  • тесное взаимодействие с заказчиком;
  • разделение общего объема работ на части;
  • деление рабочего коллектива на небольшие группы от 7 до 9 человек.

Сегодня данная методология наиболее распространена в IT-сфере (Agile-разработка сайтов и ПО), однако рассматриваемый подход постепенно завоевывает и другие области: обучение, маркетинг, бизнес. Гибкая система управления проектами начинает все чаще применяться в частных компаниях и государственных организациях.

Так, методы разработки Agile используют: правительство Новой Зеландии, компания Return Path (программное обеспечение), компания Oreo (занимается производством сладостей), компания Aviasales (крупный продавец авиабилетов), крупнейшая российская финансовая организация «Сбербанк».

Эти и многие другие предприятия довольно успешно применяют в своей работе самые разные методы, основанные на Agile.

Преимущества и недостатки Agile-разработки

Изучая основы Agile-разработки, стоит обратить внимание как на преимущества, так и на недостатки данной методологии. Для начала предлагаем рассмотреть ее достоинства.

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

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

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

Самое важное достоинство Agile - получение продукта, который можно использовать как можно раньше - (MVP) Minimum Viable Product. Это также дает возможность быстрее оценить текущий и потенциальный эффект от продукта, оценить потенциальные затраты и принять решение по дальнейшему развитию продукта или закрытию проекта при необходимости.

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

Agile-разработка

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

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

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

Как внедрить Agile-разработку

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

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

Внедрение и последующее использование Agile-методологии должно осуществляться высококвалифицированными специалистами (Scrum Master). Все члены команды должны знать ключевые установки и принципы Agile-разработки, а также уметь применять их на практике. Если в организации нет таких работников, следует направить подчиненных сотрудников на обучение.

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

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

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

2 метода управления, альтернативные Agile-разработке

Agile-разработка

1. Scrum.

Эта платформа, разработанная в 1986 году, считается наиболее структурированным членом семейства Agile. Scrum включает в себя как элементы традиционного подхода, так и гибкие идеи проектного управления.

Использование Scrum подразумевает деление проекта на части, которые могут использоваться заказчиком для получения ценности. Такие части называются заделами продуктов (product backlog) или, как привыкли говорить в российской практике, беклогами. Беклог разделяется на эпики (блоки функциональности) и беклоги релизов. После разделения беклога продукта на беклоги релизов и эпики, они приоретизируются совметно с представителями заказчика.

Наиболее важные части проекта первыми отбираются для выполнения в спринте (аналогичные используемым в Agile временные промежутки, длительность которых варьируется от 2 до 4 недель). По окончании спринта заказчик получает готовую часть проекта и может начинать использовать ее в своих целях.

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

Чтобы произвести продукт, который будет максимально соответствовать требованиям заказчика, перед началом каждого спринта осуществляется переоценка предстоящих работ, после чего вносятся необходимые корректировки. В оценочном процессе, так же как и в процессе определения дальнейшей рабочей тактики, принимают участие: члены проектной команды, руководитель (Scrum Master – лидер команды) и заказчик.

Agile-разработка

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

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

Механизм действия Scrum-методологии основан на проведении пяти основных встреч:

  1. Встреча по упорядочиванию беклога (Backlog Refinement Meeting). Это своеобразный аналог фазы планирования в традиционном проектном управлении. Данные встречи проводятся в первый день каждого спринта. На повестку дня выносятся следующие вопросы: подведение итогов прошедших спринтов, анализ оставшегося объема работ и постановка дальнейших задач. При этом приоритетность задач определяется представителем заказчика. От проведения таких встреч зависит эффективность спринта, а значит, и то, какой результат получит заказчик после окончания итерации.
  2. Встречи по планированию спринта. После того как представитель заказчика озвучил приоритетность основных задач, члены команды встречаются для определения тактики, которая поможет им достичь цели предстоящего спринта. На данном этапе могут использоваться самые разные инструменты планирования и оценки, главное, чтобы они не противоречили установкам и принципам Scrum. Собрание по планированию спринта проводится сразу после встречи по упорядочиванию продукта.
  3. Ежедневные летучки (стендапы). Ежедневно, на протяжении всего спринта, члены команды встречаются друг с другом, чтобы поделиться информацией о состоянии рабочего процесса. Такие встречи обычно проводятся в одно и то же время и имеют небольшую продолжительность (примерно 15 минут).
  4. Ежедневные летучки не предназначены для обсуждения проблем или принятия решений – в случаях, когда после встречи возникают вопросы и конфликты, Scrum-мастер и участники разбирательства обсуждают их отдельно. На летучке члены команды лишь обмениваются друг с другом информацией о ходе работ, чтобы все участники проекта имели представление о реальном положении дел.

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

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

  • Преимущества Scrum.

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

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

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

  • Недостатки Scrum.

Scrum-методология предъявляет очень высокие требования к участникам проектной команды. Рабочая группа должна быть небольшой (от 5 до 9 членов) и кросс-функциональной – т. е. все участники команды должны обладать познаниями в нескольких актуальных для разработки проекта сферах. К примеру, разработчик программного обеспечения должен также разбираться в тестировании и бизнес-аналитике. Такой подход позволяет задействовать всех членов команды независимо от специфики текущих работ, а также дает возможность сотрудникам подменять друг друга и оказывать взаимопомощь.

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

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

2. Kanban.

Данный подход был разработан инженером компании Toyota Тайичи Оно в 1953 году. По своей сути Kanban напоминает производственный процесс, который начинается с кусочка металла и заканчивается готовой деталью. То есть разработка проекта осуществляется поэтапно: инкремент продукта передается вперед до тех пор, пока не получится необходимый заказчику элемент.

Стоит отметить, что создателю Kanban нравился принцип организации работы супермаркетов и их кредо: «держи на полках только то, что нужно клиенту». Поэтому данная методология позволяет оставлять некоторые поставленные задачи незавершенными (в случае, если они неактуальны в данный момент времени и есть другие срочные задачи).

Работа по методологии Kanban гораздо лояльнее, чем по Scrum – здесь отсутствует распределение ролей, да и время спринтов не ограничивается жесткими рамками. Согласно установкам Kanban, член рабочей команды даже может выполнять несколько задач одновременно (что абсолютно недопустимо в Scrum). Кроме того, в основах Kanbab отсутствует информация о необходимости встреч по поводу обсуждения статуса проекта, т. е. их проведение вовсе не является обязательным.

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

Методология Kanban в вашей организации может быть настолько гибкой, насколько вы сами этого захотите, однако у нее тоже есть 4 базовых установки:

  1. Карточки. Для каждой задачи в обязательном порядке заводится индивидуальная карточка, в которой отображаются все необходимые сведения. Так нужная информация о конкретной задаче всегда под рукой.
  2. Ограниченное количество задач на этапе. На каждом этапе можно создать лишь определенное количество карточек. Это облегчает контроль рабочего процесса и позволяет быстро решать проблемы в случае их возникновения.
  3. Непрерывная работа команды. Задачи из беклога решаются в порядке приоритета и рабочий процесс никогда не останавливается.
  4. Постоянное улучшение (kaizen). Идея постоянного совершенствования появилась в Японии в конце XX столетия. Ее суть заключается в систематическом анализе рабочего процесса и постоянном поиске путей повышения производительности.
  • Преимущества Kanban.

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

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

  • Минусы Kanban.

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


Свяжитесь с нашими специалистами, заполнив форму ниже.
В ней укажите ваши контактные данные и перечислите задачи, которые стоят перед вашим бизнесом. Мы подберем для вас оптимальное решение.