Сегодня в рамках обучения начинающих аналитиков разберем, что представляют собой 2 самых популярных Agile-подхода к организации работы в ИТ-проектах. Что общего у Scrum и Kanban и чем они отличаются, а также можно ли их использовать совместно.
Что такое Agile
Напомним, Agile-подход предполагает гибкий итеративный подход к управлению проектами и разработке ПО, позволяющий командам ускорить доставку ценности клиентам. Вместо «монолитного» выпуска всего продукта целиком, Agile-команда выполняет работу в рамках небольших итераций, поставляя ценность частями, которые называются-инкрементами. При этом требования, планы и результаты работы постоянно проходят проверку на актуальность. Такая обратная связь от клиента дает возможность быстро реагировать на изменения. Это особенно важно для продуктовой разработки, когда в рамках ИТ-проекта создается совершенно новый, ранее не существовавший продукт.
Впервые термин Agile для разработки ПО был высказан в рамках встречи разработчиков в начале 2001 года в штате Юта. Инициативная группа из 17 человек собралась, чтобы обсудить проблемы, связанные перекосом внимания проектных менеджеров и других членов команды в сторону планирования и документирования циклов разработки ПО вместо внимания к непосредственно самому процессу преобразования требований в работающий продукт. Свои идеи разработчики изложили в Манифесте Agile, который представляет собой краткий документ всего из 68 слов:
Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим.
Благодаря проделанной работе мы смогли осознать следующее.
Люди и взаимодействие важнее процессов и инструментов.
Работающий продукт важнее исчерпывающей документации.
Сотрудничество с заказчиком важнее согласования условий контракта.
Готовность к изменениям важнее следования плану.
То есть, не отрицая важности того, что справа, мы все-таки больше ценим то, что слева.
Из этих идей, изложенных в Манифесте, родились следующие 12 принципов.
На первый взгляд, эти принципы выглядят общими словами в духе «за все хорошее против всего плохого». Однако, практическая реализация этих принципов действительно позволяет повысить эффективность процессов ЖЦ ПО и сократить важную бизнес-метрику TTM (Time-to-Market), обеспечивая быстрый выпуск продукта на рынок за счет оптимального взаимодействия самоорганизованной команды. Наиболее распространенными Agile-подходами к реализации ИТ-проектов являются Scrum и Kanban, что мы и рассмотрим далее.
Что такое Scrum
По-русски Scrum означает «схватка». В основе Scrum лежат серии итераций фиксированной продолжительности (обычно 1-2 недели), называемые спринтами. На старте проекта владелец продукта (PO, Product Owner) формирует бэклог продукта – приоритизированный список требований или ошибок, которые надо исправить в продукте. Это постоянно меняющийся перечень функциональных возможностей, требований, улучшений и исправлений, из которого составляются задачи для бэклога спринта. PO постоянно обращается к бэклогу продукта, меняя приоритеты и поддерживая актуальность. Это постоянное изменение бэклога соответствует гибким принципам Agile: изменения могут произойти на любом этапе, поэтому выполнять некоторые задачи будет нецелесообразно, возникнут новые требования, появятся запросы на новые возможности продукта или будут доступны более оптимальные способы решения бизнес-проблем.
В бэклог спринта попадают элементы с наивысшим приоритетом, т.е. из верхней части бэклога продукта, отобранные командой разработчиков для реализации в текущей итерации. Перед каждым спринтом проводится собрание по планированию спринта, где команда выбирает, какие задачи из бэклога продукта выполнить в рамках спринта. Бэклог спринта может меняться по ходу спринта, но он остается нацеленным на результат, который нужно получить за текущую итерацию. Этот результат или цель спринта называется инкремент — готовый к использованию конечный продукт по итогам спринта, включающий какую-то новую функциональную возможность (фичу, от англ. feature).
С точки зрения коммуникаций и организации работы команды в Scrum явно выделены следующие ключевые точки:
- Планирование спринта — собрание команды по планированию для определения объема работы на следующий спринт;
- Ежедневные Scrum-миттинги или стэндапы (daily meeting) – короткие 15-минутные планерки для синхронизации работы команд, где кратко каждый член команды говорит о том, что он сделал вчера, что планирует сделать сегодня и что его задерживает, например, нехватка данных. Обычно эти планерки проводят стоя, чтобы не превращать их в долгие совещания.
- Демонстрация спринта (демо-день) – общее собрание с демонстрацией результатов, достигнутых командой в ходе работы над прошедшим спринтом;
- Ретроспектива (ретро) – подведение итогов по завершении спринта, обзор удачных и неудачных событий текущего спринта и обсуждение действий для улучшения следующего спринта.
В Scrum у каждого члена команды есть своя уникальная роль. В команде обязательно должен быть Scrum-мастер, который отвечает за реализацию процедур работы и коммуникации согласно подходу Scrum, Владелец продукта и самоорганизуемая Scrum-команда из специалистов разного профиля с высокой мотивацией, которые выполняют поставленные задачи. Классическая роль менеджера проекта здесь отсутствует, хотя на практике бывает явно закреплена за отдельным членом команды. Примечательно, что роль аналитика тоже явно не выделяется в Scrum-команде, хотя, разумеется, задачи сбора, разработки и анализа требований все равно выполняются в рамках проекта разработки ПО. Иногда эти обязанности ложатся на владельца продукта, хотя его главная задача – понимать требования бизнеса, клиента и рынка, чтобы правильно расставить приоритеты между рабочими задачами, которые Scrum-команда будет выполнять. Роль владельца продукта не всегда совмещена с ролью менеджера продукта, который отвечает за рутинное управление продуктом, включая сбор и анализ продуктовых метрик. Важно, чтобы владельцем продукта всегда был один человек, т.к. другие варианты нарушают принцип единой ответственности и приводят к дезорганизации.
От процессов к продуктам: Product Ownership и Agile-практики для бизнес-аналитика
Код курса
POAP
Ближайшая дата курса
11 июля, 2024
Продолжительность
8 ак.часов
Стоимость обучения
18 000 руб.
Scrum-мастер следит за применением принципов Scrum в командах, обучая ее членов и владельца продукта тонкостям этого гибкого подхода. Scrum-мастер выполняет роль координатора, который составляет перечень требуемых ресурсов (кадровых и материально-технических) для собраний по планированию спринта, демо, ежедневных митингов и ретроспективы.
Всю работу по реализации элементов бэклога в готовый продукт выполняет Scrum-команда. Самые успешные Scrum-команды сплочены, находятся в одном месте и обычно состоят из 5–7 участников. Оптимальный размер команды определяется по эмпирическому правилу «двух пицц» от Джеффа Безоса, основателя компании Amazon: в команде должно быть столько участников, сколько можно накормить 2-мя пиццами. Обычно это не более 7 человек.
Scrum-команды составляют план на каждый спринт, прогнозируя объем работы, который можно выполнить за эту итерацию на основании своего прошлого опыта. Такая прогнозная оценка (estimation) оценка задач или требований, представленных в виде пользовательских историй (user story), обычно выражается в соответствующих пунктах (story point) по шкале от 1 до 10. Разумеется, по мере увеличения опыта, точность таких прогнозов повышается. Scrum отлично подходит для создания совершенно новых продуктов, когда есть слаженная команда из квалифицированных специалистов с высокой мотивацией и самодисциплиной.
Что такое Kanban
Другую гибкую методологию, получившую признание в РФ, называют Kanban. Исторически она пришла из послевоенной Японии, где ее впервые применила автомобильная компания Тойота, чтобы оптимизировать свои технологические процессы. На заводах Toyota для отслеживания объемов производства в цехе и взаимодействия с поставщиками в режиме реального времени использовалась специальная карточка, называемая Kanban, которую рабочие передавали между командами. Когда в корзине заканчивались материалы, нужные на этом участке производства материалы, на склад передавали Kanban-карточку с указанием материала и его количества. А на складе уже стояла новая корзина с этим материалом, которую отправляли в цех. При этом работники склада отсылали назад свою Kanban-карточку. Когда у какого-то производственного отдела заканчивались карточки, это сигнализировало о его полной загрузке и невозможности обслужить новые запросы. Таким образом, Kanban-карточки играли роль средства организации процессов по принципу «точно вовремя» (Just In Time, JIT), без создания неиспользуемых, но занимающих место, запасов.
В Kanban работа сопоставляется с ресурсами команды, чтобы выполнять задачи как можно быстрее за счет равномерного прохода по каждому этапу всей цепочки. Благодаря этому Kanban-команды могут реагировать на изменения даже быстрее Scrum-разработчиков. Хотя этот подход тоже соответствует принципам Agile, в отличие от Scrum, Kanban поддерживает не выталкивающее, а вытягивающее производство, ориентированное на мощность и пропускную способность команды, без перегрузок или простоев любого звена за счет выравнивая потока работ.
Kanban-команды могут создавать непрерывные процессы и выпускать релизы в любой момент. Поэтому данных подход особенно прижился в DevOps-командах, направленных на устранение барьеров между этапами разработки, тестирования, развертывания и сопровождения ПО. Вся работа видна, подсчитана и готова к выполнению, поэтому по завершении одной задачи команда сразу же переходит к следующей, реализуя непрерывную интеграцию и поставку (CI/CD, Continuous Integration and Continuous Delevery). Kanban-подход включает следующие компоненты:
- Список работы – проблемы, требования, ошибки или задачи, которые необходимо решить. На первый взгляд это похоже на бэклог продукта в Scrum, но в отличие от Scrum, в Kanban нет бэклогов, а вся работа находится в списке «Сделать» (To Do).
- Этапы работы – списки или вертикальные столбцы для разделения задач, соответствующих различным рабочим процессам, стадиям ЖЦ ПО, проектам и пр.;
- Лимиты задач в работе (Work In Progress, WIP) — правило ограничения объема работы на основании ресурсов команды;
- Непрерывные релизы — команда работает над определенным числом работ в пределах лимита WIP и может выпустить релиз в любое время.
Команда получает определенный объем работ, исходя из лимитов WIP — заранее определенного количества задач, которые могут одновременно находиться в одном списке, кроме списка «Сделать». На практике подход Kanban наглядно реализован во многих системах управления задачами, например, Trello. Этот подход уместен для командной работы по множеству текущих задач в рамках нескольких проектов.
Scrum vs Kanban: сходства и отличия
При том, что Scrum и Kanban представляют собой популярные Agile-подходы, они часто противопоставляются друг другу. В частности, Scrum использует модель выталкивающего производства (обработка изделий крупными партиями с максимальной скоростью исходя из прогнозируемого спроса с последующим перемещением изделий на следующую производственную стадию или на склад, независимо от фактического темпа работы следующего процесса), а Kanban – вытягивающего, когда последующие операции сигнализируют о своих потребностях предыдущим операциям. Тем не менее, оба подхода являются гибкими, т.е. реализуют принципы Agile, поддерживая ориентацию на эффективность и деление сложных заданий на мелкие рабочие задачи.
Разработка ТЗ на информационную систему по ГОСТ и SRS
Код курса
TTIS
Ближайшая дата курса
3 июня, 2024
Продолжительность
12 ак.часов
Стоимость обучения
27 000 руб.
Однако, Scrum строится вокруг небольших итераций с фиксированной продолжительностью. Сперва определяется продолжительность спринта, затем выбираются элементы бэклога продукта, которые можно реализовать в рамках этой итерации. В Kanban количество заданий или объем невыполненной работы, т.е. лимит WIP, которые нужно выполнить в текущей итерации, задается изначально. Затем ведется обратный отсчет времени, которое уйдет на реализацию этих возможностей.
У Kanban нет жесткой структуры и операций Scrum, таких как ретроспектива, ежедневные митинги, демо-дни и пр. Scrum требует формирования многофункциональной команды, чтобы возможность достижения цели не зависела от сторонних участников. На практике собрать такую команду довольно сложно. Поэтому Kanban проще использовать, а внедрение Scrum влечет за собой изменение образа мышления и особенностей деятельности команды разработчиков.
Выбирая для своей команды оптимальный подход следует понимать, что важнее смысл подхода, а не его внешние атрибуты и ритуалы. Например, если яркие стикеры на Kanban-доске не отражают реальный ход работы или ежедневные Scrum-митинги превращаются в рутину и не несут фактической ценности команде, речь не идет о реальном внедрении того или иного подхода в практическую деятельность. Впрочем, на практике, несмотря на множество отличий между рассмотренными Agile-методологиями, некоторые команды объединяют Scrum и Kanban в Scrumban или Kanplan. Из Scrum берется распределение ролей, бэклог и фиксированные спринты, а из Kanban — ориентация на время цикла, визуализация хода работы и лимиты незавершенной работы.
Например, в популярной системе управления задачами Jira от разработчиков ранее упомянутого Trello для визуализации работы используются доски – списки работ как в Kanban, так и в Scrum-проекте. В Scrum на собрании по планированию спринта команда перемещает элементы из бэклога продукта в бэклог спринта, чтобы повысить прозрачность управления. В Kanban-проекте подобная доска используется для визуализации выполняемой работы, позволяя руководителю видеть задачи и определять сроки их выполнения.
Основы бизнес-анализа: вход в профессию для начинающих
Код курса
INTRO
Ближайшая дата курса
28 июня, 2024
Продолжительность
24 ак.часов
Стоимость обучения
54 000 руб.
Как применять лучшее из этих практик Agile при управлении требованиями в проектах разработки ПО, вы узнаете на курсах Школы прикладного бизнес-анализа в нашем лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве:
