Agile-взаимодействие в распределенных командах

Количество инструментов для поддержки работы распределенных Agile-групп растет постоянно [1], иногда не поспевая за требованиями масштабируемости разработки, тем не менее имеются эффективные средства, применяемые компаниями для поддержки взаимодействия.

Инструменты совместной работы для распределенных групп Agile

Инструменты совместной работы можно обобщенно разделить на три группы (см. рисунок) в соответствии с тем, какие функции они поддерживают.

Инфраструктура взаимодействия

Взаимодействие. Средства в этой категории обеспечивают обмен информацией между заказчиками и разработчиками распределенного проекта. К ним относятся, например, системы мгновенного обмена сообщениями, средства IP-телефонии, системы конференц-связи, платформы совместной работы с функциями календаря и демонстрации экрана.

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

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

Рассмотрим каждую категорию, уделяя особое внимание технологиям поддержки взаимодействия, как имеющим первостепенное значение для распределенных Agile-групп. Эти технологии не только обеспечивают возможность совместной работы, но и выполняют роль центров, через которые проходит вся необходимая информация [2], помогая участникам команды поддерживать осведомленность о текущей ситуации — об элементах своего окружения, сотрудниках, задачах и артефактах [3].

Коммуникации

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

Платформы совместной работы

Сегодня участники распределенной группы все чаще взаимодействуют с помощью коммуникационной платформы, позволяющей создать единое рабочее пространство проекта, в котором все внутренние дискуссии можно оформить в виде отдельных каналов («комнат»). В этой категории господствует система Slack, успех которой вдохновил на создание аналогичных инструментов, в том числе Microsoft Teams — претендента на «трон», особенно среди групп, уже использующих Skype for Business или Google Hangouts (сервис, который из потребительской чат-системы был переработан в коммуникационное решение корпоративного класса).

На всех этих платформах общение может происходить как в текстовом режиме, так и в режимах голосовой и видеосвязи — пользователи могут переключаться между синхронным и асинхронным режимами, используя эти системы вместо электронной почты. При этом вся история событий сохраняется в журнале с возможностью поиска, что предотвращает потерю знаний и разрозненность сведений. Имеются базовые функции совместной работы: календарь, обмен файлами и демонстрация экрана; кроме того, можно подключать многочисленные сервисы, используемые в разработке ПО, с которыми можно взаимодействовать путем простого ввода команд. Такая «разработка в режиме беседы», иногда называемая ChatOps, особенно полезна при внедрении практик DevOps в распределенных проектах, так как повышает удобство решения эксплуатационных задач для разработчиков.

Веб-решения

Классическая альтернатива новым коммуникационным платформам — системы веб-конференций, такие как Cisco WebEx и GoToMeeting. Наиболее заметное их отличие в том, что они, как правило, не предоставляют разделяемое на каналы рабочее пространство для связи в режиме чата. Кроме того, у них обычно есть только платные варианты, тогда как Slack, Microsoft Teams и Google Hangouts — это freemium-продукты, и их бесплатные версии широко применяются малыми командами, которым не нужны групповые конференции.

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

Все перечисленные системы имеют полнофункциональные мобильные приложения.

Рабочее пространство

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

Рабочее пространство проекта

Разработка — основной вид деятельности групп программных инженеров. Среды коллективной разработки GitHub и GitLab предоставляют рабочее пространство проекта, повышая продуктивность и комфорт труда разработчиков. Это достигается путем сосредоточения в одном месте стандартного инструментария, к которому относятся: система управления версиями (Git), средства контролируемого обмена артефактами ПО, система отслеживания проблем (база данных для управления отчетами о дефектах и запросами изменений) и система управления контентом, содержащая знания о проекте.

Требования и проектирование

В Agile-проектах спецификации выражаются на естественном языке в форме пользовательских историй, которые сохраняются в системе отслеживания проблем. Обычно трекеры проблем встроены в рабочее пространство проекта, но есть и специальные системы вроде Pivotal Tracker и Jira, которые реализуют управление заданиями с помощью досок канбан и Scrum, а также осуществляют анализ производительности на базе Agile-метрик (выработка — burndown, диаграмма скорости и т. п.).

Взаимодействие в инженерных группах подразумевает обмен не только файлами, но и контентом, например проектными моделями. Существует несколько веб-инструментов для коллективного создания UML-диаграмм, один из них — Creately, который напрямую интегрируется с Jira, Cacoo и GenMyModel.

Центры знаний

Распределенным проектам нужна система управления контентом для обмена знаниями — внутренними документами, стандартами и оптимальными методами. Обычно для этой цели используются вики-системы, поскольку их легко редактировать, они автоматически обеспечивают общий доступ к контенту и нередко уже встроены в рабочее пространство проекта, как, например, в GitHub и GitLab. Но современные команды также пользуются платформами вопросов и ответов наподобие Stask Overflow Enterprise, в которых проще сохранять и искать накопленные группой знания. Существуют и бесплатные системы форумов, где можно получить информацию по многим вопросам — например, Question2Answer, TalkYard и Scoold.

Сборка и тестирование

Распределенным проектам необходимы защищенные репозитории с возможностью удаленного доступа, а также системы управления сборкой. Выбор инструментов сборки, разумеется, зависит от языка программирования. В Java-проектах для компиляции и управления внешними зависимостями используются Maven или Gradle, а проекты на Python и JavaScript полагаются на диспетчеры пакетов pip и npm соответственно.

Согласно «Манифесту Agile», в основе Agile-разработки лежат четыре элемента: взаимодействие, поставка, анализ и совершенствование. Стержнем методов Agile, ключевым инструментом анализа и улучшения является тестирование. Выбор средств тестирования тоже зависит от языка программирования. Фактическим стандартом модульного тестирования для Java-проектов стал JUnit. В проектах, базирующихся на JavaScript-фреймворках, часто применяется Jasmine для создания поведенческих тестовых случаев, а Karma — для выполнения тестов. Для веб-приложений также используется Selenium — система автоматизации тестирования в различных браузерах.

Сборка и тестирование сегодня часто выполняются вместе при помощи инструментов непрерывной интеграции (continuous integration, CI), которые, как только очередные изменения переносятся в основную ветвь кода, автоматически выполняют скрипты для сборки ПО, запуска платформ тестирования и развертывания выпусков в нужной среде (промежуточной или рабочей). В число широко применяемых CI-решений входят Travis CI, Jenkins и CircleCI.

Внедрение CI в Agile-проектах способствует не только автоматизации рабочих процессов, но и DevOps-взаимодействию за счет стирания различий между ролями разработчиков и специалистов по эксплуатации: первые получают возможность готовить к работе серверы и контейнеры и управлять ими с помощью машиночитаемых файлов определений («инфраструктуры в виде кода») в рамках всего жизненного цикла проекта.

Жизненный цикл

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

ALM и PLM

Средства управления жизненным циклом изделий (product lifecycle management, PLM) чаще применяются для продуктов, состоящих из множества различных компонентов (например, для критически важных электронно-механических систем и встроенной электроники), а системы управления жизненным циклом приложения (application lifecycle management, ALM) — в основном для ПО, к которому не предъявляются строгие требования функциональной безопасности. Лишь немногие пакеты поддерживают командную работу с синхронизацией изменений и автоматическим распространением на затрагиваемые компоненты.

К числу популярных решений относятся: Microsoft Visual Studio Foundation Server, интегрированный пакет для совместной работы, включающий средства разработки, систему сборки и инструмент управления версиями; IBM Rational Collaborative Lifecycle Management; интегрированный набор инструментов Team Concert, DOORS NG и Quality Manager; Siemens Teamcenter Polarion, интегрированная платформа для автоматизации разработки групп проектов; Micro Focus Connect, решение, предлагающее возможности проектирования, моделирования и коллективного выпуска ПО; Versionone — и средство для управления Agile-проектами, и платформа разработки ПО.

При выборе решения ALM/PLM нужно учитывать общие затраты, которые потребуются на протяжении всего жизненного цикла, и их возможность привязки к поставщику. Высокоинтегрированные пакеты, например IBM Rational, предлагают готовые механизмы триггеров и консистентности, однако последующее переключение на другую среду затруднительно. Традиционные Agile-среды вроде Polarion со временем интегрируются в более крупные пакеты, что уменьшает вероятность сохранения приемлемых по цене лицензий для небольших развертываний. Поэтому предпочтительны федеративные подходы, в рамках которых возможна гибкая эволюция по мере роста бизнеса. Всегда следует предусматривать стратегию выхода, в том числе механизмы экспорта в другие инструментарии. Например, в системах управления требованиями стандартом экспорта может быть Requirements Interchange Format.

Контроль качества

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

Независимо от модели взаимодействия и условий контрактов с поставщиками важно выбрать верные цели, установив их в качестве ключевых показателей эффективности для руководства в каждой точке жизненного цикла разработки. В числе технологий, поддерживающих проверку кода на соответствие требованиям, — статический анализ и непрерывное модульное тестирование (основа разработки с опорой на тестирование); эти средства можно включить непосредственно в среды непрерывной разработки. Завершенность кода в распределенных Agile-группах должна оцениваться по двум критериям-триггерам: отсутствие серьезных предупреждений системы статического анализа и стопроцентное покрытие управляющего кода («C0»).

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

Насколько необходимы командные технологии?

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

Управление проектами, подготовительные стадии разработки и проектирование продуктов редко удается хорошо интегрировать ввиду большого числа участников различной специализации. Как следствие, результаты инженерного труда — спецификации, документация и тестовые случаи — оказываются несогласованными. Например, нет единого стандарта наименований элементов (сигналов, параметров и т. п.), а изменения требуют большого объема дополнительной работы, в том числе по контролю отсутствия упущений. К тому же исчезает возможность многократного использования результатов. Эта ситуация усугубляется, если речь идет о взаимодействии в рамках сетей поставщиков и сложных рабочих процессов. Работа в распределенных Agile-группах без адекватно подобранных инструментов и ИТ-инфраструктуры быстро приведет к проблемам и высоким накладным расходам. Взаимодействие между несколькими предприятиями и распределенными командами часто сопровождается фрагментацией процессов и инструментальных цепочек, разнобоем интерфейсов, дублированием и несогласованностью процедур управления данными, нехваткой прозрачности.

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

***

В каком направлении будет развиваться Agile-взаимодействие? В числе прочего существует потребность в более тесной связке между управлением знаниями и бизнесом. Бизнес-цели и соответствующие метрики должны стать ориентирами для проектных команд, направляющими процессы разработки ПО и формирования продуктовых линеек. Пример — разработка смартфона с большим объемом встроенного ПО: для потребительских товаров бизнес-целями будут показатели возврата и лояльности к бренду. Дефекты увеличивают первое и уменьшают второе, оказывая разрушительное влияние на бизнес. Анализ проектов, продуктов и процессов покажет необходимость переориентации инженерных процессов с чрезмерной фокусировки на особенностях производства к уделению повышенного внимания удобству использования.

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

Литература

P. Lous, M. Kuhrmann, P. Tell. Is Scrum fit for global software engineering? Int. Conf. Global Software Eng. (ICGSE 17). — 2017. — P. 1–10.
F. Calefato, F. Lanubile. A hub-and-spoke model for tool integration in distributed development. Int. Conf. Global Software Eng. (ICGSE 16). — 2016. — P. 129–133.
F. Lanubile, F. Calefato, C. Ebert. Group awareness in global software engineering // IEEE Softw. — Mar./Apr. 2013. Vol. 30, N. 2. — P. 18–23.

Фабио Калефато (fabio.calefato@uniba.it) — доцент, Университет Бари (Италия); Кристоф Эберт (christof.ebert@vector.com) — директор Vector Consulting Services.