Сама по себе идея ALM (Application Lifecycle Management), управления жизненным циклом приложения, заключается в том, чтобы создать целостный и комплексный подход к разработке приложений. Концепция не новая, но по мере того, как инструменты и технологии с течением времени улучшались, идея ALM привлекала к себе все больше и больше внимания. В конце концов, чем тщательнее вы подходите к процессу разработки в целом, тем вероятнее, что вы своевременно выявите проблемы, исправите баги, сдадите проект вовремя и осчастливите ваших заказчиков.

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

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

Беглый взгляд на линейку инструментов ALM (Application Lifecycle Management) покажет, что в эту категорию входят все продукты, так или иначе связанные с жизненным циклом приложения - от сбора требований и контроля версий кода до управления проектами и мониторинга. Неудивительно, что существует некоторая путаница вокруг термина «инструменты ALM». Исторически «инструменты ALM» начинались как категория управления версиями исходного кода, но по мере того, как процесс разработки становился все более запутанным и сложным, все больше новых типов добавлялось в эту категорию.

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

Они говорят: переходим на гибкую разработку (Agile). Все будет просто супер. Они, разумеется, не технические писатели.

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