CC BY
5
УДК 004.67
А. С. ЖЕЛЕПОВ, Н. Г. ЯРУШКИНА
НЕЧЁТКАЯ СИСТЕМА РЕЙТИНГА КОМПЛЕМЕНТАРНЫХ ПРОЕКТНЫХ КОМАНД
Описывается система нечёткой логики, которая позволяет упорядочивать комплементарные проектные команды по уровню их компетенций. Данный уровень определяется показателями совместной работы членов команды над общими программными продуктами.
Ключевые слова: система нечёткой логики, лингвистическая переменная, комплементарная команда, анализ данных.
Работа выполнена при финансовой поддержке Минобрнауки России в рамках проекта №075-00233-20-05 от 03.11.2020 «Исследование интеллектуального предиктивного мультимодального анализа больших данных и извлечения знаний из различных источников».
Введение
Рост 1Т-индустрии заставляет 1Т-компании трансформировать внутренние процессы, одним из которых стало обеспечение удалённой работы сотрудников. Одновременно с этим для компаний открылась и перспектива глобального найма. Однако многие организации оказались не готовы к этому из-за того, что глобальный процесс поиска и подбора персонала коренным образом отличается от поиска сотрудников, привязанный к конкретной географической локации.
Глобальный поиск сотрудников предрасполагает к разработке информационных систем анализа больших данных. Источником данных для таких систем выступают хранилища проектных репозиториев. В представляемом исследовании в качестве источника данных был выбран GitHub, на начало января 2020 года согласно официальной статистике сервиса было зарегистрировано 40 миллионов пользователей и 190 миллионов проектных репозиториев.
Отдельный интерес с точки зрения найма для компаний представляют комплементарные проектные команды - группы инженеров, ранее совместно работавших над общими проектами. Преимущество таких коллективов заключается в том, что процессы уже выстроены, и компании нет необходимости проводить сложную процедуру онбординга.
Процедура поиска команды значительно отличается от поиска конкретного специалиста, так как дополнительно требует проведения тщательного анализа предыдущих разработок, портфолио команды для определения уровня её компетентности. Таким образом, цифровая
© Желепов А. С., Ярушкина Н. Г., 2021
трансформация процесса поиска проектных команд представляет собой актуальную задачу.
1. Рейтинг комплементарных команд
Задачей модуля «Рейтинг» в разработанной информационной системе является упорядочивание полученной выборки проектных команд после проведения процедуры поиска. Процедура сортировки проектных команд по уровню их комплементарности позволяет отнести на второстепенный план те команды разработчиков, которые работали совместно непродолжительное время, тем самым не являются искомыми комплементарными командами.
Например, группа разработчиков Team = { devi, dev2, ... devn } согласно результатам поиска совместно работала над множеством проектных репозиториев Repos = { repo1, repo2, ... repon }, при этом вклад инженеров в проекты стремится к минимальному. Например, данное значение может быть выражено числом их коммитов в репозиторий проекта. Таким образом, образование команды разработчиков Team носит случайный характер, а задача модуля заключается в проведении оценки деятельности команды и помещении её в конец общего рейтинга. В выборках часто попадаются «случайные» команды, участники которых одновременно были кон-трибьюторами крупных opensource-проектов (например, React, Vue или Angular). С одной стороны, это является недостатком алгоритма поиска, который учитывает такие проекты. С другой стороны, сканирование проектов, в которых принимает участие большое количество разработчиков, позволяет находить больше команд.
Для упорядочения команд в рейтинге по результатам поиска вводится нечёткий критерий комплементарности R. С помощью него
Рис. 1. Критерий комплементарности проектной команды
Рис. 2. Графической представление функций принадлежности лингвистической переменной X
Ext Ext Ext
Team = { devi, dev2, ... (
Rare (|3i) Episodic (p2) Frequent (вз) Constant (в4)
ti t2 t3 t4 t5 t6 t7
0 10 20 30 40 50 60 70 80 90 10
Рис. 3. Пример совместной работы множества разработчиков Team над общим проектом
Рис. 4. Функции принадлежности лингвистической переменной р
Worldv
(Е4]
0 10 20 30 40 50 60 70 80 90 10i
50 100 150 200 250 300 350 400 450
D
Ext
tn-1
Рис. 5. Функции принадлежности лингвистической переменной у
становится возможными оценить проектную деятельность каждого коллектива из множества Teams. R представляет собой переменную нечёткого вывода, множество значений которого находится на интервале [0;100]. На рисунке 1 представлено распределение значений данной переменной согласно функциям принадлежностям.
Как видно из рисунка 1, лингвистическая переменная R принимает значения из множества термов TR = {«Низкая», «Средняя», «Высокая»}. Учитываются и пограничные значения комплементарности «Ниже среднего» и «Выше среднего».
Рис. 6. Функции принадлежности лингвистической переменной е
Значения выходного критерия, разработка системы нечёткой логики для определения степени комплементарности проектной команды, включая значения аппарата лингвистических переменных, были выполнена с участием группы практикующих экспертов в области работы над созданием программного обеспечения.
Необходимость создания системы нечёткой логики для расчёта значения критерия компле-ментарности команды разработчиков на основе данных связана с тем, что оценка проектной команды чаще всего субъективна.
С одной стороны, оценка деятельности проектной команды может быть выполнена с учётом метрических показателей, таких как затраченное
время на разработку, количество сделанных разработчиками коммитов и написанных строк кода, число закрытых проектных задач за заданный период времени.
Применение данных метрик не сможет помочь ответить на вопросы: «Какая сложность проекта?», «Насколько согласованно действовала команда при работе над проектом?». Ответы на эти вопросы, как правило, всегда субъективны для каждого IT-проекта, потому что не существует чёткой зависимости между объёмом проделанной проектной работы и сложностью проекта, которые в совокупности характеризуют слаженность команды разработчиков.
С другой стороны, система рейтинга, основанная на алгоритмах кластеризации и классификации репозиториев проектных команд, не даёт точной оценки их деятельности. Это связано с тем, что большинство проектов имеют индивидуальные особенности: сложность, объём выполненной командой работы. Например, если команда работала с уже существующим проектом, то внесённых изменений может быть сравнительно немного. Также проведение кластеризации / классификации затрудняет тот факт, что каждая рассматриваемая команды Teami в среднем состоит из 4-8 человек, а количество их общих проектов в среднем не превышает 3-6 репо-зиториев. Таким образом, данных для качественного статистического анализа недостаточно.
2. Система нечёткого вывода
Нечёткая система для определения значения комплементарности проектной команды построена на основе алгоритма Мамдани. Выбор алгоритма основан на простоте его реализации и быстродействии, что важно в условиях создания highload-решения поиска и оценки команд. Ещё одним преимуществом алгоритма является гибкая настройка базы правил для определения значений выходной переменной.
Нечёткая система поддерживает следующие лингвистические переменные: отношение команды к проекту (X); степень совместной работы над проектом (Р); взаимодействие команды с проектом (у); признание проекта в сообществе разработчиков (s).
В качестве входных данных алгоритм получает соответствие найденной проектной команды и их проектных репозиториев, Team = { dev1, dev2, ... devn } и Repos = { repo1, repo2, ... repom}. Оценка комплементарности R определяется для каждого из проектов repoi. Совокупная оценка R для Team по всем проектам на множестве Repos считается, как среднее арифметическое.
Лингвистическая переменная X определяет степень вовлечения команды Team в проект repoj и характеризует объём проделанной командой работы. X определена на множестве термов TX е { «Случайная», «Ядро проекта», «Основная команда» }. Универсум нечётких переменных определяется на множестве XX = [0; 100]. Метрически значения переменной выражены в процентах. X обозначает, какой совокупный вклад внесли разработчики команды Team в виде количества коммитов от общего числа коммитов, сделанных всеми разработчиками проекта в рамках репозитория repoj.
На рисунке 2 представлены функции принадлежности лингвистической переменной X.
Интервалы каждой из функций принадлежности позволяют оценить вклад проектной команды в проект. «Случайной» является та команда, которая внесла сравнительно небольшой вклад. Как правило, присутствие таких коллективов среди результатов поиска проектных команд обусловлено погрешностью алгоритма поиска. С целью ускорения и оптимизации алгоритма поиска не учитывается объём изменений, вносимых командой разработчиков.
«Ядром проекта» является команда, сделавшая значительное количество изменений. Терм введён с целью того, чтобы учитывать прошлые достижения команды в рамках проекта. Под этим понимается, что рассматриваемая в данный момент команда могла работать с проектом в прошлом, например, разработала его MVP. Однако затем проект мог быть передан другому коллективу. Терм «Основная команда» выделяет команду как главных разработчиков рассматриваемого проектного репозитория.
Ввод лингвистической переменной в позволяет оценить, насколько слаженно действует проектная команда, как часто максимальное количество разработчиков одновременно работают над проектом.
в определяется на множестве термов Tp е {«Редкое», «Эпизодическое», «Частое», «Постоянное» }. Универсум нечётких переменных определяется на множества Xp = [0; 100], значения переменной выражаются в процентах.
Для определения X проектной команды Team необходимо найти экстремум количества разработчиков, принадлежащих множеству Team и совместно работавших над проектом за каждый дискретный промежуток времени t периода T. Считается, что разработчики из множества Team работают совместно, если они делают коммиты за одинаковые t. В качестве примера на рисунке 3 представлено временное распределение
коммитов разработчиков в рамках работы над проектом.
По указанной выше формуле (1) находится доля временных участков, в которые команда работала в своём наиболее полном составе. В формуле учитывается значение допустимого отклонения о от максимального количества задействованных разработчиков. Данный параметр является дополнительным и применим для случая, когда At устанавливается равной сравнительно небольшому промежутку времени с точки зрения разработки проекта (например, день или час).
На рисунке 4 представлены функции принадлежности лингвистической переменной p.
Интервалы представленных функций принадлежности переменной в в зависимости от значения экстремума разработчиков позволяют оценить взаимодействие и слаженность действий множества разработчиков Team.
Лингвистическая переменная у определяет вид деятельности множества разработчиков Team при работе с проектным репозиторием. Переменная у определена на множества термов TY е {«Сопровождение», «Разработка»}. Значение нечёткой переменной определяется на промежутке [0; 100], выраженном в процентах. На рисунке 5 представлены функции принадлежности переменной.
Значение лингвистической переменной на универсуме X определяется путём оценки количества файлов проекта, которые разработчики видоизменили. Это позволяет учесть не только количественные, но и качественные проектные изменения, отражённые в следующем принципе разработки и проектирования сложных систем «разработчик знает проект лучше, если изменял большее количество файлов в нём».
Лингвистическая переменная s позволяет оценить уровень признания разрабатываемого множеством инженеров Team проекта среди других разработчиков. s определяется на множестве термов Ts е {«Внутренний проект», «Узкоспециализированный проект», «Популярный проект», «Проект мирового масштаба»}. Значение переменной определяется на промежутке [0; +да] и выражается в количестве использований рассматриваемого проекта repoj глобальным сообществом разработчиков. На рисунке 6 представлены функции принадлежности лингвистической переменной.
3 Правила системы нечёткого вывода
Для реализации системы нечёткого вывода по определению степени комплементарности проектной команды был сформирован ряд правил, основные представлены в таблице 1. Весовые коэффициенты установлены на основе экспертной оценки.
Таблица 1
Основные правила системы нечёткого вывода
Правило R ^R
AND p1 AND y AND (s3 OR s4) 0 Very Low
AND p2 AND y AND (s3 OR s4) 15 Low
AND (в1 OR p2) AND y1 AND (S2 OR S3) 25 Low
X2 AND (p1 OR p2) AND (y OR y2) AND (s2 OR s3) 40 Bel. average
(X2 OR X3) AND (p1 OR p2) AND (y OR y2) 50 Averag e
(X2 OR X3) AND (p2 OR p3) AND y2 70 Ab. average
(X2 OR X3) AND (p3 OR p4) AND y1 AND (s1 OR s2) 80 High
(X2 OR X3) AND (p3 OR p4) AND (y OR y2) AND (s3 OR s4) 90 High
X3 AND p4 AND y2 100 Very high
Из правил видно, что уровень признания проекта (е) оказывает наиболее значимое влияние на комплементарность проектной команды. Это следует из того, что «если команда основная, а ее проект используется большим количеством других разработчиков, то команда профессиональная, так как работа над проектом носит постоянный характер и ответственность перед другими разработчиками».
С другой стороны, если команда «довольно редко и не постоянно работает над проектом мирового масштаба, значит данная команда не обладает высокой комплементарностью и, скорее всего, является просто группой контрибьюторов в данный проект». Также значительное влияние на уровень комплементарности оказывает степень вовлеченности команды в процесс разработки
Заключение
Система формирования рейтинга используется в информационной системе поиска проектных команд для оценки деятельности найденных коллективов инженеров на основе данных разработанных ими ранее проектов. Рейтинг позволяет упорядочить результат поиска, предоставив HR-специалисту наиболее релевантную выборку потенциальных команд-кандидатов.
В рамках дальнейших исследований планируется провести оптимизацию системы построения рейтинга с точки зрения времени, которое затрачивается на чтение данных из системы GitHub. В самой система рейтинга планируется добавление ряда лингвистических переменных, с помощью которых было бы возможно оценить не только техническую комплементарность команд, но и их комплементарность на основе soft-skills метрик.
СПИСОК ЛИТЕРАТУРЫ
1. [Elias J.] Google warns pandemic could hinder its ability to 'maintain corporate culture' in 2021, TECH, [сайт].иКЬ: https://vk.cc/c0erAj (дата обращения: 01.03.2021 г).
2. [Newton C.] Facebook says IT will permanently shift tens of thousands of jobs to remote work, The Verge, [сайт].иКЬ: https://vk.cc/ c0erGb (дата обращения: 01.03.2021 г.).
3. [Kashyap N.] GitHub's Path to 128M Public Repositories, Towards Data Science, [сайт].иКЬ: https://vk.cc/c0es3N (дата обращения: 01.03.2021 г.).
4. [Gil E. 2018] Gil E., High Growth Handbook: scaling startups from 10 to 10,000 people, Stripe Press.
5. [Zhelepov A., Yarushkina N. 2021] Alpha-Search Algorithm for Cohesive Teams of Software Engineers. In: Dolinina O. et al. (eds) Recent Research in Control Engineering and Decision Making. ICIT 2020. Studies in Systems, Decision and Control, vol 337. Springer, Cham. https://doi.org/10.1007/978-3-030-65283-8_39.
6. [Kniberg H. 2015] Scrum and XP from the Trenches. How we do scrum, pp. 94-98, 2nd Edition, InfoQ.
7. [Afanasieva T., Moiseev V. 2019] Assessing the Software Developer's Quality Using Fuzzy Estimates. In: Abraham A., Kovalev S., Tarassov V., Snasel V., Sukhanov A. (eds) Proceedings of the Third International Scientific Conference "Intelligent Information Technologies for Industry" (IITI'18). IITI' 18 2018. Advances in Intelligent Systems and Computing, vol 874. Springer, Cham. https://doi.org/10.1007/978-3-030-01818-4_20.
8. [Kleppman M. 2017] Designing DataIntensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems, pp. 144145, pp. 257-258, O'Reilly Media.
9. [Grossman S. 2017] Minimum Viable Product: Master Early Learning and Develop an MVP with Scrum, pp. 32-33, CreateSpace Independent Publishing Platform.
10. [Kim H. 2020] Soft Skills for Hard People: A Practical Guide to Emotional Intelligence for Rational Leaders, pp. 71-72, Helena Kim.
Желепов Алексей Сергеевич, ассистент кафедры «Информационные системы» УлГТУ. Ярушкина Надежда Глебовна, доктор технических наук, ректор УлГТУ.
Поступила 15.09.2021 г.
