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

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

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

    Последнее детище нашей компании – ATI, в миру известный как Acronis True Image. Этот продукт довольно давно в разработке – настолько, что мы успели написать о нем на Хабр не одну, не две и даже не три статьи (четвертую найдите сами). Команда разработчиков ATI достаточно внушительная, а потому у нас накопился большой опыт управления подобными проектами.

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

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

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

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

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


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



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

    Scrum


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

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

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



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

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

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

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


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

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

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

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

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

    Kanban


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

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



    Выводы


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

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

    Each projects deserves it's methodology of development
    (мантра команды разработчиков Acronis)
    Acronis
    Company

    Comments 24

      0
      Что вы делаете с задачами которые не «умещаются» в один спринт? А подзадачи этой задачи невозможно демонстрировать (как итог спринта) т.к они не самодостаточны.
        0
        Например?
          0
          Ну пусть юзер-стори «хочу бэкап на Луну, боюсь ядерного взрыва». Оценка 50-80 человеко-месяцев на самый простой канал до Луны. Раньше, чем через 2 месяца, вы ничего не можете показать.
            +3
            Даже простой канал до Луны не строится мгновенно и в одно действие. Такой высокий уровень абстракции легко разбивается на подзадачи, а если речь идет о разработке ПО, декомпозировать задачи до 8-16 часовых подзадач — дело вполне реальное.
              +1
              Дополню.
              Показать же можно уже через спринт какое-то цельное и работающее решение. Пусть оно будет в виде тележки, подвозящей провод от генератора к площадке запуска, но оно будет работать.
                +1
                Задача разбивается на подзадачи, это понятно. Но пользовательскую историю как разбить на под-истории?

                Важное требование к нашим историям – их размер: одна история должна укладываться в один спринт.

                Что если не укладывается? Вот конкретно, с Луной :)
                  +1
                  тут вы правы и не правы одновременно. можно разбить, но только это будет не совсем пользовательская история в таком случае в прямом понимании термина. поясню на примере:

                  делали per-to-per передачу данных с одного компьютера на другой через интернет(через NAT и так далее), разбили примерно так:

                  1. два компа нашли друг друга в инете
                  2. передали просто текстовое сообщение с одного на другое

                  дальше уже пошли более осмысленные истории близкие к конечному пользователю.
                    0
                    Ну понятно, т.е. тоже можно показать результат по спринту. Вопрос был в том, как вы поступаете, если показать нельзя. Похоже, что ваш ответ — таких случаев не было :)
                      0
                      думаю были случаи, когда нельзя было показать, но в целом стараемся хотя бы что-то, но показать…
                        0
                        А вам действительно надо что-то показывать в конце спринта? Вы же не отдаете продукт конечному пользователю каждый спринт? Может тогда и время на это не тратить? Ведь основной момент — это понять, что конкретно было сделано за спринт, где вы находитесь, и где находится весь проект с точки зрения end-to-end продукта. Или я что-то пропустил? Это можно понять и по состоянию тест плана. Или нет?
                          0
                          В целом внешнего требования показать что-то в конце спринта нет, но мы стараемся все таки устраивать такие показы, чтобы команда видела прогресс.

                          чтобы понять где находится весь проект, мы используем burn-down на весь проект. Он, конечно, дает весьма примерное понимание, но так как у нас проект сопровождается постоянными изменениями, то в целом этого достаточно.
                            0
                            А вехи (milestone) какие-то внутри девелопмента есть?
                              0
                              да, альфа, бета1, бета2, бетаN, RC, RTM, GA. обычно примерно так.
                0
                Что значит не могу? Еще как могу. Если бекапим на какой-нибудь луноход, который уже на луне — сделаем аплоад и даунлоад одного килобайта. Если строим с нуля — прототипируем передачу килобайта на соседнюю гору. Всегда есть следующий маленький осмысленный шаг.
            0
            Процессы внедряются сверху вниз или снизу вверх?
              0
              да по разному, смотря какая проблема вылезла.
              0
              Спасибо за статью. Практический опыт — это всегда интересно. Жаль только, мало кармы плюсануть -)

              Хотелось бы узнать: как бы Вы охарактеризовали уровень сложности ваших проектов? В любой удобной для Вас форме.
                0
                затрудняюсь ответить, честно говоря, есть свои нюансы. сроки, наличие старого кода, кроссплатформенность.
                0
                Важный момент: продукт должен быть выпущен точно в срок не позднее фиксированного момента времени.

                А чем это обусловлено конкретно в вашем случае?
                  0
                  Бизнесом в первую очередь, в определенный момент времени можно заработать денег, если выйти с новым решением.
                  0
                  Когда прочитал «3. Четкие цели на спринт для всех участников проекта». Появилась мысль, что цели ставятся для каждого члена команды отдельно. Отсюда появился вопрос «Как обстоит дело с достижением общей цели на спринт?». И ниже читаю «Внедрение описанных выше механизимов обнажило другие проблемы: рассинхронизация команды и расфокусирование отдельных ее членов». Поэтому хотелось бы уточнить как вы до этого цели ставили? Например, Вася, ты делаешь вот это и это. Петя с тебя вот это и то. И т.д. Или это было в каком-то другом виде?

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

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

                    второй абзац: Версии в SVN, каждые полчаса проверка сборки билда и урезанный набор тестов. Каждую ночь полная пересборка и прогон большого BVT, два раза в неделю прогон «Общих» автотестов, он занимает до полутора суток. Таким образом тестируется регрессия. Оно делается не для каждого изменения, так как за день может быть несколько комитов, но все же довольно часто. Есть еще ручное тестирование, там отдельные уровни тестирования.

                    третий абзац: Да, не про скрам, ну так я и описывал как мы эволюционировали =). Нам как раз нужна быстрая адаптация к новым требованиям. Ну вероятно можно сказать относительно быстрая, но все же. Спецификации и мокапы да, стараемся писать до начала спринта, но не всегда получается. Выходим из ситуации рассказывая на грумингах как и что собираемся сделать.
                      0
                      Понятно, спасибо. =) А сколько у вас человек в одной scrum-команде?
                        0
                        примерно 7-10, больше уже плохо.

                  Only users with full accounts can post comments. Log in, please.