Руководство финансовой группы (ФГ) Лайф, в состав которой входят девять самостоятельных коммерческих банков, хорошо понимает важность использования ИТ для обеспечения и повышения эффективности ведения бизнеса. Сегодня банки Группы используют более двух десятков программных продуктов, внедряются и новые решения. Помимо применения тиражного ПО значительная часть потребностей бизнес-подразделений покрывается приложениями и системами, создаваемыми внутри самой Группы по заказным спецификациям. И потому вопросы управления жизненным циклом разработки и эксплуатации приложений, в том числе на базе современных методов в стиле «гибкой разработки» Agile являются важным направлением оптимизации процессов в ФГ. О том, как эта работа выглядит на практике и какие эффекты она дает, рассказал начальник сектора интеграции информационных систем ФГ Лайф Алексей Лосев.

Есть ли какие-то организационные особенности в разработке ПО в вашей компании?

Наверное, главное состоит в том, что руководство Лайф отлично понимает актуальность этой работы и необходимость постоянного ее совершенствования на основе новейших инструментов и методов. Если же говорить именно об организации процессов разработки ПО, то, пожалуй, самое важное — это сочетание децентрализованной модели разработки с централизацией информационных ресурсов. В банках ФГ используются программные решения, многие из которых находятся в процессе постоянной модернизации. Часть таких разработок передана на аутсоргинг, но большинство обслуживается внутренними командами, которые географически распределены по разных городам страны. Всем этим занимаются более десятка групп, в общей сложности объединяющие свыше ста разработчиков.

До сих пор каждая команда сама выбирала для себя методологию разработки и поддержки ПО, опираясь на некий общий «свод внутренних правил». Но сейчас в ФГ Лайф запущен проект по созданию единого корпоративного подхода на основе идей Application Lifecycle Management (ALM), целями которого являются аудит текущей ситуации в управлении жизненным циклом приложений, оптимизация процесса и его автоматизация.

Наша команда пришла в ФГ Лайф в 2011 г., мы работаем в Калуге, а наш Team Foundation Server установлен в Москве, где находятся и основные наши бизнес-клиенты. Мы занимаемся разработкой систем внутренней автоматизации сервисных подразделений и их интеграцией в ИТ-сервисы ФГ Лайф на базе платформы Microsoft .Net с использованием инструмента Visual Studio 2013. Мы давно уже использовали гибкие методы управления процессом разработки (если конкретно, то за основу у нас принята методика Scrum) и продолжаем применять их в ФГ Лайф. По Agile-схемам работают и некоторые другие команды

Про концепцию Agile-разработки говорится уже давно и много, и все же: как вы сами сформулировали бы ее основные идеи? В чем она отличается от традиционных подходов, в чем преимущества и какие есть подводные камни?

Общие принципы достаточно хорошо и понятно сформулированы в Agile-манифесте. Мне кажется, что главная идея этой концепции — не только максимальное приближение работы программистов к реальным потребностям заказчиков, но и перенос акцента в связке «процессы и люди» с процессов на людей. Это не значит, что процессы становятся неважными, нет, они важны, но все же приоритеты несколько меняются. Разработчики из простого исполнителя техзадания становятся как бы непосредственными участниками автоматизируемого ими процесса. Важно еще и то, что методы Agile широко используются не только в разработке ПО, но и в любых проектных работах и в бизнесе. Помимо снижения затрат на разработку достоинством Agile является повышение прозрачности процесса создания ПО для бизнес-заказчиков и руководства компании.

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

Что представляют собой ваши проекты и как конкретно они реализуются?

Наша команда занимается разработкой систем внутренней автоматизации сервисных подразделений, в первую очередь ИТ- и хозяйственного управления. Проекты разные, от системы заключения SLA, на которой строится большинство других систем, до управления работами и расчета доступности сервисов для заказчиков. Задачи решаются стандартные: управление требованиями, разработка, тестирование, развертывание. Команда у нас классическая для Scrum-схемы — восемь человек, в том числе аналитик, разработчики, специалисты по тестированию. Получается такая feature-team, доводящая проект от сырого ТЗ до работающего продукта. Со сроками бывают разные варианты. Есть проекты, которые «живут», постоянно дорабатываются, пополняются новым функционалом. Но довольно много и небольших проектов, которые идут один-два месяца, передаются в эксплуатацию и в таком виде используются без доработок дальше.

А какова роль собственно средств разработки в реализации идей Agile, в том числе того, которое используете вы, — Visual Studio?

С платформой .NET я начал работать более десяти лет назад, фактически сразу после ее появления на рынке. Понятно, что лучший инструмент для нее — Visual Studio, который за эти годы превратился из инструментального набора в платформу разработки. Она полностью покрывает наши потребности в разработке, динамически развивается, вполне успевая за «велениями времени». Так что у меня никогда не было желания заменить ее чем-то другим. Наша команда уже несколько лет ориентирована на .NET и Visual Studio. С появлением новых версий инструмента мы достаточно быстро переходим на них, используя имеющиеся в них возможности.

В плане совместимости версий были незначительные трудности при переходе от версии 2010 к 2012, но зато именно тогда был получен заметный эффект в плане применения Agile: как раз в VS 2012 реализованы очень важные функции в этом направлении. Переход же к версии 2013 вообще прошел почти незаметно.

В целом VS 2013 — это сейчас наш основной рабочий инструмент, им пользуются все члены команды, каждый, конечно, в рамках своих задач. Аналитик формирует пользовательские истории и рисует UML-диаграммы, тестировщики — тестируют. Ну а про разработчиков и говорить нечего. Вообще выход VS 2013 осенью прошлого года нас сильно порадовал. Много нового появилось: и IntelliSense в редакторе XAML улучшился, и новая панель TeamExplorer намного функциональнее, и фильтрация в модульных тестах, и прочее и прочее... С этой версии Microsoft стала использовать метод регулярных обновлений инструмента (примерно с частотой раз в два месяца) вместо выпусков сервисных пакетов.

Разумеется, для поддержки коллективной работы мы используем Team Foundation Server (TFS).

C какими проблемами в процессе разработки чаще всего приходится сталкиваться вашей команде?

В ФГ Лайф входят девять банков, которые расположены в разных городах, а значит, и наши заказчики рассредоточены по всей стране. Разработка ПО также распределена по России — команды разработчиков находятся в Москве, Саратове и Калуге. Всё это приводит к трудностям и в согласовании требований, и при интеграции различных решений. Нам пришлось улучшать процессы взаимодействия с заказчиками и управления требованиями. Еще одной проблемой, отнимающей много времени, является то, что в рамках одной итерации может потребоваться внесение изменений в большое количество систем. Разработчикам приходится переключаться из контекста в контекст, а это занимает немалое время.

Как построен процесс взаимодействия с заказчиками в вашей команде? Какие инструменты управления требованиями вы используете?

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

Сначала (но при необходимости) для уточнения ролевой модели и функционала строится UML-диаграмма Use Case. Затем формируются пользовательские истории (Product Backlog Item, PBI), включающие в себя всю информацию, необходимую для реализации требования разработчиками. В них добавляются прототипы интерфейсов, тестовые сценарии, а для удобства отслеживания зависимостей между историями — ссылки на диаграммы Use Case. При наличии сложных алгоритмов строятся диаграммы активностей, ссылки на них также добавляются в PBI.

А поскольку TFS позволяет работать с PBI через Web-интерфейс, то, разграничив права вплоть до областей проекта, наши заказчики могут из браузера зайти и посмотреть их статус, определить для них приоритет. Некоторые заказчики, оценив все прелести такого взаимодействия, даже требования начали выставлять сразу в TFS. И специалисту-аналитику остается только доуточнить их.

Преимущество такого подхода заключается в том, что он позволяет согласовывать и уточнять у заказчика не большое ТЗ, а конкретные сценарии, да и разработчики быстрее погружаются в контекст, когда он собран в одном месте. Ну а возможность для заказчика самому расставлять приоритеты своим требованиям, в режиме реального времени отслеживать, какие PBI взяты в работу и в каком статусе находятся, конечно, сказывается на его удовлетворенности.

А как разработчики отнеслись к использованию UML-диаграмм в требованиях?

Сперва прохладно, потом сами стали требовать. Особенно востребованы диаграммы активностей. Не надо тратить время, чтобы из текста выделять алгоритм. Можно сразу брать его в разработку. У этих диаграмм есть и еще одно применение. Так как у нас все Check-In привязываются к задачам, то у разработчиков при внесении изменений в существующий код есть возможность посмотреть, кто его писал, к каким задачам и PBI привязаны решения о Check-In, и, просмотрев диаграммы, значительно быстрее разобраться, что в этом коде должно происходить. Кстати, и в тестировании диаграммы активностей постоянно используются. Тестировщик смотрит, какие есть ветви, планирует зоны эквивалентности и разрабатывает под них тестовые сценарии.

А другие типы диаграмм вы не используете?

Еще используем диаграммы слоев (Layer Diagram). У них в Visual Studio есть очень интересный сценарий использования для автоматического контроля архитектуры. Можно спроектировать архитектуру, привязать имеющиеся проекты, пространства имен к ее слоям и при построении решения будет выполняться проверка на соответствие имеющегося кода запланированной архитектуре.

Ну а если посмотреть в целом: какие новые возможности VS 2013 вы используете активнее всего?

Осенью прошлого года у нас наметился рост количества ошибок, обнаруживаемых в процессе разработки. Соответственно стало тратиться много времени на их устранение. Было принято решение для повышения качества кода, попадающего в TFS, использовать практику Code Review. Как оказалось, в VS это просто и удобно. Достаточно перед Check-In парой щелчков мышью указать, кому отправить изменения на Review. Рецензенту в область задач прямо в Visual Studio приходит запрос, содержащий всю информацию о внесенных изменениях: связанную задачу, комментарий разработчика и, самое главное, конкретные места изменений в коде. Можно смотреть файлы в режиме «было — стало», оставлять комментарии к фрагментам кода. После отметки об окончании рецензирования у разработчика уже в области его задач появится отметка об окончании ревью. Результат стал сказываться уже с первой итерации после внедрения такой практики, а через три итерации количество ошибок в разработках уменьшилось на 40%.

Давайте подведем итог нашей беседы — как вы сформулировали бы его сами?

Главное достоинство Visual Studio — это конечно же уменьшение времени между появлением требований и передачей готового функционала в эксплуатацию. Ну а внедренные процессы и появляющиеся инструменты позволяют улучшить качество решений, получаемых заказчиками.

Agile и Visual Studio — это forever, навсегда! Я совершенно уверен, что с помощью этих методов и средств мы сможем решать все возникающие задачи. Но при этом хотел бы только уточнить: все же главное в процессе разработки — люди.

СПЕЦПРОЕКТ КОМПАНИИ MICROSOFT