Home

Автор: Вячеслав Панкратов, Новичков Александр

Материал опубликован в журнале «Стратегия IBM в области программного обеспечения». №1, 2007 год. (PDF, 2mb)

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

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

Проблемы «затяжного прыжка»

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

Инструменты реализации

Экономика должна быть...

• Заказчик, как правило, сам определяет состав инструментальных средств, необходимых для автоматизации процессов разработки и сопровождения ПО. Во внимание принимается известность брэнда, совокупная стоимость владения, включающая стоимость лицензий ПО и технической поддержки, а также стоимость консалтинга.
• Несмотря на то что выбору инструментальных средств уделяется слишком много времени, в поиске лучших средств организации, как правило, ничего не находят. Современные инструменты с точки зрения функциональности практически одинаковы и различаются лишь в деталях. Основные различия кроются именно в совокупной стоимости владения.
• Рыночные тенденции сейчас таковы, что большинство компаний — разработчиков ПО стараются ориентироваться на бесплатные утилиты. При этом учитываются прямые затраты на лицензии.
• Как видно из таблицы (см. в конце статьи), идеальных инструментов нет. Два ведущих производителя средств разработки не обеспечивают пол ного покрытия всех процессных областей.
• В двух других случаях есть свои недостатки и особенности, также не позволяющие их называть идеальными кандидатами. В качестве особенностей IBM Rational можно отметить излишний академизм средств, которые отпугивают многих именно своей фундаментальностью, устраивающей большие компании, но не очень подходящей для маленьких. Бесплатные системы хороши всем, кроме того, что они не создаются как единый комплекс, а состоят из вороха разрозненных инструментов, требующих логической связи для получения целостного результата (что уже есть в Rational и других брэндах). А это уже программирование и, как следствие, дополнительные затраты.

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

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

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

Быстрое внедрение

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

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

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

Опыт, зафиксированный в инструментальных решениях

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

Правила быстрого внедрения

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

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

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

Прочный фундамент для процессных изменений

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

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

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

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

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

Основные игроки рынка инструментальных средств разработки