Когда и зачем внедрять Scrum и Kanban?

Многие задаются вопросом: почему Scrum, что это означает? Это часто встречающийся вопрос, мой ответ тоже не будет новым, Америку я, конечно, не открою, но все же. На самом деле, достаточно давно было замечено, что проекты, над которыми работают небольшие команды специалистов различного профиля, систематически показывают лучшие результаты. В регби есть понятие «схватка» (scrum). Целью схватки является возобновление игры после незначительного нарушения или ее остановки. Схватка формируется на игровом поле. От каждой команды участвуют по восемь игроков: они обхватывают друг друга руками, выстроившись в три линии и сомкнувшись с соперниками. По сути ничего не напоминает? Как по мне, так это описание работы в Agile-команде, а также описание кроссфункциональной команды. Именно по этой причине в гибкие методологии перекочевал термин из регби.

Основной принцип работы в Scrum — итеративная разработка. После каждой итерации формируется рабочий продукт, который уже можно использовать, и появляется моментальная обратная связь от заказчика и конечных пользователей, после получения которой есть возможность скорректировать продукт. Огромный интерес к данной методологии возник в начале 2000-х годов, а до этого все использовали ставший уже классическим метод водопада (waterfall). Что он собой представляет?

Ключевой принцип каскадной модели — последовательное выполнение работ: вначале анализ (подготовка функциональных требований), затем разработка, потом тестирование, стабилизация и вывод на продуктив. Основное различие между waterfall и Scrum в том, что уже по завершении первых итераций Scrum-команда выдает готовый инкремент продукта, которым может пользоваться заказчик/пользователь.

Приведу наглядный пример. Вернемся во времена Наполеона и разберем, какие шаги надо выполнить для того, чтобы выстрелить из пушки. Что мы делаем? Сначала выкатываем пушку на позицию, далее целимся, заряжаем и стреляем. А затем наблюдаем и оцениваем, насколько точно попали в цель (да и вообще — попали ли). Если точность нас не устраивает, придется все начинать сначала. Данный пример иллюстрирует работу по методу водопада.

А теперь рассмотрим выстрел с использованием самонаводящейся ракеты. Из каких шагов он состоит? Я думаю, примерно из следующих: определяем координаты цели, передаем их в ракету, а дальше — запуск. Ракета взлетает и устремляется в направлении к цели. Она постоянно корректирует свою траекторию, чтобы не столкнуться с препятствием и максимально точно попасть в цель. На что это похоже? Да на работу в Scrum, так как на всем отрезке пути от точки А до точки B мы корректируем свой курс, чтобы попасть в цель, а именно — сделать тот самый продукт, за которым обратился к нам заказчик. Грамотное использование фреймворка Scrum позволит в сжатые сроки дать заказчику инструмент, который уже позволит решать поставленные задачи.

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

Так какой фреймворк лучше? Думаю, не стоит формулировать вопрос именно так. Почему? Потому что эти инструменты призваны решать конкретные узкоспецифичные задачи. Если нам надо закрутить шуруп, мы не будет делать это топором. Лучше взять отвертку — будет удобнее и быстрее. Поэтому всегда надо выбирать подход с умом и понимать, что универсального инструмента не существует — волшебную палочку еще не изобрели. Наш опыт говорит, что Kanban оптимально подходит для доработки готовых продуктов, а Scrum — для разработки продукта с нуля. А что говорит ваш опыт?

А теперь поговорим о темной стороне Луны — о проблемах, которые могут возникать при использовании фреймворков.

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

1. Сложности в мотивации команды

Одна из сложностей внедрения фреймворков, да и любых новых методов, — принятие новых правил игры всей командой. Расскажите людям, как теперь будет строиться их работа, что в ней изменится и какие требования будут предъявляться, и будьте готовы к тому, что не все сотрудники согласятся с предложенными нововведениями. По нашему опыту, на этом этапе команду покидают примерно 17–20% участников (это верхний предел).

Например, у нас в штате был очень талантливый разработчик. Когда стартовал один из наших проектов, мы приняли решение вести разработку по методологии Scrum. Провели ряд встреч, объяснили новые правила и начали работать. Дальше наступил этап «отрицания» Scrum. Тот самый талантливый разработчик искренне пытался перестроиться, но, увы, не смог. В чем честно признался. Пришлось вывести его из команды, хотя нам этого очень не хотелось, но решение было принято. К тому же мы понимали, что Scrum — это командная работа и ее результат зависит от коллективных усилий, а не от достижений отдельных сотрудников. В результате команда отлично отработала и успешно закрыла проект.

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

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

2. Заказчик не видит ценности в работе Scrum-мастера

А вот это — самая тяжелая проблема, с моей точки зрения. Произвести расчет монетизации работы Scrum-мастера и суметь донести смысл этих аргументов до заказчика — очень непросто (врагу не пожелаешь!). Одна из главных задача Scrum-мастера — выстраивать эффективную коммуникацию между командой и заказчиком, убирать на пути команды все препятствия, которые мешают ей достичь поставленной цели. Как правило, для заказчика это просто слова. Ведь от этой работы у него ничего не остается — никаких артефактов. А с другой стороны, если между командой и заказчиком, а также и в самой команде нет взаимопонимания, на финише выходит полный рассинхрон. В этом случае качество артефактов, за которые заплатил заказчик, оставляет желать лучшего. Это как в басне Крылова «Квартет»: пока команда не научится слушать и слышать друг друга, сыграть красиво у них не получится. И Scrum-мастер как раз и выполняет функции дирижера (в дополнение к остальным задачам). Показателем эффективности его работы является то, насколько успешны спринты, насколько точно команда попадает в цель. Высший пилотаж — когда команда работает как швейцарские часы, а присутствие Scrum-мастера совсем незаметно.

Очень важно донести до заказчика мысль о том, что все роли Scrum-команды важны и нельзя изменять ее состав. Данная практика не приведет к положительным результатам, так как у каждой роли есть своя зона ответственности, а нарушая такое распределение, мы напрямую негативно влияем на успех проекта.

Зачем платить деньги за «беседы»?

В среднем мероприятия Scrum (планирование, предпланирование ретро и демо, Scrum-митинги) занимают 10–12% рабочего времени команды за спринт. Чаще всего заказчик не готов платить деньги за «разговоры», он готов оплачивать время «чистой» работы (например, время, в течение которого разработчик пишет код или аналитик пишет текст). В такой ситуации поможет только диалог с привлечением фактов из положительной практики использования предложенного фреймворка в аналогичных проектах. Наберитесь терпения, соберите «доказательную базу» и убедите заказчика в том, что отказываться от подобных «бесед» не стоит.

Как решать проблемы подобные тем, что описаны выше?

• Не верьте в панацею. Фредерик Брукс еще в 1986 г. в своем труде говорил, что «серебряной пули нет». Но спустя 33 года все еще находятся те, кто верит в существование волшебной палочки, один взмах которой решает все проблемы. Может, она и существует, но это точно не Scrum или Kanban.

• Приводите факты. Учитесь находить факты и правильно их преподносить «сомневающимся» людям. Если вы действительно уверены в том, что ценность и польза от внедрения гибких методологий больше, чем «вред», который возможен как следствие возникших проблем, то потратьте время, соберите достаточное количество фактов и развейте все сомнения, возникшие у заказчика или финансистов вашей компании.

• Договаривайтесь. Учитесь выстраивать правильные диалоги со всеми заинтересованными сторонами, иначе можно потерпеть неудачу уже на старте внедрения Agile-методов. Например, перед началом всех работ обязательно детально обсудите новый подход с командой и всеми остальными заинтересованными участниками данного проекта. Зафиксируйте достигнутые договоренности.

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

Наш опыт: от LeSS до ScrumBan

Наша практика показывает, что использовать Scrum и Kanban в чистом виде целесообразно только на определенных видах проектов, процент которых в общем объеме низок. Так что мы кастомизируем эти фреймворки под конкретные проекты. Например, максимальная численность Scrum-команды должна составлять не более 10 человек. Но такое количество сотрудников просто не способно быстро реализовать масштабные проекты, и их выполнение может растянуться на годы. К примеру, мы разрабатывали ИБ-решение для крупной государственной организации. У нас были очень сжатые сроки — полтора года, хотя, по нашим оценкам, на подобный проект стоило закладывать 3–3,5 года.

Это была разработка с нуля, поэтому мы решили использовать Scrum. Команда проекта постоянно росла и в итоге составила 30 человек, что втрое больше, чем рекомендуется в рамках Agile. Подход начал буксовать: Scrum-митинги длились уже по 30–40 минут вместо положенных 15. Тогда мы разделили команду на подкоманды для создания модулей продукта и в каждой выделили представителя, который участвовал в общих встречах.

В дальнейшем было сделано еще несколько тонких настроек. Мы стали использовать фреймворк LeSS (Large-Scale Scrum) — подход, позволяющий применять принципы Scrum для больших команд. Затем, когда начался этап опытной эксплуатации, мы сформировали ScrumBan, объединив лучшие практики Scrum и Kanban. Например, мы ставили ограничение по количеству задач (Kanban) и продолжали личные встречи с заказчиком (Scrum).

Итак, гибкие методы разработки:

1. Ускоряют работу над проектом. Команда регулярно получает обратную связь от заказчика. Грубо говоря, мы шаг за шагом идем «от скейта к мотоциклу»: поэтапно дорабатываем функционал продукта, наращиваем его возможности.
   
   
2. Улучшают коммуникацию. Чаще всего заказчик приходит с конкретной болью —назревшей проблемой, но не всегда может четко сформулировать задачу. Agile-методологии позволяют лучше понять, какой продукт и с каким функционалом ему необходим.
   
   
3. Повышают прозрачность. Если разработка ведется по «водопаду», заказчик не знает, на каком этапе в данный момент находится исполнитель. Используя Scrum, команда после каждой итерации выдает готовый продукт, которым можно пользоваться.
   
   
4. Улучшают психологический климат в команде. Когда участники команды видят, что за короткий срок разработали жизнеспособное решение, они готовы по полной вкладываться в другие проекты.