Июнь, 2015

«Порядочный» код в Scrum

Опубликовано: 08.06.2015 | 3650

Если вы определились с выбором методологии разработки, значит, вы уже видели нашу статью о сравнении каскадной (Waterfall) и гибкой (Agile) моделей. Самое время двигаться дальше и нырнуть в детали! Сегодня мы расскажем о сложностях работы в одной из «гибких» методик – Scrum (Скрам). Оказывается, завалить проект в нем можно на раз-два, а вот построить одинаково эффективные процессы на каждой итерации намного сложнее.

Scrum? Какой такой Scrum?

Scrum – это методика управления проектами, позволяющая в жестко фиксированные и небольшие по времени итерации создать и адаптировать продукт в условиях меняющегося рынка и бизнеса.Для выполнения списка задач в рамках одного цикла-итерации команда выбирает отрезок времени от 1 до 4 недель, он называется спринт.

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

Бэклог

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

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

Вот мы и подошли к основным ролям в Scrum.

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

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

Scrum-команда состоит из разработчиков, тестировщиков, аналитиков, архитекторов и прочих специалистов, нужных для реализации проекта. Идеальный размер команды – 7 человек, плюс-минус ещё 2. За результат работы команда отвечает, как единое целое, никто кроме нее не вмешивается в процесс разработки во время всего спринта.

Кодовая база

Разбор полетов

Многие проекты, которые ведутся в Scrum, стартуют как ракета – быстро и с огоньком. Но потом команда начинает притормаживать, задачи копятся, итерации превращаются в бесполезную болтологию. В такой ситуации проще отказаться от «толкучки» (scrum с английского) раз и навсегда.

Давайте разберемся, от чего разваливается работа в Scrum, и как этого избежать.

В начале у вас маленькая кодовая база. Добавлять новые функции, вносить изменения и держать её в аккуратном виде не сложно. Но чем длиннее код, тем сложнее поддерживать его качество на должном уровне. Разработчики начинают сбавлять темпы под грузом плохо написанной системы. Гиперпродуктивность куда-то исчезает, команда катится прямо в хаос, убивший не один проект.

Солнце зашло, мораль упала, Scrum люто ненавидят и заказчики, и менеджеры.

А дело в том, что для грамотной работы в рамках выбранной методики разработчики должны делать всего две вещи, но одновременно:

  • Писать код в одинаково быстром темпе,
  • Сохранять его чистым.

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

Программирование

Нужно мотивировать людей на результат ачивками (достижения в играх), т.е. геймифицировать процесс работы. А чтобы составить полноценный игровой рейтинг, нужны цифры.

Давайте измерим показатели скорости и чистоты. Если команда работает в хорошем темпе, но нагромождает ненужные строки кода, она остается без «плюшек». Если кодовая база в порядке, но разработка ступорится, никакой награды. Ребята-девчата пишут быстро и чисто? Это поощряется!

Мы можем измерить «кодовый беспорядок», используя практику разработки через тесты (TDD).

Бухгалтеры, двойная запись и TDD

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

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

Разработка через тесты – аналог двойной записи в программировании. Если ваша команда практикует TDD (Test driven development), вы найдете, что измерить:

  • Объем тестов. Тестовые методы должны состоять примерно из 5-20 строк кода. Общий объем качественного тестового кода примерно равен объему системного кода.
  • Скорость проведения тестов. Качественно написанные тесты отрабатывают за минуты, а не за часы. Быстрые тесты поощряем!
  • Дефектность тестов. Следите за тем, как тесты справляются с изменением кода продукта. Если абсолютное большинство падает, то команде нужно поработать над тест-дизайном.
  • Время без падений билда. Считайте дни месяца, в которые билд упал. Награждайте команду за месяцы без сбоев и измеряйте время, потраченное на исправление косяков.
  • Дублируемый код. Мы советуем использовать средства статического анализа (Checkstyle, FindBugs), чтобы определять слабые места в коде и количество дублируемых строк.

Дублируемый код

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

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

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