agile scrum kanban что это
Agile scrum kanban что это
Agile, Scrum, Kanban – в последние годы эти термины переживают пик популярности, (по крайней мере в украинском социуме). Все больше людей стало интересоваться гибкими методологиями управления проектами и их особенностями. И это неудивительно, ведь по ним можно эффективно работать в любой отрасли, но особенно хорошо они подходят для ИТ. Но в чем суть каждой? И чтобы вы не путались в терминах, давайте разберемся как их успешно использовать.
Определение
Смысл 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, с которым мелкими «шажками» (спринтами) можно постоянно разрабатывать и улучшать продукт благодаря быстрой обратной связи. В итоге конечный продукт может быть совершенно другим, чем тот, который планировался в начале, но он будет максимально соответствовать ожиданиям пользователей.
Agile/Scrum/Kanban/Lean это про что?
Программное обеспечение разрабатывается с начала 60-х годов. Сегодня в этом процессе заняты самые разные специалисты, и их работу нужно структурировать, контролировать, планировать и приоритизировать.
В начале 90-х годов на замену «тяжелым» методам разработки стали приходить новые: RAD, Scrum, Crystal Clear, XP, которые сейчас принято называть гибкими методологиями разработки ПО. В 2001 году был опубликован «Манифест гибкой разработки программного обеспечения» (AGILE)
В общем смысле Agile стал философией современной разработки, в которой Scrum организует структуру совместной работы и определяет четкие роли в проекте, Kanban балансирует задачи и визуализирует их, а концепция Lean помогает оптимизировать задачи, и процессы.
Общая цель подхода Agile – создание продукта в максимально короткие сроки, организация работы по четким ролям в установленные временные отрезки.
В методологии Scrum принято работать спринтами от 1 недели до 1 месяца, с регулярными собраниями, на которых могут корректироваться цели, задачи и сроки их выполнения.
В этом смысле методология Kanban дает больше свободы командам разработки, здесь отсутствует микроменеджмент, команда работает сообща на достижение конкретных промежуточных целей и их выполнения, роли могут меняться в процессе. Выглядит это примерно, как здесь:
Конечно, такой подход требует очень высокой самоорганизации каждого участника команды, так как за результат фактически отвечают все вместе, и если это не самостоятельный стартап, то без Scrum скорее всего не обойтись.
В заключении, скажу пару слов о методологии Lean – бережливой разработке ПО. Смысл концепции заключается в том, что:
Гайд по сертификациям. Часть 1. Agile
По Agile доступно огромное количество курсов. Кроме специализированных курсов по проектному управлению есть ещё сертификации.
Зачем получать сертификаты по проектному управлению? Существуют несколько причин:
Систематизировать ранее полученные знания.
Получить новые знания. Во время подготовки к сертификации вы можете обнаружить, что у вас существуют пробелы в знаниях, которые необходимо восполнить.
Проверить свои силы. Сертификация даст ответ «насколько ты хорош».
Переход на новую должность или роль. Вы хотите получить знания, необходимые для выполнения новых обязанностей.
Повышение. Сертификаты повышают вашу стоимость в глазах работодателя.
Сертификаты можно разделить на три типа:
Перед подготовкой к сертификации вам нужно ответить для себя на несколько вопросов:
Для чего вам нужен сертификат?
Какую методологию/фреймворк вы используете или хотите использовать?
Какая у вас текущая или желаемая роль в компании?
ICAgile
ICAgile. После прохождения обучения вы можете получить международный сертификат. Тренинги от ICAgile достаточно известны и популярны. Получить сертификат достаточно просто: прослушал курс – получи сертификат.
Обучение проходит по 8 трекам плюс 1 бизнесовый блок.
В каждом треке есть 2 уровня. Прошёл обучение по каждому уровню – получаешь статус по всему треку.
Обучение на каждом уровне длится в течение 3-х дней, много практики.
Сертификат
Сертификат пришлют в течение 4 недель после курса. Сертификат выдаётся бессрочно, продлевать не нужно.
Проверить сертификат на действительность можно по ссылке.
Стоимость обучения варьируется в зависимости от трека от 35 до 90 тысяч рублей. Стоимость курса включает выдачу сертификата. Ничего доплачивать не нужно.
Разнообразие, можно прослушать курсы по нескольким направлениям: Agile, DevOps, опер блок.
Сертификат выдаётся бессрочно.
Отсутствует экзамен. Человек, который старался, слушал курс, и человек, который просто присутствовал, равны.
PMI. Одна из самых сложных сертификаций. На экзамене понадобятся знания широкого круга методологий и фреймворков.
Сертификат
Это одна из немногих сертификаций, до которой ещё необходимо допуститься.
Для получения доступа к экзамену потребуется:
Не менее 12 месяцев опыта управления проектами за последние 5 лет;
Не менее 8 месяцев управления Agile проектами за последние 3 года;
21 час обучения на любом курсе Agile (не обязательно аккредитованом).
Описание требований для доступа к экзамену. Курсов по подготовке к экзамену не так много.
Нужно быть готовым подтвердить информацию в анкете. Ваша заявка может попасть под аудит.
Сам экзамен состоит из 120 вопросов, большая часть вопросов – ситуационные, основаны на практических кейсах. На экзамен отводится 3 часа. Критерий успешной сдачи не раскрывается, но, по слухам, составляет примерно 70 правильных ответов. Русский язык на экзамене пока ещё недоступен – придётся сдавать на английском.
Проверить сертификат на действительность можно по ссылке.
Сертификат необходимо продлевать каждые 3 года. Для этого достаточно пройти 30 часов обучения на сертифицированных курсах. Подробная информация по ссылке.
Стоимость аккредитованных курсов от 1 до 200 тысяч рублей. Зависит от количества часов, страны и жадности провайдера курсов.
Одна из самых именитых компаний.
Необходимо сдать экзамен.
Одна из самых сложных сертификаций.
Необходимо допуститься до экзамена.
Высокая стоимость экзамена (495 USD).
Экзамен доступен только на английском языке.
Нужно продлевать сертификат.
IAPM. Малоизвестный провайдер IAMP. Сертификация основана на стандарте Agile PM Guide 2.0. Стандарт включает инструменты и техники из нескольких фреймворков: Agile, Scrum, Kanban и других.
К сертификации доступно 4 уровня: Certified Junior Agile Project Manager, Certified Agile Project Manager, Certified Senior Agile Project Manager, и Certified International Project Manager.
Сертификат
Курсов по подготовке не так много, и доступны они только на английском языке.
Проверить сертификат на действительность можно только отправив запрос на почту support@iapm.net.
Экзамен состоит из 120 вопросов, на которые будет отведено 80 минут. Для успешной сдачи необходимо правильно ответить на 78 вопросов. Более подробно по ссылке.
Стоимость сдачи экзамена зависит от страны пребывания сдающего, составляет примерно 650USD. Сдать экзамен может любой желающий – отсутствуют обязательные требования для допуска к экзамену.
Необходимо сдать экзамен.
Не нужно продлевать сертификат.
Малоизвестный провайдер в РФ.
Экзамен доступен только на английском языке.
Scrum Alliance
Scrum Alliance. Компания была основана в 2002 году авторами «The Scrum guide» Джеффом Сазерлендом и Кеном Швабером. Сертификат от Scrum Alliance один из двух самых известных в мире сертифицирующих организаций по Scrum. О второй позже.
В Scrum Alliance есть три трека для сертификации по ролям: Scrum master, Product owner, Developer. У всех трёх ролей есть три ступени — Certified, Advanced и Professional.
Также Scrum Alliance предлагает еще 4 дополнительных трека — Agile Leadership, Team Coach, Enterprise Coach и Trainer.
Сертификат
Чтобы допуститься к экзамену, необходимо обязательно пройти аккредитованные курсы.
Курс длится 2 дня. После прохождения обучения у вас будет несколько попыток сдать экзамен на официальном сайте Scrum Alliance.
Проверить сертификат на действительность можно по ссылке.
После прохождения обучения вам будет доступно несколько бесплатных попыток для сдачи экзамена. Экзамен доступен на официальном сайте scrum alliance и только на английском языке.
Для получения следующей ступени сертификации необходимо обязательное наличие предыдущей.
Сертификацию нужно продлевать каждые 2 года. Для продления необходимо набрать достаточное количество баллов SEUs на аккредитованных курсах плюс заплатить взнос. К примеру, для продления самой популярной сертификации Product owner и Scrum Master потребуется 30 часов курсов и оплата взноса в размере 175 долларов.
Подробная информация о продлении по ссылке.
Всемирно известная компания.
Необходимо сдать экзамен.
Экзамен доступен только на английском языке.
Нужно продлевать сертификат.
Scrum.org
Scrum.org. Вторая всемирноизвестная сертификация по Scrum. Компания Scrum.org была основана в 2009 году Кеном Швабером.
Для сертификации доступно 8 треков, 3 из которых организованны по ролям: Scrum Master, Product Owner и Developer. Остальные пять — Scaled Professional Scrum, Professional Scrum with Kanban, Professional Agile Leadership, Professional Agile Leadership-EBM, Professional Scrum with User experience.
Сертификат
После прохождения обучения вам будет доступно несколько бесплатных попыток для сдачи экзамена. Экзамен можно сдать на официальном сайте scrum.org и только на английском языке.
Проверить сертификат можно по ссылке.
Количество вопросов и стоимость сертификации отличается от трека к треку.
Скрам умер. Да здравствует канбан
Я пользовался методом управления проектами Scrum (скрам) с самого начала карьеры. Я изучал скрам в колледже. Тогда он считался лучшим методом управления разработкой программного обеспечения. Когда я начал работать, мне нравилось всё, что имеет отношение к скраму: ежедневные встречи, планирование, ретроспективные совещания, спринты и так далее. В конце концов, я пользовался на практике тем, чему меня учили.
Но через несколько лет я начал кое-что замечать: в последние дни спринта все бросаются доделывать всё то, чем занимались в предыдущие две недели, стремясь избежать переноса задач на будущее. Часто те, кто так поступали, брали на себя ненужный риск.
Почему? Разве какие-то задачи не могут подождать до следующей недели? Так ли важно доделать абсолютно всё до выходных? Нет, не так уж это и важно. А всё это происходит из-за того, что «Переносы задач — это плохо».
Скрам — это уже не совсем «гибкая методология разработки»
Я пришёл к выводу о том, что в скрам слишком большое внимание уделяется процессу работы. Или, как минимум, люди обращают на это слишком много внимания, что выражается в следующем:
Учитывая всё вышесказанное, я могу отметить, что члены моей команды начали чувствовать недовольство от происходящего. Это повлияло на качество того, что мы создавали. Программисты больше заботились о том, чтобы уложиться в срок, чем о том, чтобы достичь нужного уровня качества.
В этот момент мы начали поиск других возможностей организации работы, поиск другого agile-фреймворка, который лучше подошёл бы к используемым нами методам работы.
Тогда мы нашли Kanban (канбан).
Что такое канбан?
Канбан — это метод управления производством, который появился в компании Toyota в 1950-х годах. В то время в Toyota использовали доску с тремя колонками: «Запланировано», «В работе», «Завершено». Данный фреймворк позволял Toyota более эффективно выделять ресурсы в ситуациях, когда где-то на производственной линии возникали узкие места.
Затем, когда стало ясно, что применение канбан способно повысить скорость разработки ПО, канбан перенесли и в сферу технологий.
Сравнение фреймворков скрам и канбан
В последние годы скрам и канбан сражаются за место ведущего agile-фреймворка. Несмотря на то, что скрам занимает первое место, канбан постепенно распространяется всё сильнее. А что если их сравнить?
Если взять за основу скрам и сравнить его с канбан, то получится следующее:
Канбан даёт команде разработчиков достаточно высокий уровень гибкости. Пользовательские истории, в сравнении со скрам, выполняются в более свободной манере. Но свобода — это ответственность. Несмотря на то, что канбан не требует того, что разработчики каждые две недели берут на себя какие-то обязательства, применение этого метода управления разработкой предусматривает собственные средства контроля за работой. Это, например, такие метрики, как время цикла и пропускная способность системы.
Всё дело в метриках
Нельзя оценить эффективность (или неэффективность) работы, не имея специализированных метрик. Рассмотрим метрики, применяемые в скрам и в канбан.
▍Метрики скрам
При применении скрам используются следующие метрики и графики:
«Скорость» не измеряет скорость выпуска готовых подсистем продукта. Эта метрика оценивает лишь количество выполненных этапов работы, имеющих отношение к некоей пользовательской истории. Если на работу над историей уходит больше времени, чем было запланировано, эта метрика оказывается бессмысленной.
«Соотношение обязательств, которые взял на себя разработчик, к объёму выполненных задач» вообще не должно рассматриваться как метрика. Эта «метрика» сопоставляет обязательства с результатами. Не стоит и говорить о том, что это может привести к тому, что люди будут закрывать и повторно открывать задачи только для того, чтобы они были бы «выполнены».
«Диаграмма сгорания задач» — это то, на что лично я никогда не обращал особого внимания. В основном это так из-за того, что подобные диаграммы часто выглядят примерно так, как показано ниже.
Диаграмма сгорания задач
Почему это так? Предположим, вы начинаете с пустой доски, и приступаете к параллельной работе, например, с тремя пользовательскими историями. Работы по этим историям, вероятно, будут вестись с одинаковой скоростью — именно поэтому на диаграмме сгорания задач можно видеть такие мощные нисходящие движения. Более того, если в команде имеется всего один тестировщик, который должен тестировать результаты выполнения работ по всем задачам, то он окажется узким местом команды.
▍Метрики канбан
Я полагаю, что метрики — это самая важная из сильных сторон канбан. В канбан имеется множество различных метрик, которые помогают лучше понять то, что происходит с командой. Например:
Кумулятивная диаграмма потока
Существует плагин для Jira, который позволяет пользоваться всеми этими метриками. Это — ActionableAgile for Jira — Agile Metrics. Он помогает исследовать метрики, имеющие отношение к деятельности команды, используя ту же платформу, что используется для управления работой.
Адаптация канбан
Применение «чистого» канбан не предусматривает выполнение некоторых операций, обязательных при применении скрам. Но этот метод управления проектами достаточно гибок и позволяет, если подобные действия кажутся полезными, добавлять их в рабочий процесс.
Ретроспективные совещания — это один из самых важных видов совещаний. Именно на таких совещаниях члены команды могут поговорить о том, чего удалось достичь, о том, что прошло не совсем удачно, о том, что можно улучшить. Ретроспективное совещание — это спокойное мероприятие, на котором можно рассказать о своих проблемах и поздравить с успехом тех, кто отлично справился со своими задачами.
Несмотря на то, что ретроспективные совещания не являются необходимыми в канбан (в скрам они проводятся в конце каждого спринта), мы сочли их ценными мероприятиями и не стали от них отказываться. На самом деле, мы даже начали проводить их еженедельно, а не каждые две недели, как раньше. Это позволило нам быстрее реагировать на возникновение каких-либо проблем. Мы, кроме того, используем эти совещания для того чтобы анализировать метрики команды и проверять рабочие процессы на наличие проблем и узких мест.
Мы сохранили и ещё один элемент из наших скрам-времён, который необязательно применять при использовании канбан. Речь идёт об оценке времени, необходимого для работы над пользовательской историей. Это делается в ходе уточнения задач, которые входят в историю. В скрам подобные оценки используются для того чтобы лучше понять то, что «поместится» в спринт. Можно подумать, что, так как в канбан нет спринтов, то оценка историй тут не нужна. Но, на самом деле, это не так.
Оценка сроков, необходимых на выполнение пользовательской истории помогает обеспечить то, что все члены команды одинаково видят объём задач, который необходимо решить в ходе работы над историей. Если кто-то даёт истории оценку в 8 баллов, а кто-то — в 3, очевидно то, что нужно продолжить обсуждение этого вопроса. Кто-то может, оценивая сроки, учитывать какие-то проблемы, о которых другие не знают. В чьём-то понимании в объём работ по пользовательской истории должно входить что-то такое, что другие в таком качестве не рассматривают.
Собственно говоря, всё это подталкивает членов команды к дискуссиям.
Когда происходит нечто подобное, становится очевидным то, что не у всех есть чёткое понимание того, какой объём работ нужно выполнить по некоей пользовательской истории.
Ещё один часто встречающийся сценарий выглядит так: вся команда даёт трудоёмкости истории довольно высокую оценку (обычно это — всё, что больше 8 баллов). Это говорит о неуверенности. Это значит, что либо речь идёт о большом объёме работы, либо — о решении очень сложных задач, что вызывает у членов команды неприятные ощущения. В подобном случае лучше всего будет разделить пользовательскую историю на несколько более мелких историй и чётче определить цели работ.
Итоги
Скрам навсегда останется в наших сердцах как первая широко распространившаяся agile-методология. Но по мере того, как компании переходят к схемам непрерывного развёртывания решений, использование спринтов, ограниченных по времени, больше не имеет смысла.
Всегда будут существовать особые проекты, в которых скрам способен отлично себя показать. Правда, учитывая то, что в компаниях всё чаще пользуются agile-методологиями, канбан постепенно выйдет на первое место, сместив с него скрам.
Что больше подходит вам? Скрам или канбан?