Этапы гибкого цикла создания Agile

Этапы гибкого цикла создания Agile
Этапы гибкого цикла создания Agile

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

Необходимо отметить, методологии не всегда могут обладать гибкостью, например, она не свойственна Waterfall. Лучшие из методик управления задачами и проектами представлены в топ-10 нашего рейтинга.

Здесь же более детально будет рассмотрен вопрос этапов разработки проекта в соответствии с методикой Agile.

Базовые принципы Agile

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

Русифицированный вариант принципов Agile представлен на сайте проекта Agilemanifesto.org:

  • потребности заказчика превыше всего;

  • требования к проекту допустимо менять в любой момент;

  • цикличность выпуска проекта не должна превышать двух месяцев;

  • заказчик должен включаться в состав команды;

  • реализация проекта возможна только профессионалами с хорошей мотивацией;

  • непосредственное общение — основа эффективного обмена информацией;

  • работающий продукт является основным критерием эффективности;

  • бесконечный ритм разработки возможен, и к нему необходимо быть готовым;

  • упрощение — основа сокращения расходов;

  • техническое совершенствование нельзя останавливать;

  • в командах должна быть полноценная самоорганизация;

  • анализ и оптимизация работы — залог ее эффективности.

В основе манифеста Agile необходимо выделить следующие фундаментальные принципы:

  • люди и их взаимодействие играют основную роль в любом проекте;

  • основной ориентир в работе — создание полноценно функционирующего продукта;

  • готовность к трансформациям должна быть постоянной;

  • наличие прямого взаимодействия с клиентом важнее совершенствования договоров.

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

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

Методологии Agile

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

Методика Kanban

В основе данной методики, предложенной японскими менеджерами, лежит следующий набор принципов:

  • поощрение возникновения лидеров;

  • всеобщее признание непрерывного эволюционирования проекта;

  • необходимость начинать реализацию проекта с имеющимися возможностями;

  • все процессы и роли требуют уважительного отношения.

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

Технические особенности:

  • kanban не предполагает обязательности наличия итерации;

  • скорость планирования и цикличность устанавливаются на основе поставленных задач;

  • циклы релизов и разработки не предусматривают существования четкой привязки;

  • для оценки величины затрат используется продолжительность минимального цикла;

  • использование показателей KPI не является обязательным для оценки;

  • приоритетность разработки не предусматривает строгости требований;

  • появление новых требований возможно на любой стадии реализации проекта;

  • канбан-доска позволяет отслеживать состояние всех существующих задач;

  • задачи не регламентируются по степени сложности или величине.

Несмотря на то что методика kanban предполагает достаточный уровень свободы и минимум четких регламентов, во многих случаях представители команд самостоятельно вырабатывают те или иные правила, позволяющие повысить эффективность функционирования группы:

  • На ежедневной основе проводятся совещания в команде по вопросам прогресса. Чаще всего в первой половине дня. График их организации может меняться в соответствии с потребностями и интересами участников, в первую очередь заказчика.

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

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

Методика Scrum

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

Данная методика также предполагает наличие непрерывного процесса контроля, в котором активно участвует заказчик.

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

Технические особенности:

  • одинаковые по продолжительности итерации, оговариваемые с заказчиком в самом начале проекта;

  • обязательное использование KPI и иных показателей для оценки достигнутого в процессе реализации прогресса;

  • наличие собственных целей и задач для каждой итерации без возможности их корректировки;

  • задачи должны иметь требования, допускающие возможность реализации в сроки одной итерации;

  • наличие четкого распределения ролей между участниками команды проекта, включая представителей заказчика;

  • бэклоги спринтов являются индивидуальными, наличие общего бэклога допускается только для всего проекта в целом;

  • в рамках одного бэклога его элементы выстроены относительно друг друга по принципам приоритетности.

Шаги разработки в гибких циклах

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

Для Scrum порядок осуществляемых действий имеет наличие зафиксированной последовательности:

  • Планирование (Sprint Planning).

  • Daily Scrum — короткое совещание/встреча до начала рабочего дня с целью обсуждения основных задач и уточнений.

  • Sprint Review — предпоследнее из событий в рамках конкретного спринта, необходимое для проверки результатов.

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

Фактически перед менеджерами не стоит ограничений на совмещение подходов Agile с проведением последовательной разработки проекта.

Варианты реализации

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

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

После того как MVP удалось реализовать и предоставить продукт заказчику, можно переходить к методикам Agile.

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

Начать дискуссию