Чем отличается scrum от agile
Перейти к содержимому

Чем отличается scrum от agile

  • автор:

Чем отличается scrum от agile

Agile (agile software development, от англ. agile – проворный) – это семейство «гибких» подходов к разработке программного обеспечения. Такие подходы также иногда называют фреймворками или agile-методологиями.

Agile возник в IT-среде, но затем распространился и в другие сферы – от промышленной инженерии до искусственного интеллекта.

Смысл Agile сформулирован в Agile-манифесте разработки ПО: «Люди и взаимодействие важнее процессов и инструментов. Работающий продукт важнее исчерпывающей документации. Сотрудничество с заказчиком важнее согласования условий контракта. Готовность к изменениям важнее следования первоначальному плану».

Agile-манифест – главный документ всех «гибких» подходов к разработке. Он был создан в 2001 году группой энтузиастов-программистов, которые хотели понять, что именно лежит в основе разработки востребованного и полезного IT-продукта. Agile предполагает, что при реализации проекта не нужно опираться только на заранее созданные подробные планы. Важно ориентироваться на постоянно меняющиеся условия внешней и внутренней среды и учитывать обратную связь от заказчиков и пользователей. Это поощряет разработчиков и инженеров экспериментировать и искать новые решения, не ограничивая себя жесткими рамками и стандартами.

К отдельным agile-подходам относятся scrum и kanban.

Scrum – это «подход структуры». Над каждым проектом работает универсальная команда специалистов, к которой присоединяется еще два человека: владелец продукта и scrum-мастер. Первый соединяет команду с заказчиком и следит за развитием проекта; это не формальный руководитель команды, а скорее куратор. Второй помогает первому организовать бизнес-процесс: проводит общие собрания, решает бытовые проблемы, мотивирует команду и следит за соблюдением scrum-подхода.

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

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

Вся команда едина – в kanban нет ролей владельца продукта и scrum-мастера. Бизнес-процесс делится не на универсальные спринты, а на стадии выполнения конкретных задач: «Планируется», «Разрабатывается», «Тестируется», «Завершено» и др.

Главный показатель эффективности в kanban – это среднее время прохождения задачи по доске. Задача прошла быстро – команда работала продуктивно и слаженно. Задача затянулась – надо думать, на каком этапе и почему возникли задержки и чью работу надо оптимизировать.

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

Примеры употребления

Один из принципов Agile стоит на личной ответственности человека, а не на отлаживании внутренних процессов.

(Из статьи на VC.ru)

Когда в работе с профессиональными командами мы используем Scrum, чаще всего мы выбираем цикл длиной в 2–3 недели с ретроспективными собраниями, которые позволяют держать все под контролем.

(Из интервью «Ведомостей» с Фрэнком Сосьером, коучем компании Freestanding Agility)

Главная идея Kanban – визуализация рабочего процесса. Она заключается в создании физической панели, на которой можно наглядно отмечать прогресс.

(Из перевода колонки Forbes на Rusbase)

Если говорить о том, что такое agile, я бы ограничился такой фразой – это набор ценностей, в рамках которых мы строим свою работу с продуктами, с процессами внутри организации.

(Управляющий партнер ScrumTrek Алексей Пименов в статье на Rusbase)

Слово экспертам

В зависимости от задач мы применяем разные методы в рамках философии – agile, scrum, kanban. Scrum позволяет развить в сотрудниках необходимые качества – проактивность, самостоятельность, организованность, коммуникабельность и дальновидность. Основной смысл метода – это выполнение задач в самоорганизующихся командах, где у каждого есть своя роль и каждый несет ответственность за свою часть работы. Используя scrum, мы проводим опросы персонала, составляем графики ожидаемой скорости выполнения задач. Agile мы используем во внутренних коммуникациях. Недавно провели очередной спринт по ликвидации опозданий сотрудников. Все начальники и специалисты, задействованные в проекте, провели целый день на совещании, обсуждая достижения, проблемы и предстоящие задачи в новом спринте. Сейчас мы активно внедряем в компании метод kanban. Цель внедрения kanban – повысить гибкость производства, лучше приспосабливаться к изменяющимся требованиям рынка. На практике метод помог нам добиться соответствия между складскими запасами и реально используемыми в производстве продуктами.

Владимир Овелян
Владелец и генеральный директор Dostаевский

Важный момент: agile-методология – это общее направление, а kanban и scrum – уже ее разновидности. Мы используем связку scrum + waterfall, а также дорабатывали в течение года саму agile-доску. Главная причина использования: прозрачность и простота. По сути, это получается тот же самый конвейер Генри Форда: переход задачи от статуса к статусу со сменой исполнителя, поэтому основным принципом к самой agile-доске является уже простота. Мы используем agile как непосредственную часть нашего workflow, поэтому все проекты, от брендинга и разработки сайтов и вплоть до нашего стартапа по AI и нативной рекламе NativeOS, в бюро Chernika ведутся как раз по данному workflow. Работающий продукт важнее подробно прописанной документации. Это не говорит о том, что мы не ведем никакую документацию, нет. Это скорее взгляд в сторону эффективности с ударом по излишней бюрократии.

Виталий Сотников
Креативный директор Бюро визуальных коммуникаций «Черника»

Scrum принес в нашу команду ритмичность и понимание — успеваем или не успеваем в срок. Мы видим скорость работы команды, нет ощущения постоянного факапа. Раньше были ситуации, что перед жесткими релизами scrum куда-то пропадал и все начинали просто фигачить — сейчас у нас это пропало, есть постоянное ощущение, что успеваем в срок. Если появляются риски, мы обсуждаем их с PD на ранних этапах, корректируем план или уменьшаем объем задач каким-то образом. Работа стала прозрачнее, рабочий день стал укладываться в 8-часовую норму и, по ощущениям, мы стали успевать больше. Мы понимаем, что когда у тебя есть ощущение, что ты не успеваешь, чувствуешь, что надо работать больше — это очень плохо влияет на продуктивность, от этого надо избавляться.

Илья Шихалеев
Ведущий разработчик и скрам-мастер iSpring

Для наглядности и открытости работы отдела разработки мы повесили специальную доску с пометками “to do”, “in progress”, ”review”, ”test”, “done”, где все члены команды наклеивают стикеры с задачами (в колонке “to do”), а по мере их выполнения перемещают в последующие пункты. И счастливый финал – конечный пункт “done”. Это помогает составить общую картину и дает возможность видеть, над чем работает каждый участник. Очень важный момент метода (и организации рабочего процесса): после утверждения всех задач (“to do”), список блокируется на внесение. Так новые поступающие задачи не отвлекают от процесса и не тормозят работу. Все участники также оценивают каждую задачу на предмет временных и материальных затрат, которые потребуются на выполнение. И вишенка на торте – ежедневные встречи в определенное время (Daily Scrum), где каждый член команды коротко рассказывает о том, что собирается сделать сегодня, что сделал вчера (и столкнулся ли с какими-то препятствиями). Это важно на пути к долгосрочным задачам – именно так можно вовремя понять, что пора сменить стратегию.

Евгений Россинский Директор по технологии в онлайн-кинотеатре ivi

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

Ирина Черепанова
Директор по продукту uKit Group

Agile – это философия, scrum – структура, waterfall – метод, kanban – система управления. Scrum и kanban – варианты agile, но у них есть некоторые явные различия. Методика scrum требует фиксированных ролей, тогда как у kanban нет необходимых ролей. Scrum основана на итерациях, объединяющих планирование, оптимизацию процессов и выпуск. В kanban это можно делать регулярно или каждый раз, когда вам нужно. Команда scrum требует оценки своей работы, тогда как команде kanban это не нужно.

Инга Корягина
Доцент кафедры теории менеджмента и бизнес-технологий РЭУ им. Г.В. Плеханова

Что почитать по теме?

  1. Agile-манифест разработки программного обеспечения (Manifesto for Agile Software Development)
  2. Дж. Сазерленд «Scrum. Революционный метод управления проектами»
  3. Д. Андерсон «Канбан. Альтернативный путь в Agile»
  4. Э. Стелманн, Дж. Грин «Постигая Agile. Ценности, принципы, методологии»
  5. K. Schwaber, J. Sutherland “The Scrum Guide”
  6. M. Cohn “Agile estimating and planning”

RB.RU организует встречу проекта Founders’ Mondays для начинающих и опытных предпринимателей. Дважды в месяц по понедельникам.

Текст: Александр Петров.

Видео по теме:

Waterfall, Agile, Scrum или Kanban — в чем разница?

Waterfall, Agile, Scrum, Kanban, гибкие методологии разработки, таск-трекер

Бэтмен или супермен? Agile или Waterfall? Scrum или Kanban? Три вопроса, о которых люди могут спорить часами. Мы не являемся экспертами в области супергероев, но поможем вам разобраться с базовыми терминами методик управления проектами. В статье расскажем, что скрывается за перечисленными понятиями и какой подход лучше выбрать для своего бизнеса.

Что нужно знать о методологиях разработки

Методология — набор методов и принципов, подкрепленных теорией.

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

Виды разработки продукта

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

Ниже расскажем о плюсах и минусах как Waterfall, так и Agile.

Методология водопада

Схема каскадной модели разработки

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

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

Еще один принцип каскадного метода разработки — подробная документация. Перед началом работы команда обсуждает каждый аспект будущего продукта и фиксирует все важные моменты (от требований к проекту до расставления дедлайнов).

Классическая водопадная модель состоит из 5 этапов:

  1. Сбор требований к продукту и оформление их в техническое задание. На этом этапе подробно прописывают план работы, распределяют роли в команде, закладывают время на проект и риски.
  2. Проектирование. Здесь прописываются функции и фишки продукта, к примеру, логика и архитектура сайта. После под выбранную концепцию подбирают инструменты: язык программирования, методы и т.д.
  3. Разработка. Этап, на котором сотрудники разрабатывают продукт или пишут код в строгом соответствии ТЗ, макетам и требованиями — и ни шагу в сторону. Этот этап занимает большую часть проекта.
  4. Тестирование. Здесь команда проверяет продукт на соответствие ТЗ и баги, чтобы исправить всё до релиза.
  5. Поддержка. Продукт выпускают и поддерживают его работоспособность на рынке. Разработчики собирают обратную связь от клиентов и улучшают продукт, например, добавляя новые функции.

Какие плюсы есть у подхода

Каскадный метод хорошо подходит для крупных проектов, в которых важно точное планирование и четкое следование ТЗ. Например, при строительстве дома нельзя вносить изменения в проект каждую неделю. Чтобы дом не рухнул, нужно следовать изначальному плану. Также Waterfall подойдет проекту, потому что:

  • Естьопределенность в сроках и бюджете. Стоимость продукта и сроки сдачи проекта рассчитаны и утверждены в самом начале и не меняются в процессе.
  • В доступе у сотрудников естьнесколько инструкций и правил по всему процессу — изобретать велосипед не нужно.
  • Waterfall хорошо дисциплинирует сотрудников, благодаря составленному плану, пошаговой последовательности и строгому менеджменту.
  • Гибкость на ранних этапах. Можно легко вносить изменения до этапа разработки.
  • Метод устойчив к обновлению кадров. Благодаря четкому планированию и документации можно быстро погружать новых сотрудников в проект.

Чем плох Waterfall

Каскадный подход может не подойти вашему проекту, потому что:

  • Есть зависимость команд друг от друга. Если одна из команд не успеет выполнить работу к поставленному дедлайну, то это отразится не только на работе их коллег, но и на релизе будущего продукта.
  • Тестирование — один из последних этапов разработки. Ошибку разработчика можно заметить слишком поздно. А откатиться к прошлому этапу для ее исправления сложно и дорого.
  • Чаще всего финальный продукт не ориентирован на клиента и заказчика, т.к. их полностью изолируют от процесса разработки.
  • Низкая вовлеченность в команде. Сотрудники меньше вовлечены в командный проект, потому что каждый работает сугубо над своими задачами, общаясь с коллегами по минимуму.
  • Нет самоуправления. Из-за того, что все работают по оговоренному регламенту и определенным инструкциям, нельзя проявлять инициативу и изменять рабочий процесс.

Методология Agile

Схема разработки продукта по Agile

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

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

Документация не так важна в Agile, как в каскадном подходе. Но это не значит, что «работать по Agile = работать без документов». В таких командах тоже есть документация, но основной упор делается на работающий продукт.

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

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

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

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

Преимущества Agile

Начнем с плюсов. Благодаря Agile-методологии:

  • Команда открыта к изменениям. Из-за гибкости, можно быстро реагировать на изменения и вносить их, чтобы создать полезный продукт для клиента.
  • Снижается вероятность провала, потому что тестирование и сбор обратной связи от заказчика проходят после каждого спринта.
  • Увеличивается вовлеченность команды. Благодаря постоянному взаимодействию сотрудников и отсутствию микроменеджмента, каждый участник видит свое влияние на проект.
  • Сокращается рутинная работа в духе скрупулезного ведения документов, в которых фиксируется каждый шаг. На первом месте всегда будет работающий продукт.
  • Улучшается коммуникация между сотрудниками. Прозрачные рабочие процессы и общение на равных, где ценен каждый голос, — это философия работы всей команды.

Недостатки подхода

Некоторые разработчики не в восторге от Agile, потому что:

  • Нет четкого плана для проекта. Заказчик может вносить новые требования к продукту в ходе разработки, и финальный продукт может сильно отличаться от того, что было запланировано вначале.
  • Нужна постоянная коммуникация. Некоторым сотрудникам комфортнее работать в одиночку и отчитываться перед руководством после завершения проекта. У заказчика же может просто не быть времени, сил или желания постоянно давать комментарии и общаться с командой.
  • Сложное погружение новых сотрудников. Из-за того, что команда работает небольшими итерациями, нового коллегу придется погружать в несколько прошедших периодов — это огромный объем информации.
  • Проделанная работа может пропасть. Согласно Agile, если продукт потеряет ценность для клиента, команда должна изменить цель проекта. В этом случае почти вся проделанная работа может кануть в лету. Этот момент может тяжело даться сотрудникам и «добить» их мотивацию.

Waterfall vs Agile

Выбирайте Waterfall, если

Выбирайте Agile, если

Заказчик знает, чего хочет. И у него есть проработанная концепция, которую точно не нужно менять

Команда готова адаптировать продукт под меняющиеся требования клиента

Разрабатывается сложный продукт, у которого есть четкая последовательность разработки

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

Заказчик планирует отдать ТЗ проекта разработчикам и не хочет участвовать в каждом этапе проекта

Заказчик хочет активно участвовать в жизни проекта: посещать встречи и давать комментарии

Команда уже создавала аналогичный продукт, а значит вся работа поставлена на поток

Сотрудники работают над новым продуктом, из-за чего приходится тестировать новые гипотезы и пробовать новые методы в работе

Что нужно знать об Agile-методиках

Чем Kanban отличается от Scrum

Kanban и Scrum — это методики Agile, они имеют сходства:

  1. Команды Scrum и Kanban — самоорганизованные и кросс-функциональные.
  2. Оба подхода визуализируют работу с помощью досок: виртуальных или реальных.
  3. Обратная связь о проделанной работе очень ценна. С ее помощью сотрудники могут быстро адаптироваться к изменяющимся бизнес-требованиям.
  4. Всем участникам команды нужно работать вместе: обсуждать продукт, решать проблемы и обмениваться опытом.
  5. Благодаря прозрачным рабочим процессам, команды постоянно совершенствуются.
  6. Задачи берутся в работу в зависимости от их приоритета, который определяется ценностью продукта для клиентов и бизнеса.

Scrum

Scrum — фреймворк для Agile-управления проектами. Каждый проект разбивается на небольшие итерации продолжительностью от 1 до 4 недель — спринты. Если спринт уже начат, то в него не должно вноситься изменений — не получится добавить новые задачи в текущий спринт.

Стандартная Agile-команда включает в себя:

  • владельца продукта — посредника между клиентов и командой;
  • скрам-мастера — специалиста, помогающего выстроить коммуникацию на встречах и работать согласно ценностям Agile;
  • команды разработчиков — группы специалистов, отвечающих за реализацию ТЗ.

Для улучшения рабочего процесса, каждый этап спринта сопровождается встречами:

  • планирование,
  • daily-встречи,
  • обзор и тестирование,
  • ретроспективы.

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

Подробнее о Scrum читайте в этой статье.

Kanban

Kanban — это способ управления рабочим процессом, основанный на визуализации целей, задач и прогресса.

Если Scrum-команда разбивает проекты по времени, то команда, которая работает по Kanban-методу, разбивает проекты на этапы рабочего процесса с помощью канбан-доски.

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

  • «В плане»,
  • «В работе»,
  • «Готово».

Каждая рабочая задача — это карточка на доске, которая постепенно перемещается слева направо. К примеру, можно визуализировать на доске ключевые этапы разработки сайта: «В очереди», «Проектирование», «Дизайн», «Верстка», «Тестирование» и «Готово».

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

Итого

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

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

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

Фреймворк Scrum подойдет для проектов и команд, которые:

  • Работают в условиях неопределенности и создают новый продукт, экспериментируя в разработке.
  • Хотят чаще и быстрее выпускать продукт или его новые версии.
  • Заинтересованы в сборе обратной связи от клиентов и хотят постоянно корректировать продукт.
  • Не привязывают запуск продукта к конкретной дате.

Kanban-метод подойдет для команд, которые хотят:

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

Подробнее о двух популярных фреймворках и их преимуществах мы рассказали здесь.

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

Внутри Kaiten есть все необходимые инструменты для работы по Agile, Scrum и Kanban

Похожее

Самостоятельные сотрудники, управление, команда, таск-трекер, Kaiten, как управлять сотрудниками

Управление

Как сделать сотрудников более самостоятельными — советы от HR-эксперта

Конкретные шаги, следуя которым можно развить самостоятельность подчиненных

Irina Filyakina 1 февр. 2024 г. • 5 min read

Что такое Discovery, что такое Delivery, разработка, продукт, таск-трекер, Kaiten

Управление

Discovery и Delivery: когда исследования бесценны. Конспект подкаста Kanban Talks

Рассказываем, что такое Discovery и Delivery в современных компаниях и как их выстраивание помогает улучшать процесс создания продуктов

Алекс Цыбульник 31 янв. 2024 г. • 8 min read

Кто такой project manager, кто такой проджакт менеджер, сколько зарабатывает менеджер прожукта, требования проекта

Управление

Искусство управления проектами: роль и задачи project manager

Рассказали о всех задачах менеджера проектов и собрали мнения специалистов

Дарья Литвинова 26 янв. 2024 г. • 8 min read

Новое

Ошибки при использовании Канбан-метода, Kanban, Kaiten, таск-трекер, Agile, как работать по Канбан

Что в Канбан-методе понимают неправильно

Рассказываем, какие ошибки допускают при внедрении Канбан-метода в рабочие процессы и как их избежать

Дарья Литвинова 5 февр. 2024 г. • 7 min read

Самостоятельные сотрудники, управление, команда, таск-трекер, Kaiten, как управлять сотрудниками

Как сделать сотрудников более самостоятельными — советы от HR-эксперта

Конкретные шаги, следуя которым можно развить самостоятельность подчиненных

Irina Filyakina 1 февр. 2024 г. • 5 min read

Что такое Discovery, что такое Delivery, разработка, продукт, таск-трекер, Kaiten

Discovery и Delivery: когда исследования бесценны. Конспект подкаста Kanban Talks

Рассказываем, что такое Discovery и Delivery в современных компаниях и как их выстраивание помогает улучшать процесс создания продуктов

Чем отличается scrum от agile

МЕРОПРИЯТИЯ

Cinimex DATA meetup

15 февраля Санкт-Петербург Онлайн Бесплатно

Data Fusion Contest 2024

15 февраля Онлайн Бесплатно

Комментарии

Популярные По порядку
Не удалось загрузить комментарии.

ЛУЧШИЕ СТАТЬИ ПО ТЕМЕ

�� ТОП-14 российских аналогов Jira и систем управления проектов

Компания Atlassian заявила об уходе с российского рынка, поэтому мы отобрали российские аналоги сервиса Jira и рассмотрели их с точки зрения функциональности и цены.

Бесплатные книги по управлению проектами для новичков и профи

Подборка бесплатных книг по управлению проектами в разных сферах деятельности. Учебники для новичков, пособия для профессионалов и мировые шедевры.

Как найти ментора в IT-сфере и откуда начать поиски?

Тысячи курсов, видео и интерактивных сайтов, с которыми можно освоить программирование. Но найти ментора – задача обязательная.

Agile, Scrum и Kanban: в чем суть и как это работает

Agile, Scrum, Kanban – в последние годы эти термины переживают пик популярности, (по крайней мере в украинском социуме). Все больше людей стало интересоваться гибкими методологиями управления проектами и их особенностями. И это неудивительно, ведь по ним можно эффективно работать в любой отрасли, но особенно хорошо они подходят для ИТ. Но в чем суть каждой? И чтобы вы не путались в терминах, давайте разберемся как их успешно использовать.

Определение

Scrum и Kanban — это гибкие методологии создания продукта. По ним можно работать в любой отрасли, но особенно хорошо они подходят для ИТ. В основе обеих методологий лежат принципы Agile. Сам Agile (agile software development, от англ. agile – проворный) – это семейство «гибких» подходов к разработке программного обеспечения. Такие подходы также иногда называют фреймворками или agile-методологиями.

Смысл Agile сформулирован в Agile-манифесте разработки ПО: «Люди и взаимодействие важнее процессов и инструментов. Работающий продукт важнее исчерпывающей документации. Сотрудничество с заказчиком важнее согласования условий контракта. Готовность к изменениям важнее следования первоначальному плану».

К отдельным agile-подходам относятся scrum и kanban.

Scrum – это «подход структуры». Над каждым проектом работает универсальная команда специалистов, к которой присоединяется еще два человека: владелец продукта и scrum-мастер. Первый соединяет команду с заказчиком и следит за развитием проекта (это не формальный руководитель команды, а скорее куратор). Второй помогает первому организовать бизнес-процесс: проводит общие собрания, решает бытовые проблемы, мотивирует команду и следит за соблюдением scrum-подхода.

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

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

Вся команда едина – в kanban нет ролей владельца продукта и scrum-мастера. Бизнес-процесс делится не на универсальные спринты, а на стадии выполнения конкретных задач: «Планируется», «Разрабатывается», «Тестируется», «Завершено» и др.

Главный показатель эффективности в kanban – это среднее время прохождения задачи по доске. Задача прошла быстро – команда работала продуктивно и слаженно. Задача затянулась – надо думать, на каком этапе и почему возникли задержки и чью работу надо оптимизировать.

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

В чем разница между Scrum и Kanban?

Основу Scrum составляют короткие спринты, как правило, 2-3-х недельные. Перед началом спринта команда сама формирует список задач на итерацию, далее запускается спринт.

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

На Kanban дает больше гибкости, если под гибкостью понимать частоту смены приоритетов. Если вчера разработчик залил выполненную задачу, а сегодня получили данные с “передовой” и узнали, что вот эта штука не работает так, как было задумано, то дают новые требования. Дополненные новые задачи поднимаются вверх и программист берет эту задачу «сверху», выполняет ее и, к вечеру все работает как надо. Все счастливы и эффективны как никогда.

В Scrum задачи принято оценивать в Story points или в часах. Без оценки не получится сформировать спринт: ведь нам нужно знать, успеем ли мы сделать задачи за 2 недели. Через 2 недели мы получаем ценную статистику — сколько часов или Story points команда смогла сделать за спринт. Velocity — это производительность команды за один спринт. Этот параметр позволяет Scrum менеджеру предсказать, где команда будет через 2 недели.

В Kanban не принято делать оценку. Это опционально, команда решает сама. Здесь нет понятия «скорость работы команды», считается только среднее время на задачу. Время это считается с помощью специального отчета — Cycle Time.

Cycle Time для задачи = время выполнения задачи минус время начала работы над задачей. Например, у вас есть колонки: to do, reopened, developing, testing, stage testing, deployed. Cycle time для задачи будет равен deployed-developing, то есть сколько времени прошло от момента, когда задачу начали делать до момента пока она попала в deployed.
Итак, в Scrum наша цель — закончить спринт, в Kanban — задачу.

Или, если хотите проще: Scrum — это автобус, который останавливается лишь на определенных остановках, где люди выходят группами. А Kanban — это маршрутка: захотел пассажир выйти, попросил водителя и вышел там, где ему нужно.

Scrum и Kanban на практике

В чистом виде отдельные методы встречаются редко. Чаще всего компании сочетают те части гибких систем, которые им больше всего подходят. К примеру, для продуктовой разработки больше подойдет Scrum. Для начальных этапов, таких как исследование или тестирование гипотез, – Kanban. С точки зрения других подразделений, используется облегченный вариант Kanban: для координации ежедневных задач, синхронизации, и уверенного пути вперед!

Scrum является очень удобным инструментом планирования. Он дает некую гибкость в непосредственном улучшении продукта. К примеру, во многих ИТ-компаниях, его используют раз в две недели для планирования самой разработки. Это помогает не тратить два-три месяца на решение проблемы, а запускать MVP (Minimal Viable Product, минимальный жизнеспособный продукт) и оперативно его дорабатывать после получения обратной связи от пользователей. Kanban,в свою очередь, отлично подходит для мониторинга хода выполнения работ. Ведь его ключевая задача — обеспечить процесс и ход разработки.

Что выбрать — Scrum или Kanban

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *