Работа аналитика на проекте: Agile, Kanban, Scrum
Определения
Agile (agile software development, от англ. agile – проворный) – это семейство «гибких» подходов к разработке программного обеспечения. Такие подходы также иногда называют фреймворками или agile-методологиями.
Более 17 лет назад лидеры IT-разработки сформулировали манифест Agile. Главное, что можем выделить из манифеста:
Люди и взаимодействие важнее процессов и инструментов.
Работающий продукт важнее исчерпывающей документации.
Сотрудничество с заказчиком важнее согласования условий контракта.
Готовность к изменениям важнее следования первоначальному плану.
Agile предполагает, что при реализации проекта не нужно опираться только на заранее созданные подробные планы. Важно ориентироваться на постоянно меняющиеся условия внешней и внутренней среды и учитывать обратную связь от заказчиков и пользователей. Это поощряет разработчиков и инженеров экспериментировать и искать новые решения, не ограничивая себя жесткими рамками и стандартами.
Основополагающие принципы Agile-манифеста
- Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.
- Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
- Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
- На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
- Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
- Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
- Работающий продукт — основной показатель прогресса.
- Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.
- Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
- Простота — искусство минимизации лишней работы — крайне необходима.
- Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
- Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.
Scrum и kanban - основные понятия
Scrum – это «подход структуры». Над каждым проектом работает универсальная команда специалистов, к которой присоединяется еще два человека: владелец продукта и scrum-мастер. Первый соединяет команду с заказчиком и следит за развитием проекта; это не формальный руководитель команды, а скорее куратор. Второй помогает первому организовать бизнес-процесс: проводит общие собрания, решает бытовые проблемы, мотивирует команду и следит за соблюдением scrum-подхода.
Scrum-подход делит рабочий процесс на равные спринты – обычно это периоды от недели до месяца, в зависимости от проекта и команды. Перед спринтом формулируются задачи на данный спринт, в конце – обсуждаются результаты, а команда начинает новый спринт. Спринты очень удобно сравнивать между собой, что позволяет управлять эффективностью работы.
После окончания спринта выполненные фичи заливаются на продакшн, а невыполненные — переносятся в другой спринт. Как правило, фичи, которые делаются во время спринта, не меняются: что было на старте спринта — должно быть сделано любой ценой к окончанию спринта.
Kanban – это «подход баланса». Его задача – сбалансировать разных специалистов внутри команды и избежать ситуации, когда дизайнеры работают сутками, а разработчики жалуются на отсутствие новых задач.
Вся команда едина – в kanban нет ролей владельца продукта и scrum-мастера. Бизнес-процесс делится не на универсальные спринты, а на стадии выполнения конкретных задач: «Планируется», «Разрабатывается», «Тестируется», «Завершено» и др.
Главный показатель эффективности в kanban – это среднее время прохождения задачи по доске. Задача прошла быстро – команда работала продуктивно и слаженно. Задача затянулась – надо думать, на каком этапе и почему возникли задержки и чью работу надо оптимизировать.
Разница между Scrum и Kanban
Kanban дает больше гибкости, если под гибкостью понимать частоту смены приоритетов.
Пример: вчера залили на продакшн новую фичу, а сегодня получили данные с передовой и узнали, что вот эта штука не работает так, как было задумано — люди не нажимают кнопку «купить». UX дает вам новые требования. Вы поднимаете наверх очереди эту задачу, программист берет эту задачу «сверху», выполняет ее и, к вечеру fix уже на проде, конверсия в платежи выросли на 12%. Это победа.
В Scrum задачи принято оценивать в Story points или в часах. Без оценки не получится сформировать спринт: ведь нам нужно знать, успеем ли мы сделать задачи за 2 недели. Через 2 недели мы получаем ценную статистику — сколько часов или Story points команда смогла сделать за спринт. Velocity — это производительность команды за один спринт. Этот параметр позволяет Scrum менеджеру предсказать, где команда будет через 2 недели.
В Kanban не принято делать оценку. Это опционально, команда решает сама. Здесь нет понятия «скорость работы команды», считается только среднее время на задачу. Время это считается с помощью специального отчета — Cycle Time: сколько времени прошло от момента, когда задачу начали делать до момента пока она попала в deployed.
Сходства между kanban и scrum
Kanban и scrum имеют некоторые общие черты, уникальные для цикла разработки agile. К ним относятся:
Гибкость Оба метода предоставляют возможности для изменений и являются достаточно гибкими. Тем не менее следует понимать, что kanban менее регулируемый.
Ограничение для незавершенных задач Scrum измеряет скорость команды и ограничивает количество задач на спринт на основе оценки в форме Story Points. Kanban, в свою очередь, ограничивает количество незавершенных задач, но это может быть не более двух задач, выполняемых одновременно.
Эмпирический подход Scrum и kanban — это эмпирические подходы, которые используются с целью постоянной оптимизации процесса разработки. Предположим, kanban допускает одновременное выполнение не более двух задач. Однако ваша команда способна выполнить четыре задачи. Таким образом, вы можете адаптировать kanban для улучшения вашего рабочего процесса.
Управление процессом В Scrum это называется бэклог продукта (список задач для разработки продукта). Для каждого спринта скрам-команда вместе с владельцем продукта берет задачи из бэклога, расставляет приоритеты, оценивает их и добавляет их в спринт.
Что касается kanban, здесь бэклог продукта не является обязательным, поскольку приоритеты могут меняться очень быстро. То же самое можно сказать и о задачах. Колонка To Do в kanban является аналогом бэклога. Обычно команда и клиент руководствуются принципом извлечения задач из этой колонки.
Визуализация И в scrum, и в kanban используются доски для визуализации процесса работы. В scrum для каждой новой итерации подготавливается чистая скрам-доска, а вот в kanban все отображенные задачи остаются на доске в течение всего процесса разработки.
Быстрое и постоянное наличие результата И scrum, и kanban сфокусированы на быстром и частом релизе инкрементов. В scrum это происходит в конце каждой итерации, обычно после демо.
Самоорганизованные команды Scrum и kanban предполагают наличие самоорганизованных команд, работающих над разработкой продукта. Все участники равны и вносят свой вклад в выполнение задачи.
Дробление работы на небольшие, но конкретные подзадачи В scrum и kanban большие задачи всегда разбиваются на более мелкие, легкие для понимания подзадачи, которые могут быть сделаны сравнительно быстро. На самом деле, это один из факторов, который отличает agile от Waterfall.
Инструменты Kanban
Для визуализации agile-подходов используют доски: физические и электронные. Они позволяют сделать рабочий процесс открытым и понятным для всех специалистов, что важно, когда у команды нет одного формального руководителя.
Сервисов для ведения Kanban-досок в онлайн достаточно много. Есть универсальные решения, например, Jira от Atlassian или всем знакомый Redmine.
В Kanban используются специфические метрики для измерения потенциала команды и оценки продолжительности проекта.
Командная скорость (team velocity) определяет, сколько задач может выполнить команда в заданный период времени, например, за неделю. Знание скорости команды помогает лучше предсказать, когда будет завершен необходимый объем задач.
Время выполнения и время цикла (Lead time/Cycle time) определяют среднее время, необходимое для выполнения задачи. Время выполнения вычисляется с момента, когда команда получает запрос от клиента до завершения работ, а время цикла вычисляется с момента начала работы над задачей.
Показатель времени выполнения используется, чтобы понять, как долго пользователь (клиент) будет ожидать оказание сервиса, а времени цикла — для вычисления, как быстро команда производит продукт. При этом важно понимать, что Kanban обычно хорошо ложится на сервисные команды, например, развертывание колл-центра, тогда как для создания продукта лучше подходит Scrum.
Все эти метрики позволяют делать достаточно точные прогнозы по срокам выполнения того или иного типа задач в бэклоге.
Рекомендуемая литература
- Алистер Коберн: Командная разработка и agile (статья)
- 5 ключевых инструментов метода SCRUM (видео)
- Сравнение PMI, Scrum и Kanban (видеолекции)
- Дэвид Андерсон: Канбан. Альтернативный путь в AGILE (книга)
- Джефф Сазерленд: Scrum. Революционный метод управления проектами (книга)
- Роман Пихлер: Управление продуктом в Scrum. Agile методы для вашего бизнеса (книга)
- Эндрю Стеллман, Дженнифер Грин: Постигая Agile. Ценности, принципы, методологии (книга)
- Лисса Адкинс: Коучинг agile‐команд. Руководство для scrum-мастеров, agile-коучей и руководителей проектов в переходный период (книга)