Agile и «водопад», или История одного изменения
Не открою Америку, если скажу, что типичный заказчик, по крайней мере для ИТ, хочет двух вещей: предсказуемости от проекта и работающего продукта. Также не открою Америку, сказав, что в реальной жизни добиться этого достаточно сложно. Особенно если ты исполнитель. И особенно если ты привык работать «по водопаду»...
В самом начале
Дело было достаточно давно. Деревья были выше, небо ближе, а проект только начинался. Большой заказчик, большая задача, большие надежды заказчика, энтузиазм исполнителя и амбиции команды с обеих сторон. Как водится, был договор и было ТЗ. Достаточно абстрактное «Система должна…» и никакой особой конкретики. Продавцы решили, что конкретику можно привнести по ходу, главное — продать! И даже список систем, с которыми планируется интеграция, «необходимо определить при реализации». Про архитектуру — тоже почти ничего, кроме разве что «развернуть систему необходимо на таком-то программно-аппаратном комплексе, в такие-то сроки». Про интерфейсы — небольшое упоминание в разделе «Эргономика»: «должны быть, соответствовать, быть удобными». Всё. Словом, типичное «приложение к договору», которое не изменить никак. Да, и сроки. Первая, вторая и третья очередь с жестко установленными сроками — и санкциями за срыв.
В общем, ситуация, которая для «водопадной» модели разработки не подходит просто по определению (точнее, подходила бы, если бы сроки умножить на два, а лучше на три). Но на тот момент другой модели в работе просто не было. Поэтому начали с того, что есть. То есть попытались применить героизм. В данном случае героизм состоял в том, что первые две недели честно пытались работать «по ТЗ». Привело это к тому, что аналитики выли волками, архитектор искал веревку и мыло, разработчики оттачивали мастерство, создавая разные «заделы на будущее». Но вот с точки зрения управления проект разваливался, потому что, кроме контрольных точек в ТЗ, понимания по конкретике так и не прибавилось. А заказчик ненавязчиво интересовался, когда на его серверах будет развернута боевая промышленная система? Хотя бы первый прототип.
В итоге было принято несколько важных решений. Во-первых, создать стенд у заказчика, с высокой степенью готовности к непрерывной интеграции (тогда, правда, этот термин только входил в обиход, являясь уделом избранных). Во-вторых, необходимо было конкретизировать ТЗ, по крайней мере в части результатов первого этапа по договору (надо же было что-то сдавать). В-третьих, к обычному принятому трехуровнему ландшафту (разработка — dev-тестирование — тестирование) добавить шлюз непрерывной интеграции на стенд заказчика. До того, естественно, построить сам стенд. Все это было прекрасно, но не отвечало на главный вопрос: что именно разрабатывать прямо сейчас? И как разрабатывать?
Творческая трансформация Agile
Для того чтобы ответить на эти вопросы, были рассмотрены несколько моделей. «Водопад», по которому работать умели, и умели неплохо. Итерационная. И Agile. Собственно, уже на старте (а если точнее, то еще до старта) было понятно, что водопадная модель в данной ситуации просто не сработает, хотя ТЗ и договор готовились именно в концепции «запускаем к такой-то дате». Итерационная модель рассматривалась более серьезно. Можно было, например, пойти путем проработки части ТЗ, его реализации, исправления по итогам доработки второй части и т. д. Перспектива в этом случае выйти на результат выше, чем при работе по водопадной модели. Но и риски не завершить проект тоже выше. Все-таки итерационная модель предполагает изготовление достаточно крупных «кусков» системы, и, следовательно, возможность для разработки «уйти в сторону» — выше. Получается, что для снижения этого риска итерации должны быть минимальные по времени. Путем несложных расчетов было установлено, что при заданных параметрах минимальная итерация составит 9–10 недель. Или около пяти-шести итераций в год. При сроке проекта в два года, это порядка десяти итераций. (В реальности — меньше, так как есть контрольные точки, не совпадающие с идеальным делением.). То есть цена одной ошибки «уйти не туда» — достаточно высока. В итоге вспомнили про Agile.
Вообще-то на первых обсуждениях, казалось, что Agile — «не наш случай», потому что он предполагает фокус на продукте, функциональности при заранее не определенных требованиях. Но как оказалось впоследствии, именно Agile помог разрешению ситуации. Правда, для этого его пришлось малость модифицировать.
Во-первых, бэк-лог был творчески трансформирован. Появился общий бэк-лог в соответствии с договором и привязками к датам. Во-вторых, появился бэк-лог ТЗ, из расчета, что для каждого следующего спринта требования в виде части ТЗ будут готовы на выходе предыдущего. В-третьих, была разделена деятельность по подготовке ТЗ и разработке (ТЗ готовилось параллельно, на каждый следующий спринт). В-четвертых, Product Owner’ом стал ведущий аналитик. Длительность спринта была определена в две недели, по истечении которых заказчик получал готовый прототип и кусок ТЗ на очередной этап. Такое задание рассматривалось в течение одного дня (это было принципиально) и возвращалось либо с одобрением, либо с правками. Спринт ТЗ был смещен на два дня «в прошлое» по отношению к спринту разработки — таким образом ТЗ на новый спринт было гарантированно поставлено к началу разработки следующего. Усилили блок аналитиков, так как после первых итераций стало понятно, что аналитика требует существенно больше планируемых изначально ресурсов. Назначили Master Product Owner - представитель Заказчика, который осуществлял вычитки ТЗ, приемку работ, демонстрацию системы будущим пользователям, сбор от них обратной связи. Наладили процесс управления изменениями: запросы на изменение регистрировались, анализировались, и либо попадали в бэк-лог ТЗ, либо откладывались для рассмотрения на проектном комитете — специальном органе заказчика и исполнителя, который собирался раз в неделю и обсуждал ход проекта. Важным отличием от классического Agile стало то, что весь процесс был «заточен» на поставку в соответствии с изначальным, приложенным к договору техническим заданием, точно в обозначенный срок. Вторая цель — обеспечение качества результата. Еще одно отступление от Agile — то, что в результате спринта появлялся результат, который в ряде случаев выглядел для заказчика как «то же самое». Например, спринт, посвященный созданию интеграционных «заглушек», ничего нового не привнес в интерфейс. Особенно это касалось так называемых системных спринтов, когда дорабатываются объекты ядра системы.
О сложностях
Какие были сложности? Условно, их можно разделить на три части.
Недооценка объема. На старте было трудно оценить реальный объем необходимых работ. Поэтому проект хоть и был завершен с прибылью, часть ее пришлось пустить на оплату того самого незапланированного объема (но, к счастью, за границы предполагаемого резерва на потери проект не вышел).
Человеческий фактор. Пользователи зачастую не понимали, «зачем оно», когда «и так все хорошо работает». И аргументы, что по итогам проекта работать станет проще, воспринимались в штыки. Эта позиция транслировалась на руководство проекта со стороны заказчика. К счастью, те стойко держали оборону и не «велись» на подначки. Кстати, следует отметить: после перехода на систему, которая явилась результатом проекта, пользователи с таким же энтузиазмом начали засыпать руководство предложениями по ее улучшению и всячески пиарить внутри компании. Нужно особо подчеркнуть, что с пользователями проводилась отдельная работа — с членами команды как исполнителя, так и заказчика. Она сводилась к миссионерству, анализу возражений и демонстрации возможностей системы (они превышали функциональность ранее используемых систем, не говоря уже об удобстве и скорости).
К «человеческим» сложностям надо отнести и дополнительные требования, либо не входящие в первоначально заданный объем проекта, либо вообще не относящиеся к теме. Наивно было бы полагать, что их вообще не возникнет. Но вот реальное количество спрогнозировать оказалось действительно очень сложно. Особенно то, что допотнительных требований будет настолько много. В проекте был некий резерв, предусматривающий подобные неожиданности, но уже спустя несколько недель после старта кампании по выдаче обратной связи стало понятно, что заложенного бюджета на все не хватит. Так что пошли по пути «сделаем, что можем, не расходуя резервы» и «расход резерва только и исключительно по согласованию с заказчиком». Это вообще-то не очень вписывается в Agile, но такой подход позволил соблюсти ограничения проекта, по максимуму не теряя в функциональности и наращивая степень удовлетворенности пользователей.
Последние трудности — технологические. На них подробно останавливаться не буду, скажу лишь, что они также есть практически в каждом ИТ-проекте, где имеется новый продукт и много разнообразной интеграции. Наладка, настройка шлюзов, разрыв между спецификацией и реальными данными, низкая производительность шлюзов интеграции, перенастройка на ходу — все это было. Но все это было успешно решено. Тут, кстати, очень помог псевдо-Agile — при двухнедельном цикле работ обновления имели хорошие шансы успеть за реальностью, постепенно сокращая технологический разрыв до идеального (или близкого к нему) состояния.
Под капотом методологии
Еще немного о том, что было «под капотом». Про цикл разработки. Продукт разрабатывался на dev-стенде. Было введено понятие «минорная версия», то есть некая версия, которая в рамках спринта ставится заказчику. Продукт разрабатывался по принципу максимально изолированных платформенных сервисов. Заказчику в конечном итоге направлялся пакет с новыми либо обновленными сервисами. После того как разработка начерно закончена, сервис отправляли на стенд dev-тестирования, где силами разработчиков проводилась проверка основной функциональности и на ночь запускался автотест. Затем сервис переносили на стенд тестирования. Там он тестировщики и аналитики выполняли необходимые процедуры. После чего при положительных результатах сервис включали в состав «бандла» (он же минорный релиз), который через систему непрерывной интеграции поставлялся на стенд заказчика. Отдельная сложность была именно с сопровождением и настройкой этого стенда, по крайней мере в части интеграции. Но данный участок работы взяли на себя специалисты заказчика из числа тех, кто впоследствии планировал выполнять работы по сопровождению поставляемого продукта.
Что в итоге? По основной функциональности проект сдан вовремя, но, несмотря на это, часть важных, но не срочных дополнительных функций была реализована за рамками согласованного времени (по дополнительному соглашению). Это как раз большая часть того самого резерва, о котором я говорил. Затем проект продолжался в части реализации не вошедших в периметр проекта требований... но это совсем другая история.
В итоге получается совершенно неканоническая картина. Вроде бы жесткие сроки, но и элементы Agile присутствуют. Вроде бы и гибкие методологии, но есть ограничения в виде сроков и бюджета. Тем не менее, как ни удивительно, подобный «монстр» оказался достаточно жизнеспособным. Конечно, не последнюю роль в этом сыграл заказчик, очень заинтересованный в реализации проекта и, как следствие, вовлекающий необходимые ресурсы и поддерживающий процесс со свой стороны. Но и сама организация процесса была в чем-то уникальна. По крайней мере мне такого больше не встречалось ни разу.
Опубликовано 22.12.2016