Waterfall (Водопад). Agile. Канбан. Scrum. Какое отношение эти слова имеют к управлению проектами, в чём их различия и как выбрать методологию, подходящую для вашей команды?
Если вы не уверены в значении какого-либо из этих терминов, мы вам поможем. В этой статье мы подробно рассмотрим, что означает каждый из этих терминов, каковы их преимущества и недостатки, а также в чём их отличия, в том числе между Agile и Scrum, а также между Scrum и Канбаном.
Если вы хотите получить ответ на конкретный вопрос, воспользуйтесь ссылками слева, чтобы перейти к нужному заголовку. Или оставайтесь с нами, чтобы ознакомиться с исчерпывающим руководством, в котором даются ответы на все ваши вопросы о методологиях Waterfall, Agile, Канбан и Scrum.
Канбан — это ветвь методологии Agile, которая функционирует в рамках более широкой философии Agile. Философия Agile строится на адаптивном планировании, ранних поставках и непрерывном улучшении — и всё это может поддерживать канбан.
Сравнивая Kanban и Scrum, важно отметить, что обе эти методологии являются фреймворками Agile, но подходят к работе по-разному.
Когда речь заходит о Канбане в управлении проектами, чаще всего имеют в виду канбан-доски. Канбан-доска представляет собой этапы работы с колонками, в которых содержатся отдельные элементы работы для каждого этапа, но об этом мы поговорим чуть позже.
Фреймворк Канбан очень гибкий и со временем может помочь командам стать более динамичными и гибкими. Хотя сравнение Kanban и Scrum является распространённым, гибкость Kanban отличает его во многих рабочих процессах.
Бесплатный шаблон канбан-доскиФреймворк Канбан был разработан Тайити Оно в компании «Тойота» в 1940-х годах и на протяжении нескольких десятилетий оцифровывался, адаптировался и совершенствовался. В своей основе современный фреймворк Канбан — это визуальный способ онлайн-управления работой.
Когда люди говорят «Канбан», они, скорее всего, имеют в виду канбан-доски: визуальное представление управления проектами, в котором используется методология Канбан.
На канбан-доске столбцы отображают различные этапы работы. В каждой колонке находятся карточки, представляющие собой отдельные задачи и указывающие, на каком этапе они находятся. Обычно это этапы «нужно сделать», «в процессе» и «выполнено».
Канбан-доски — одна из наиболее популярных форм визуального управления проектами. Они наиболее эффективны для быстрого получения представления о потоке работы в проекте.
Читать: 3 макета для визуального управления проектами (и как их использовать)Команды, работающие по методу Канбан, устраняют узкие места и задержки, чтобы сократить время выполнения работ. Для начала они используют диаграмму кумулятивного потока (CFD), чтобы определить, где накапливается работа. Выявив эти узкие места, они устанавливают лимиты незавершённой работы (WIP). Эти ограничения WIP ограничивают количество элементов работы на каждом этапе, что предотвращает перегрузку и повышает производительность.
Используя канбан-доски для визуального управления проектами, вы предоставляете команде возможность быстро просматривать информацию, включая, помимо прочего:
Задачи или ожидаемые результаты
Исполнитель задачи
Даты сдачи и сроки выполнения
Важные теги, например, приоритет или тип задачи
Сведения о задаче
Контекст
Соответствующие файлы
Канбан-доски — это гибкий способ визуального представления работы команды. Традиционно на канбан-доске используются столбцы, отражающие этапы работы, поэтому этот способ визуализации управления проектами популярен у команд, которые занимаются повторяющейся работой и проектами, например реализацией творческих запросов или отслеживанием ошибок.
Вы также можете настраивать столбцы канбан-доски в зависимости от исполнителей задач, добавлять «дорожки» или создавать столбцы по датам сдачи.
С учётом их высокой эффективности для визуализации работы, канбан-доски являются ключевым компонентом большинства инструментов для управления проектами. Если вы хотите выбрать правильный инструмент для управления проектами для своей команды, убедитесь в том, что в нём можно просматривать информацию в виде Канбан-досок. А ещё лучше — найти инструмент, позволяющий просматривать работу несколькими способами. Например, в Asana вид «Доски» (или Канбан) — это один из четырёх способов просматривать работу, в дополнение к видам «Хронология», «Календарь» и «Список».
Читать о четырёх способах визуализации работы в AsanaScrum — это один из самых популярных фреймворков Agile. В отличие от системы Kanban, которая обычно используется как инструмент для визуализации работы, Scrum — это полноценный фреймворк, позволяющий «управлять командами». Этот фреймворк был впервые предложен Тайити Оно и предлагает общий подход к ценностям, руководствам и ролям, чтобы помочь вашей команде сосредоточиться на постоянном улучшении и повторяющейся работе.
При сравнении Kanban и Scrum важно отметить, что в Scrum более чётко определены роли и структурированы итерации. Она намного менее гибкая, чем kanban, но является отличным способом для Agile-команд взаимодействовать и выполнять важную работу.
Хотя изначально Scrum был создан для команд разработчиков программного обеспечения, сегодня его используют и в других сферах, например, в разработке продуктов, инжиниринге и т. д., чтобы выполнять работу быстрее и эффективнее.
Для ведения Scrum-процесса в команде обычно выбирается Scrum-мастер, отвечающий за три этапа, из которых этот процесс состоит, а также за то, чтобы все были в курсе происходящего. Scrum-мастером может быть руководитель команды, менеджер проекта, ответственный за продукт или человек, наиболее заинтересованный в использовании Scrum.
Мастер Scrum отвечает за проведение трёх традиционных этапов Scrum:
Этап 1. Планирование спринта. Спринт по Scrum обычно длится две недели, но можно выбрать любую другую продолжительность. На этапе планирования спринта Scrum-мастер и команда анализируют продуктовый бэклог команды и выбирают задачи, над которыми будут работать во время спринта.
Этап 2. Ежедневные стендапы. Во время этапа по Scrum (или производственного цикла) команды обычно собираются на ежедневные 15-минутные встречи, чтобы рассказать о ходе работы и убедиться в том, что она правильно распределена.
Этап 3. Ретроспектива спринта. По завершении цикла Scrum-мастер проводит встречу-ретроспективу, чтобы оценить проделанную работу, перенести невыполненные задачи в бэклог и подготовиться к следующему спринту.
Цель Scrum не состоит в том, чтобы создать что-то за две недели, передать это заказчику и больше никогда об этом не вспоминать. Речь скорее идёт о постоянном улучшении, когда команды предпринимают небольшие шаги для достижения более крупных целей. Разбивая работу на мелкие куски и работая над ними, Scrum помогает командам эффективнее расставлять приоритеты и достигать результатов.
В командах, использующих Scrum, чётко определены правила, показатели и обязанности.
Ежедневные стендапы, планирование и обзор спринта (или «ретроспектива») помогают командам постоянно быть на связи и улучшать текущие процессы.
Так как цикл Scrum начинается с просмотра незавершённой работы, этот метод отличается наличием простой, самоорганизующейся структуры, согласно которой руководители команд и ответственные за продукты могут поддерживать наиболее важную работу команды и управлять ею.
Во время цикла Scrum у команд есть определённое заранее и ограниченное количество работы и времени на каждый спринт. Этот уровень стандартных приоритетов дополняется чётко определёнными обязанностями, благодаря чему каждый всегда знает, за что он отвечает.
Наконец, ключевое отличие между Kanban и Scrum заключается в том, что последний обеспечивает выполнение работы фиксированными этапами в рамках спринтов, в то время как Kanban делает упор на непрерывный поток, ограничивая объём работы в процессе и оптимизируя процесс.
Управление проектами по методу Agile — это итеративная методология, в рамках которой работа выполняется в виде коротких спринтов. Благодаря приоритету гибкого подхода и непрерывной поставки результатов методология Agile более адаптивна к неожиданным изменениям в проекте, однако в результате она может страдать от разрастания объёма.
Методология Agile была разработана в противовес традиционному управлению проектами по каскадной модели. По мере того как в начале 2000-х годов разработка программного обеспечения становилась всё более распространенной, разработчикам потребовался итеративный подход к созданию прототипов и управлению проектами — так появилась методология Agile для разработки программного обеспечения.
С тех пор Манифест Agile стал основным источником информации о ценностях и принципах Agile для всех, кто хочет внедрить эту методологию. Методология Agile больше не используется исключительно в разработке программного обеспечения. Среди прочего, эту методологию адаптировали и модифицировали под свои отрасли специалисты в области маркетинга, ИТ, планирования событий и разработки продуктов.
Создайте шаблон плана Agile-проектаУправление проектами по системе Agile включает в себя итеративное управление бэклогами, спринты, анализ, итерации и ещё больше спринтов. Каждый Agile-спринт обычно длится от двух до четырёх недель.
Каждый спринт проходит следующие этапы:
Сначала ответственный за продукт организует продуктовый бэклог. Продуктовый бэклог — это список всех задач, над которыми можно работать во время спринта. Эта информация обычно хранится в инструменте для управления проектами.
Перед началом спринта вся команда проекта участвует в планировании спринта, чтобы определить наиболее подходящие задачи для работы в течение двух недель.
Во время спринта Agile-команды часто собираются, чтобы обсудить препятствия и задачи.
По окончании спринта участники команды собираются вместе, чтобы провести ретроспективу спринта и определить, что прошло хорошо, а что могло бы быть лучше.
Читать: Руководство по методологиям Agile для начинающихКаскадная модель делит каждый проект на различные этапы и проходит их в последовательном порядке. Ни один этап не может начаться до тех пор, пока не будет завершён предыдущий. Обычно каждая стадия завершается важным этапом проекта, который указывает на то, что можно приступать к следующей стадии.
Конкретные этапы процесса «водопада» зависят от того, что именно создаёт ваша команда, но обычно они выглядят примерно так:
Этап определения требований, иногда разделяемый на дополнительный этап анализа
Этап проектирования системы
Этап реализации, также известный как этап разработки или этап написания кода (в зависимости от типа проекта)
Этап тестирования
Этап развертывания, также известный как этап эксплуатации
Этап обслуживания
Каскадная методология получила своё название из-за того, как выглядит схема процесса. Подобно природному водопаду, проекты выглядят так, будто перетекают каскадом от одного этапа к другому.
Применение этой методологии управления проектами требует тщательного предварительного планирования и подготовки. Важной частью управления проектами по методу Waterfall является создание чёткого плана проекта, чтобы ваша команда ясно понимала требования и ограничения проекта ещё до начала работы. Это объясняется тем, что, как только проект по методу Waterfall приводится в действие, остаётся мало места для изменений, адаптации или ошибок.
При тщательном планировании вы сможете успешно создать конечный продукт с помощью чётких и предсказуемых рабочих процессов. Эта методология управления проектами отлично подходит для управления временем и отслеживания прогресса, хотя она менее гибкая, чем другие модели, например Agile.
Мы рассмотрели все тонкости и нюансы отдельных методологий и фреймворков. Теперь давайте сравним их друг с другом, чтобы выяснить, какую из них следует внедрить, чтобы помочь вашей команде достичь своих целей.
Канбан и Scrum — это две методологии, которые чаще всего называют Agile-методологиями. И Канбан, и Scrum позволяют командам постоянно улучшать процессы.
Одни из ключевых положений методологии Agile — гибкость и постоянное совершенствование. Именно поэтому разработчиков продуктов, инженеров и программистов так привлекает философия Agile. Постоянное совершенствование — важная часть и Канбан, и Scrum.
И Kanban, и Scrum — отличные инструменты для совместной работы в команде. Несмотря на то, что совместная работа может выглядеть по-разному в зависимости от выбранного фреймворка, и Kanban, и Scrum помогут улучшить сотрудничество.
Несмотря на то, что у этих двух методологий есть кое-что общее, между Kanban и Scrum существует несколько существенных различий. Давайте рассмотрим их подробнее!
Scrum имеет более чёткую структуру, чем Канбан. Scrum включает конкретный набор «правил», которым должны следовать команды. Канбан обычно используется для визуализации работы. Многие команды действительно работают по Scrum на Канбан-доске, но в этих случаях они используют Scrum, а не Канбан. Канбан — это не методология, а только способ визуализации работы.
Scrum имеет чёткие временные рамки, а канбан — гибкий. Scrum состоит из спринтов, то есть, как правило, двухнедельных рабочих циклов. В конце спринта у вас будет набор завершённой работы, какой бы она ни была. У канбан-досок нет обязательной даты начала или окончания. Наоборот, в Asana мы часто используем канбан-доски для представления постоянных процессов.
Столбцы на канбан-досках можно систематизировать по-разному. Когда вы работаете в рамках спринта по Scrum, важно отслеживать работу по мере её продвижения по этапам. Но на канбан-доске, не основанной на методе Scrum, колонки могут представлять собой не только статус работы. Столбцы могут отображать задачи, которые будут выполняться в течение каждого месяца, ретроспективу, в которой отражена уже выполненная работа, или что-то ещё, что вам нужно, — в отличие от Scrum, где «правила» более чётко определены.
При сравнении Kanban и Scrum с точки зрения командного взаимодействия различия в подходах могут существенно повлиять на то, как участники команды общаются и работают вместе. В Scrum используется структурированный подход с чётко определёнными ролями, такими как Scrum-мастер и владелец продукта. Этот фреймворк улучшает совместную работу внутри Scrum-команды благодаря регулярным мероприятиям, таким как планирование спринтов, ежедневные стендапы и ретроспективы спринтов.
С другой стороны, Канбан фокусируется на визуализации рабочих процессов с помощью канбан-доски, что естественным образом обеспечивает прозрачность и способствует постоянному взаимодействию. Канбан-команды могут легко выявлять узкие места и помогать коллегам, что способствует непрерывному потоку работы. Хотя в Канбан нет официально определённых ролей, он формирует культуру коллективной ответственности и решения проблем в режиме реального времени.
При сравнении Kanban и Scrum с точки зрения гибкости Kanban обычно обеспечивает большую адаптивность, чем Scrum. Модель непрерывного потока системы Канбан позволяет постоянно корректировать приоритеты и загрузку. Команды могут в любое время добавлять, удалять или менять приоритеты элементов работы на канбан-доске, не нарушая общий рабочий процесс.
Хотя Scrum также является гибким подходом, он работает на основе итераций фиксированной продолжительности, называемых спринтами. Такой подход с фиксированными временными рамками иногда может ограничивать возможность быстро переориентироваться или включить новую работу в середине спринта. Тем не менее Scrum обеспечивает гибкость за счёт планирования спринтов и уточнения бэклога, что помогает командам корректировать свои приоритеты для каждого нового спринта.
Не существует чётких правил, определяющих, когда вашей команде следует использовать Канбан, Scrum или другой способ визуального управления проектами. Но вот несколько признаков того, что вам подойдёт Канбан:
Вашей команде нужна система визуального управления проектами.
Вам нужно быстро понимать, на какой стадии находится проект.
Вы не инженер, разработчик продуктов и не программист.
У вас в ходу постоянные процессы и проекты.
Большая часть вашей работы не выполняется за короткое время.
Даже если вы не будете пользоваться фреймворком Scrum, вы можете найти в нём что-то полезное для себя. Например, возможно, вы не хотите разбивать работу на двухнедельные спринты, но ведение списка невыполненных работ поможет вашей команде лучше понимать задачи и определять их приоритет. Самое привлекательное в Канбан то, что можно использовать только те части методологии, которые вам подходят, не обращая внимания на всё остальное.
Scrum может стать отличным методом организации рабочих процессов и определения приоритетов в их рамках. Scrum подходит не каждой команде, но эта методология будет вам полезна, если:
Вы инженер, разработчик продуктов или программист, либо входите в состав Agile-команды.
Вы считаете, что вашей команде пойдёт на пользу более жесткая структура.
У вас большой бэклог, с которым нужно разобраться.
Вашу команду мотивируют сжатые дедлайны и быстрые результаты.
Кто-то в вашей команде готов быть скрам-мастером.
Помните: при сравнении Канбан и Scrum вы всегда можете объединить эти две методологии, ведя управление работой по Scrum на канбан-доске.
Когда речь идёт о сравнении Agile и Waterfall, анализ преимуществ и недостатков каждой из этих методологий, скорее всего, облегчит вам выбор той, которая лучше всего подходит вашей команде. Давайте рассмотрим их подробнее.
Каскадная методология управления проектами более эффективна для межфункциональных проектов. Одними из главных преимуществ методологии Waterfall являются следующие возможности:
Планировать проекты заранее, чтобы предотвратить разрастание объёма.
Легко отслеживать ход выполнения на разных этапах проекта.
Работать над несколькими проектами, не посвящая себя полностью одной инициативе.
С лёгкостью управлять зависимостями.
Однако у методологии Waterfall есть и несколько недостатков, о которых важно помнить:
Может привести к повышению рисков проекта из-за недостаточной гибкости.
Может привести к потере информации, если на разных этапах над проектом работают разные люди и не ведут чёткую документацию.
Может привести к неожиданным ошибкам, если контроль качества проводится слишком поздно.
Может привести к снижению удовлетворённости клиентов при отсутствии их участия.
Методология Agile популярна не просто так — вот некоторые из самых значительных преимуществ для команд, использующих Agile. Они…
Быстро адаптируются к неожиданным изменениям
Сосредоточены на удовлетворённости клиентов
Испытывают высокую внутреннюю мотивацию благодаря акценту на командной работе и вовлечённости участников команды
При всей этой гибкости у Agile-команд есть несколько недостатков, с которыми им приходится сталкиваться:
Могут неожиданно привести к разрастанию объёма и увеличению бюджета проекта
Может быть сложно взаимодействовать с клиентами, если у них нет времени или возможностей
Сосредоточенность исключительно на процессе спринта Agile не позволяет участникам команды работать над другими инициативами
Виртуальным командам может быть сложно успешно работать в условиях Agile
Хотя большинство команд могут в той или иной степени извлечь пользу из любой из этих методологий, вот простое сравнение Agile и Waterfall, которое поможет вам решить, какая методология подходит вам лучше всего:
Используйте методологию Waterfall, если…
Вы работаете над последовательным проектом, и ни один этап не может начаться, пока не будет завершён предыдущий.
Вы хотите жёстко контролировать разрастание объёма.
Вы цените чёткое и эффективное планирование.
Вы хотите понять весь жизненный цикл разработки до начала проекта.
Вы цените функциональность больше, чем быстрое выполнение.
Попробуйте подход Agile, если…
Вы хотите использовать более итеративный процесс.
Вы хотите быстро получать результаты, даже если это означает, что их придётся улучшать позднее.
Ваша команда работает быстро.
Ваша команда ценит адаптивность больше, чем предсказуемость.
Ваши клиенты хотят быть активными заинтересованными лицами.
Если вы выбрали методологию Agile, следующим шагом, скорее всего, будет решение вопроса о том, подходит ли Scrum для управления вашей командой.
Когда речь заходит об Agile и Scrum, вопрос не в том, что выбрать, а скорее в том, хотите ли вы сделать Scrum своим предпочтительным фреймворком Agile.
Безусловно! Scrum, возможно, является самым распространённым фреймворком Agile, но вы всё равно можете использовать методологию Agile, не придерживаясь правил Scrum.
Agile может существовать сам по себе. Однако без мастера Scrum, ежедневных стендапов и спринтов, проводимых раз в две недели, есть несколько лучших практик, которые следует учитывать, чтобы обеспечить бесперебойный рабочий процесс:
Делайте проекты небольшими. Без правил Scrum будет намного проще управлять небольшим проектом с небольшой командой, которая работает над достижением небольшой цели.
Назначьте ответственного за разработку продукта. В отсутствие скрам-мастера вам нужно будет назначить сотрудника, который будет следить за требованиями проекта и потребностями в ресурсах. Этот участник команды будет контактным лицом по вопросам, касающимся рабочего процесса, изменений в проекте и распределения ресурсов.
Проводите регулярные совещания. Если у вас небольшая команда и небольшая общая цель проекта, еженедельных совещаний должно быть достаточно, чтобы настроить вас на успех. Воспользуйтесь возможностью проверить ход выполнения проекта и обсудить цели каждого участника на предстоящую неделю, чтобы поддерживать высокий моральный дух и вовлечённость вашей команды.
Планируйте частые проверки. Подобно тому, как вы собираетесь, чтобы обсудить еженедельные цели, вашей Agile-команде также будут полезны регулярные проверки качества. Эти проверки могут выявить детали проекта, требующие большего внимания, и обеспечить высокое общее качество вашего проекта.
Понимание различий между Agile и Scrum поможет вам адаптировать свой подход к потребностям вашей команды и требованиям проекта.
Всё ещё не можете выбрать между Kanban и Scrum? Возможно, вам подойдёт Scrumban.
Чтобы проводить эффективные ежедневные стендапы, планирование и ретроспективы спринтов, вам нужен надёжный способ визуализации выполняемых задач по этапам и отслеживания всей работы, находящейся в процессе. Канбан-доски могут помочь вам справиться с бэ\-логом спринта и организовать поток работы во время спринта, чтобы каждый цикл Scrum был успешным.
Команды, работающие по Scrum на канбан-досках (или на Scrum-досках, как их ещё называют), часто создают новую доску для каждого спринта. Так происходит по двум причинам:
Команды, которые создают новые доски для каждого спринта, могут начинать с чистого листа. Так скрам-мастеру и всей команде проще визуализировать работу, которая должна быть выполнена в каждом спринте.
Скрам-мастера используют предыдущие доски, чтобы видеть работу, выполненную за каждый цикл. Так как одной из важных причин использовать Scrum является стремление к улучшению процессов и повышению эффективности, просматривать предыдущие достижения бывает полезно.
Как видите, всё сводится к поиску комбинации методологий, фреймворков и инструментов, которые подходят вашей команде и проекту.
Создать шаблон ScrumbanНезависимо от того, внедряете ли вы подход Waterfall или Agile, выбираете между Kanban и Scrum или используете канбан-доски, обязательно отслеживайте свою работу в едином централизованном инструменте.
Когда у участников команды есть чёткое представление о том, кто какую работу выполняет и к какому сроку, они могут точнее планировать свою работу и достигать поставленных целей.
Если вы готовы приступить к работе, попробуйте Asana. Asana — это инструмент для управления работой, который помогает вашей команде организовывать работу, отслеживать процессы и достигать поставленных целей.
Попробовать Asana для управления работойВ чём разница между Scrum и Канбан?
Ключевое отличие Scrum от Канбана заключается в подходе к управлению работой. В Scrum используются итерации с фиксированной продолжительностью, называемые спринтами, с определённым бэклогом и конкретными ролями, такими как Scrum-мастер и владелец продукта. Канбан ориентирован на непрерывный поток и использует канбан-доску для визуализации работы в процессе, ограничения объёма незавершённой работы (WIP) и оптимизации длительности цикла.
Как выбрать между Kanban и Scrum для своей команды?
Чтобы выбрать между Kanban и Scrum для своей команды, проанализируйте рабочий процесс команды и требования проекта. Используйте Scrum, если вашей команде подходят структурированные роли, регулярное планирование спринтов и чёткие временные рамки. Выбирайте Канбан, если вашей команде нужны гибкость, непрерывная сдача результатов и возможность адаптации в режиме реального времени без фиксированных спринтов.
Канбан — это всё-таки Scrum?
Канбан — это не Scrum. Хотя обе эти системы являются методологиями Agile, Канбан ориентирован на непрерывный поток и визуализацию работы, а Scrum — на спринты с чёткими временными рамками и определённые роли.
Могут ли в Канбане быть спринты?
В Kanban обычно не используются спринты. Однако некоторые команды сочетают Канбан со Scrum, что называется Scrumban, чтобы включать спринты для конкретного планирования, сохраняя при этом непрерывный поток работы.