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

Когда Scrum получал всё более широкое распространение, многие команды перенимали его ценности, но не принципы. Для них это был жёсткий процесс, а не подход к формированию наиболее оптимальной именно для них схемы разработки. Многие команды внедряли его, чтобы измерять и максимизировать производительность, элегантно подгоняя процесс разработки под традиционную модель, где он выглядит как поток, последовательно проходящий несколько этапов. Такой метод иногда называют мини-каскадной моделью разработки. Всецело сосредоточившись на оценках, диаграммах сгорания задач и скорости, но забывая об основополагающих принципах (рефлексии, систематическом поиске и тестировании новых способов повысить эффективность), команда рискует растерять все преимущества гибких методологий.

Мини-каскадная модель разработки

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

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

Кто такой владелец продукта (Product Owner)

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

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

Кто такой скрам-мастер (Scrum Master)

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

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

Скрам-мастер следит за тем, чтобы команда в действительности следовала принципам гибкой разработки, а не догматике скрама.

Планирование спринта

Митинги по планированию спринтов проводят для того, чтобы выбрать задачи на текущий спринт, чётко обозначить объём работ и создать план действий, который не будет нарушаться или изменяться в течение спринта, а также убедиться, что все члены команды понимают критерии готовности элементов.

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

Цель «планировочного покера» — не договорить об одном жёстком показателе продуктивности, а оценить то, насколько хорошо продуманы и чётко очерчены задачи. Очки используют не для расчёта затрат, а для определения сложности работ. Если история спринта получает 3 очка, значит, неизвестных переменных нет и работу будет выполнить несложно, а если 8 — будет много зависимостей, неизвестных, размытых условий или сложностей с интеграцией кода. Цель этого этапа — выявить, какие истории нужно разбить на части, детализировать или подробнее изучить для более глубокого понимания.

Пики (Spikes)

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

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

Ежедневные совещания

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

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

Ретроспективное совещание

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

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

Есть надёжная модель проведения ретроспективных совещаний «Stop, Start, Continue». Команда разбивает процесс коммуникации и разработки на проекте на элементы и анализирует их. Это отличная возможность выявить факторы, которые снижают продуктивность команды, а также найти способ нивелировать их. Например:

«В прошлом спринте мы пытались выполнить задачу со сложностью 8, но в самом начале разработки поняли, что нам придётся использовать некоторую неизвестную технологию. Понадобилось больше времени, чем мы ожидали, чтобы разобраться с ней. Из-за этого мы выбились из графика и не выполнили задачи X, Y и Z, а также пришлось сжать цикл тестирования, чтобы завершить спринт в срок».

«Чтобы такого больше не произошло, нам следует заранее тщательно исследовать и продумывать наиболее сложные задачи, по возможности делить их на более простые, и выделять достаточно времени, чтобы изучить всё неизвестное, прежде чем приступать к спринту».

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

Слово «stop» в этой модели означает необходимость выявить проблемы в скрам-процессе и возможности его непрерывного улучшения, «start» — придумать план решения проблемы, а «continue» — проверить его действенность на практике и интегрировать в дальнейший процесс. Это основа гибкой методологии разработки программного обеспечения.

Непрерывная поставка готового ПО

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

Чтобы команда могла стабильно поставлять ценное ПО:

1. она должна быть способна быстро тестировать и развёртывать ПО, не прерывая цикл разработки. Для этого нужно хорошо отладить процесс автоматического тестирования и конвейер непрерывного развёртывания;
    
2. очередная версия ПО в рамках задачи должна быть полностью готова к поставке перед закрытием пользовательской истории и удалением из бэклога. Поэтому истории должны быть составлены так, чтобы их можно было разбить на серию более мелких, полезных функций;
    
3. полный набор автоматизированных тестов гарантирует, что после развёртывания не перестанет работать уже имеющийся код;
    
4. архитектура должна содержать как можно меньше сильных взаимозависимостей, чтобы команда могла быстро развёртывать новый код без риска нарушить существующий.

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

Отмечать успехи

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