Этапы гибкого цикла создания 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.
Далее останется сформировать общий перечень задач, необходимых для реализации, подобрать их в соответствии со спринтами. Вовлечение в процесс заказчика обеспечивает возможность не только организации полноценного контроля на всех этапах, но и своевременного внесения коррективов в перечень задач до начала очередной итерации.
Источник: официальный канал Projecto на Дзен