Для Epicor Software разработка ПО — это основа бизнеса, а не вспомогательная функция. Компания — известный во всем мире поставщик решений для управления ресурсами предприятия (ERP), управления продажами, управления цепочками поставок (SCM) и управления персоналом (HCM) для различных отраслей. Однако далеко не все, в том числе и пользователи продуктов Epicor, знают, что значительная часть софта этой компании со штаб-квартирой в г. Остин (США) создается в нашей стране. О том, как организована данная работа, рассказывает старший директор по развитию московского центра R&D компании Вадим Савельев.

Что представляет собой система разработки ПО компании Epicor в глобальном масштабе и какова в ней роль московского центра R&D?

Epicor — это международная компания, использующая распределенную модель организации разработки и имеющая около десяти центров R&D, расположенных в разных странах, в том числе в России. Московский центр был создан еще в начале прошлого десятилетия и сегодня является одним из крупнейших R&D центров компании. В нем трудится более 150 человек, из которых примерно 120 — это собственно разработчики. В свою очередь, центр делится на отдельные команды, ведущие те или иные проекты. Но специфика процесса разработки в компании такова, что, хотя организационная структура является территориально распределенной, все центры в той или иной степени взаимосвязаны. То есть каждая команда работает не изолированно, а в постоянном контакте как со смежными группами внутри одного центра, так и с центрами в других странах. В общем, все подразделения должны работать в единой информационной среде. Но при этом все центры, а часто и многие команды, работают по полному жизненному циклу создания и развития ПО, начиная от технического задания до выдачи готового продукта. Это означает, что в процессе производства задействовано несколько категорий разработчиков (аналитики, проектировщики, программисты, тестировщики), которые также могут способствовать повышению эффективности процесса создания ПО и управления жизненным циклом продуктов.

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

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

Какие методики разработки вы используете?

Примерно два года назад мы перешли на использование методов гибкой разработки Agile, а именно на методику Scrum. Тогда мы сначала решили проверить возможности Scrum в пилотном варианте на одной из наших автономных команд, занимавшейся интеграцией iScala с некоторыми внешними системами, в том числе Microsoft CRM. Этот пилот длился около полугода, и по результатам мы увидели, что наши ожидания по поводу повышения эффективности оправдались. Надо сказать, что мы использовали Scrum в его классическом варианте, включающем: двухнедельные циклы, выделенные группы, находящиеся в одном пространстве, четкое распределение ролей (Product Owner, Scrum Master, Scrum Team) и пр.

После этого мы стали распространять данную методику на все другие группы в нашем центре, а также на ряд зарубежных подразделений компании. Можно сказать, что практически вся работа по созданию 10 версии Epicor ERP (анонсирована этой весной) велась уже по модели гибкой разработки.

В чем же выражается эффект от перехода на Scrum?

Я бы выделил два основным момента. Во-первых, сокращение затрат на различные бюрократические процессы типа согласования, уточнения и принятия решений. Во-вторых, мы стали более организованными. Сократив затраты на управление, мы одновременно повысили качество управления проектом. Вот такой парадокс; действительно несколько неожиданный, но вполне реальный.

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

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

Если же посмотреть на некоторый конечный результат от внедрения Scrum, то, с точки зрения высокого руководства, главным является повышение прозрачности процесса и получение гарантированного результата. Если взять такой крупный проект, как Epicor ERP 10, то в его реализации принимало участие довольно большое число распределенных команд, а время реализации составило полтора-два года. Из-за этого процесс отслеживания всех процессов — скажем, придерживаются ли команды плана-графика — является очень сложным. В то же время, по ходу выполнения работ в проект нужно вносить постоянные корректировки и дополнения (меняется рыночная ситуация, появляются новые технологии и устройства), поэтому задача кажется практически невыполнимой. Другой сложностью является необходимость в постоянном перераспределении человеческих ресурсов, поскольку оценка трудоемкости разработки невероятно сложна.

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

И еще один важный результат: переход на гибкие методы внутри проекта дал нам возможность перейти на выпуск более частых промежуточных релизов конечного продукта, с регулярностью примерно в полтора-два месяца, что сегодня очень важно для мирового рынка в целом с его высокой динамикой развития требований заказчиков и тем более для нашей страны с ее темпами коррекции нормативно-законодательной базы.

А какова тут роль самих средств разработки, инструментария?

Она является основополагающей. Без этих средств реализация идей Agile была бы крайне затруднена или даже невозможна. Я уже сказал о нашей ориентации на технологии Microsoft, поэтому вполне естественно, что мы используем платформу разработки Visual Studio. Я бы хотел подчеркнуть два момента. Первое — мы применяем Visual Studio не потому, что это Microsoft, а потому, что это действительно один из лучших инструментов, особенно для Windows-систем. Второе, я прибегаю к термину «платформа разработки», поскольку слово «инструмент» никак не отражает состав и возможности этой системы, в которую входит широкий набор средств, охватывающий задачи всего жизненного цикла создания и сопровождения ПО. Здесь следует отметить два основных компонента системы — сам Visual Studio как персональный инструмент отдельного члена команды (хотя тут есть целый набор ролей — аналитик, тестировщик, несколько вариантов разработчика) и Team Foundation Server (TFS) как ключевой компонент поддержки групповой работы.

Мы работаем с Visual Studio уже много лет, видим его развитие от версии к версии, и я могу сказать, что мы вполне удовлетворены динамикой этого развития, которая идет в ногу (а часто и опережает) с ростом наших потребностей и развитием ИТ в целом. Если говорить о самой среде разработки, то она становится одновременно и проще (в смысле — удобнее), и надежнее, и более гибкой с каждым новым обновлением. Разумеется, все это — на фоне роста функционала и круга решаемых задач. Очень важным для нас является большое внимание авторов Visual Studio к вопросам его масштабирования в плане как поддержки групповой работы, так и сложности создаваемых программных систем. Наш опыт показывает, что Visual Studio может отлично применяться и отдельным программистом для решения какой-то частной задачи, и практически не ограниченной по численности командой разработчиков.

Помог ли как-то Visual Studio в переходе на методологию Scrum, и как он показал себя при ее использовании?

Помог самым непосредственным образом. Два года назад вышла версия Visual Studio, в которой Microsoft реализовала целый ряд новшеств, связанных именно с использованием гибких методов разработки. Собственно, мы думали о переходе на Scrum еще раньше, но появление подходящего инструмента стало в определенной мере решающим толчком для нас. Хотя самым главным тогда мы считали переход с SourceSafe на TFS, что позволило перевести поддержку групповой работы на качественно новый уровень.

SourceSafe, кажется, уже давно не поддерживается Microsoft...

Да, этой программе уже более 20 лет, хотя, конечно, она все эти годы развивалась. Тогда задачи групповой работы были еще не так актуальны, поэтому SourceSafe была изначально ориентирована на поддержку отдельного разработчика и решала в основном вопросы версионности. Потом в ней стали появляться возможности коллективной разработки, но все же сама архитектура (она реализована в клиентском варианте) создавала большие ограничения. Все эти проблемы решило создание TFS, предназначенного именно для поддержки групповой работы и выполненного в трехзвенной серверной архитектуре. Кстати, он может использоваться для многоплатформенной разработки с помощью различных инструментов, например Eclipse. Более того, известно, что TFS успешно применяется и для управления непрограммистскими проектами.

Первые варианты TFS у Microsoft появились еще лет восемь назад, но в тот момент они не покрывали всех возможностей SourceSafe. Я бы хотел добавить, что мы сами активно занимались доработкой, расширяя возможности SourceSafe, и то, что мы использовали у себя, серьезно отличалось от стандартного варианта. Короче говоря, переход всех старых версий наших продуктов, традиционно использующих SourceSafe, на TFS (который к тому времени намного превосходил свой первоначальный вариант) мы начали также два года назад. Миграция с SourceSafe прошла без каких-то заметных проблем. Сейчас можно уверенно констатировать, что именно TFS сегодня является ключевым платформенным компонентом, на котором базируется все процессы разработки ПО в нашем центре.

А если вернуться к самому Visual Studio, то какие его новшества вы бы выдели в первую очередь с учетом своего практического опыта?

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

В заключение я бы хотел добавить, что наше общее впечатление от Visual Studio и TFS является положительным.

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