Гибкая разработка ― это коллективный, поэтапный и итеративный подход к разработке программного обеспечения, который позволяет своевременно и экономически эффективно производить высококачественное ПО. Изначально гибкие методы предназначались для небольших локальных групп, но их можно приспособить и к более сложной обстановке. IBM имеет опыт работы с этими методами как внутри собственной организации, так и для крупных корпоративных клиентов. Одни из наиболее ценных уроков, которые мы извлекли при реализации гибкого проектирования на предприятии, были получены во время работы с крупной страховой компанией, которую мы будем называть InsuranceCo, по адаптации для нее методов гибкой разработки и внедрению ПО IBM Rational Team Concert.
Внедрение гибкой разработки на предприятии
Изменение любого процесса на предприятии никогда не бывает легкой задачей, и переход от традиционных методов разработки к гибким методам не является исключением. Для внедрения методов гибкой разработки требуется много усилий, и процесс может занять несколько лет, потому что нужно изменить культуру организации, ее убеждения, методы руководства, кадровую политику, табель о рангах, методы финансирования и многое другое. Односторонний или бессистемный подход в долгосрочной перспективе работать не будет. Он обязательно должен быть последовательным и поэтапным. Это один из уроков, которые извлекла IBM, работая с одним из своих клиентов ― крупной страховой компанией, которую я буду называть InsuranceCo.
Проблемы разработки программного обеспечения InsuranceCo
Переход InsuranceCo на гибкие методы проектирования начинался с внедрения Rational Team Concert. Компания хотела усовершенствовать управление проектами, добиваясь прозрачности, более тесного сотрудничества и более унифицированного рабочего процесса для групп разработчиков разного типа, очень тесно сотрудничающих друг с другом. Вскоре после того как я со своей командой начал этот проект, стало очевидно, что существуют серьезные препятствия для достижения этих целей.
Например, там были сотни разработчиков в многочисленных распределенных группах, более 20 типов различных рабочих образований, почти никакой отчетности и бессистемные перестановки в руководстве. Большинство групп не практиковали непрерывной интеграции, они не могли видеть проекты в развитии, что позволило бы ограничить риски на ранних стадиях, а сам процесс выпуска продуктов требовал значительного ускорения.
Вскоре мы поняли, что эта компания не получит реальной отдачи от своих инвестиций в инструменты, если не внесет изменения в свои процессы. Мы предложили перейти к гибким методам проектирования и извлекли пять ценных уроков по масштабированию этих методов.
- Лучше всего работает погрупповой, поэтапный подход.
- Средства измерения и управления помогают добиться участия руководства и поддерживать его, а также улучшить процесс разработки.
- Наставничество и инструктаж должны проводиться в первую очередь по процессу и во вторую ― по инструментам.
- Интегрированные инструменты помогают продемонстрировать получаемые выгоды.
- Для непрерывного совершенствования важны ретроспективы.
При адаптации гибкого проектирования не существует такого понятия, как "один размер, подходящий всем". В случае InsuranceCo нужно было поддерживать все виды проектов по разработке, в том числе на платформах Java, IBM WebSphere и мейнфрейма, а также специализированные ресурсы, такие как администраторы баз данных и разработчики архитектуры данных. Для всех этих групп гибкие методологии просто невозможно было реализовать одинаково или пытаться преобразовать их все одновременно.
Вместо этого мы проанализировали, как работает каждая группа, и определили, какие методы ей следует применять и какие изменения необходимо внести в основные процессы гибкого проектирования. Например, разработчики ПО для мейнфреймов должны выпускать весь свой код за раз; они не могут вводить его в свою тестовую среду последовательно. Поэтому мы составили историю для разработки и историю для тестирования, которые отличались от чистых и простых методов гибкой разработки. Обычно одна история охватывает все. Однако мы поняли, что ввиду существующих ограничений нужно поступить иначе и работать с этими группами отдельно. Со временем мы нашли способ изменить среду и инфраструктуру этих групп, чтобы они могли стать еще более гибкими.
Инструменты для руководителей и разработчиков
Решающее значение для внедрения методов гибкой разработки на крупном предприятии имеет участие руководства. В InsuranceCo этого было особенно трудно добиться, потому что директор по информационным технологиям вначале выступал против гибких методов. Мы встретились с руководством, чтобы объяснить, в чем будет разница и как это будет функционировать. Мы использовали примеры из реальной жизни, чтобы продемонстрировать им, что результат будет стоить вложенных средств. Для поддержания участия руководства после начала проекта мы снабдили его набором показателей и мер. Мы предложили руководителям информационные панели и отчеты, которые показывали, над чем работают группы, добиваются ли они успеха и как быстро они выпускают свои продукты. Обеспечение прозрачности работы групп программирования помогло поддержать заинтересованность руководителей.
В отдельных гибких группах мы внедрили инструменты, упрощающие управление задачами. Готовые шаблоны процессов демонстрировали возможности Rational Team Concert. Эти шаблоны помогли группам разработчиков InsuranceCo использовать удачные приемы гибкой разработки и обмениваться ими, предоставляя администраторам поддержку по различным процессам и позволяя распространять новые приемы, чтобы группы могли самостоятельно совершенствовать свои процессы.
Сначала изучать процессы, а затем инструменты
В процессе внедрения гибких методов мы обнаружили, что InsuranceCo выделила специалистов по предметным областям (SME), чтобы помочь в обучении групп, но многие из этих SME не обладали опытом в области гибких методов. Они были не в состоянии облегчить внедрение гибких методов, потому что нельзя, дав кому-то минимум знаний, ожидать, что он станет инструктировать других.
Поэтому мы обеспечили дополнительное наставничество и инструктаж. Мы ежедневно проводили 30-минутные совещания по процессам и инструментам, на которых наши внутренние инструкторы отвечали на вопросы и делились опытом. Кроме того, мы организовали сообщество с дискуссионными форумами, вики, ответами на часто задаваемые вопросы и учебными материалами. Внедряя гибкие методы в каждой группе, мы проводили занятия с ними и для каждой группы по мере необходимости корректировали процессы и инструменты. Еще мы выявляли повторяемые модели, которые каждая группа могла использовать "как есть" или адаптировать под свои уникальные потребности.
Интеграция помогает продемонстрировать выгоду
Так же как не рекомендуется односторонний подход к внедрению гибкой разработки на крупном предприятии, не рекомендуется и односторонний подход к замене инструментов. Чтобы продемонстрировать растущую выгоду, нам удалось использовать тот факт, что программное обеспечение Rational интегрируется с системами других компаний. В InsuranceCo использовался инструмент управления качеством другой компании, и благодаря возможности интеграции они смогли продолжать использовать его после внедрения нашего ПО. Со временем они решили, что смогут достичь лучшей интеграции, если будут использовать только программное обеспечение IBM. Но вначале, еще не приняв решение использовать что-то другое, они смогли убедиться в эффективности одного из инструментов IBM.
Непрерывное совершенствование: ретроспектива
Непрерывное совершенствование ― неотъемлемая часть гибкой разработки. Чтобы гарантировать, что новый процесс и инструменты эффективно работают для групп и понять, с какими проблемами они могут столкнуться, мы с каждой из групп проводили ретроспективное совещание через две недели после их обучения процессу и инструментам. Это помогло нам определить области, в которых требовалась дополнительная подготовка. Один из примеров ― написание историй. Нас несколько раз попросили помочь группам написать историю для них, и мы увидели в этом систему; тогда мы добавили в свой процесс дополнительную подготовку по написанию историй.
Для внедрения методов гибкой разработки на крупном предприятии требуется последовательный, поэтапный подход. Попытки осуществить все сразу, когда имеются различные платформы разработки, разные виды ресурсов и глобально распределенные группы, ведут к неизбежному провалу. Но если следовать индивидуальному подходу, согласовывая гибкие приемы с потребностями каждой группы, внедряя инструменты, соответствующие целям разработки и способствующие участию руководства, и если вкладывать средства в подготовку и наставничество, помогая прививать хорошие манеры гибкой разработки, то даже самая крупная компания сможет получить полномасштабные выгоды от гибкой разработки.