Аутсорсинг проектов гибкой разработки: Часть 1. Предварительные замечания

Источник: IBM

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

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

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

Понимание мотивов - поставщика и своих собственных

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

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

Другими словами, мы должны начать разговор с гибкости на уровне бизнеса, а затем уже спускаться к его технической подоплеке. Всегда нужно отталкиваться от искомой гибкости бизнеса. Речь не о том, отдавать ли предпочтение экстремальному программированию (XP) перед разработкой на базе тестирования; речь о необходимости предложить рынку нужное программное обеспечение, чтобы предприятия могли принести больше выгод своим клиентам и получить больше прибыли. Это верно как для работодателей, так и для их субподрядчиков.

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

Предпочтения отдельных лиц и их взаимодействие важнее процессов и инструментов

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

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

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

Работающее программное обеспечение важнее полной документации

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

Я как-то работал над государственным проектом по созданию онлайновой системы для органов полиции. От партнера по аутсорсингу требовали систему на основе устаревшей технологии, которая грозила создать проблемы с точки зрения производительности. В контракте говорилось, что критерии оплаты и выходного контроля считаются выполненными, если исполнитель представит документацию по архитектуре программного обеспечения, показывающую, как в унаследованной системе решаются эти проблемы производительности. Спустя шесть месяцев был готов 250-страничный документ, полный схем и текстовых описаний того, как они собираются решать эти проблемы. И им заплатили. Но спустя еще 18 месяцев никакого работающего программного обеспечения все еще не было, и пришлось вмешаться юристам.

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

Заключение

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

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

IBM PureApplication System.

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

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

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

Главная » IBM