Исследование современного состояния гибкой разработки

Как ИТ-группы справляются с переходом на методы гибкой разработки

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

Пол Горанс, руководитель практикума ускоренного выпуска решений, IBM Global Business Services, Application Services, IBM

Фото автораПол Горанс (Paul Gorans) возглавляет международный практикум ускоренного выпуска решений (Accelerated Solution Delivery) в отделении IBM Global Business Services. Он и его группа предоставляют услуги по "соединению гибкого подхода с производственной дисциплиной", работая с другими группами IBM над внедрением методов гибкой разработки в проекты по созданию продуктов и услуг и преподавая гибкие методы специалистам IBM Global Business Services. Имеет более чем 20-летний опыт работы в ИТ-отрасли; руководил многими проектами гибкой разработки, анализировал гибкие программы и реализовывал проекты по оценке и преобразованию организаций. За последние 10 лет лично проконсультировал более 400 клиентов и проектов, расширил глобальное сообщество гибкой разработки IBM и принял участие в написании целого ряда книг и исследований Forrester в области гибкой разработки.



Скотт У. Эмблер, ведущий специалист по практическому применению гибкой разработки, Rational Methods Group, IBM

Скотт Эмблер (Scott W.Ambler) ― президент консалтинговой фирмы Ronin International, специализирующейся на наставничестве по процессу объектно-ориентированного программирования, архитектурномe моделированию и Enterprise JavaBeans (EJB)-разработке. Автор или соавтор ряда книг по объектно-ориентированному программированию, включая вышедшую недавно Азбуку объектов, 2 редакция, в которой подробно разбираются темы, кратко изложенные в этой статье. Электронный адрес: scott.ambler@ronin-intl.com; Web-сайт: www.ambysoft.com.



09.01.2013

Об исследовании

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

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

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

Это широкий круг людей из различных отраслей и организаций. Многие представляют весьма небольшие группы, но некоторые респонденты работают в очень больших командах. Например, 16% указали группы из 21 и более человек, а хороший процент этих групп насчитывает свыше 100 членов. Подобная статистика характерна и для традиционных организаций по разработке программного обеспечения.

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

Все детали этого исследования, включая источник данных и оригинальные вопросы, которые мы задавали, можно найти на странице www.ambysoft.com/surveys/.


Практическое применение гибких методов

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

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

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


Выгоды гибкой разработки

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

Интересно, что одна треть опрошенных отметила улучшение качества документации, поставляемой вместе с системой, а половина ― равный уровень качества документации и системы. Примерно 80% сообщили, что качество документации получается не хуже, чем при традиционных методах работы. "Ну и что?", ― спросите вы. Просто документация ― одна из вещей, за которые сообщество гибкой разработки годами критиковали, хотя на самом деле, похоже, гибкая документация тоже получается вполне качественной.

Конечно, никакая техническая гибкость ничего не значит, если она не помогает становиться более гибким самому предприятию. Свыше 90% участников нашего опроса заявили об улучшении своей способности реагировать на изменения, в том числе изменения в бизнес-среде и в бизнес-требованиях.

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


Базовой подготовки недостаточно

Мы много лет помогали клиентам, придерживаясь очень прагматического подхода к гибкой, рациональной и быстрой разработке, но в последние два года объединили свои методы дисциплинированной и масштабируемой разработки в комплексную методологию и теперь помогаем клиентам в ее реализации. Дисциплинированная гибкая разработка (Disciplined Agile Delivery - DAD) — это набор процессов, который отражает те реалии, с которыми организации сталкиваются на пути внедрения гибких методов и попыток эффективно их применять. DAD поддерживает более строгие методы работы, чем одни только чисто гибкие методы.

Поэтому один из вопросов, которые нас живо интересовали, состоял в том, действительно ли для успеха достаточно двухдневного курса сертифицированного координатора (Certified ScrumMaster - CSM). Утвердительно ответили менее 4% респондентов, так что мы пришли к следующему выводу: это разумное начало, но обучение не должно на этом заканчиваться.

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


Другие проблемы

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

Измерение успеха

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

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

Расхождение финансового управления с гибкими методами

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

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

Негибкие группы

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


Заключительные размышления: усилия по внедрению гибких методов в IBM и других крупных организациях

IBM являет собой пример внедрения гибких методов в одной из крупнейших в мире организаций. Мы не только внедрили гибкие методы в своих собственных группах разработки (и уже описали это в нескольких книгах и исследованиях опыта внедрения гибких методов), но и помогли перейти на гибкие методы сотням других организаций. Это главное, к чему мы стремимся. Мы помогаем организациям понять гибкие стратегии и найти способы их эффективного применения.

Многие из наших групп в IBM работают над большими проектами, и весьма значительная часть наших групп разработчиков практикует гибкие методы. Продукт IBM Rational Team Concert создан для гибких разработчиков распределенной международной группой. И мы активно помогаем своим клиентам освоить гибкие методы для применения в масштабных проектах. Наши гибкие системы Rational и Global Business Services обеспечивают основу для масштабирования.

При случае посетите Agile Transformation Zone и зайдите на Jazz.net, чтобы узнать очень интересные вещи о том, что мы делаем. Те же, кому не удается совместить гибкие методы с дисциплиной и масштабом, пусть обратятся к представителю IBM, и мы обсудим их конкретные проблемы и договоримся о том, как удовлетворить их потребности.


Заключение

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

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Rational
ArticleID=854361
ArticleTitle=Исследование современного состояния гибкой разработки
publish-date=01092013