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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Планирование (Sprint Planning).
Daily Scrum — короткое совещание/встреча до начала рабочего дня с целью обсуждения основных задач и уточнений.
Sprint Review — предпоследнее из событий в рамках конкретного спринта, необходимое для проверки результатов.

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

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

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

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

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

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

#методология #методологияуправления #управлениепроектами #управлениепродуктом #управлениебизнесом #управлениеперсоналом

Источник: официальный канал Projecto на Дзен