Три роковых ошибки при реализации методов гибкой разработки

Источник: IBM

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

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

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

Неопытность: много шума, но мало результатов

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

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

Отказываетесь планировать? Будьте готовы к неудаче

Чтобы реализация методов гибкой разработки была успешной, группа должна:

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

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

Гибкие команды могут просить, чтобы их оставили в покое, но если никто из руководства не поддерживает их или не знает об их полезных начинаниях, такие группы далеко не пойдут. Без плана, который четко оформляет инициативу и включает в себя способы преодоления препятствий на пути реализации методов гибкой разработки (например, контрольные точки процесса "водопад", поддержка со стороны других необходимых подразделений), будет трудно оформить инициативу, собрать группу и получить финансирование, бороться с противниками и поддерживать постоянное участие руководства. Инициативы нескольких клиентов IBM, у которых не было плана, в конечном итоге свелись к религиозной войне слов. В этих случаях часто побеждают сторонники существующего порядка, ссылаясь на риск перехода на методы гибкой разработки для организации.

Ограниченная поддержка руководства означает ограниченную гибкость

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

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

Избегайте ошибок

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

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

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

Заключение

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

IBM PureApplication System.

IBM завершает приобретение компании StoredIQ.

Параметр компилятора помогает отлаживать оптимизированный код.

Использование IBM Rational Functional Tester для измерения производительности IBM Rational ClearQuest Web (download).

IBM Rational Data and Application Modeling Bundle.

Главная » IBM