Если вы определились с выбором методологии разработки, значит, вы уже видели нашу статью о сравнении каскадной (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), вы найдете, что измерить:
Ок, а что теперь делать со всеми этими измерениями? Составьте графики, нарисуйте инфографику с метриками и повесьте огромные плакаты на стенах: на кухне, проектной комнате, в каждом офисе и кулуарах.
Отмечайте достижения намеченных целей специальными «вечеринками», поощряйте всякими приятными и полезными штуками. Нам кажется хорошей практикой тимбилдинга напечатать, например, футболки с именем проекта и надписью «500 идеальных тестов». Покажите людям, что им есть, для чего стараться, что успехи каждого означают успех всего проекта, что продуктивность будет замечена и вознаграждена!
Как видите, работа в Scrum не так проста, как хотелось бы думать. И одним из самых больших нюансов здесь, как и в любой другой методологии разработки, является человеческий фактор. Помните, что любая эффективная методика на словах в реальном мире провалится без правильного управления командой, тесной взаимосвязи разработки с тестированием и, конечно, чистого лаконичного кода.
Предыдущая статья
5 «плюшек» аутсорсинга для СЕО
Следующая статья
Тренды электронной коммерции 2015-2016
WebmartSoft 
+375 (29) 740-06-29