Быть гибким быть в agile

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

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

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

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

Для успешного внедрения Agile в смешанных командах, включающих IT-специалистов, маркетологов и креативщиков, необходимо учесть ряд факторов и следовать определенным принципам.

## Кросс-функциональные команды

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

В Agile-методологии существуют стандартные роли, которые часто присутствуют в командах:

- Product Owner
- Scrum Master
- Разработчики

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

## Гибкое планирование

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

Это позволяет быстрее реагировать на изменения и корректировать планы в соответствии с новыми требованиями или клиентской обратной связью.

Agile-методология предоставляет 2 популярные рамки работы — Scrum и Kanban, которые помогают командам маркетинга эффективно планировать и управлять проектами.

Оба метода, Scrum и Kanban, предлагают командам гибкую систему планирования и управления проектами.

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

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

## Регулярная обратная связь

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

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

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

1. Модель Плюсы и минусы:
   В этой модели команда собирается вместе и обсуждает конкретное событие, проект или задачу, а затем перечисляет плюсы (что прошло хорошо) и минусы (что можно улучшить или исправить). Это помогает команде получить полную картину и понять, что нужно поддерживать и что нужно изменить.

2. Модель Стоимость, возможности, риски и время (CORT):
   Эта модель используется для анализа и обсуждения проектов или инициатив. Команда обсуждает стоимость реализации, возможности, которые предоставляет проект, связанные риски и время, необходимое для его завершения. Это помогает команде оценить ценность и сложности проекта и принять информированные решения.

3. Модель Обратная связь на основе данных:
   В Agile-среде основным принципом является фокус на фактах и данных. Эта модель обратной связи основана на сборе и анализе данных, таких как метрики производительности, клиентская обратная связь или результаты тестирования. Команда анализирует эти данные и использует их для улучшения процессов и принятия решений.

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

Как работает обратная связь через ретроспективы

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

Доска расчерчивается на 4 блока:

1. Что произошло хорошо
2. Что можно улучшить
3. Что нужно изменить
4. Действия

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

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

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

Визуализация процесса

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

Примеры некоторых инструментов, которые можно использовать для визуализации процесса и управления задачами:

• Agile-доски
• Kanban-доски
• Диаграммы Ганта
• Майнд-карты

Конкретный выбор инструментов и досок для визуализации процесса зависит от предпочтений команды, доступности и особенностей проекта.

Управление рисками

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

Критический анализ и постоянное обновление планов позволяют командам быть готовыми к любым сценариям и минимизировать отрицательное воздействие потенциальных проблем.

Направления рисков:

• Уход зарубежных компаний с российского рынка
• Необходимость поиска альтернативных инструментов
• Разработка собственных решений и адаптация стратегий

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

Стратегии управления рисками:

• Гибкость
• Творческое мышление
• Готовность к новым вызовам

Постоянное обучение и улучшение

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

Процессы для улучшения:

1. Анализ данных и метрики:

   • Google Analytics
   • Adobe Analytics

2. Автоматизация маркетинговых процессов:

   • HubSpot
   • Marketo
   • Mailchimp

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

Персонализация и таргетинг

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

Аналитика социальных медиа

Интенсивное использование социальных медиа в маркетинге требует эффективного анализа и измерения этих платформ. Инструменты для аналитики социальных медиа, такие как Sprout Social, Hootsuite или Buffer, помогают командам маркетинга измерять и анализировать метрики эффективности социальных медиа, такие как вовлеченность, рост подписчиков и влияние контента.

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

Улучшение производительности

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

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

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

Ретроспективы спринта

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

Поэтапная оценка проектов

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

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

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

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

Scrum-команды обычно следуют «правилу двух пицц», сформулированному генеральным директором Amazon Джеффом Безосом. В нем говорится, что наиболее продуктивные команды состоят не более чем из девяти человек — именно стольких можно накормить двумя большими пиццами!

Как провести ретроспективу спринта

В своей книге 2006 года «Agile ретроспектива: как превратить хорошую команду в великую» эксперты по Agile Эстер Дерби и Диана Ларсен описали пятиступенчатую структуру успешной ретроспективы проекта:

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

Рис. 1. Пять этапов ретроспективы спринт-проекта

Например, представим, что вы — ведущий Scrum-встречи команды из восьми человек. В своем последнем спринте команда выполнила только три из пяти запланированных задач, и вы хотите выяснить почему. Давайте посмотрим, как провести ретроспективу спринта, используя пятиэтапный подход Дерби и Ларсен.

Подготовьте почву

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

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

Предложите членам команды кратко изложить свои мысли или ощущения по поводу спринта. Их можно написать на доске или на стикерах. Это поможет вам сразу понять, какие вопросы наиболее важны для команды.

Соберите данные

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

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

Генерируйте идеи

Когда вы проанализируете данные, подумайте о том, что сработало, а что нет, и почему. Используйте метод «5 Почему», если вам трудно определить причины каких-либо проблем. Запишите все идеи на доске или на стикерах.

Кроме того, не игнорируйте успехи, достигнутые вами в спринте. Если что-то удалось сделать хорошо однажды, это можно повторить в будущем.

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

Примите решение о действиях

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

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

Закройте ретроспективу

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

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

Подходят ли вам ретроспективы спринтов?

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

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

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

Пять форматов эффективных ретроспектив спринтов

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

Ниже приведены пять форматов, которые помогут вам начать работу по проведению ретроспектив.

Марка автомобиля

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

Просто спросите у членов вашей команды: «Если бы этот этап проекта был автомобилем, то какой марки?» Чем выше их удовлетворенность, тем более престижный или «спортивный» бренд они, скорее всего, назовут.

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

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

Прекратить, начать, продолжить

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

Напишите три заголовка — «Прекратить», «Начать» и «Продолжить» — на доске или флипчарте. Затем попросите сотрудников ответить на следующие вопросы:

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

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

Воздушный шар

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

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

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

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

Пустая змея

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

В начале спринта нарисуйте голову и хвост змеи и прикрепите их к стене.

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

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

Ретроспектива вопросов

В этом формате ведущий Scrum-встречи задает ряд вопросов команде. Желательно начать с четырех ключевых вопросов, определенных Норманом Кертом в его известной книге 2001 года «Ретроспектива проекта. Как проектным командам оглядываться назад, чтобы двигаться вперед»:

В своей книге 2013 года «Извлекаем пользу из Agile-ретроспектив: подборка ретроспективных методов» Луис Гонсалвес и Бен Линдерс предлагают дополнительные вопросы, в том числе:

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

Начните бесплатно с шаблона для управления проектами Jira

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

Что такое управление проектами по методике agile?

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

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

Вот что вам нужно знать, чтобы начать работу с agile или использовать эту методику эффективнее.

Статьи об agile-управлении проектами

При управлении проектами по методике agile используется итеративный инкрементный подход, а в каскадной модели — линейный, поэтапный подход.

Начало создания agile-процесса

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

Эпики, истории, темы и идеи

Эти популярные agile-методики помогают командам найти золотую середину между четкой структурой и свободой действий.

Эпик — большой объем работы, который можно разбить на несколько небольших историй. Узнайте, как организовать рабочий процесс agile с помощью эпиков.

Пользовательские истории | Примеры и шаблон

Пользовательские истории — это требования к системе, которые зачастую выражены в виде «личность + потребность + назначение». Узнайте, как истории выступают в качестве ориентиров для agile-проектов и как начать работу с ними.

Что такое оценка сложности в Agile и как ее проводить?

Раскрываем секреты использования agile-оценки и очков за истории. Хорошая agile-оценка помогает владельцам продукта оптимизировать процессы для повышения эффективности и производительности.

Пять действительно нужных показателей agile

Узнайте об использовании agile-показателей KPI, таких как диаграмма Burndown для спринта, эпика и релиза, скорость, контрольные графики и сводная диаграмма процесса.

Изучите scrum с помощью Jira Software

Пошаговое руководство по ведению scrum-проекта, расстановке приоритетов в бэклоге, упорядочиванию работы в спринты, проведению scrum-собраний, другим вопросам — и все это в Jira.

Диаграммы Ганта

Диаграммы Ганта — это инструмент управления проектами, иллюстрирующий план проекта. Узнайте, чем они могут помочь, и ознакомьтесь с примером такой диаграммы

Краткая история управления проектами по гибкой методологии Agile

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

Традиционный agile-подход к управлению проектами включает две методологии: Scrum и Kanban. Scrum предполагает итерации с фиксированной продолжительностью, а Kanban — непрерывные релизы. По окончании одного команда сразу переходит к следующему.

Методика 1 для управления проектами по Agile

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

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

Четыре составляющих Scrum

Планирование спринтов ДЕМОНСТРАЦИЯ СПРИНТА Ежедневные стэндапы Ретроспектива

Собрание команды по планированию для определения объема работы на следующий спринт. Общее собрание с демонстрацией результатов, достигнутых командой в ходе работы над последним спринтом. Известно также как «стендап»: короткое 15-минутное совещание для синхронизации работы команды. Обзор удачных и неудачных событий текущего спринта и обсуждение действий для улучшения следующего спринта.

Scrum-доска

Доска Scrum используется для визуализации работы в рамках спринта. В ходе собрания по планированию спринта команда перемещает элементы из бэклога продукта в бэклог спринта. На досках Scrum рабочие процессы представляются по этапам, например Сделать, В работе и Готово. Доски Scrum — это ключевой компонент для повышения прозрачности при agile-управлении проектами. Начните использовать доску Scrum в нашем бесплатном шаблоне Scrum для Jira.

Методика 2 для управления проектами по Agile

Kanban представляет собой agile-методику управления проектами, в которой работа сопоставляется с ресурсами команды. Ее цель — выполнять работу как можно быстрее, поэтому kanban-команды могут реагировать на изменения даже оперативнее, чем scrum-разработчики.

В отличие от scrum, в kanban-методологии обычно нет бэклогов. Вся работа находится в столбце «Сделать». Благодаря этому kanban-команды могут создавать непрерывные процессы и выпускать релизы в любой момент. Вся работа видна, подсчитана и готова к выполнению, поэтому по завершении одной задачи команда сразу же переходит к следующей. Команда получает определенный объем работ, исходя из лимитов WIP — заранее определенного количества задач, которые могут одновременно находиться в одном столбце (за исключением столбца «Сделать»). Kanban-методология подразумевает четыре компонента.

Четыре компонента Kanban

Список работы (истории)Столбцы или полосыЛимиты задач в работе (WIP)

Список работы (истории) — это проблемы или задачи, которые необходимо решить. Используются в kanban-досках для разделения задач, соответствующих различным рабочим процессам, пользователям, проектам и т. д. Правило для ограничения объема работы на основании ресурсов команды. Команда работает над определенным числом историй в пределах лимита WIP и может выпустить релиз в любое время.

Kanban-доска

Чтобы планировать новые задачи или спринты, необходимо как-то отслеживать ход работы команды. При этом неважно, какая методология agile-разработки ПО была выбрана. Благодаря оценке проектов по agile-методике командам, использующим scrum или kanban, проще оценивать свои ресурсы. В agile-отчетах показано, как движется работа в команде. А ведение бэклога помогает руководителям проектов подготовить для команды список актуальных задач.

Оценка проекта по методике agile

Оценка проекта — это необычайно важный аспект управления проектами и в Kanban, и в Scrum. Kanban-команды в большинстве своем устанавливают лимиты WIP для каждого этапа работы, исходя из своего опыта и размера команды. Scrum-команды определяют, сколько работы можно сделать в рамках одного спринта, путем оценки проекта. Многие agile-команды для вычисления этого значения используют уникальные методики, такие как покер планирования, оценка в идеальных часах или в очках за истории. Это дает точку отсчета, благодаря которой в процессе ретроспективы спринта становится понятно, как идет работа. Jira Software можно настроить с учетом уникальной системы оценки проекта, используемой той или иной командой.

Agile-отчеты

Оценку проекта следует выполнять в начале и в конце каждого спринта. Таким образом, в начале спринта команда определяет, что можно сделать, а в конце — насколько точной была первоначальная оценка. Agile-отчеты, например диаграммы сгорания, показывают, сколько «очков за историю» будет отработано в течение спринта. Jira Software предлагает десятки встроенных отчетов, в которых эффективность команды отображается в режиме реального времени. Данные, на которые можно опираться в ретроспективах, открывают перед вами невероятные возможности по улучшению своей работы.

Ведение и управление

Бэклог продукта — это список задач для команды разработчиков с указанием приоритетов. Он основан на дорожной карте продукта и ее требованиях. Команда разработчиков забирает в каждый спринт задачи из бэклога продукта.

Эффективное взаимодействие с заинтересованными сторонами

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

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

Клэр Драмонд работает в Atlassian как специалист по маркетинговым стратегиям, докладчик и писатель. Она написала множество статей для блогов Trello и Atlassian. Материалы, подготовленные с ее участием, регулярно публикуются на Medium, в том числе в категориях HackerNoon, Art+Marketing и PoetsUnlimited. Клэр выступает на технических конференциях по всему миру, рассказывая о методиках agile, преодолении разрозненности и развитии эмпатии.

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

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

Agile (от англ. «гибкий») — семейство методологий для улучшения производимого продукта. Философию Agile характеризуют гибкость, скорость и прозрачность рабочих процессов.

Как правило, для Agile-команды характерна работа небольшими порциями — итерациями на 2-3 недели. Внутри каждой итерации собрано несколько задач для реализации продукта:

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

Как появился Agile-метод

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

На первый взгляд может показаться, что такое скрупулезное планирование — неплохой вариант. Но на деле появляется огромное количество подводных камней, которые тяжело предвидеть. Например:

Разработчики просто устали от излишней строгости и поняли, что создавать инновационные технологии по старым методологиям просто нельзя. В качестве альтернативы в 2001 и появилась Agile-концепция. В американском штате Юта 17 разработчиков со всего света собрались и подписали манифест об основных принципах Agile.

Ценности и принципы Agile

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

Всего принципов 12:

Из того, что провозглашает манифест Agile, сегодня выделяют 4 ключевых ценности Agile:

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

Начнем с плюсов:

➕ Гибкость и открытость к любым изменениям. Команда может оперативно вносить изменения в проект, дорабатывать продукт по комментариям заказчика и реагировать на изменения рынка.

➕ Небольшие риски потерпеть неудачу. В каждом цикле работы присутствует тестирование, аналитика и общение с заказчиком. Так можно быстрее выявить проблему и исправить ее, не перебирая этап за этапом, как в каскадном подходе.

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

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

➕ Минимум рутинной работы. Разработчикам не нужно тратить огромное время на аналитику, планирование и заполнение отчетов. Главное — работа над продуктом.

➖ Проект непредсказуем. В конце ожидания могут совсем не совпасть с реальностью. Возможно, это станет минусом для заказчиков с четким ТЗ.

➖ Потребность в тесном взаимодействии. Команде нужно постоянно общаться с заказчиком, чтобы отслеживать промежуточные результаты и вовремя обновлять продукт.

➖ Тяжелое погружение новых сотрудников. Поменять руководителя или важного сотрудника в процессе работы над проектом — задачка не из простых. Придется уделить приличное количество времени для онбординга нового коллеги.

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

Где используют гибкие методологии разработки

Если говорить о сферах бизнеса, то изначально Agile применялся разработчиками для создания нового программного обеспечения, интерфейсов и игр.

На сегодняшний день гибкая управление по Agile — стандарт для большинства современных проектов. Сейчас его могут использовать абсолютно все: от гигантов IT-индустрии, как Google и Microsoft, до небольших стартапов.

В каком случае применять Agile

Вам стоит попробовать Agile, если:

Вам не нужно использовать Agile, если:

Agile — философия, методология или фреймворк? Разграничиваем понятия

Чтобы понять, как работать по Agile, важно четко разграничить 3 понятия: философия, методология и фреймворк.

Философия отвечает на вопрос: «Что важно?».

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

В основе философии гибкого подхода лежит Agile-манифест и его 12 ценностей и принципов разработки.

Методология управления отвечает на вопрос: «Как применить эти ценности на практике?».

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

Методологии в Agile не зря называют гибкими — каждую из них можно подстроить конкретно под свою команду.

Фреймворки отвечают на вопрос: «Как именно выполнить задачу?».

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

Теперь расскажем про главные методологии управления проектами по Agile.

Методы управления проектами по Agile

В семейство Agile входит несколько разных видов управления проектов — фреймворков. В СНГ наибольшей популярностью пользуются два — Scrum и Kanban.

Как внедрить Agile в проект

Самое главное — это разделять философию Agile. Попробуйте начать с «пилотной группы» и рассказать о подходе небольшой команде. Крайне важно, чтобы сотрудники добровольно согласились использовать новый метод в работе. После дайте коллегам время. Если в течение 6-8 месяцев всё хорошо — можно постепенно масштабировать Agile во всей компании. О том, как подготовить сотрудников к переменам мы рассказали здесь.

Чтобы проекты выполнялись в срок и без ошибок, нужны и специальные инструменты управления: планировщики задач, календари, командные доски. Одним из таких сервисов и является Kaiten — визуальная система управления рабочими процессами.

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

Kaiten — гибкий инструмент для управляемых и прогнозируемых процессов с Agile-блоком в коробке