Agile, Scrum, Kanban: что это и как работает?

Василий — начинающий Scrum-мастер. Вася наслышан о многих фреймворках, но всем сердцем влюблен в один лишь Scrum. Поэтому когда его друг Андрей — PM, который менеджерит проекты по Kanban-у — говорит об отсутствии спринтов и о важности выполнения каждой задачи, бровь Васи непроизвольно ползет вверх от недоумения. «Как так можно работать?» — читается немой вопрос читается в глазах.

Далеко не каждый начинающий менеджер знает, как работают подходы и фреймворки, с которыми еще не сталкивался. Однако, знания об артефактах, принципах и целях, на которых базируются разные методологии пригодятся не только в споре с друзьями-PM-ами. Владея этой информацией, легче общаться с многочисленными заказчиками и разработчиками, которые только недавно в команде и ранее работали по другой системе, и перейти в другой формат управления проектами тогда, когда старый не работает, не впадая в панику.

Мы не будем навязывать мнение, восхвалять один подход и говорить о недостатках другого. Тогда зачем эта статья? Расскажем, что и с чем едят, а вы уже сами сможете сделать выводы — какой фреймворк подойдет вашему проекту. 

Гибкие подходы

Agile — это гибкий структурированный итеративный подход к управлению проектами. Собственно, отсюда и название — Agile — «гибкий, проворный». На самом деле, это нечто большее. Это не отдельная методология, а целая система гибких подходов, в которую входят не только Scrum и Kanban. 

Ценности Agile:

• люди и взаимодействие важнее процессов и инструментов;
• работающий продукт важнее исчерпывающей документации;
• сотрудничество с заказчиком важнее согласования условий контракта;
• готовность к изменениям важнее следования первоначальному плану.

«Таким образом, не отрицая важности того, что справа, всё-таки больше ценится то, что слева», — подчеркивается в Agile-манифесте.

Agile-манифест — основной документ эджайлистов, созданный в 2001 году, в котором описаны ценности и принципы гибкого подхода.

Принципы Agile

Гибкость Agile в том, что важно ориентироваться на постоянно меняющиеся условия. Поэтому изменения в требованиях не только одобряются, но и приветствуются. Ведь удовлетворить запрос заказчика и принести максимальную ценность пользователям  — главный приоритет. Поставка рабочего продукта клиенту происходит за относительно короткие сроки — от нескольких недель до пары месяцев.

Мотивация — то, на чем держится проект. PM заинтересован в том, чтобы замотивировать команду и обеспечить поддержку владельцам бизнеса. Эффективнее всего это можно сделать на встречах, где передача информации происходит лично, в присутствии всех и вне переписок, чтобы избежать эффекта «испорченного телефона». 

Гибкость гибкостью, но без постоянства тоже далеко не уйдешь. Agile способствует устойчивости. Процесс разбит на равные временные промежутки — итерации. Заказчик получает готовые фичи для своего ПО с одинаковой периодичностью. Пользователи знают, что обновления выходят, скажем, раз в месяц.

Так как команда в Agile самоорганизующаяся, то она самостоятельно анализирует свои действия и корректирует их. Постоянное внимание к техническому совершенству и качеству архитектуры способствует той самой гибкости, которая так важна в Agile. 

Самоорганизующаяся команда — команда, члены которой работают над общей целью и принимают решения самостоятельно, без одобрения кого-то «вышестоящего». Принципы, на которых базируется работа в такой команде, способствуют самореализации каждого из её членов. В команде присутствует доверие друг к другу и вера в целесообразность принятых решений. 

Слышали, что «простота — лучшее качество человека»? Так вот, не только человека, еще и работы. Не делать того, что не прописано в требованиях, — искусство, так как часто хочется добавить «чего-нибудь эдакого». Нужно быть осторожным и вовремя остановиться, ведь добрые намерения могут сыграть злую шутку. Agile не приветствует того, что выходит за рамки, чего-то «сверх-». Поэтому не надо делать лишнего. Просто не надо. 

Как в Agile отслеживается прогресс проекта? Работающим программным обеспечением. Этот пункт включает в себя все предыдущие. Без успешной реализации каждого предыдущего этапа и следования каждому из принципов, на которых базируется Agile, работающего ПО не выйдет.

Популярные Agile-подходы

Нет какого-нибудь достоверного рейтинга «Самые популярные подходы в проджект менеджменте». Те графики, что гуляют по интернету, едва ли можно считать точными. Дело в том, что для достоверных цифр должны быть опрошены PM-ы со всех уголков Земли — от Америки до Китая. Согласитесь, сложновато. 

Еще одно препятствие на пути создания точной статистики — не все понимают, по какому фреймворку работают, как бы смешно это не звучало. Кому-то, у кого команда состоит из 30 разработчиков, которые объединены в одну команду, может казаться, что он работает по Scrum-у. Кто-то думает, что менеджерит по Kanban-у, при этом раздавая каждому участнику роль в команде (спойлер для новичков: так делать в этом фреймворке ни в коем случае нельзя). Кто-то вообще работает без фреймворков в каноническом понимании и ни капли этого не стыдится.

Scrum и Kanban

С такими неточными исходными данными очень сложно определить, какой из подходов наиболее популярный. Опираясь на практику наших студентов, менторов и спикеров менеджерских направлений, наиболее ходовыми из «чистых» фреймворков являются Scrum и Kanban. Гибридные (50% от одного и 50% от другого) и кастомные не брали в счёт. 

Поэтому далее и поговорим об этих двух «игроках» — Scrum-е и Kanban-е. Они как нападающий и защитник в футболе, с разными принципами и схемой игры. Agile как тренер — хотя и «поделился» своими ценностями и знаниями, остался отдельной фигурой. 

Scrum

Возможно, когда кто-то слышит фразу «гибкий подход», в голове появляются яркие картинки хаоса, убегающих от дедлайнов разработчиков и рвущих на себе волосы PM-ов. Scrum, хоть и гибкий, но структурированный подход. Давайте будем как Scrum и разберёмся со всем по порядку.

Scrum-команда: можно ли накормить всех двумя пиццами

Некогда Джефф Безос, создатель Amazon, установил правило: каждая внутренняя команда должна включать в себя такое количество сотрудников, чтобы их можно было накормить двумя пиццами. Дело в том, что продуктивно работать и сотрудничать друг с другом можно, только если в команде будет немного людей. Скажем, 5-9. 

Возможно, в те времена люди ели меньше или пиццы были больше по размеру, но суть этого правила Scrum перенял. Количество человек в команде не должно превышать 9. Если больше — это уже не скрам-команда.

В такой команде существует 3 роли: 

• product owner (владелец продукта), который по сути выступает в роли голоса заказчика;
• scrum-мастер — мастер-джедай, который координирует работу в команде и является своеобразным мостом между продакт оунером и командой разработки;
• команда разработки — самоорганизующаяся и кросс-функциональная. 

Итерации: почему спринты, а не рабочие недели

Scrum — итеративный подход. Итерации называются «спринтами», их длительность определяется на старте проекта и фиксирована до конца. Обычно спринты длятся от двух до четырех недель (очень редко — одну неделю). Чем они короче, тем легче работать с изменениями. Когда спринт 1- или 2-недельный, легче вносить правки в продуктовый бэклог в случае необходимости, чем когда итерация длится 4 недели. Миллионы корректировок нежелательны во время спринта, но возможны. Если выясняется, что задача в работе не так уж важна для клиента и абсолютно нерелеванта для проекта в целом, то она однозначно убирается. 

Зачем вообще нужны эти спринты, когда есть обычные человеческие недели? Чтобы лексикон разработчиков пополнился еще одним словом? Конечно нет, это мерило. За спринт команда должна сделать запланированный скоуп. 

Скоуп (scope) — содержание проекта: что, каким образом и для кого должно быть сделано, чтобы проект считался реализованным. 

Не для всех команд, например, подойдет срок в неделю. На это может быть ряд причин: общее расписание проекта, количество человек в команде разработки, количество задач и т.д. Если в одном проекте спринт может быть двухнедельным, то для другого оптимальными будут четыре. В конце каждого спринта команда презентует заказчику результаты работы. 

Цель фреймворка — закончить спринт, в идеале выполнив все задачи. Самое главное — предоставить клиенту рабочую версию продукта на демо. Бывает, что какую-то из задач не успевают реализовать. Если для того, чтобы фича работала, эта задача не обязательна, не страшно: она перенесётся на следующий спринт. 

Митинги: трата времени или важная стратегическая часть Scrum-а

Митинг. Слово, заставляющее сердца Scrum-мастеров биться быстрее, а разработчиков вздыхать. Последние часто злятся и не понимают, зачем это всё, когда можно просто лишний час поработать. Agile, из которого вытекает Scrum, говорит, что личное взаимодействие важнее и продуктивнее, чем опосредованное. Легче договориться face-to-face, чем в слаке, когда висит 50+ новых сообщений, и уже не помнишь, с чего все начиналось. 

Sprint planning meeting

На этом митинге решается судьба. Нет, не человечества — спринта. На нём присутствуют Scrum-мастер, Product Owner и команда разработки. Владелец продукта рассказывает, какой результат хочет видеть в конце спринта. Разработчики выясняют нужные моменты во избежание миллиона вопросов, которые могут появиться в процессе. Команда разбирается с нагрузкой. Исходя из всего этого определяется цель спринта. Так проходит первая часть митинга. Во второй части команда составляет спринт бэклог — задачи, которые нужно реализовать. 

Длительность митинга зависит от длительности спринта. На собрание по планированию выделяется по 2 часа на каждую неделю в спринте. Если определяем, что спринты будут длиться 2 недели, то на планирование нужно выделить 4 часа. Если весь кофе выпит, спина заболела от долгого сидения на митинге, а длительность перевалила за 8 часов — что-то пошло не так. Задумайтесь: это случайность или есть тенденция затягивать собрания? В случае закономерности скорее всего ваш Scrum нужно масштабировать. 

Daily Scrum Meeting

Ежедневное собрание, которое помогает синхронизироваться членам команды. Именно синхронизироваться, а не пожаловаться, похвастаться или обвинить всех в этом мире. 

Так как Scrum-команда кросс-функциональна, все участники взаимосвязаны. Легче за какие-то 15-20 минут разобраться, кто и как связан в задачах, к кому идти и кто от кого что сегодня ждет, чем на протяжении дня пинговать всех на свете.

Вопросы, которые хоть и повторяются из митинга в митинг, но которые очень помогают понять текущую ситуацию по прогрессу:

• Что было сделано? 
• Что запланировано? 
• Есть ли проблемы, и что может помочь?

Sprint review meeting

Всё, что происходило в спринте, было ради этого. Ревью — двигатель дальнейшего прогресса. Команда разработки наглядно показывает, что было сделано за спринт. Если показать невозможно, то объясняют, как говорится, на пальцах. Такое бывает, когда сделаны технические задачи, которые продемонстрировать не получится, но без которых ничего или не будет работать, или будет, но плохо. После формируются предложения, мнения, жалобы и видение дальнейшего развития. Всё это берется в расчет на следующий спринт.

Время для ревью выделяется прямо пропорционально количеству недель в спринте: для недельного спринта — час, для трёхнедельного — три. 

Sprint retrospective meeting

Скалолаз, который достиг вершины горы, оглядывается на проделанный путь, ловит какие-то инсайты, хвалит себя за то, чего добился. Делает пометки в голове наподобие «В следующий раз нужно купить более надежную экипировку». В Scrum-е это называется ретроспективой. Команда собирается, чтобы выяснить:

• Что было хорошо? 
• Что было плохо? 
• Что можно улучшить?

Ретро проводится в последний день спринта. Не существует каких-то четких временный рамок. Обычно на этот митинг потребуется 45 минут, умноженные на количество недель в спринте. 

Мы рассказали об артефактах, которые холят и лелеют в скраме. Если по какой-то причине у вас с ним не ладится, советуем прочитать статью, в которой скорее всего найдете решение проблемы.

Kanban

Если Scrum — структурный подход, то Kanban можно назвать подходом баланса. Визуальный метод, благодаря которому предельно ясно, за что нужно браться в первую очередь. Здесь целью являются выполнение задачи. Изменения и смещения по плану принимаются безболезненно. Никого пиццами кормить не нужно. В Kanban-е нет ограничения по количеству человек в команде и по длительности итераций, нет командных ролей и обязательных митингов. Что есть вместо этого? Обо всём по порядку. 

Командные роли: есть кто живой

Scrum — не Scrum без Scrum-мастера и других ролей. В Kanban-е всё по-другому. Командных ролей нет, есть «команда». «И за всё, что мы делаем, отвечаем тоже вместе!» — слышали такое? Это девиз команды, работающей по Kanban-у, потому что за ход всего проекта отвечают все. 

Из-за особенностей Kanban-а, о которых поговорим далее, команда может включать в себя несколько узкопрофильных подкоманд: дизайнеров, разработчиков, аналитиков. Не всегда их работа происходит параллельно, особенно на первых этапах разработки. Прежде, чем мастера кодов приступят к работе, дизайнерами уже должен быть разработан прототип, который основан на данных, которые в свою очередь должны быть собраны аналитиками.

Процесс: бездедлайновый хаос

В Kanban-е нет спринтов. Вся работа над проектом происходит непрерывно. Важные проектные события — планирования, релизы — происходят тогда, когда решит команда. Это может быть конкретный день недели, а может быть «делаем это после того, как сделаем это». Таким образом релизы не привязаны к концу итерации. Сделали существенно раньше, чем предполагалось? Отлично! Сделали позже? Бывает. 

Доска Kanban

Свидетели доудалённого периода еще помнят доску Kanban в физическом виде — доску, на которой происходило распределение задач с помощью стикеров или маркера. Сейчас в основном используются электронные варианты. 

Движение задач на доске происходит слева направо: от статуса To Do, где собраны все задачи для реализации, до Done, где задачи достигают своеобразного дзена. Когда все задачи перейдут в колонку Done, считается, что проект готов.

Задачи на доске визуализированы благодаря карточкам, на которых указан приоритет, нужный для понимания очередности выполнения задач. Для того, чтобы мозг не закипел, а команда не работала над задачами 24 часа в сутки, задачи в каждом из статусов ограничены по их общему весу. Вес — мера, которая показывает, сколько времени «весит» задача. Команда сама определяет на начальном этапе, как долго нужно просидеть над задачей, и ставит каждой задаче свой вес. Если в колонке «Testing» ограничение в 3, то общий вес задач в этом статусе может быть 3. 

Статусы Kanban

Благодаря статусам в рабочем чате можно узнать, кто чем занят, а благодаря статусам Kanban — отследить, что и как долго находится на каждом этапе. Статусы существуют для прозрачности и создания ограничения для любителей нырнуть в таски и погрязнуть там, не завершив ни одного. Количество колонок на доске зависит от проекта. Есть основные, а есть опциональные — они добавляются по договорённости исходя из нужд и особенностей проекта.

Основные:

• To Do 
• In Progress 
• Testing 
• Done 

Исходя из потребностей команда может добавить и другие колонки. Например, Blocked — когда задача уже сделана, протестирована, но из-за каких-то ошибок не может быть перенесена в колонку Done как готовая и без багов. 

Что лучше: Agile, Scrum или Kanban

Agile, Scrum и Kanban объединяет мысль о том, что люди — ключевое звено проекта. Помимо взаимоотношений всегда будут принципы, которые будут важны одной команде и абсолютно безразличны другой. Это и отличает их друг от друга. 

Ниже в таблице сравним основные артефакты, которые разнятся в Scrum-е и Kanban-е. Их принципы базируются на Agile, поэтому нет смысла сравнивать базу и два фреймворка, которые вытекают из этой базы.

Мы не задавались целью написать в финальной части статьи «…как вы понимаете, лучше всего работать по…».  Лучше всего в выборе подхода или фреймворка для вашего проекта поможет ваше личное понимание и здравый смысл. Между ценностями подхода в управлении проектами и вашими должен быть мэтч. 

Agile, Scrum и Kanban — иголки в стоге подходов и фреймворков. Возможно ни один из тех, о которых говорили в статье, не подойдет для вашего проекта. Не стоит отчаиваться: существует еще много других на вкус и цвет любого PM-а. О них подробно рассказывают спикеры на курсе Dao PM. Практикующие PM-ы делятся кейсами из практики, впечатлениями от работы в том или ином подходе, еще и визуально показывают, как это работает в реальной жизни. 

Какой бы фреймворк для работы вы не выбрали помните — конечный результат всегда важнее процесса, так что внимательно следите, приближает ли вас практика к желанному завершению.