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

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

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

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

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

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

Давайте суммируем ключевые проблемы в организации ALM, распространенные до того, как эволюция сделала следующий шаг:

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

• Отсутствие прозрачности в процессах—Если вы проанализируете, как сейчас в компаниях и проектах внедряются инструменты - то есть каким образом внедряются сами процессы - то увидите, что каждый инструмент имеет свои собственные скрипты управления и конфигурации, а объединяются инструменты временами очень неуклюжими способами. Если у отдельных скриптов, бывает, отслеживается версионность, то интеграция в целом не имеет ни версионности, ни четкого управления. Это тоже далеко от оптимальности, поскольку процессы в компании - часть ее активов, и невозможно ничего улучшить из того, что нельзя идентифицировать, описать и измерить.
• Ненадежная синхронизация данных—Инструменты и рабочие потоки порождают много информации в процессе разработки, но инструменты часто имеют свои собственные закрытые механизмы хранения данных. Использование разрозненного набора инструментов (к примеру, для сбора требований и тестирования) очень скоро превращается в кошмар сопряжения данных. У многих инструментов существуют открытые API, облегчающие обмен данными, или встроенные функции, автоматизирующие этот обмен (например, импорт/экспорт через XML), но результаты синхронизации программным путем частенько полны ошибок и нестыковок, и чем сложнее данные - тем больше ошибок. Собственно, все это означает, что из того факта, что у вас есть инструмент по сбору требований и инструмент по тестированию, еще не следует, что у вас в наличии и ALM-связь между ними.

Оригинал: http://www.manning.com/huettermann/

Перевод: Александра Родсет

Сертифицированные курсы

Андрей Плетенев. Онлайн курс Agile. SCRUM. Курс включает более 20 уроков с практическими заданиями, которые индивидуально проверяются и комментируются тренером.

Еще интересные статьи на эту тему:

• SDLC - жизненный цикл разработки системы
• Внедрение ALM
• Как именно Agile ALM может помочь?
• Инструментарий Agile ALM
• Внедрение Agile ALM