Что такое kanban и scrum
Agile/Scrume/Kanban как выравнивать процессы, максимизировать процессы
Материал подготовлен в рамках обучения Product University, январь, 2021
Для начала определим кто такой менеджер?
Менеджер — это человек производящий и управляющий потоками, для оптимизации производственной деятельности и достижения поставленных целей и результатов.
Менеджер должен уметь правильно ставить задачи команде, следить за результатами поставками, он также должен знать основы Agile, Scrume, Kanban. Чтобы иметь представления как работать с командой.
Agile (agile software development, от англ. agile – проворный, шустрый, сообразительный) – это семейство «гибких» подходов к разработке ПО.
А теперь простыми словами, некоторые считают что Agile это методология, но любой опытный Product Manager скажет Вам что Agile это способ мышления он не включает практики, а определяет принципы и ценности это некая философия, которыми руководствуется команда.
Подход к проектам по разработке ПО
• Гибкая методология разработки,
• Постоянное формирование требований на основе целевого видения продукта
• Короткие горизонты планирования (1-2 мес.)
• Реализация внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля
• Каждый участник процесса «конвейерной сборки» вовлекается в процесс переосмысления своих задач и общего дела; каждый может вносить изменения и даже остановить разработку
1. Люди и взаимодействие важнее процессов и инструментов;
2. Работающий продукт важнее исчерпывающей документации;
3. Сотрудничество с заказчиком важнее согласования условий контракта;
4. Готовность к изменениям важнее следования первоначальному плану.
Таким образом, не отрицая важности того, что справа, всё-таки больше ценится то, что слева.
Особенность реализации проектов
• Фиксированы срок и стоимость проекта.
• Лучший контроль качества – контроль результата каждой итерации
Scrum (в переводе с англ: схватка, потасовка, толпа) — методология управления проектами, применяется при необходимости гибкой разработки; методология делает акцент на качественном контроле процесса разработки
Scrum – самая популярная из гибких методологий разработки
Позволяет решать задачи
• с минимальными затратами.
РЕЗУЛЬТАТ КАЖДЫЕ 2 НЕДЕЛИ!
В Scrum задачи принято оценивать в Story points или в часах. Без оценки не получится сформировать спринт: ведь нам нужно знать, успеем ли мы сделать задачи за 2 недели. Через 2 недели мы получаем ценную статистику — сколько часов или Story points команда смогла сделать за спринт.
Velocity — это производительность команды за один спринт. Этот параметр позволяет Scrum менеджеру предсказать, где команда будет через 2 недели.
Перед началом спринта команда сама формирует список задач на итерацию, далее запускается спринт.
ОЧЕНЬ ВАЖНА РОЛЬ ВЛАДЕЛЬЦА ПРОДУКТА, который постоянно участвует в проекте, понимает, что должно быть достигнуто, оценивает все риски и выгоды.
По методологии Scrum, оптимальной является группа из 5-9 ЧЕЛОВЕК.
Как максимизировать и выравнивать процессы?
На самом деле здесь уже все продумано, и придумать велосипед не нужно!
Используется всего четыре артефакта:
Sprint Backlog – это обязательство команды: что они должны выполнить за ближайшие 2 недели. Каждое требование разделено на задачи, которые представлены на доске.
Это краткое описание того, ради чего выполняется данный спринт, цель на спринт помогает команде принимать обоснованные решения.
Этот артефакт необходим для того, чтобы команда проекта могла самостоятельно принимать решение в случае появления альтернативных путей решения задачи. Чтобы решения команды были осознанными, Product Owner определяет цель спринта.
Sprint Burndown Chart
Есть несколько процессов, которые принято называть ритуалами. Каждый ритуал выполняется неукоснительно и в строгом соответствии с подходом. На практике такие процессы стараются немного адаптировать, но ключевые принципы не изменяют.
Ритуалы в скрам это:
Sprint Planning Meeting (встреча по планированию спринта)
Daily Meeting (ежедневная встреча команды).
Scrum Master следит за ходом встречи, побуждает участников высказываться полностью и слушать говорящего.
Sprint Review – сдача спринта Product Owner
По завершению каждого спринта команда обязана провести демонстрацию полученного результат.
Ценность Scrum для обычного заказчика во многом состоит в том, что результат работ (плохой или отличный, не важно) будет продемонстрирован в любом случае. Это знает и команда и Product Owner и другие заинтересованные лица. Если команда не проводит демонстрацию (иное название Sprint Review), то это дискредитирует все преимущества гибких процессов.
Ритуал, который направлен на обмен опытом внутри команды. Встреча проводится после Sprint Review. На встрече присутствует вся команда и Scrum Master. На встрече может присутствовать Produt Owner, если считает нужным.
Методика проведения встречи варьируется в зависимости от проекта, его команды и просто традиций в коллективе. Тем не менее, должны быть озвучены ответы на следующие вопросы:
Kanban, это система управления бережливыми производством (перевод с японского: «сигнал»/«карточка»), которая использует информационные карточки для передачи заказа на всех этапах изготовления. Простыми словами, мы отслеживаем весь путь продукта, от идеи до выхода “на полку магазина”.
Kanban — это метод для разработки продуктов, который помогает наладить текущие процессы и не перегрузить команду. Незавершенные задачи не простаивают и потоком движутся по цепочке создания продукта или его поддержки.
Kanban используют для реализации проектов.
Kanban дает больше гибкости, если под гибкостью понимать частоту смены приоритетов. Если вчера разработчик залил выполненную задачу, а сегодня получили данные с «передовой» и узнали, что вот эта штука не работает так, как было задумано, то дают новые требования. Дополненные новые задачи поднимаются вверх и программист берет эту задачу «сверху», выполняет ее и, к вечеру все работает как надо. Все счастливы и эффективны как никогда.
В Канбан «скорость работы команды» отсутствует и считается только среднее время на полную реализацию задачи
Бэклог — задачи, которые надо выполнить
Задачи, которые в данный момент разрабатываются
Задачи, которые выполнены, но еще не переданные тестировщикам
Задачи, готовы к передаче отделу тестирования
Задачи, которые проходят проверку проект-менеджером (ПМ)
Основной инструмент отображения статуса по задачам. Главный принцип: мы видим на каком этапе производственного процесса находится та или иная задача. Плюс, отслеживается время на всех участках, то есть всегда можно обнаружить “узкие места” в системе и поработать с ними.
Количество столбцов вы определяете сами исходя из особенностей своего проекта. Важно, чтобы это были основные этапы, которые проходит ваш продукт. Пример выше, это плюс-минус основные этапы, которые проходит интернет продукт.
Разбор Scrum и Kanban. Что выбрать?
Scrum — быстрая разработка сырых User Stories.
Kanban–медленная разработка проработанных User Stories.
Немного утрировано, но так легче разобраться, когда лучше использовать Scrum, а когда Kanban. Оба Agile подхода позволяют гибко управлять созданием и развитием продукта, но отличий у них намного больше.
Дисклеймер: мною написанный текст лишь мое собственное мнение и он не претендует на истину. Статья появилась на основе интервью в продуктовых командах и в процессе создания и развития продуктов по Scrum и по Kanban.
Моя цель — прояснить ситуацию с двумя подходами, помочь вам сэкономить время и сделать правильный выбор.
Мы не будем рассматривать все ритуалы Scrum и Kanban. Но исследуем почему применить Scrum удается не всем, и почему чаще всего лучше использовать Kanban.
Если даже один ритуал фреймворка не выполняется — это уже не Scrum. Да, в жизни идеальных условий не бывает, но ритуалы придумали не для галочки. Kanban не такой требовательный, и поэтому легче прижился в продуктовых командах. В то же время, Scrum более модный, и в желании не отставать от трендов появился народный SсrumBan (Scrum + Kanban).
По моим наблюдениям, практически все команды, которые используют Scrum и с которыми мне повезло провести интервью, в действительности используют ScrumBan. На мой взгляд, лучше их использовать отдельно, так как у них разные цели.
Scrum хорошо подходит в условиях неопределенности. Когда у вас или заказчика есть только гипотезы, и вы еще не знаете верны они или нет. Есть ли смысл разрабатывать подробные блок-схемы и согласовывать со всеми, если мы только предполагаем, что нужно пользователю? Акцент на скорости, метриках продукта и обратной связи от пользователей.
Задача сформировать гипотезы в виде User Stories (US) и как можно быстрее запустить спринт. Процесс примерно такой:
— оценка US и запуск спринта;
— разбивка US на задачи;
— ежедневные встречи (Stand up);
— фиксирование скорости команды (в Story Points);
— уточнение бэклога продукта;
— релиз (выпуск обновленного продукта);
— обзор спринта;
— ретроспектива.
Мы не тратим время на блок-схемы и на согласования, но тратим время на ресурсоемкие ритуалы Scrum. Именно они помогают сырую US как-то оценить, вовремя подправить и быстро обновить на проде, что позволяет своевременно собрать метрики, и сделать выводы.
Да, задачи не согласованы и не проработаны так тщательно, как, например, в Kanban. Но мы потратили всего 2 недели. Даже если ошиблись с гипотезой (что часто бывает), мы не растягивали процесс во времени и обошлись ресурсами небольшой команды (Product Owner, Scrum Master, Dev team).
Работа по Scrum это бесконечный процесс формирования и валидирования гипотез. Без настройки продуктовых метрик и без интервью с пользователями не обойтись. Чем быстрее и качественнее мы будем собирать данные, тем быстрее и правильнее будут наши решения. Тем лучше это будет сказываться на продукте.
Шагая в неизвестность, необходимо устранять любые неопределенности, например: скорость команды. Нам важно знать когда мы сделаем обновление продукта и когда соберем обратную связь. Если в итоге гипотеза окажется неверна, будет поздно. Поэтому мы добросовестно выполняем все ритуалы. Например Poker планирование и замер скорости путем закрытия Story Points на ежедневных встречах (Stand Up). Анализируем Burn Down Chart на ретроспективе, чтобы в следующем спринте равномернее закрывать задачи. В таком ритме это жизненно необходимо.
Подробнее о фреймворке Scrum здесь
Kanban, на мой взгляд, лучше подходит когда задачи расписаны на месяцы и каждый шаг необходимо согласовывать с заказчиком. Акцент на согласованном процессе, тестировании и качественном релизе.
Один цикл, от поступления задачи до ее выпуска на продуктиве, может затрагивать широкий круг специалистов из разных команд:
— анализ и разработка блок-схем;
— согласование со всеми заинтересованными лицами (ЗЛ);
— UX/UI дизайн;
— backend разработка;
— frontend разработка;
— тестирование;
— доработка;
— релиз (выпуск обновленного продукта).
Мы растягиваем процесс, но в итоге имеем согласованный и качественный релиз. Подробная доска поможет вам и ЗЛ увидеть узкие места. Например: скопилось много задач по дизайну, и разработчики сидят без дела, скорей всего команде нужны еще дизайнеры. Установите WIP-лимиты (Work In Progress), например: больше одной задачи разработчикам в работу не брать. Это сделает процесс еще прозрачнее и разработчики не будут тратить время на переключение с одного таска на другой.
В Kanban тоже есть свои ритуалы, но они не такие ресурсоемкие. Сбор метрик и обратная связь от пользователей важны, но не настолько критично как в Scrum. Ваш заказчик может быть одновременно пользователем вашего продукта. Если весь цикл вы согласовывали с ним каждый шаг, будет странным если завтра он попросит все переделать.
Процесс закрытия задач последовательный, согласованный и поэтому требует больше времени. Вы можете параллельно запускать в работу несколько US, возвращать задачу на предыдущий этап и добавлять в любое время новую. Главное, постоянно настраивать и улучшать доску под себя и свои нужды, устраняя узкие места и обеспечивая непрерывный поток. Мы знаем кто, что и когда делает и видим все этапы конвейера. Осталось зафиксировать время цикла от появления задачи и до ее релиза. Это позволит следить за темпом, непрерывно его настраивать и улучшать.
В крупных компаниях руководство или заказчики требуют список задач на месяцы вперед. Если вы делаете продукт на внешний рынок и используете Scrum, то ваш список задач может выглядеть примерно так:
— Увеличить Retention на x% к дате n;
— Повысить NPS на x значений к дате n;
— Повысить LTV на x% к дате n.
Подробнее о полезных метриках здесь
Чувствуете как непросто принять фактически отсутствие плана? Если мы будем прописывать конкретные задачи и функционал, мы сами себя ограничим. Что важнее, сделать продукт с набором функций или продукт, который достигает product/market fit? Когда клиенты выстраиваются в очередь. Небольшое изменение в фокусе и вы уже создаете не функции, а продукт с конкурентными преимуществами, соответствующий потребностям рынка.
Подробнее о product/market fit здесь.
Никаких конкретных задач, только улучшение показателей продукта, потому что каждые 2 недели вы будете пересматривать бэклог опираясь на полученные данные. Стратегическая цель от этого не меняется — улучшить метрики и повысить лояльность ваших пользователей. А что может быть важнее? Тем более когда вы выпускаете сырые US на продукте. Да, мы будем проводить интервью с потенциальными клиентами перед началом работ, но окончательную точку, в отношении вашей гипотезы поставят только метрики продукта и обратная связь пользователей.
Еще раз, если вы не привыкли или не видите смысла ориентироваться на метрики продукта и обратную связь от пользователей когда формируете бэклог задач, то смысла в ритуалах Scrum нет. Значит, вы и так знаете что делать. Не усложняйте себе жизнь и берите Kanban. Но если вы ошиблись с тем что нужно было делать все эти месяцы — последствия могут быть плачевными: много времени и человеческих ресурсов будет потрачено.
Если вы решились идти по Scrum, помните, что команда должна быть кросс-функциональной. Компетенций должно быть достаточно для выполнения полного объема работ с минимальным привлечением сторонних команд. Полное погружение в один продукт/сервис/проект. Иначе не получиться давать оценку US в Story Points и фиксировать скорость, так как вы отвечаете только за часть функционала. Не сможете контролировать время выхода релиза и вовремя получать данные. Обычно это приводит к скоплению не проработанных и не проверенных US в продукте, и к его закрытию в итоге.
Перед запуском первого спринта по Scrum расскажите о роли каждого участника команды (SM, PO и Dev team) и абсолютно о всех ритуалах и артефактах (их очень много). Не забудьте объяснить для чего они нужны, чтобы осознанно и регулярно их выполнять. И лишний раз убедиться, что Scrum вам действительно подходит.
Если все же сомневаетесь, ниже список из 10 пунктов, когда Scrum, скорей всего не подойдет:
1. Команда не видит смысла в некоторых ритуалах Scrum.
2. Команда не кросс-функциональна, выполняет только часть US.
3. Не настроены метрики продукта (Retention и LTV) или настроены, но не анализируются (если продукт ориентирован на внешний рынок).
4. Product Owner самостоятельно или совместно с заказчиком принимает решение куда развивать продукт не опираясь на обратную связь от пользователей и анализ метрик продукта (если продукт ориентирован на внешний рынок).
5. В текущий спринт вам постоянно подкидывают новые задачи.
6. Роли не зафиксированы, и каждый участник команды может выполнять не одну роль.
7. Команда работает над двумя и более продуктами.
8. Команда не фиксирует скорость, не анализирует Burn Down Chart и вообще не видит в этом смысла.
9. Акцент на качестве и согласованости, а не на скорости команды, метриках продукта и обратной связи от пользователей.
10. Road map в виде конкретных задач, а не в виде улучшения показателей продуктовых метрик.
Если не видите смысла в тех или иных ритуалах Scrum, не мучайте себя и берите Kanban. Без анализа метрик продукта и обратной связи от пользователей многие ресурсоемкие ритуалы фреймворка будут лишними. А это уже будет не Scrum. Даже если в команде опытный скрам мастер. Особенно если продукт ориентирован на внешний рынок.
Только не подумайте, что в Scrum ничего не согласовывается, а в Kanban не анализируются метрики, просто акценты у двух подходов разные.
Kanban практически в любой команде и в любых условиях можно использовать. Но он менее требовательный и поэтому, на мой взгляд, меньше подходит для работы в условиях неопределенности. Для себя отметил, что его лучше использовать там, где известны задачи на месяцы вперед и без согласования со всеми заинтересованными лицами задачу двигать дальше нельзя.
Scrum, мне нравится больше, но он очень требовательный и ресурсоемкий. Редкие команды обладают достаточной свободой и свойствами для его применения. Его лучше использовать там где есть большая доля неопределенности. И акцент на том, чтобы, как можно быстрее определиться. В отношении того, что в действительности нужно пользователям. В отношении скорости команды и того на сколько равномерно закрываются задачи во время спринта.
Хорошо если ScrumBan вам помогает, но чаще всего это не так. Команды выполняют ресурсоемкие ритуалы Scrum и не видят в них смысла. В этом случае лучше чередовать оба подхода и в конечном счете определиться с одним из них.
Неважно, что вы используете, главное не отчаиваться, если с первого раза у вас не получилось. Оба подхода предназначены для того, чтобы спринт за спринтом (Scrum) или цикл за циклом (Kanban) совершенствовать применение. Исключением является ScrumBan, где происходит топтание на месте, с небольшими отклонениями то в сторону Scrum, то в сторону Kanban.
Поделитесь, что вы используете Scrum, Kanban или ScrumBan? Буду рад любой обратной связи моя страница в Facebook.
Agile, scrum, kanban: в чем разница и для чего использовать?
Главный редактор RB.RU
Если раньше офисы модно было обустраивать «по фэн-шую», то теперь — исключительно «по эджайлу». Agile – это не только цветные стикеры, на которых удобно отмечать ход работы (стикеры, скорее, стоит относить конкретно к подходу kanban). А ведь есть еще и scrum – он тут при чем?
Специально для тех, кто запутался в терминах, мы кратко разобрали эти понятия и спросили экспертов, зачем компании переходить на новую систему.
Определение
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 стоит на личной ответственности человека, а не на отлаживании внутренних процессов.
Когда в работе с профессиональными командами мы используем Scrum, чаще всего мы выбираем цикл длиной в 2–3 недели с ретроспективными собраниями, которые позволяют держать все под контролем.
(Из интервью «Ведомостей» с Фрэнком Сосьером, коучем компании Freestanding Agility)
Главная идея Kanban – визуализация рабочего процесса. Она заключается в создании физической панели, на которой можно наглядно отмечать прогресс.
Если говорить о том, что такое 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-часовую норму и, по ощущениям, мы стали успевать больше. Мы понимаем, что когда у тебя есть ощущение, что ты не успеваешь, чувствуешь, что надо работать больше — это очень плохо влияет на продуктивность, от этого надо избавляться.
Для наглядности и открытости работы отдела разработки мы повесили специальную доску с пометками “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 это не нужно.
Что почитать по теме?
Тест: привлечёт ли твой стартап финансирование?
Текст: Александр Петров.
Видео по теме: