Для использования приемов гибкого (agile) программирования есть множество причин. Но, может быть, самая важная из них заключается в том, что когда-нибудь эти приемы позволят спасти ваше предприятие. Рассказывает Дэвид Уэбб, ведущий специалист по гибкому программированию из компании Exigen Services.
Накопившиеся со временем и наслоившиеся друг на друга технические проблемы усугубляются при использовании жесткой ИТ-архитектуры, вспомогательных приложений и устаревшего оборудования. Создание архитектуры для конкретных условий — обычное явление в любой отрасли. В начале своего жизненного цикла они работают очень хорошо. Но со временем оборудование устаревает и не позволяет внедрять новые технологии.
Что именно подразумевается под накоплением технических проблем?
Что такое накопившиеся технические проблемы? Ворд Каннингхем, разработавший концепцию Wiki и ставший одним из основоположников экстремального программирования, усматривает в этом понятии прекрасную метафору для описания случаев, когда что-то сделано быстро, но плохо и, следовательно, когда-нибудь придётся все переделать. Это очень похоже на денежный долг. Консультант Мартин Фаулер тоже видит связь между понятиями технической и финансовой задолженности. Заключается она в том, что со временем нарастают проценты — в данном случае будущие чрезвычайные усилия для исправления небрежно выполненной работы.
Например, если ядро вашей архитектуры унаследовано от прошлых времен, а вы хотите предоставлять услуги электронной коммерции, то информационная служба будет вынуждена приспосабливать ядро для работы с более современной технологией. Унаследованные системы не предусматривают такой возможности , значит, вам придется построить свой программный “мост”. Новое приложение на базе веб окажется зависимым от основных информационных систем, которые оно будет использовать в качестве шлюза, чтобы производить аутентификацию, распространять и обновлять важнейшую информацию, предназначенную для компании, ее клиентов и различных финансовых органов. В каждом случае потребуются свои программные “мосты”.
Долгосрочные последствия
Экстраполируйте приведенный пример на пятилетний срок, и окажется, что ваша информационная служба “подстраивала” ядро архитектуры раз пятьдесят, создавая тысячи таких программных “мостов”. Если вся работа велась собственными силами компании, то сколько программистов успело смениться? Они оставили своим преемникам удобочитаемую документацию? Может статься, что у вас всего один-два “героя” — совершенно необходимые сотрудники, которые единственные во всей компании способны устранять любые проблемы, возникающие в информационной системе. В результате могут увеличиться перерывы в обслуживании клиентов и может образоваться узкое место при оказании нового вида услуг.
Поскольку любое приложение зависит от ядра архитектуры, ошибка в его работе, возникшая в любом месте в сети, которая может показаться изолированной, на самом деле способна отразиться на множестве других сервисов. Из-за этого некоторые из них станут недоступны и несчетное число пользователей лишится доступа к ним. Так как существуют тысячи созданных своими силами программных “мостов”, отыскать источник проблемы будет непросто и на это потребуется время. Соответственно не удастся быстро восстановить работоспособность сервисов. В подобной системе все взаимосвязано, а следовательно, такое ядро архитектуры является жестким и хрупким.
Почему накопившиеся технические проблемы отражаются на конечном результате?
Производительность ИТ-системы сегодня играет огромную роль в деятельности любой компании. Унаследованные информационные системы влияют на конечный результат, идет ли речь о предоставлении новых сервисов, об устранении ошибок в системе, об оплате труда, обеспечении безопасности или соблюдении требований законодательства. Если вернуться к вопросу о “героях”, то в современных условиях наличие лишь одного программиста создает угрозу для работоспособности компании. Стоит ему уволиться, и у вас возникнут проблемы. А если останется, то может постоянно требовать от вас увеличения заработной платы.
Многие компании разрабатывают политики, в соответствии с которыми все действия с информационными системами должны производиться во время плановых простоев. Такие жестко фиксированные сроки ослабляют конкурентоспособность предприятия. Например, недавний кризис ипотечного кредитования заставил финансовые институты направить средства в нижний сегмент рынка, т. е. финансировать малые и средние предприятия.
Финансовые компании теряют огромные деньги из-за неспособности предложить свои услуги клиентам такого рода. Соответственно они не могут извлечь прибыль из миллионов ежедневных денежных транзакций на этом рынке. Если окно для проведения ИТ-работ не появится на протяжении трех месяцев, инициативу может перехватить более гибкий конкурент, который захватит рынок. Тогда накопившиеся технические проблемы станут для вас причиной потери дохода в миллионы долларов.
Где решение?
Обычно для устранения накопившихся технических проблем отбрасывают буквально всё имеющееся ПО и начинают с нуля. В этом есть определенный смысл. Однако остаются нерешенными две весьма важные проблемы. Во-первых, могут потребоваться очень большие затраты. Не говоря уже о необходимости переобучения персонала, устранения возникающих на этапе внедрения проблем и непредсказуемых сбоев, сопровождающих любую масштабную замену информационной системы. Во-вторых, если задачу ликвидации накопившихся технических проблем не сделать приоритетной, вы рискуете выбраться из одной ямы лишь для того, чтобы сразу начать скатываться в другую.
Как гибкое программирование помогает устранить накопившиеся технические проблемы?
Чтобы избавиться от накопившихся проблем, важно понять, что в действительности представляет собой гибкая разработка приложений. Если говорить упрощенно, ее можно сравнить с золотым штампом с надписью “Одобрено”. Это гарантия, что на всех этапах проекта — при планировании, написании и тестировании программного кода — использовался передовой опыт. Четыре перечисленные ниже требования гибкого программирования имеют ключевое значение для тех, кто хочет освободиться от накопившихся технических проблем. Они позволяют наметить контрольные точки, которые не дадут вашей организации вновь погрузиться в эту пучину.
1. Создание независимых приложений и их изоляция.
2. Разложение на элементарные операции, упрощение нового программного кода и любого кода, с которым приходится работать.
3. Многократное автоматизированное тестирование программных модулей, а также функциональное тестирование.
4. Написание документации только для востребованных нужд бизнеса (for only required business needs).
Накопившие технические проблемы можно устранить и без помощи гибкого программирования. Однако не исключено, что они вновь станут нарастать. Создание приложения с использованием гибкого программирования начинается с анализа имеющейся ИТ-структуры и выявления наиболее значимых для бизнеса элементов, после чего работа должна вестись в первую очередь над важнейшим программным кодом. Чтобы этого добиться, необходимо изолировать зависимые приложения и заставить их функционировать вне связи с ядром информационной системы. Это позволит сократить сроки проекта и пользоваться отдельными приложениями, пока другие находятся “в стадии разработки”.
Автоматизированное тестирование может потребовать колоссальных расходов и вылиться в весьма хлопотное занятие, если нужно будет переписывать большой объем унаследованного кода. Важно соблюсти баланс между автоматизированным тестированием и регрессивным, которое проводится каждый раз при разработке нового решения.
Разложение унаследованного кода на элементарные операции способно вырасти в ничуть не меньшую по объему задачу. Выгоды от использования простого кода, который легко поддерживать с помощью вашей информационной службы, очевидны. Но в случае с унаследованными приложениями необходимо найти золотую середину. Программисты должны стремиться разложить любой код, с которым им приходится иметь дело в процессе разработки, в том числе унаследованный.
При гибком программировании вам гарантируется, что разработчики трудятся над основными функциями системы и не отвлекаются на создание ненужной, раздутой документации. Если заставить их сконцентрироваться на написании кода, а не слов, то можно быстрее получить более значимые предложения. И вдобавок при этом сократится количество изменений, вносимых во второстепенную документацию.
В настоящее время Дэвид Уэбб является вице-президентом компании Exigen Services по профессиональным услугам. Более пяти лет он проработал в распределенных командах разработчиков, использующих гибкое программирование, где создавал приемы и метрики, позволяющие эффективно управлять офшорными проектами в этой области. Живет Дэвид в Лондоне.
