Пять уроков масштабирования гибкой разработки на опыте крупного поставщика услуг страхования

Гибкая разработка ― это коллективный, поэтапный и итеративный подход к разработке программного обеспечения, который позволяет своевременно и экономически эффективно производить высококачественное ПО. Изначально гибкие методы предназначались для небольших локальных групп, но их можно приспособить и к более сложной обстановке. IBM имеет опыт работы с этими методами как внутри собственной организации, так и для крупных корпоративных клиентов. Одни из наиболее ценных уроков, которые мы извлекли при реализации гибкого проектирования на предприятии, были получены во время работы с крупной страховой компанией, которую мы будем называть InsuranceCo, по адаптации для нее методов гибкой разработки и внедрению ПО IBM Rational Team Concert.

Ричард Настер, менеджер по практике управления жизненным циклом проектов гибкой и коллективной разработки международного уровня, IBM

Фото автораРичард Настер (Richard Knaster) ― менеджер отделения IBM Rational по практике управления жизненным циклом проектов гибкой и коллективной разработки международного уровня. Он помогает клиентам во всем мире реализовывать методы, практические приемы и инструменты гибкого проектирования. Член организации IBM QSE Agile Leadership, обладающий более чем 20-летним опытом разработки программного обеспечения ― от практиканта до руководителя. Внес вклад в разработку стандартов PMI Portfolio and Program Management; специалист по гибкому планированию и управлению портфелями заказов. Обладает опытом работы в области проектирования бизнес-процессов и совершенствования с измеряемыми результатами, имеет звание PMP PMI; все это в совокупности служит ценным подспорьем, когда нужно помочь организациям перейти от традиционной практики разработки к современной.



25.12.2012

Внедрение гибкой разработки на предприятии

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


Проблемы разработки программного обеспечения InsuranceCo

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

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

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

  1. Лучше всего работает погрупповой, поэтапный подход.
  2. Средства измерения и управления помогают добиться участия руководства и поддерживать его, а также улучшить процесс разработки.
  3. Наставничество и инструктаж должны проводиться в первую очередь по процессу и во вторую ― по инструментам.
  4. Интегрированные инструменты помогают продемонстрировать получаемые выгоды.
  5. Для непрерывного совершенствования важны ретроспективы.

Погрупповой, поэтапный подход

При адаптации гибкого проектирования не существует такого понятия, как «один размер, подходящий всем». В случае InsuranceCo нужно было поддерживать все виды проектов по разработке, в том числе на платформах Java, IBM WebSphere и мейнфрейма, а также специализированные ресурсы, такие как администраторы баз данных и разработчики архитектуры данных. Для всех этих групп гибкие методологии просто невозможно было реализовать одинаково или пытаться преобразовать их все одновременно.

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


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

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

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


Сначала изучать процессы, а затем инструменты

В процессе внедрения гибких методов мы обнаружили, что InsuranceCo выделила специалистов по предметным областям (SME), чтобы помочь в обучении групп, но многие из этих SME не обладали опытом в области гибких методов. Они были не в состоянии облегчить внедрение гибких методов, потому что нельзя, дав кому-то минимум знаний, ожидать, что он станет инструктировать других.

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


Интеграция помогает продемонстрировать выгоду

Так же как не рекомендуется односторонний подход к внедрению гибкой разработки на крупном предприятии, не рекомендуется и односторонний подход к замене инструментов. Чтобы продемонстрировать растущую выгоду, нам удалось использовать тот факт, что программное обеспечение Rational интегрируется с системами других компаний. В InsuranceCo использовался инструмент управления качеством другой компании, и благодаря возможности интеграции они смогли продолжать использовать его после внедрения нашего ПО. Со временем они решили, что смогут достичь лучшей интеграции, если будут использовать только программное обеспечение 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=853364
ArticleTitle=Пять уроков масштабирования гибкой разработки на опыте крупного поставщика услуг страхования
publish-date=12252012