Scrum и Kanban: объяснение двух мощных методологий Agile

Итак, вы собираетесь управлять сложным проектом? Есть куча работы, которую нужно сделать, но не паникуйте! Как менеджер проекта, вы будете нести ответственность за планирование, мониторинг, управление бюджетом, выполнение, проверку качества и своевременный выпуск окончательного проекта. К счастью, существует множество методологий управления проектами, которые могут сделать вашу (и вашу команду) работу проще и эффективнее!

В этой статье я хотел бы сосредоточиться на двух самых популярных методологиях Agile — Scrum и Kanban , — которые в последние годы штурмом захватили мир разработки программного обеспечения. В наши дни вы вряд ли найдете компанию, производящую программное обеспечение, которая не использует эти две структуры для управления проектами. О чем они? Читайте дальше и узнайте все, что вам нужно знать о Scrum и Kanban!

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

Сегодня компании уже не работают над одним проектом, не протестировав его на всех этапах процесса разработки. Это просто не окупается! Почему бы и нет?

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

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

Что интересно, хотя в течение многих лет Agile преобладал в ИТ и компаниях по разработке программного обеспечения, эта методология оказалась настолько эффективной, что в настоящее время используется во многих других областях, таких как маркетинг, продажи, HR или операции. Согласно отчету о состоянии Agile, подготовленному Verison One, в 2020 году 95% технологических компаний и производителей программного обеспечения применяли различные методы Agile.

Фреймворк Scrum: почему он такой классный?

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

Что такое Scrum и когда его можно использовать?

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

Несмотря на то, что Scrum стал ведущим фреймворком, особенно в последние годы, на самом деле в нем нет ничего нового. Вернемся в 1986 год, когда в Harvard Business Review была опубликована статья The New Product Development Game . Там авторы описали подход к управлению, используемый такими компаниями, как Honda или Canon, который привел к их успеху. Затем, в 1993 году, эти концепции вдохновили Джеффа Сазерленда и команду Easel Corporation на создание командного процесса под названием Scrum.

Роли и обязанности в Scrum-команде

В Scrum-команде все роли четко определены с самого начала и обычно не меняются на протяжении всего проекта. Как правило, в этом фреймворке есть 3 фундаментальные роли: Владелец Продукта, Scrum Master и Команда Разработки.

Скрам-мастер

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

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

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

Владелец продукта

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

Вот основные обязанности владельца продукта:

• управление бэклогом продукта
• контакт с заинтересованными сторонами
• определение главной цели каждого спринта
• планирование выпуска новых функций
• оценка работы Команды Разработки и отмена спринта при необходимости

Команда разработчиков

Без Команды Разработки Scrum был бы невозможен, поскольку они выполняют реальную работу и выполняют все задачи, запланированные для определенных спринтов.

Как правило, команда разработчиков состоит из людей с опытом в определенной области , такой как iOS, машинное обучение, бэкэнд или фронтенд разработка. Все они объединяют усилия для обеспечения высококачественных функций цифрового продукта. Однако следует помнить, что хотя термин «команда разработчиков» обычно относится к инженерам, это не всегда точно. Маркетологи, дизайнеры, аналитики, тестировщики, копирайтеры или специалисты по продажам также могут принести некоторую пользу и стать частью команды Scrum.

Одна из вещей, которую следует учитывать при создании Команды Разработки, — это количество ее членов. Даже здесь Scrum устанавливает некоторые основные правила! Говорят, что такая команда должна состоять из 3-9 человек , и они должны обладать навыками, необходимыми для реализации всех функций. Конечно, все зависит от сложности проекта и потребностей клиента; иногда для создания цифрового продукта вполне достаточно 4 или 5 разработчиков.

Но какова именно роль Команды Разработки в Scrum? В принципе, он должен:

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

Коротко о процессе разработки Scrum

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

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

1. Бэклог продукта : список всех элементов, которые необходимо создать в следующих спринтах. Он управляется владельцем продукта вместе со скрам-мастером, который точно знает, когда должна быть выпущена каждая функция или элемент.
2. Совещание по планированию спринта : основная цель этого собрания — определить, что каждый член команды разработчиков будет делать в следующем спринте. Он всегда организуется до начала спринта, чтобы каждый мог оценить, сможет ли он выполнить все задачи до установленного срока. Убедитесь, что каждый член команды полностью понимает основную цель спринта.
3. Бэклог Спринта : это выбранные задачи, взятые из Бэклога Продукта, которые команда решила выполнить в данном Спринте.
4. Спринт : здесь происходит все волшебство. Спринт — это короткий период, который обычно занимает 1-4 недели, когда Команда Разработки работает над выполнением всех задач, поставленных во время весеннего совещания по планированию.
5. Ежедневные скрамы (также называемые стендапом): Сверхкороткие встречи, проводимые каждый день в одно и то же время, во время которых каждый сообщает о ходе своей работы в 1-2 предложениях: говорят о том, что уже сделано, а что еще нужно сделать.
6. Обзор спринта : когда спринт заканчивается, у каждого есть возможность представить то, что они сделали, другим товарищам по команде и даже заинтересованным сторонам, которые довольно часто посещают обзоры спринта.
7. Ретроспектива Спринта : пришло время последней встречи, завершающей весь цикл Спринта. Если у кого-либо из членов команды есть предложения или идеи о том, что можно улучшить в следующем спринте, они могут сделать это во время ретроспективы спринта.

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

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

Несколько слов о Канбане

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

Что такое Канбан и когда его можно применять?

Термин Канбан происходит из японского языка, и его можно просто перевести как «визуальный сигнал». Это в основном то, о чем эта методология. В Канбане каждый элемент имеет свое визуальное представление — карточку, которую члены команды кладут на доску и меняют ее статус (например, «сделать», «выполняется» или «готово»).

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

Интересно, что Канбан на самом деле является гораздо более старой методологией, чем Скрам. Его начало восходит к 1940-м годам, когда Toyota представила систему отдельных карточек, размещаемых на досках на своих фабриках, которые рабочие могли переключать в любое время. В результате эта стратегия значительно упростила их работу и ускорила общение между командами.

Кто есть кто в канбан-команде?

При обсуждении Scrum я описал точные роли, обязанности и компетенции каждого члена команды (Scrum Master, Product Owner и разработчики). Здесь все по-другому. Канбан не определяет, у кого больше полномочий или обязанностей, поскольку практически все члены команды равны и объединяют усилия и наборы навыков коллективно.

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

Что такое канбан-доска и как ее создать?

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

Этот пример точно показывает, что такое Канбан и как он визуализирует работу:

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

В приведенном выше примере показаны типичные категории столбцов, а именно:

• 'сделать'
• 'в ходе выполнения'
• «тестирование»
• 'Выполнено'

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

Если вы хотите, чтобы ваша команда преуспела, есть еще одна вещь, о которой вам нужно знать — вы должны определить ограничения для элементов, над которыми ваша команда может работать одновременно. Вот почему Канбан дополнительно рекомендует установить лимиты незавершенного производства (WIT) . Как применить на практике? Вам нужно указать, сколько карточек может оставаться в столбце (например, «В процессе») одновременно. Если ваша команда достигает этого предела, они просто не могут добавить больше карт. Установление этих границ всегда является отличным решением, чтобы справиться с перегрузкой на работе.

Скрам против Канбана: какой фреймворк победит в этой битве?

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

Готовы к следующему программному проекту?

Давайте работать вместе

Вот основные различия между этими двумя фреймворками управления проектами:

Итак, какую из этих гибких платформ вы выберете для управления своими проектами? Или вы хотите, чтобы за вас это сделали специалисты? Не стесняйтесь обращаться к нам — внедряя различные методологии Agile, мы создали более 150 готовых к использованию успешных продуктов!