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

И в самом деле, недавний опрос среди IT-профессионалов показал, что приоритеты в этой сфере несколько сместились. 75% опрошенных указали, что главное в управлении жизненным циклом приложения (Application Lifecycle Management - сокращенно ALM) - это управление его разработкой как бизнес-процессом. А основным приоритетом респонденты указали скорость разработки приложений - существенное изменение, ведь еще несколько лет назад во главе списка стояло сокращение издержек.

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

Миф №1: «Лучший в своем классе» - лучший в принципе

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

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

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

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

Внутри отрасли идеал «лучшего в своем классе» цвел пышным цветом вплоть до того неизбежного дня, как бизнес попытался собрать свои инструменты воедино. Многие приложения оказались погребены под гнетом куда более сложного, чем предполагалось, объединения разрозненных инструментов внутри жизненного цикла приложения: каждый сам по себе был хорош, но оркестра из них не составилось, и музыки не получилось.

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

Миф №2: все-в-одном подходит всем

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

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

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

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

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

Миф №3: скомбинировали - и готово

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

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

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

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

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

Разрываем замкнутый круг

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

Автоматизация процесса обеспечивает гарантию, что все следует задуманной канве, и в любой момент можно включить в процесс новые звенья, получив на то одобрение (или отказ) на любой стадии жизненного цикла. Это важно как для отчетности, так и для возможности проследить ведь процесс.

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

Автор: Кевин Паркер

Оригинал статьи: http://searchsoftwarequality.techtarget.[...]yths-of-application-lifecycle-management

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

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

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

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

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