Сегодня большинство компаний используют методологию Agile при разработке программного обеспечения. У Agile есть разные системы с похожими принципами и конечными результатами, но они различаются по структуре и подходу к управлению. Какой из них лучше всего подходит для вашего проекта? Это Скрам или Канбан? Или оба?
В преддверии старта курса Agile Project Manager поговорили об этом с экспертом Otus - Олегом Мельником.
Олег Мельник
Technical Lead в компании Proxify, а также преподаватель в OTUS
Agile
В последние годы это стало самой популярной стратегией управления проектами. Ключевые особенности методологии - открытое общение и гибкость, всегда ориентированная на результат . Его основная цель - предоставить покупателю ценность.
Agile - это интерактивная и поэтапная методология управления проектами, характеризующаяся постоянной адаптацией проекта к требованиям конечных пользователей посредством совместной работы и адаптивности. По моему опыту, этот подход всегда требует адаптивного планирования , эволюционных решений и точной доставки программного обеспечения.
Scrum
Scrum - это гибкий метод управления потребностями проекта. Он используется в основном при разработке программного обеспечения, где задачи эффективно делегируются небольшой команде . Этот тип управления доказал свою эффективность благодаря своей простоте и производительности . В последние годы он стал самым широко используемым подходом при разработке программного обеспечения.
Фактически, термин «scrum» происходит от scrimmage , позиции игрока в регби, образованной членами команды, толкающими друг друга, чтобы получить мяч. Соответственно, основная идея структуры - это регулярное сотрудничество внутри команды, направленное на устранение коммуникационных пробелов. Таким образом, становятся ясными цели проекта и задачи, возникающие на его пути.
В Scrum есть три роли : Product owner, Scrum Master и команда разработчиков, которые разбивают работу по разработке продукта на небольшие этапы, называемые спринтами. Это временные рамки, состоящие из мероприятий по планированию спринтов, ежедневных схваток, обзоров спринтов и ретроспективных мероприятий спринта, которые проходят каждый спринт. В каждом спринте высокопроизводительная команда Scrum находит инновационные решения сложных проблем, чтобы разработать, выпустить и поддерживать продукт.
Команда относительно небольшая, обычно 3–9 человек. Product owner и клиент устанавливают все правила , Scrum Master выступает в роли фасилитатора и коуча, а разработчики привержены своим обязанностям.
Команда Scrum поставляет программное обеспечение постепенно, с пометкой «Готово», чтобы максимизировать обратную связь и повысить эффективность.
Kanban
Подобно Scrum, Kanban - это управленческий подход, предназначенный для удовлетворения меняющихся требований. Он ориентирован на непрерывную поставку работающего программного обеспечения без установления строгих правил. Как правило, он состоит из нескольких небольших команд, работающих независимо над конкретными задачами, размещенными на доске Канбан. Гибкость - один из основных принципов Канбана. «Канбан» в переводе с японского означает рекламный щит. Следовательно, визуализация доски является основным организационным инструментом для фреймворка Канбан.
В Канбане нет конкретных размеров команд или должностей. На доске указаны главные приоритеты каждой команды. В канбан-менеджменте нет временных ограничений. Это дает членам команды свободу работать так интенсивно, как они хотят, чтобы выполнить свою работу. Фактически, свобода дает больше обязанностей. Команды должны организоваться и полагаться на свой опыт, не ожидая присмотра.
Нет необходимости в ограничении задач или мерах контроля. Однако менеджер может измерить среднее время выполнения задач и обсудить это с командами в качестве попытки улучшения. Также он организует доску, на которой записываются все цели, будущие задачи, тесты и выполненные задачи.
Отличия
Рабочие роли и обязанности
Как обсуждалось выше, у членов команды Scrum есть предопределенные роли, в то время как Kanban более свободны. Владелец продукта Scrum полностью контролирует постановку целей , делегирование задач и планирование процессов. Существуют иерархии, которые обычно не меняются на протяжении жизненного цикла проекта.
В Kanban менеджер является организатором проекта, где команды разработчиков сотрудничают и помогают друг другу независимо от того, над какой стороной проекта они работают. Например, если разработчик программного обеспечения закончил со своими задачами на доске, он начинает работу по тестированию, когда команда QA отстает.
Какая команда работает лучше? Это зависит от характера проекта. Проект разработки программного обеспечения, требующий строгого набора правил, будет лучше управляться командой Scrum. Напротив, если проект требует непрерывной реализации , гибкая команда Kanban подойдет лучше. Таким образом, тип команды зависит от гибкости проекта, делегирования задач и организации.
Планирование и сроки поставки
Скрам - это самое время. Всё должно быть «сделано» в течение одной или двух недель. Сразу после этого начинается следующий Спринт. После точного измерения возможностей команды в предыдущих графиках, в обзорах спринтов обсуждается оптимизация рабочей нагрузки и времени.
Канбан не заботится о времени. Речь идет о прозрачности, эффективности и продолжительности. Если Scrum - это «марафон», то Канбан - это «путешествие». В Scrum продукт доставляется часто, в то время как в Kanban он доставляется как единое целое, когда это будет готово.
Планирование времени лучше или нет?
В идеале руководство должно отвечать ожиданиям клиента относительно того, когда будет выпущен продукт. Скрам определенно лучший вариант для доставки вашего продукта в отведенное время. Из-за спринтов Scrum желателен для проектов, в которых клиент и руководство фиксируют прогресс. Отсутствие согласованного расписания в канбане предназначено для более сложных проектов в долгосрочной перспективе, когда работа выполняется точно, а не в спешке.
Производительность и измерение
Scrum и Kanban нацелены на улучшение качества , наряду с производительностью, чтобы повысить эффективность компаний, занимающихся разработкой программного обеспечения. Команда Scrum сотрудничает для выполнения задач, уделяя особое внимание решению всех проблем, возникающих при разработке и тестировании программного обеспечения. Ежедневный скрам и обзоры спринтов позволяют непрерывно измерять производительность труда. Это способствует способности команды выполнять сложные проекты.
Канбан ориентирован на достижение индивидуальных целей, записанных на доске Канбан. Прогресс не имеет конкретных мер. Обычно визуализация задач показывает прогресс каждой небольшой команды.
Является ли одна гибкая методология более продуктивной, чем другая? Конечно же нет. Не существует правильного рецепта гибкого управления. Это зависит от потребностей проекта. Просто дайте понять: каковы цели проекта? Какой рабочий процесс лучше всего подходит членам команды? Каков спрос со стороны конечного пользователя?
И Scrum, и Kanban усиливают управление проектом, но по-другому. Так зачем выбирать только один из них? Что, если есть третий метод, сочетающий в себе их лучшие качества?
Scrumban?
Scrumban создан для того, чтобы помочь в переходе Scrum на Kanban. Это гибрид , характеризующийся методами управления, которые позволяют постоянно совершенствовать разработку программного обеспечения. Предполагается, что у Скрама есть место для улучшения, применяя принципы Канбан.
Визуализация рабочих элементов из системы Канбан представлена в Scrum. Рабочие элементы Scrum, находящиеся в процессе выполнения, подробно описаны на доске Kanban. Диаграммы применяются для выявления слабых мест и выявления возможностей для улучшения. Следовательно, Scrumban будет иметь растущую прозрачность, где каждый может видеть, что происходит с проектом.
Команда Scrum становится более специализированной. Обычно есть рабочие роли, но делегирование обязанностей более гибкое. Таким образом, команда работает в полную силу . Члены команды мотивированы работать вместе, как в Scrum, но у них есть индивидуальные задачи. Scrumban помогает повысить эффективность обязательств в команде.
Команда Scrum иногда может прийти к незавершению нескольких задач из-за ограничений по времени. При применении метода планирования Канбан задачи полностью завершаются до перехода в столбец «Готово». Вместо того, чтобы выпускать рабочие элементы раз в 2–3 недели в Sprints, существует постоянная поставка рабочего программного обеспечения. Качество превыше времени. Таким образом, в Scrumban есть улучшения по запросу, чтобы максимизировать поток работы.
Поэтому, не любите Scrum. Самыми важными стали метрики Канбан, а не скорость. Улучшение проекта выявляется внутри каждой команды самостоятельно. Это позволяет более достоверно оценивать прогресс.
Однако в Scrumban структура Sprint по-прежнему присутствует для обратной связи с командами.
Обзоры спринтов используются для анализа результатов каждого рабочего цикла. Далее, как и в Scrum, ежедневные встречи отслеживают непрерывную работу над требованиями.
Scrumban - это инновационный гибкий подход, при котором руководство стремится повысить эффективность проектов разработки программного обеспечения. Это обеспечивает гибкость Scrum и измерение потока работы Kanban. Качество работы улучшается за счет минимизации потерь времени и выполнения задач вовремя, но с максимальной загрузкой.
На этом все. А тех, кто желает подробнее узнать о курсе, познакомиться с преподавателями и почерпнуть еще больше полезной информации, приглашаем на бесплатный демоурок по теме: "Как уточнять статусы задач и подружиться с соседями".
