There is no silver bullet, или как мы от водопада до Канбана через скрамовые аджайлы дошли

В данной статье я бы хотел поделиться опытом использования разных методик управления разработкой (Waterfall, Scrum, Kanban) в компании Acronis и рассказать, чем был обусловлен выбор той или иной методики или практики.

Для начала пара вводных слов. Цикл разработки продукта у нас в Acronis, как правило, длится от полугода до года. В разработке принимает участие команда из 40-45 человек. Сам продукт является системным приложением, а основная разработка идет на C++. Важный момент: продукт должен быть выпущен точно в срок не позднее фиксированного момента времени (да-да, и такое бывает). Команда разработчиков ATI достаточно внушительная, а потому у нас накопился большой опыт управления подобными проектами.

Итак, когда-то очень давно у нас была классическая «водопадная» модель разработки:
Требования -> Дизайн -> Реализация -> Тестирование и стабилизация -> Поддержка.

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

Дальше речь пойдет о гибких методологиях разработки. Забегая вперед, отмечу: гибкие методологии с короткими итерациями подталкивают команду к созданию не очень правильных с архитектурной точки зрения решений: начинает накапливаться технический долг, который рано или поздно придется выплачивать. Да и, честно признаться, в 2004-2006 г. в России (да и в мире, наверное) еще не были столь популярны и известны Agile или Scrum.

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

##Agile. Длинные итерации

Для начала мы решили перейти к итерациям длиной в 1-2 месяца, чаще 2. Каждая итерация была, по сути, небольшим каскадным подпроектом. В первую итерацию мы брались за важную и труднореализуемую функциональность, в следующие – за менее важную, и так далее. Получалось, что последнюю итерацию мы часто отбрасывали и посвящали это время стабилизации. Положительный результат был налицо – проект стал более предсказуемым.

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

##Scrum

По мере работы над проектами сами собой стали рождаться практики, необходимость которых мы ощущали на себе. Так, мы заметили недостаток коммуникаций в проекте: некоторые члены команды проявляли склонность к написанию “велосипедов”, дублированию кода или затягивали сроки, поскольку стеснялись уточнить детали. Заметив это, мы решили проводить утренние встречи, чтобы обсуждать проблемы прошедшего дня и планы на день сегодняшний. Так, ничего не зная тогда о Scrum, мы ввели один из его элементов в работу. Причем методика была воспринята довольно положительно самими разработчиками (что, как известно, случается далеко не всегда). Думаю, это связано с тем, что подход решал в тот момент наши насущные проблемы.

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

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

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

Спринт на 2-3 недели. Недавно мы решили, что все-таки эффективнее по 3 недели;
Каждый спринт включает перепланирование, демонстрация и ретроспектива;
Четкие цели на спринт для всех участников проекта.

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

##Пользовательские истории

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

Предположим, мы получили это описание. Дальше это описание нужно осмыслить проект-менеджеру, разработчикам, тестерам. Одним необходимо завести задачи на девелоперов, чтобы все это реализовать, другим — написать массу тест-кейсов, чтобы протестировать. Возникает главный вопрос: как понять, что требование выполнено? Вот именно для этого мы и решили описывать истории и пользовательские сценарии.

Типичный формат наших историй выглядит примерно так:

Проблема пользователя, которую история призвана решить;
Сама история;
Проверочный лист.

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

##Kanban

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

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

##Выводы

Основной наш посыл к читателю: сначала — понимание проблемы, а только потом – ее решение.
Я довольно часто вижу стремление выбрать один из методов ради метода, а не ради результата или решения проблем. Поэтому в этой статье я постарался описать на конкретных примерах, для чего необходима и когда уместна та или иная методология.
Каскад – для ортодоксальных классиков, адептов кода.

Agile – для команд, особенно неравнодушных к процессу, с грамотным руководителем и гуру тайм-менеджмента во главе.
Scrum – для команды с налаженной коммуникацией, четкой системой ролей и взаимозаменяемостью. И, что немаловажно, эта система подходит заказчику, который готов перенять ваш ритм работы и участвовать в совершенствовании процессов.
И, наконец, Kanban – для команд, готовых решать большие задачи при отсутствии таймбоксов; то есть для тех, кому важнее всего минимизировать объемы work in progress.