Сегодня в рамках обучения начинающих аналитиков разберем, что представляют собой 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
Ближайшая дата курса
15 ноября, 2023
Длительность обучения
8 ак.часов
Стоимость обучения
15 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
Ближайшая дата курса
25 сентября, 2023
Длительность обучения
12 ак.часов
Стоимость обучения
20 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
Ближайшая дата курса
30 октября, 2023
Длительность обучения
24 ак.часов
Стоимость обучения
50 000 руб.
Как применять лучшее из этих практик Agile при управлении требованиями в проектах разработки ПО, вы узнаете на курсах Школы прикладного бизнес-анализа в нашем лицензированном учебном центре обучения и повышения квалификации системных и бизнес-аналитиков в Москве:
