Visual Studio 2017

Как управляют R&D в «Лаборатории Касперского»

Для «Лаборатории Касперского» – производителя антивирусов с мировым именем – эффективная организация разработки продуктов является бизнес-критичной задачей. Процесс должен быть прозрачным, управляемым, эффективным и одновременно комфортным для более чем 900 разработчиков. В 2011 г. компания выбрала для управления разработками платформу Microsoft Visual Studio Team Foundation Server, а в 2014 г. внедрила последнюю версию системы. О том, как внедрение помогло оптимизировать работу R&D и улучшить сам TFS, рассказала Маргарита Николаева, руководитель группы разработки внутренних инструментов «Лаборатории Касперского».

CNews: Расскажите об истории обращения к платформе Team Foundation Server (TFS).
Маргарита Николаева: В 2011 году у руководителя департамента появилась идея внедрить единый инструмент для управления разработками во всем подразделении R&D. На тот момент мы увидели единственный на рынке инструмент, полностью покрывающей весь процесс разработки, начиная от управления требованиями, тестированием и заканчивая кодом – Microsoft Team Foundation Server. Есть ряд других интересных и удобных инструментов, но они решают локальные задачи, и назвать их единой платформой нельзя.

Летом того же года началось планирование проекта. Параллельно около полугода решение пилотировалось в инфраструктурном подразделении R&D, чтобы понять, смогут ли команды вообще работать в TFS. В ходе пилотного проекта мы увидели, что работать с системой можно. А по результатам сбора требований от остальных команд, поняли, чего недостает в TFS2010 для полномасштабного внедрения в «Лаборатории Касперского». Тогда мы попытались своими же силами реализовать дополнительные инструменты, которые решали бы эти проблемы. Фактически переход на TFS начался в середине 2012–го года, когда все вспомогательные инструменты были готовы.

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

Подробнее

Понимание заказчиками актуальности тестирования ПО постоянно возрастает

PC Week/RE №13 (868) 19 августа 2014
09.07.2014

Тестирование ПО чаще всего ассоциируется с разработкой программных продуктов, причем обычно в контексте поддержки полного жизненного цикла ПО, от постановки задачи по созданию до завершения его использования. Менее известны — но не менее важны — вопросы тестирования информационных систем в процессе их внедрения и эксплуатации у конкретных заказчиков. Их актуальность была, в частности, хорошо видна на прошедшей в конце мая в Подмосковье конференции Microsoft DevCon 2014 — доклады по данной теме вызвали большой интерес аудитории. Своим опытом работы там поделился директор по развитию бизнеса компании Logrocon Владимир Туровцев, который ответил на наши вопросы.

Есть ли различия в проведении тестирования при разработке программных продуктов и при исследовании внедряемых систем?

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

Чем же занимается ваша компания?

Мы занимается разработкой ПО, его тестированием, а также консалтингом в области организации процессов разработки ПО. Logrocon ориентируется на использование в своей работы инструментов и технологий Microsoft, недавно мы получили сертификат Gold ALM Partner, это высший статус партнера корпорации в сфере разработки и управления жизненным циклом приложений (ALM), который в России имеют всего четыре компании, включая нас. Менеджмент компании занимается этим ИТ-направлением уже 15 лет, мы долгое время работали в телекоммуникационной отрасли, где ИТ-системы всегда были критически важными для бизнеса и требования по их надежности и производительности были очень высоки. При этом телеком отличается крайне высокими темпами модернизации и ввода в действие новых решений, внедрение и обновление там идет постоянно, и очень важно, чтобы это процесс никак не мешал функционированию действующих систем, работающих в непрерывном круглосуточном режиме и почти всегда в режиме реального времени. Понятно, что роль тестирования здесь очень велика, тем более что разработкой часто занимается большое число команд и нужно проверять работоспособность объединенных результатов их труда. Однако постепенно тестирование становится очень актуально и в других бизнес-отраслях, в том числе в банковском секторе — сейчас клиенты Logrocon это не только ИТ-компании, в том числе разработчики программных продуктов и системные интеграторы, но и банки.

Вы сказали об использовании инструментов Microsoft. Значит ли это, что вы тестируете только системы, построенные на базе технологий и решений корпорации?

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

Да, Microsoft сегодня один из признанных игроков ALM-рынка, но еще десять лет назад компания не была в числе фаворитов. Вы не опасались тогда, что ставите не на лидера?

Да, уже тогда рынок средств управления жизненным циклом приложений, в том числе и тестирования, был уже достаточно сформировавшимся, зрелым. Там были (и есть) другие вендоры и специализированные поставщики, а Microsoft только собиралась начать восхождение к этому Олимпу. Но ее инструментарий уже тогда в существенной степени отвечал нашим задачам. В результате получилось, что развитие ALM-средств Microsoft шло как бы параллельно с ростом наших профессиональных потребностей. Если посмотреть за динамикой этих инструментов, то можно точно сказать, что от версии к версии они становились все мощнее и функциональнее. Возможно, более поздний старт в этом направлении сыграл компании на руку: она могла сосредоточиться на наиболее актуальных проблемах, используя самые передовые технологии и опыт пользователей.

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

Какие именно ALM-средства Microsoft вы используете?

Одним из ключевых направлений развития средства разработки Microsoft Visual Studio является именно развитие инструментов управления жизненным циклом ПО, в том числе тестирования. Собственно Visual Studio — это уже не просто некий отдельный инструмент, а интегрированная платформа разработки, включающая большое число инструментов и средств. Фактически эта система поставляется и используется в виде нескольких наборов компонентов, ориентированных на широкий круг задач и соответствующие роли специалистов. Если говорить о решаемых наших задачах, то мы применяем в основном вариант Visual Studio Ultimate, который включает функциональность Test Manager для собственно тестирования (функционального, нагрузочного, регрессионного) и управления процессом тестирования (от планирования до анализа результатов).

Но ключевым, интегрирующим, компонентом всего этого комплекса является Team Foundation Server (TFS), который служит, с одной стороны, для поддержки коллективной работы, а с другой — информационным хранилищем, содержащим все данные о проекте (в том числе, техническое задание, сценарии тестирования и результаты). Мне кажется, что достоинством средств Microsoft является как раз их высокий уровень интеграции и возможность выбора и использования именно тех инструментов, которые наиболее оптимальны для решения той или иной задачи исследования и тестирования ПО.

Надо также отметить, что TFS является настраиваемым инструментом. Через имеющиеся у него механизмы настройки, в том числе набора API, мы создаем собственные панели управления, которые позволяют автоматизировать процессы тестирования. Всегда можно быстро и просто создать новую форму нужного нам отчета. Более того, мы используем TFS для задач управления нашей компанией, например, управляем операционными и стратегическими задачами с помощью TFS, контролируем расходование рабочего времени с детализацией по проектам и задачам, а также сделали специальный модуль, с помощью которого ведется подбор кадров. Причем в таком нестандартном " применении TFS мы не одиноки — практика его использования для таких «не ИТ» задач известна и в других компаниях, особенно в проектной модели управления организацией. Свои программные разработки для TFS мы сейчас оформляем в виде отдельного «коробочного» программного продукта (add-on для TFS), который предлагаем своим клиентам.

Вернемся к проблемам ИТ-заказчиков. Насколько тема тестирования программных систем актуальна и востребована рынком? Есть ли достаточно хорошее ее понимание со стороны заказчиков?

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

В конце 1990-х, когда я только начинал свою трудовую деятельность, практически не было ни больших объемом промышленного тестирования, ни специалистов. Сегодня ситуация радикально иная. Принципиально важным показателем уровня зрелости является то, что задачи тестирования вышли за рамки функций внутренних ИТ-отделов компаний и развивается схема аутсорсинга в этой сфере. У заказчиков сегодня уже есть четкое понимание того, что обычное ПО и промышленное ПО — это две разные вещи, причем, что еще очень важно — понимание этого есть не только у ИТ-начальников, но и у бизнес-руководителей. Они понимают ценность сокращения времени вывода решения на рынок, а также надежности функционирования и сокращения интервалов «технологических окон»: сегодня именно бизнес является ведущей силой, требующей от организации серьезного промышленного тестирования внедряемых ИТ-систем.

Кто сегодня является основным заказчиком на услуги тестирования?

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

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

Еще вопрос, с которого, наверное, надо было начать разговор — что является целью тестировании? Только проверка работоспособности программного решения?

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

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

Использование опыта специалистов Logrocon позволяет заказчикам сконцентрироваться на главных вопросах своего бизнеса и получить качественные процессы и стабильный результат, не совершая многих типовых ошибок и экономя самый ценный ресурс в мире — время.

М.Видео повышает эффективность управления разработкой ПО с помощью Microsoft Team Foundation Server

Развитие розничной сети «М.Видео», расширение ассортимента и усложнение бизнес-процессов требуют постоянного совершенствования информационной системы, используемой для управления торговыми операциями.

Чтобы справляться с возрастающей нагрузкой, Департамент ПО Дирекции по ИТ компании «М.Видео» выполнил проект по автоматизации отдельных задач в сфере управления разработкой. Система, созданная на платформе Microsoft Team Foundation Server, позволяет прослеживать взаимосвязь между новыми бизнес-задачами и ошибками, выявленными в ходе эксплуатации ПО, и теми изменениями, которые приходится вносить в программные коды для их реализации или исправления. Кроме того, в TFS хранятся все исходные коды и результаты тестирования, а также все прошлые и текущие задания с указанием их исполнителей. Анализ этой информации помогает руководителям ИТ-подразделений контролировать ход реализации проекта и составлять рабочие планы с учетом текущего объема задач и загруженности специалистов.

Ситуация
Компания «М.Видео» использует учетную систему, разработанную ИТ-подразделением на платформе Microsoft Visual Basic. С 2000 года интенсивность автоматизации резко возросла, и постепенно число разработчиков увеличилось в несколько раз. Единственным средством для организации их совместной работы оставалось решение Microsoft Visual SourceSafe. Эта система хорошо интегрировалась с платформой разработки и обеспечивала эффективное управление программными кодами, однако у нее отсутствовали возможности для решения других важных задач — в частности, система не позволяла прослеживать связи между вносимыми в код изменениями и теми бизнес-требованиями или обнаруженными ошибками, которые стали причиной этих изменений. Кроме того, система не содержала инструментов для автоматизации тестирования, контроля качества и своевременного информирования заказчика о ходе работ. Все эти недостатки ограничивали использование системы рамками одного подразделения и не позволяли добиваться высокой эффективности процесса разработки ПО.

В 2010 году в связи с тем, что срок эксплуатации «самописной» торговой информационной системы был продлен еще на несколько лет и ее активное развитие возобновилось, руководство ИТ-подразделения приняло решение о внедрении нового инструмента для управления разработкой — Microsoft Team Foundation Server (TFS), который был выпущен в качестве замены Visual SourceSafe. Система TFS превосходно интегрируется не только с современной средой разработки Visual Studio, но и с предыдущей версией Visual Basic, а в дополнение к возможностям по управлению программными кодами, уже реализованным на базе Visual SourceSafe, позволяет автоматизировать другие подпроцессы отдела разработки.

Предполагалось, что внедрение TFS постепенно охватит весь жизненный цикл разработки, тестирования и поддержки ПО, и объединит специалистов всех смежных подразделений — разработчиков, тестировщиков, аналитиков и менеджеров проектов.

Решение
Архитектура решения строилась в соответствии с рекомендациями Microsoft — на двух виртуальных машинах были развернуты сервер TFS и необходимая для его функционирования СУБД Microsoft SQL Server. Рабочие процессы было решено выстраивать на основе методологии MSF for CMMI, поддержка которой реализована в TFS.

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

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

В течение следующего года на платформе TFS были автоматизированы и некоторые бизнес-процессы смежных подразделений: управление исходными кодами на платформах JAVA и SharePoint, а также тестирование нового функционала корпоративных управленческих систем (SAP SCM, FOBO), веб-портала и интернет-магазина компании «М.Видео».

На некоторых этапах к участию в реализации проекта привлекалась компания Luxoft, входящая в группу компаний IBS и являющаяся золотым партнером Microsoft. В частности, ее специалисты помогли настроить интеграцию TFS с SQL Server Analysis Services и Reporting Services и c SharePoint Server.

«Исходя из нашего опыта, грамотная интеграция продуктовых решений компании Microsoft позволяет эффективно и быстро решать комплексные задачи по внедрению систем управления жизненным циклом разработки (ALM). В рамках данного проекта настройка интеграции TFS c SharePoint Server и SQL Server Analysis Services и Reporting Services помогла улучшить производительность всей проектной команды и сделать процесс разработки значительно более удобным. С одной стороны, была повышена прозрачность процесса разработки для руководителя проекта, с другой стороны, проектная команда получила удобное средство визуального контроля над данными TFS. В то же время изменение конфигурации TFS помогло повысить безопасность и удобство администрирования системы», — утверждает Максим Кузнецов, директор подразделения по работе с российскими клиентами компании Luxoft, группа компаний IBS.

В настоящее время в компании «М.Видео» систему TFS используют около 70 сотрудников ИТ-департамента и дирекции по проектам (разработчики, тестировщики, аналитики, менеджеры проектов), специалисты смежных подразделений, а также около 100 внешних пользователей из консалтинговых компаний и поставщиков ПО.

Преимущества
Важнейшими достижениями проекта стали систематизация и унификация типовых задач управления процессом разработки.

«Благодаря решению, развернутому на платформе Microsoft Team Foundation Server, мы автоматизировали сквозные и взаимосвязанные процессы регистрации требований, заданий, изменений в программных кодах и результатов тестирования. Это позволило организовать эффективную совместную работу специалистов, вовлеченных в единый процесс создания ПО, и уменьшить потребность в “ручном” директивном управлении разработкой со стороны менеджеров проекта», — утверждает Олег Стриженов.

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

Благодаря интеграции TFS и SQL Server пользователи могут отслеживать текущий статус обработки каждого требования, запроса на изменение и задания на исправление обнаруженной ошибки. Все эти данные доступны в виде удобных отчетов на портале SharePoint.

Еще одним важным достоинством TFS является простота внедрения и последующей эксплуатации. Все ее механизмы, настроенные и интегрированные в соответствии с инструкциями поставщика, действуют в автоматическом режиме и не нуждаются в поддержке со стороны ИТ-специалистов.

«По итогам первого полного года эксплуатации TFS подразделение разработки выполнило свой план более чем на 90%», — подводит итог Олег Стриженов.

ALM-платформа помогла нам договориться с бизнесом о сроках ИТ-разработок

http://banks.cnews.ru/articles/bank_vtb24_almplatforma_pomogla_nam

Разработка и внедрение критичных приложений в таких крупных организациях, как банк ВТБ24, – задача непростая: несколько бизнес-заказчиков с разными приоритетами, большое число требований, многочисленная команда внешних и внутренних разработчиков, высокие требования к качеству и сжатые сроки. Заместитель директора департамента банковских и информационных технологий Денис Гузовский и начальник управления разработки Андрей Залманов из банка ВТБ24 рассказали CNews, как внедрение платформы управления жизненным циклом приложений от Microsoft помогло банку навести порядок и соблюсти баланс интересов в этом процессе.

CNews: Расскажите, какие проблемы заставили ИТ-руководство банка ВТБ24 задуматься о внедрении системы управления жизненным циклом приложений?

Денис Гузовский: Предпосылок было много. Первая, наверное, историческая – с 2007 года банк бурно рос. Мы проводили стратегию захвата рынка. Соответственно, рос ИТ-арсенал – собственные и покупные разработки. ИТ-системы быстро множились и интегрировались между собой. Задача оптимизации ИТ-сферы не являлась первоочередной, поскольку при захвате рынка нет необходимости оптимизировать ресурсы. Рынок свободен, и его поглощение приносит сверхприбыль.
В итоге мы оказались со множеством быстро внедренных систем и процессов. Когда в прошлом мы строили ИТ-машину, мы не уделяли серьезного влияния рентабельности. Но со временем ситуация менялась, и возникли вопросы рентабельности всего происходящего в ИТ. Тогда мы начали наводить порядок и возник вопрос – как этим всем управлять.
Управлять было тяжело, применялись всевозможные схемы жизненного цикла: собственные разработки «с нуля», разработки только партнеров, совместные с партнерами разработки. Все это вместе требовало грамотной методологии управления, и мы начали ее искать.
В России в принципе тяжело регламентировать процессы. Особенность российского рынка – документацию никто не читает или все считают, что сделать по-другому быстрее и лучше. К тому же нередко воздействие менеджмента на процесс, идет вразрез со всеми им же утвержденными методологиями. Применение свободных форматов коммуникаций в форматах Word или Excel ничего не дает. Процесс изначально необходимо строить, применяя определенный жесткий инструмент, иначе контролировать не получается. Если в России выстроить процесс, а потом пустить его на самотек – он начинает через какое-то время деградировать. Например, если в Москве открывается хороший ресторан, то через полтора года он почему-то становится уже не таким хорошим.

CNews: Была ли масштабная модернизация системы дистанционного обслуживания «Телебанк» одной из предпосылок к внедрению системы?

Денис Гузовский: Да, «Телебанк» – это один из первых успешных кейсов применения платформы. У нас была масса кейсов и масса вопросов, которые мы решили. «Телебанк» – один из самых наглядных результатов. Во-первых, потому что это круглосуточная нон-стоп система, любая ее остановка сразу видна. Как показывает практика, москвичи очень любят в 3–4 часа утра залезть в «Телебанк» и пораспоряжаться собственными финансами. Наверное, потому что они такие же трудоголики, как мы, – ушли в час ночи с работы, немножко отдохнули и вспомнили, что надо еще заплатить за что-то. Поэтому и в ночное время «Телебанк» достаточно востребован.
Наша задача состояла в том, чтобы наладить процесс установки программного обеспечения так, чтобы система работала на 100%. Мы часто сталкиваемся с проблемой, когда готовый, оттестированный продукт дает сбои из-за сложностей переноса на продуктивную среду. Можно провести аналогию со сложным устройством с кучей проводочков, лампочек, ручек, которые надо правильно повернуть, чтобы оно заработало. Перенос ИТ-решения в продуктивную среду также требует качественного наблюдения и контроля. Раньше все это делалось артельно. Были гуру-люди, которые знали, как все настраивалось. Иногда они что-то забывали, иногда менялись. Сейчас мы построили управляемый процесс благодаря единой платформе разработки – все описано и понятно. Простоев «Телебанка» уже нет. Мы недавно внедрили новую версию, а это сложный процесс, в том числе и потому, что там заложено множество новинок, рассчитанных на будущие потребности рынка. Теперь, если и возникают проблемы, то скорее из-за программных, не найденных при тестировании ошибок, а не в результате ошибок самого процесса установки. Процесс установки версий и их обновлений на данный момент налажен.

CNews: Почему вы остановились на платформе Microsoft?

Денис Гузовский: Поскольку большая часть разработок велась на основе продуктов компании Microsoft, мы остановились на идеологии Microsoft. Мы внедрили платформу управления жизненным циклом разработок Microsoft Team Foundation Server (TFS) для управления процессами разработки программного кода. Перед банком стояла задача построить управление изменениями так, чтобы на всех этапах – от бизнес-идеи до конечного кода – можно было учесть все нюансы. Это оказалось сложно в силу хаотического роста банка. Мы ориентированы на клиента, и где-то у нас клиентоориентирвоанный подход, хотя банк, увеличивая количество продуктов и услуг, частично ставил продукт во главу бизнес-процесса. Сегодня банк находится в стадии перестройки.

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

CNews: Это будут только ИТ-подразделения или вы планируете затронуть и бизнес-департаменты?

Денис Гузовский: Все внутренние структуры, которые находятся между ИТ и бизнесом – проектировщики, технологи, бизнес-подразделения. Хотелось бы, чтобы бизнес в свою очередь генерировал собственные требования. У нас, конечно, есть документы, все это описывающие, замыкающие разработку на технологов, единая инструментальная платформа и методы. С другой стороны, существуют тяжелые и пока неразрешенные противоречия. Перед банком часто появляются неожиданные и быстрые задачи с конечным сроком. Какие методологии управления в этом случае применить? Пока, конечно, мы движемся поступательно – нащупываем почву. Возможно, как организация, мы находимся не на конечном уровне зрелости, чтобы полностью регламентировать процессы. В то же время не до конца формализованные процессы дают колоссальную гибкость.
Самое страшное, когда методология и инструменты навязываются, система привыкает к стереотипам. Остальные идеи уже кажутся неправильными, хотя это не так. Сложнее дать путь инновациям.

CNews: В 2012 году вы начали работу в TFS. Трудно ли было ее внедрять, «погружать в нее системы», потребовалась ли помощь интеграторов?

Денис Гузовский: Я могу сказать, что система внедряется легко. Она – не общебанковский или даже не общеайтишный проект. Наши сотрудники внедрили ее в фоновом режиме, самостоятельно. Так легко внедряется далеко не каждая система.

CNews: Какие преимущества получил бизнес с внедрением TFS?

Денис Гузовский: В первую очередь – сокращение времени вывода на рынок новых продуктов. Ради этого все и делается. Впрочем, за счет внедрения мы, возможно, не сильно повысили показатель time-to-market, поскольку от идеи до тиражирования на все наши отделения проходит не слишком много времени. Однако мы оптимизировали процессы минимум на 10–25 % за счет повышения контроля.

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

Еще одну проблему, которую удалось решить, я бы назвал «лебедь, рак и щука» – когда люди с разными приоритетами бегут в разные стороны. Если не управлять при помощи единой системы, то конечный результат собирается по последнему прибежавшему. Я бы назвал это проблемой постоянной смены приоритетов.

CNews : Сколько человек сейчас работает в системе TFS?

Андрей Залманов: Сейчас подключено порядка 40 наших разработчиков, вместе со сторонними поставщиками системой пользуются порядка 100 человек.

CNews : Это единственная система, в которой разработчики отчитываются о сделанной работе?

Андрей Залманов: Есть система учета заявок бизнес-подразделений – Jira, она охватывает весь банк. Она содержит высокоуровневые описания бизнес-требований. Вытекающие из этих описаний декомпозированные и детализированные требования к разработке хранятся уже в системе TFS. При этом мы реализовали двухстороннюю синхронизацию между TFS и Jira.

CNews : Каковы ваши основные требования к системе управления разработками?

Андрей Залманов: Прежде всего, комплексность этой системы. Она должна охватывать весь процесс разработки, начиная от формулирования бизнес-требований и заканчивая анализом результатов внедрения и эксплуатации. При этом процесс должен функционировать в рамках единой методологии, поддерживаемой единым набором инструментов. Microsoft предоставляет инструменты для каждого этапа процесса разработки ПО. Это действительно комплексный полнофункциональный ALM (Application Lifecycle Management, система управления жизненным циклом приложений). Здесь есть и средства управления портфелями проектов, и средства управления проектами, и средства управления бизнес-требованиями.

Для нас было большой проблемой отсутствие четкой взаимосвязи между требованиями и реализацией: к какому бизнес-требованию относится тот или иной фрагмент кода, и наоборот, где это требование реализовано, в каком коде? Если требование надо изменить, то какой кусочек надо поправить? Это непонимание порождало серьезные издержки на поиски соответствия. Платформа Microsoft ALM хорошо эти задачи решает. Ее инструменты дают возможность от высокоуровневых требований быстро перейти к декомпозированным, а от них – к реализации. С другой стороны, есть возможность легко пройти по этой цепочке и в обратном направлении.

Важно также, что платформа обладает достаточными возможностями расширения и кастомизации. Практически любую недостающую функцию можно реализовать собственными силами, причем с помощью тех же инструментов (и тех же разработчиков), что используются и при разработке основных проектов.

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

К тому же мы достаточно глубоко проросли в Microsoft, а Microsoft в нас. Мы видим синергию приятного, знакомого ландшафта с использованием привычных продуктов, таких как Project Server, Outlook с уведомлениями и т. д. Добавьте к этому ненавязчивость системы для людей, которые в ней работают. Особенно это важно для людей творческих, время которых стоит дорого. Наша задача сделать так, чтобы формальные действия тоже были легки, потому что это человекоминуты, которые превращаются в часы и потери инвестиций. Кроме того, психологически творческие люди – а айтишники по большей части люди творческие – не особо приемлют формализм. Наша система достаточно прозрачна, легка, нам хватает всего с точки зрения руководства. При этом люди не сильно загружены и достаточно комфортно себя чувствуют.

Благодаря бесшовной интеграции с широко распространенными майкрософтовскими же продуктами, документы, которые готовят технологи и бизнес-аналитики в офисных программах Word, Excel, Project, можно применять в средствах управления жизненным циклом Microsoft.

Приведу пример, показывающий работу части системы. Мы берем согласованное техническое задание, сделанное в текстовом документе в Word бизнес-технологом при нашем участии. Думаю, что на многих российских предприятиях аналитическая постановка задач представляет собой большие документы связного текста в Word. Все. Наша система сама со значительной степенью автоматизации разбирает этот сплошной текст на конкретные детерминированные требования. Дальше показывает их в разрезе: выполнены, не выполнены, в каком коде, в какой системе, поставке, как протестированы, как установлены. Есть обратная связь, где можно увидеть ошибки, возникшие при выполнении требования, и т. д.

Андрей Залманов: Очень важно, что при этом сохраняется обратная связь – в исходном документе динамически отражается информация о состоянии работ по реализации того или иного требования.

CNews : Поделитесь вашими планами по масштабированию системы.

Денис Гузовский: На первом этапе мы погрузили в систему не все процессы. Сейчас в ней только половина собственных разработок и две трети проектных. С точки зрения горизонтального расширения мы планируем загрузить систему по максимуму.

Кроме того, у нас есть планы по масштабированию. В первую очередь мы начнем, конечно, с ИТ-сопровождения. Сейчас процессы сопровождения, повышения качества продуктов, исправления инцидентов четко не разбиты на программистов и компании. Руководствуемся пока только ощущением – здесь много ошибок, здесь мало. Мы хотим, во-первых, построить настолько прозрачную цепочку, чтобы продукты автоматизировано проходили через все стадии внедрения, тестирования, и была обратная связь. Это несложно, поскольку процесс детерминированный, формализованный. Надо просто приложить усилия по подключению коллег к данным системам.

Во-вторых, есть желание масштабироваться в сторону управления изменениями или бизнес-запросами. Думаю, нам здесь потребуется консалтинговая поддержка коллег из Microsoft. Поскольку этот процесс самый бурный и неформализованный. Именно там постоянно меняются требования.

Не хочется загонять заказчиков в жесткие рамки. Для них эти исследования по сути являются частью R&D. Не хочется убить творческую активность, но одновременно нужны понятные процессы и взаимоотношения.

CNews : Если сравнить с передовым зарубежным опытом, на какой стадии вы находитесь в управлении разработками?

Денис Гузовский: Сложно сравнивать. Во-первых, когда говорят «зарубежный опыт», часто думают о Европе, Америке, но точно не об Азии. Хотя в последнее время мы часто смотрим на опыт азиатских банков – клиентские объемы там абсолютно не сопоставимы с Европой, они гораздо больше. Возможно, сопоставимы с Америкой. Они тоже находятся в состоянии бурного развития новых услуг и тем интересны. Американский рынок давно стабилизировался. Поэтому сравнивать нас с американцами практически невозможно. Они делают один-два проекта в год, используя другие процессы. Европа делает еще меньше, просто потому что население меньше.

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

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

CNews : Достаточен ли для вас функционал TFS?

Андрей Залманов: Если говорить о том, каких функций нет в системе, и какие нам хотелось бы видеть – это функции, связанные с безопасностью программного кода. Здесь мы планируем внедрение сторонних решений. В ближайшей перспективе мы собираемся внедрять системы анализа кода на предмет наличия в нем случайных либо намеренно введенных уязвимостей или закладок.

Денис Гузовский: Только благодаря тому, что мы погрузили инструменты в TFS, мы можем подключить к этому процессу внешнюю систему. Раньше это было просто невозможно потому, что исходники хранились в текстовых файлах и были недоступны для обработки.

CNews : В чем вы видите главный эффект от внедрения?

Денис Гузовский: Как минимум, мы перестали срывать сроки, которые сами же ставили. Это говорит о том, что система планирования стабилизировалась. Да, наверное, мы еще не достигли уровня оптимизации процессов, и находимся на стадии измерения. Оптимизация – это следующий шаг. Но качество повысилось значительно. У нас за последний год не было ни одного сбоя по причине установки новых систем или обновления старых. Сбои случались, как правило, даже не из-за ошибок в системе, а из-за необнаруженных внутренних взаимодействий между сложными разрозненными компонентами. Несомненно, еще один из положительных моментов для бизнеса – повысилась прозрачность и измеримость процесса. Если раньше бизнес был недоволен сроками, то сейчас, когда процесс стал более прозрачен, он понимает эти сроки. У нас появился механизм, при помощи которого мы обосновываем время, необходимое с точки зрения технологий для решения определенной задачи. Нам стало проще вести диалог с бизнесом.

Agile и Visual Studio отлично подходят друг другу

PC Week/RE №9 (864) 27 мая 2014
22.05.2014

Руководство финансовой группы (ФГ) Лайф, в состав которой входят девять самостоятельных коммерческих банков, хорошо понимает важность использования ИТ для обеспечения и повышения эффективности ведения бизнеса. Сегодня банки Группы используют более двух десятков программных продуктов, внедряются и новые решения. Помимо применения тиражного ПО значительная часть потребностей бизнес-подразделений покрывается приложениями и системами, создаваемыми внутри самой Группы по заказным спецификациям. И потому вопросы управления жизненным циклом разработки и эксплуатации приложений, в том числе на базе современных методов в стиле «гибкой разработки» 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, навсегда! Я совершенно уверен, что с помощью этих методов и средств мы сможем решать все возникающие задачи. Но при этом хотел бы только уточнить: все же главное в процессе разработки — люди.

Visual Studio помог нам перейти на эффективную модель гибкой разработки ПО

PC Week/RE №11 (866) 24 июня 2014
18.06.2014

Для 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 является положительным.