Цель "Исследования современного состояния гибкой разработки" ― собрать информацию о том, как предприятия на самом деле внедряют методы гибкой разработки. В опросе приняли участие 168 респондентов со всего мира, работающие в различных отраслях, включая госучреждения. Они поделились сведениями о том, какую пользу они извлекли из гибких методов и с какими проблемами им пришлось столкнуться. В этой статье приводятся некоторые общие результаты исследования и говорится об основных выявленных преимуществах и проблемах.
Небольшие фирмы, как правило, не испытывают значительных трудностей при внедрении методов гибкой разработки. Это не очень сложная задача. Большинство трудностей возникает на уровне крупных организаций. Мы потратили несколько лет, пытаясь помочь нашим клиентам выяснить: Как планировать? Как заручиться участием заказчика и руководства? Как взаимодействовать со смежными группами, чтобы обеспечить успешный выпуск конечного продукта?
Когда мы говорим с клиентами, наша цель - помогать им, снабжая проверенными практическими рекомендациями и приемами, которые работали в наших проектах и которые они могут применять для решения проблем в своих организациях. Большинство групп гибкой разработки, которые мы находим, входят в состав крупных организаций, которым необходимо масштабировать гибкий проект, преодолевая препятствия на культурном уровне.
Мы провели "Исследование современного состояния гибкой разработки", чтобы узнать, как наши коллеги применяют гибкие методы на практике. Мы также хотели понять, какие выгоды они получают от использования гибких методов (и чего удается достичь их организациям) и с какими трудностями они сталкивались (или сталкиваются) в процессе внедрения. Мы ограничили исследование теми респондентами, которые имеют реальный опыт гибкой разработки.
Это широкий круг людей из различных отраслей и организаций. Многие представляют весьма небольшие группы, но некоторые респонденты работают в очень больших командах. Например, 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, потому что мы внедрили гибкие методы на своем собственном очень крупном предприятии и помогли освоить методы гибкой разработки многим другим крупным организациям.