Постигая основы гибкого управления проектами

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

В этой статье вы узнаете:

• Различия между доской Scrum и Kanban

• Пошаговое руководство по внедрению Agile в вашей команде

• Советы, как избежать ошибок на каждом этапе.

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

Он был впервые представлен в 1990-х годах для замены тяжелых каскадных методологий. Это способствует непрерывным улучшениям. В начале 2000-х годов методы Agile достигли важного этапа. 10 уважаемых практиков, включая Джеффа Сазерленда, совместно представили известный Манифест Agile-разработки программного обеспечения.

С тех пор появилось множество разветвлений. Scrum, Extreme Programming (XP), Feature-Driven-Development (FDD) и Test-Drive-Development (TDD) — это лишь некоторые из них. Однако, независимо от названий, основные принципы остаются неизменными –> уменьшить риски бизнеса путем итеративной разработки, укороченных циклов обратной связи и адаптивного планирования.

Среди всех этих фреймворков наиболее популярен Scrum. Полный цикл включает пять стадий: формирование видения, планирование спринта, ежедневный спринт, доставка и ретроспектива. Эта статья сосредоточится на фреймворке Scrum.

Но сначала…

В чем различия между Scrum и Kanban

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

Scrum – это фреймворк, процесс

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

Kanban – это метод визуализации задач

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

Kanban и Scrum — это два метода. Но из-за популярности и эффективности доски Kanban, фреймворки Scrum иногда также используют этот инструмент. Помимо вышеупомянутых терминов, вы также можете ознакомиться с Agile Glossary на сайте AgileAlliance.

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

Шаг 1: Подготовка - Построение вашей команды

Обычно Agile-команда состоит из трех ролей: руководителя Scrum (SM), владельца продукта (PO) и разработчиков. Размер команды составляет около 7(+/-2): 1 руководитель Scrum, 1 владелец продукта и 3-5 разработчиков.

Руководитель Scrum находится на стороне разработчиков, чтобы убедиться, что проект идет гладко и, возможно, быстрее. Он/она должен быть посредником или фасилитатором в качестве самостоятельной роли. Однако, в зависимости от интересов команды, техлид или QA отлично справляются с ролью частичного руководителя Scrum.

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

Лучшая практика: Избегайте серьезных конфликтов

Работайте вместе, а не конкурируйте.

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

Шаг 2: Формирование видения - Подготовка бэклога продукта

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

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

Лучшая практика: Избегайте рутинной работы

Автоматизируйте трудоемкий процесс.

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

Шаг 3: Встреча - Проведение планирования спринта

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

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

Лучшая практика: Избегайте расплывчатых целей

Дайте четкое ожидание относительно результатов спринта.

Цель спринта НЕ просто одна или две случайно выбранные фразы, а ожидания заинтересованных сторон по поводу результатов. Она работает как краткий отчет для заинтересованных сторон о том, что делает команда. Ясная цель спринта прокладывает путь для измерения эффективности доставки.

Шаг 4: Ежедневный скрам - Проверка на пути

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

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

Лучшая практика: Избегайте длительных собраний

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

Шаг 5: Доставка - Выпуск и ретроспектива

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

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

Лучшая практика: Никогда не пропускайте ретроспективу

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

Каковы ограничения Agile

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

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

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

Несмотря на это, бесчисленные успешные примеры являются доказательством того, что Agile работает. Хотя существуют подводные камни, постоянно развивающиеся фреймворки Agile предоставляют инструменты и техники, такие как непрерывная интеграция (CI/CD), автоматизированное модульное тестирование и рефакторинг кода, чтобы, по крайней мере, частично справляться с проблемами.

Ключевые выводы

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

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

Какие ваши мнения? Напишите мне в Твиттере, чтобы поделиться своими уроками и хитростями по применению методов Agile :).