(function(m,e,t,r,i,k,a){m[i]=m[i]||function(){(m[i].a=m[i].a||[]).push(arguments)}; m[i].l=1*new Date(); for (var j = 0; j < document.scripts.length; j++) {if (document.scripts[j].src === r) { return; }} k=e.createElement(t),a=e.getElementsByTagName(t)[0],k.async=1,k.src=r,a.parentNode.insertBefore(k,a)}) (window, document, "script", "https://mc.yandex.ru/metrika/tag.js", "ym"); ym(94502844, "init", { defer: true, clickmap:true, trackLinks:true, accurateTrackBounce:true }); ym(94502844, 'hit', window.location.href);

Этапы гибкого цикла создания 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.

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

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

0
Комментарии
-3 комментариев
Раскрывать всегда