Многие организации по разработке программного обеспечения используют в своих проектах внешние трудовые ресурсы. Когда компании прибегают к гибкой и рациональной разработке, часто возникает вопрос: "Вписывается ли аутсорсинг в гибкую среду?". Ответ: это возможно, но для гарантии успеха потребуется тщательная предварительная проработка и последовательное выполнение плана. В этом цикле статей из двух частей Тони Граут делится своим опытом в области эффективного применения гибкого аутсорсинга и критических элементов, необходимых для достижения оптимальных результатов.
Как правило, наилучших результатов в области аутсорсинга проектов гибкой разработки добиваются те организации, которые уже совершили культурный и организационный скачок в этом направлении и накопили определенный опыт. Но тем, кто им не обладает, но нуждается в аутсорсинге критически важных приложений ― таких, которые обращены к клиентам и на которые опирается бизнес, ― будут полезны следующие советы.
Совет 1: демонстрируйте нефункциональные требования
Начните с отражения нефункциональных требований как можно на более ранних этапах проекта, основывая их на фактической среде разработки, которая будет использоваться. Например, в проекте онлайн-системы для органов полиции, которую я описал в первой части, можно было бы составить пользовательскую историю ― то есть набор требований, связанных с определенным результатом, ― в которой отражено, как сотрудник полиции сможет получить сведения о преступнике менее чем за две секунды. Для этого нужно продемонстрировать, каким образом все приложения, входящие в инфраструктуру, будут соединены между собой, как будут решаться вопросы безопасности и т.п.
Кстати, для тех, кто не знаком с идеей "пользовательской истории" гибкой разработки, вот ее краткое описание: в своей простейшей форме она разъясняет, как пользователь получает ту или иную выгоду от системы при ее эксплуатации. Скажем, в примере с полицейской системой я хочу получить сведения о конкретном преступнике, чтобы понять, мог ли он совершить преступление, которое я расследую. Это и есть пользовательская история; задача разработчиков программного обеспечения заключается в том, чтобы обеспечить данную функциональность с помощью некоторых аспектов разрабатываемого ПО.
В нашем примере "выгода" ― это возможность отображения на экране информации, извлеченной из полицейских систем. Однако некоторые истории больше относятся к архитектурным, или нефункциональным, моментам, чем другие. Пользовательские истории не обязательно должны освещать чисто технические или нефункциональные вопросы. Они могут быть как функциональными, так и бизнес-ориентированными (то есть нефункциональными с точки зрения того, что именно программное обеспечение делает при взаимодействии с пользователем; это называется сценарием использования [use case]). Важно, чтобы на всем протяжении проекта пользовательские истории были согласованы с техническими рисками.
Отдавая работу на субподряд и ведя переговоры с партнером, нужно сбалансировать истории, которые обеспечат максимальные выгоды на ранних стадиях, с теми, которые исключают или уменьшают основные технические риски.
Совет 2: выберите подходящего поставщика (или двух)
В начале проекта неизвестно, правильно ли вы выбрали партнера, если только а) вы не работали с ним раньше или b) с ним раньше не работал кто-то очень близкий вам, кто заслуживает доверия.
У большинства системных интеграторов есть перечень выполненных проектов. В первую очередь нужно искать таких, у кого наибольший опыт в области гибкой разработки, кто занимается этим все время. Гарантии, что вы будете работать с лучшими специалистами, нет, но начинать всегда нужно с поиска таковых. Если применять подход своевременных поставок при гибкой разработке (disciplined agile delivery), то нет никаких сомнений в том, что это будет эффективнее обычного поиска субподрядчика.
Если партнер собирается создавать программное обеспечение и, скажем, может предъявлять вам что-то раз в месяц, то он должен быть в состоянии составлять автоматизированные отчеты о текущих версиях (build records). Он должен присылать вам код и развертывать его в вашей среде, если у него есть к ней доступ. Они должен делать это регулярно и часто, чтобы вы могли наблюдать фактическую работу, не дожидаясь окончания проекта.
Прелесть гибкого подхода состоит в том, что он дает возможность увидеть, что представит ваш избранный партнер, согласно договору, по окончании первого этапа проекта. Если это критически важный проект, который необходимо выполнить точно и в срок, то параллельная работа с двумя разным исполнителями поможет вам быстро оценить, какой из них работает лучшие, и впоследствии обеспечит повышенную уверенность. Это позволит быстро переключиться, если окажется, что партнер не годен, или заставить его выделить на ваш проект лучших специалистов, вместо тех, которые явно не справляются. Таким образом, выбор поставщика согласуется с одним из основных принципов гибкой разработки, который требует частого выпуска действующего программного обеспечения.
Совет 3: согласовывайте свои контракты с гибким подходом к выпуску продукции
Заключаемые контракты должны допускать поэтапные решения о выборе поставщика, а не сразу на весь проект; это обеспечит возможность в случае необходимости перейти к другому поставщику на более раннем этапе процесса. Контракты должны содержать критерии исключений как по оплате, так и по предоставлению результатов, увязанные с взаимодействием или количеством этапов, так чтобы можно было управлять рисками, связанными с изменением требований.
Соглашение об уровне обслуживания (SLA) должно соответствовать гибкому подходу, которого вы придерживаетесь. Так, одна из отправных точек - это условия нарушения соглашения. Если у вас определены ворота качества, используйте их для управления своими взаимоотношениями, особенно если нужна возможность разрыва подписанного контракта.
Вот отличный пример гибкого договора субподряда.
С точки зрения чисто гибкого подхода необходимо как можно быстрее получить выгоду. Но также нужно повышать свой собственный уровень знаний и как ИТ-организации, и как предприятия в целом. Ведь в конечном итоге гибкость ― это способность быстро понять ситуацию и принять правильное решение. Хороший инструментарий создает возможности для быстрого поиска информации и принятия решений, основанных на этой информации. Я сейчас говорю не о бизнес-анализе, а, скорее, о способности найти архитектурные средства, которые документируют взаимодействие компонентов, то есть связи между ними, возможные изменения в серверном приложении для ускорения их совместной работы или способы подключения сторонних систем.
Гибкие методы по своей сути ― это коллективные методы, режим разработки программного обеспечения силами всей команды. Этот коллективный аспект принципиально важен, особенно способность эффективного взаимодействовия. Как отмечает Уокер Ройс, разработка программного обеспечения больше напоминает создание кинофильма, чем строительство моста. Это коллективный, интеллектуальный процесс, который не всегда точно следует сценарию. Это творческий процесс, и необходимо поддерживать связи между людьми, которые в нем участвуют.
Почему важен инструментарий? Из-за плохого взаимодействия и неспособности находить нужные документы и отслеживать их от начала до конца, как и сами артефакты, теряется много времени. Хороший инструментарий позволяет помечать ресурсы, чтобы на протяжении всего проекта разработки программного обеспечения знать, у кого что находится и кто за что отвечает.
Часто используют инструментарий сообщества разработчиков ПО с открытым исходным кодом, но он не приспособлен для отдельных предметных областей. Например, инструмент с открытым исходным кодом может обеспечить удовлетворительное управление кодом в небольшой, локализованной среде. Однако начав связывать фрагменты кода в контрольных задачах, вы обнаружите, что такой инструмент затрудняет сотрудничество через организационные границы. Требуется обеспечить как можно меньше трения при взаимодействии, чтобы команды тратили больше времени на решение задач, а не на поиск тех или иных артефактов, определение внесенных изменений и сбор замечаний по поводу определенных ресурсов.
Прослеживаемость от начала до конца важна всегда, а при аутсорсинге, пожалуй, даже еще важнее. Возможность проследить идею от требований бизнес-уровня по всему пути до работающего кода и даже до данных, которые где-то накручиваются на диск, имеет принципиально важное значение по целому ряду причин. Например, если контракт составлен, исходя из фиксированной цены, и в проекте используется инструмент управления изменениями, то вы получите прослеживаемость ссылок, чтобы поставить изменившиеся требования в соответствие результирующему коду.
Это прослеживаемость на бизнес-уровне и договорном уровне. При разрастании проекта вам придется решать многочисленные проблемы, такие как пересечение организационных границ при составлении контрактов и графиков платежей, и тогда прослеживаемость становится еще важнее. Это особенно верно, если то, что вы создаете, рассчитано на длительный срок. Если в группе шесть человек, и вы проектируете очередную поисковую систему, то вам, вероятно, незачем беспокоиться о многократном использовании. На следующий год вы выбросите этот алгоритм и напишите лучший. Но когда организация из 300 сотрудников создает ядро банковской системы, то оно может проработать 60 лет.
Так что будь то традиционные требования к прослеживаемости кода или более высокоуровневые требования прослеживаемости между людьми и системами, гибкая реализация не просто выполнит их, а максимально уменьшит трение и сделает все на соответствующем уровне. Истинная гибкость ― это возможность быстро принимать решения, и прослеживаемость обеспечивает такую быстроту.
Совет 5: требуйте видимости и прослеживаемости, чтобы обеспечить доверие
Для успеха гибкого проекта с применением аутсорсинга важно на протяжении всей работы доверять отчетам, информации для руководства и результатам бизнес-анализа. Мы уже говорили о важности прослеживания, которое имеет решающее значение для успеха проекта, но нужна также видимость того, что происходит на самом деле.
Рассмотрим случай автопроизводителя. Автомобильная промышленность основана на идее комплексной цепочки поставок, когда нужно видеть, что делает ваш партнер, чтобы точно знать, какой вы получите результат и когда. Вы видите процесс и знаете, что происходит и что вам предстоит сделать, поэтому можете приступить к работе своевременно ― это и есть рациональное мышление.
Теперь нам нужно перенести его на процесс выпуска программного обеспечения, чтобы получить такой же уровень распоряжения информацией. Бизнес-анализ указывает, где мы находимся, и позволяет надежно предсказать, когда мы сможем выпустить свой продукт или сервис, сможем ли мы предоставить его быстро и обеспечим ли требуемое качество. И такой уровень видимости нужен на протяжении всего проекта ― от начального этапа до завершения проекта партнером.
В идеале нужно использовать один и тот же инструментарий, или же партнер должен предоставить вам доступ к своим информационным панелям, чтобы вы могли видеть, что происходит. Изменения, вносимые партнером, должны извлекаться из реальной информации о том, что происходит на его предприятии ― не из электронных таблиц, сообщений электронной почты или документов Word, которые он наспех состряпает, а из надежных записей, которые позволяют при желании углубиться в детали и увидеть код, над которым работают исполнители.
Такая прозрачность и отчетность служит ключом к укреплению доверия и уверенности при взаимодействии с партнером по аутсорсингу. Чтобы завоевать доверие, партнер должен отчитываться каждые четыре недели и позволять вам видеть детали, стоящие за этими отчетами, чтобы вы могли сравнить фактические результаты с теми, что представлены в отчете.
Организация, не имеющая большого опыта в области гибкой разработки, может сделать несколько важных вещей, чтобы добиться успеха при использовании аутсорсинга разработки критически важных бизнес-приложений. Ключом служит создание условий, в которых нужно заслужить и сохранить доверие ― от определения нефункциональных требований до правильного выбора поставщика и внесения гибкости в контракт и взаимодействие, обеспечения видимости и прослеживаемости в инструментарии ― и первостепенное значение имеет последовательный выпуск действующего программного обеспечения, созданного с применением принципов гибкой разработки.