Innersource в разработке приложений

27 сентябрь, 2017 - 17:34Александр Черников

Применение методологии разработки open source к корпоративной, «внутренней» разработке ПО (internal software development) позволяет быстрее вводить инновации, уменьшает время выхода готового продукта, а также просто нравится сотрудникам.

Innersource в разработке приложений

Компании самых разных масштабов и едва ли не во всех отраслях промышленности сегодня используют innersource для повышения уровня сотрудничества в разработке ПО и его повторного использования.

Этот блог можно рассматривать как краткое введение в innersource. Рассматриваются некоторые его ключевые аспекты и компоненты, а также исследуются проблемы, которые innersource может помочь устранить.

Что такое innersource?

Innersource определяется как практика применения уроков, извлеченных из разработки open source ПО, для разработки ПО в пределах корпоративной окружающей IT среды, ─ за брандмауэром компании. В рамках концепции innersource у разработчиков есть возможность и получить и дать, по крайней мере, следующее.

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

- Тестирование, расширение и устранение ошибок более многочисленным сообществом разработчиков.

Является ли это давно известной и широко применяемой совместной разработкой ПО? Да, является ее разновидностью. Однако для больших распределенных корпоративных структур она оказывается значительно шире.

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

В проектах innersource все решения, связанные с кодом, документированы и открыты. Новые команды могут использовать их, чтобы быстрее понять историю проекта и сразу включиться в работу. Основные причины, по которым компании обращаются к innersource ─ используемые на предприятиях закрытые или изолированные (siloed) модели разработки ПО.

Дублирование разработок

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

Распространение дублирования может также означать, что на предприятии слабо используются (или вообще не работают) коллаборационные схемы.

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

Время выхода на рынок

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

Ограничения

Если разработка является закрытой или изолированной, то привлекаются тестеры только определенной группы. Это ограничивает ресурсы для поиска и устранения проблем (например, уязвимостей).

С этой точки зрения IT руководители предприятий задаются вопросами ─ насколько эффективнее привлечение более широкого круга специалистов внутри предприятия и какое воздействие это будет иметь на конечное качество продукта?

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

В итоге разработчик часто «варится в собственном соку», имея возможность учиться и обсуждать свою работу не более, чем с десятками, а иногда и только с 3-5 коллегами. Общение с большим количеством разработчиков высокого класса существенно и быстро повышает квалификацию, объем знаний и опыт работы в проектах.

Согласно опросам, проведенным по данной тематике, разработчики говорят следующее.

Дайте нам:

- Минимальные ограничения для доступа к коду.

- Правильную окружающую среду (например, ─ не заставляйте нас менять наше инструментальное ПО, если это не необходимо).

- Руководящие принципы, но не приказы.

Позвольте нам:

- Распоряжаться собой.

- Самим управлять нашими проектами

- Эффективно общаться.

А также

- Пусть все условия будут максимально простыми, без сложных процессов и процедур.

Культура

Innersource намного более связана с управлением изменениями и культурными преобразованиями, чем просто с возможностью поделиться кодом или наличием определенного инструментария.

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

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

Типичное мышление ─ «Мы не знаем вас, не доверяем вашему коду, и поэтому отклоняем его».

Мышление innersource ─ «Давайте обсудим, как довести этот код до уровня, на котором он может быть слит».

Юридические аспекты

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

Образование

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

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

Инструменты

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

Время и ресурсы

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

Метрики

Программы innersource дают хороший позитивный результат. Однако, «хороший» ─ это слишком общая оценка. С innersource предприятия стремятся достигнуть одной или нескольких следующих целей.

- повышение качества процесса разработки.

- сокращение стоимости разработки.

- повышение качества конечного продукта.

- сокращение времени его вывода на рынок.

- удовлетворенность сотрудников и потребителей.

Заключение

Может показаться, что изложенные выше положения довольно банальны. Однако на практике переход к innersource часто вызывает большие трудности. Их основная причина ─ желание обособиться, не делить свои локальные достижения с другими подразделениями.

Такой подход вредит общей успешности предприятия. Образно говоря, innersource заменяет реки, разделяющие подразделения и коллективы, мостами между ними.

Многие ведущие компании, как IT, так и не-IT, уже достаточно долго используют методологию innersource. В их числе ─  Capital One, GlobalSoft, Google, HP, IBM, Lucent, Microsoft, Nokia, PayPal, Philips, SAP и др.

Для более подробного ознакомления с методологией innersource можно рекомендовать книгу «Getting Started with InnerSource» (2015).

Innersource в разработке приложений