Kanban scrum – Что такое agile, scrum, kanban и в чем разница?
Что такое agile, scrum, kanban и в чем разница?
Если раньше офисы модно было обустраивать «по фэн-шую», то теперь — исключительно «по эджайлу». Agile – это не только цветные стикеры, на которых удобно отмечать ход работы (стикеры, скорее, стоит относить конкретно к подходу kanban). А ведь есть еще и scrum – он тут при чем?
Специально для тех, кто запутался в терминах, мы кратко разобрали эти понятия и спросили экспертов, зачем компании переходить на новую систему.
Рубрика «Инновации в корпорациях» выходит при поддержке Spinon.
Определение
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 – повысить гибкость производства, лучше приспосабливаться к изменяющимся требованиям рынка. На практике метод помог нам добиться соответствия между складскими запасами и реально используемыми в производстве продуктами.
Виталий СотниковКреативный директор Бюро визуальных коммуникаций «Черника»
Важный момент: agile-методология – это общее направление, а kanban и scrum – уже ее разновидности.
Мы используем связку scrum + waterfall, а также дорабатывали в течение года саму agile-доску. Главная причина использования: прозрачность и простота. По сути ,это получается тот же самый конвейер Генри Форда: переход задачи от статуса к статусу со сменой исполнителя, поэтому основным принципом к самой agile-доске является уже простота.
Мы используем agile как непосредственную часть нашего workflow, поэтому все проекты, от брендинга и разработки сайтов и вплоть до нашего стартапа по AI и нативной рекламе NativeOS, в бюро Chernika ведутся как раз по данному workflow.
Работающий продукт важнее подробно прописанной документации. Это не говорит о том, что мы не ведем никакую документацию, нет. Это скорее взгляд в сторону эффективности с ударом по излишней бюрократии.
Илья Шихалеев
Scrum принес в нашу команду ритмичность и понимание — успеваем или не успеваем в срок. Мы видим скорость работы команды, нет ощущения постоянного факапа. Раньше были ситуации, что перед жесткими релизами scrum куда-то пропадал и все начинали просто фигачить — сейчас у нас это пропало, есть постоянное ощущение, что успеваем в срок. Если появляются риски, мы обсуждаем их с PD на ранних этапах, корректируем план или уменьшаем объем задач каким-то образом.
Работа стала прозрачнее, рабочий день стал укладываться в 8-часовую норму и, по ощущениям, мы стали успевать больше. Мы понимаем, что когда у тебя есть ощущение, что ты не успеваешь, чувствуешь, что надо работать больше — это очень плохо влияет на продуктивность, от этого надо избавляться.
Евгений Россинский Директор по технологии в онлайн-кинотеатре iviДля наглядности и открытости работы отдела разработки мы повесили специальную доску с пометками “to do”, “in progress”, ”review”, ”test”, “done”, где все члены команды наклеивают стикеры с задачами (в колонке “to do”), а по мере их выполнения перемещают в последующие пункты. И счастливый финал – конечный пункт “done”. Это помогает составить общую картину и дает возможность видеть, над чем работает каждый участник.
Очень важный момент метода (и организации рабочего процесса): после утверждения всех задач (“to do”), список блокируется на внесение. Так новые поступающие задачи не отвлекают от процесса и не тормозят работу.
Все участники также оценивают каждую задачу на предмет временных и материальных затрат, которые потребуются на выполнение. И вишенка на торте – еженедельные встречи в определенное время (Daily Scrum), где каждый член команды коротко рассказывает о том, что собирается сделать сегодня, что сделал вчера (и столкнулся ли с какими-то препятствиями). Это важно на пути к долгосрочным задачам – именно так можно вовремя понять, что пора сменить стратегию.
Ирина Черепанова
Scrum мы внедрили с двух попыток, потому что всем, от команды до пользователей, хочется иметь более прогнозируемый результат. В этом плюс методологии – четкие ритмы упорядочивают коллектив, повышают общий уровень знаний о проекте. Как следствие, результат становится более прогнозируемым, в том числе для наших «стейкхолдеров» – пользователей.
Командная работа также повышает ответственность: все получают бонус, только если команда выполнила поставленные на определенном этапе задачи.
Инга Корягина
Agile – это философия, scrum – структура, waterfall – метод, kanban – система управления. Scrum и kanban – варианты agile, но у них есть некоторые явные различия. Методика scrum требует фиксированных ролей, тогда как у kanban нет необходимых ролей. Scrum основана на итерациях, объединяющих планирование, оптимизацию процессов и выпуск. В kanban это можно делать регулярно или каждый раз, когда вам нужно. Команда scrum требует оценки своей работы, тогда как команде kanban это не нужно.
Что почитать по теме?
- Agile-манифест разработки программного обеспечения (Manifesto for Agile Software Development)
- Дж. Сазерленд «Scrum. Революционный метод управления проектами»
- Д. Андерсон «Канбан. Альтернативный путь в Agile»
- Э. Стелманн, Дж. Грин «Постигая Agile. Ценности, принципы, методологии»
- K. Schwaber, J. Sutherland “The Scrum Guide”
- M. Cohn “Agile estimating and planning”
Текст: Александр Петров.
Cover photo by Daria Nepriakhina on Unsplash
Актуальные материалы — в Telegram-канале @Rusbase
Нашли опечатку? Выделите текст и нажмите Ctrl + Enter
rb.ru
Использование Waterfall, Scrum и Kanban на примере одного кейса
В предыдущих статьях мы рассказали о возможных подходах к проектированию жизненного цикла ПО: Waterfall, Scrum и Kanban. У каждого из них есть свои особенности, которые стоит учитывать, выбирая ту или иную методологию для управления вашим проектом. Однако, в реальных проектах для достижения наилучшего результата различные методологии могут использоваться совместно. Для того, чтобы понять, каким образом можно совместить разные подходы, давайте обратим внимание на их отличительные черты, а затем рассмотрим, как эти подходы применялись при работе над реальным проектом.
Основные особенности Waterfall
Начнем с краткого обзора особенностей Waterfall. Эта модель разработки ПО стоит особняком от двух других, рассматриваемых в этой статье. В отличие от Scrum и Kanban, Waterfall не является итеративной моделью. На практике это означает, что каждый этап проекта выполняется только единожды. Проект реализуется пошагово в соответствии с заранее определенной последовательностью действий. Вот типичная последовательность фаз разработки, характерная для каскадной модели:
1. Анализ требований
2. Проектирование
3. Разработка
4. Тестирование и отладка
5. Инсталляция
6. Поддержка
В реальных проектах эти фазы могут отличаться от приведенного выше списка, но в целом они должны соответствовать этим ключевым этапам.
Каскадной модели присущи свои недостатки. Так, например, если на одном из ранних этапов будет допущена ошибка, вероятнее всего, обнаружить ее удастся только на этапе разработки или тестирования. Таким образом, рекомендуется применять данную модель только в том случае, если все требования, предъявляемые к конечному продукту точно установлены с самого начала работы и не изменяются во время разработки.
Scrum и Kanban. Основные различия
В отличие от Waterfall, методологии Scrum и Kanban имеют много общего:
- обе следуют принципам Бережливой (Lean) и Гибкой (Agile) разработки
- обе используют вытягивающие (pull) системы планирования
- при использовании как Scrum, так и Kanban центральное место занимает минимизация используемой документации и нацеленность на коммуникацию внутри команды и непрерывное обсуждение текущего проекта. Как следствие этого — важная роль визуализации процесса разработки посредством доски с учетными карточками, каждая из которых соответствует определенной задаче
- оба подхода стремятся к ограничению работы, выполняющейся в текущий момент
- и Scrum, и Kanban ориентированы на как можно более частый релиз готового продукта
Для того, чтобы лучше разобраться в особенностях этих подходов, давайте обратим внимание на существующие между ними различия.
Подход к ограничению количества выполняемых задач
Важным для обеих методологий является практика ограничения задач, которые выполняются в текущий момент (Work In Progress, или WIP). Однако, критерии, согласно которым выбирается количество таких задач для каждой методологии разные.
Вот пример того, как может быть визуализирован процесс разработки ПО:
Каждой фазе разработки соответствует определенное количество выполняемых в данный момент задач.
Согласно методологии Kanban для каждого этапа разработки еще на стадии проектирования выбирается максимальное число задач, которые могут выполняться одновременно. Четкого руководства по выбору того или иного числа задач для определенного этапа нет и оптимальное значение чаще всего определяется по завершении нескольких итераций.
Scrum, в свою очередь, не ограничивает вас количеством задач, которые могут выполняться на определенном этапе. Можно говорить только об определенном количестве задач, запланированном для спринта в целом. Это количество выбирается исходя из времени, которое предположительно будет затрачено на выполнение той или иной задачи. Это время измеряется в story point’ах. По завершении нескольких итераций команда разработчиков знает свою среднюю производительность и ей, соответственно, может быть назначено определенное количество задач.
Различные подходы к организации Scrum и Kanban досок
На начальных этапах работы над проектом создается бэклог проекта, который представляет из себя список требований, предъявляемых к конечному продукту. В случае обоих подходов на этапе визуализации рабочего процесса задачи из бэклога продукта помещаются на доску. А вот их перемещение между этапами проекта отличается для разных методик.
В случае Scrum каждая итерация называется спринтом. На основе бэклога продукта в начале каждого спринта создается бэклог спринта — список задач, которые необходимо реализовать за время работы над текущим спринтом. Таким образом, все задачи, располагающиеся на той или иной стадии проекта являются частью бэклога спринта. Владелец продукта может наблюдать за бэклогом спринта, но вмешиваться в очередность задач, из которого он состоит, нельзя. Можно вносить изменения только в бэклог продукта, но они вступят в силу только после начала очередного спринта. Результатом работы над каждым спринтом является готовый продукт. После ретроспективы и демонстрации его функциональности владелец проекта принимает решение о том, стоит выпускать продукт или нет. Эти решающие стадии каждого спринта обычно не входят в бэклог и никак не отображаются на доске.
В случае же с Kanban доской дело обстоит несколько иначе. Srum доска очищается от карточек по завершении каждого стрима. На Kanban доске отображается весь процесс разработки целиком, а не только задачи одной команды, запланированные на одну итерацию. Таким образом, Kanban доска остается неизменной. Также стоит отметить, что на Kanban доске обычно отображаются финальные фазы разработки, например, установка готового продукта.
Использование разных подходов на примере одного проекта
Проект: Онлайн-приложение для хранения данных
Разработанный проект представляет собой веб-систему, предоставляющую мгновенный доступ к обширному источнику информации и статистических данных по развитым и развивающимся рынкам мира. Система предназначена для аналитиков, консультантов, научных учреждений, корпораций, экономистов, руководителей организаций, инвестиционных банков, и всех тех, кому необходимо оперативно проводить исследования и выполнять анализ данных. Главной задачей при работе над проектом было обеспечение возможности обработки около 15 миллионов записей, поступающих в разное время из различных стран. Система должна была давать доступ к данным 500 000 пользователей одновременно.
Итак, давайте рассмотрим как могут применяться различные подходы к процессу разработки на различных этапах работы.
В реальных условиях при работе над большими проектами сложно придерживаться одной методологии на протяжении всего периода разработки. Исключение составляют, пожалуй, только те редкие случаи, когда заказчик является приверженцем какой-то определенной методологии и одним из его требований является строгое следование всем ее принципам.
В остальных же случаях имеет место совмещение разных подходов.
Использование Scrum. Разработчики придерживаются методологии Scrum большую часть так называемого «спокойного» времени: времени без релизов и презентаций.
Пример спринта в Jira
Как только процесс разработки приближается к моменту презентации или релиза, разработчики плавно переходят к использованию Kanban. На практике это выглядит примерно так. У команды есть ориентир — дата релиза или презентации. Начиная с определенного момента команда начинает реализовывать задачи, которые заказчик приоритезирует и высылает ей в виде списка ежедневно.
Waterfall применяется в тех случаях, когда требуется реализовать какой-то важный, достаточно большой и достаточно обособленный от общего проекта функционал. Например, этот подход использовался при разработке Excel add-in для приложения. Критичными в данном случае являются четко сформулированные требования. В этом случае команда разработчиков собирает все требования, документирует их и приступает в разработке.
Заключение
Для успешного управления процессом разработки программного обеспечения бывает недостаточно выбрать ту или иную методологию и следовать ей на протяжении всего процесса. В случае достаточно большого проекта, разработка которого ведется достаточно долгий период времени, важной может оказаться способность быстро менять используемую в данный момент методологию в соответствии с изменяющимися обстоятельствами. Именно поэтому, помимо четкого и ясного понимания каждой из особенностей той или иной методологии, важное значение принимает также понимание различий между теми или иными подходами и умение быстро переключаться между ними. В случае определенных проблем, появившихся вследствие непредвиденных обстоятельств, такие навыки дают дополнительную возможность их быстрого решения. Вместо того, чтобы искать возможные слабые места в применяемой в данный момент методологии производства и пытаться их устранить, можно просто выбрать другой, более подходящий к изменившимся условиям подход.
The following two tabs change content below.Бизнес-аналитик, менеджер проектов XB Software и Agile-евангелист. Воодушевленно занимается развитием эффективных команд, чтобы создавать продукты, которые улучшат этот мир.
xbsoftware.ru
Различия и сходства между методологиями Kanban и Scrum
В этой части мы рассмотрим сходства и различия между Kanban и Scrum. Эти сходства и различия помогут вам выбрать правильный метод для вашего проекта.
Канбан и Скрам — сходства
Сходство между Kanban и Scrum:
- Оба являются Agile.
- Оба используют планирование вытягивания.
- Оба ограничивают WIP, Kanban на уровне задач и Scrum на уровне спринта.
- Обе используют прозрачность в процессе разработки.
- Оба сосредоточены на выпуске освобождаемого программного обеспечения на раннем этапе.
- Оба основаны на самоорганизующихся командах.
- Оба требуют разбить работу на части.
- В обоих методах план выпуска постоянно оптимизируется на основе эмпирических данных (Scrum — Velocity, Kanban — Lead Time / Cycle Time).
Канбан и Скрам — отличия
Различия между Kanban и Scrum заключаются в следующем:
| № | Scrum | Kanban |
| 1 | Scrum предписывает роли. | В Kanban роли необязательны. |
| 2 | Отставание продукта должно быть приоритетным. | Приоритизация является необязательной. |
| 3 | Спринт должен быть коробочным. Вы можете выбрать длину спринта, но, как только он будет выбран, для всех спринтов будет сохранена одинаковая длина. | Время-боксированные итерации являются необязательными. |
| 4 | Команде Scrum необходимо зафиксировать определенный объем работы для спринта. | Обязательство не является обязательным. |
| 5 | Назначены межфункциональные команды. | Кросс-функциональные команды являются необязательными. Разрешены специальные команды. |
| 6 | Использует скорость в качестве показателя по умолчанию для планирования и улучшения процесса. | Использует время выполнения (время цикла) в качестве показателя по умолчанию для планирования и улучшения процесса. |
| 7 | Элементы, такие как истории, тесты должны быть разбиты так, чтобы они могли быть выполнены в пределах одного спринта. | Никакого определенного размера предмета не предписывается. |
| 8 | Спринт показывает, какие задачи должны выполняться во время текущего спринта. Эти задачи отображаются на плате Scrum. Область спринта фиксирована. WIP ограничен за единицу времени (WIP-предел — скорость). | Задачи определяются на уровне рабочего процесса. WIP ограничен для каждого состояния рабочего процесса. |
| 9 | Дополнения / изменения не могут быть выполнены в спринте. | Дополнения / изменения могут быть выполнены, если лимит WIP не пересек. |
| 10 | Новая доска Scrum устанавливается в начале каждого спринта. | Доска Канбана постоянна. |
| 11 | Необходимо проводить ежедневные встречи. | Ежедневные встречи не являются обязательными. |
| 12 | Предписываются графики выгорания. | Никакой конкретной карты не предписывается. |
Kanban vs. Scrum
Следующие преимущества могут помочь вам выбрать между Kanban и Scrum:
- Вам нужно выбрать Kanban, если у вас уже есть рабочие процессы, и вы хотите улучшить, не нарушая всю систему, тогда как вам нужно выбрать Scrum, если вы хотите внедрить новый процесс в организации.
- Вы можете использовать Kanban в разработке продукта с Feature Driven Development для отслеживания рабочих потоков в потоке создания ценности, тогда как Scrum можно использовать для разработки на каждой итерации.
- Вам нужно определить границы WIP в Kanban явно, тогда как вам нужно определить длину спринта в схватке, которая подразумевает ограничения WIP.
- И Kanban и Scrum адаптивны, но Scrum более предписывающий, чем Kanban.
- Канбан накладывает только два правила: визуализировать рабочий процесс и ограничивать WIP, тогда как Scrum накладывает больше ограничений, таких как спринты с отложенными по времени спринтами.
- Канбан ведет к совершенствованию организационного процесса, как в области управления, так и развития. Kanban также поддерживает операции по техническому обслуживанию. Scrum приводит к высокой пропускной способности в небольших командах разработчиков. Это не способствует развитию рабочих процессов разработки и сопровождения, которые более продолжительны с непредсказуемостью по размеру рабочих единиц и изменениями. Scrum не делает акцент на оптимизации управленческой деятельности.
- В Kanban вы можете выбрать, когда делать планирование, улучшение процесса и выпуск. Вы можете выполнять эти действия регулярно или по требованию. Итерация Scrum — это один единственный спринт Sprint, объединяющий три различных вида деятельности: планирование, улучшение процесса и выпуск (если требуется).
Таким образом, Kanban и Scrum являются эффективными инструментами в их конкретных контекстах. Вы можете комбинировать Kanban и Scrum для получения максимальной выгоды от обоих.
Адаптация Kanban и Scrum вместе
Вы можете использовать Kanban и Scrum вместе, реализуя те характеристики, которые будут соответствовать вашим потребностям. Перед тем, как приспособиться к ним, необходимо рассмотреть их ограничения. Например, Scrum требует Time-boxed Sprints, и если вы покончите с ними, вы не можете сказать, что реализовали Scrum. Оба дают вам базовый набор ограничений для управления собственным улучшением процесса.
Уважаемый пользователь! Реклама помогает поддерживать и развивать наш проект, делая его простым и удобным специально для Вас. Если проект интересный и важный для Вас, то отключите на нем блокировщик рекламы. Спасибо, что читаете сайт!
unetway.com