employee from 01.01.2021 until now
St. Petersburg, Russian Federation
employee
Russian Federation
The aim of the study is to develop a basic model that takes into account several stakeholders and allows one to determine the equilibrium positions of all the players participating in the Scrum methodology project; in addition, to highlight recommendations for using the model, its advantages and future improvements. The article is devoted to developing a tool that can correct the governing body’s work when making strategically important decisions. Research methods include an analytical review of articles in the Scopus and RSCI scientific publication databases; comparison and selection of stakeholders, the Scrum process stages and approaches to the solution; forming a mathematical description of the model, and a numerical experiment. The novelty of the work lies in considering a dynamic game based on various stakeholders’ strategic interaction in the project using the Scrum methodology, which predetermines some of the features and limitations of the game. The study results contain a description of the implemented model assumptions, the interpretation of the formulas used in it, the equilibrium position found, a visual display of the game process, a numerical experiment, and recommendations for using the basic model. The results obtained allow forming recommendations for making strategic decisions and conducting a series of experiments to display possible scenarios for the project development. In the future, this model can be improved by adding supplemental parameters to obtain more correct and realistic results. Eventually, the above model provides an opportunity to influence managerial decision-making and increase both overall and individual profits.
strategic interaction, stakeholders, game theory, the Scrum methodology, equilibrium position, decision tree
Введение
Каждый продукт имеет свой жизненный цикл, который в общем состоит из 5 стадий: идея, планирование, разработка, эксплуатация (внедрение, сопровождение) и завершение [1]. В данной работе будет рассматриваться 3-я стадия – разработка. На текущий момент существует несколько методологий, по которым осуществляется реализация продукции, например, каскадная, инкрементная, итерационная, Scrum, Kanban. Наиболее популярными являются Scrum и Kanban, поскольку основаны на Agile и Learn подходах, которые диктуют гибкость и эффективность проектов. Благодаря описанным шагам и правилам получается обеспечивать адаптацию к новым изменениям и оптимизировать ресурсы проекта, не уступая в качестве продукции [2]. Принципы гибкой методологии подразумевают активное участие заинтересованных сторон в проекте, поскольку результат основывается на их действиях [3]. Каждый участник процесса имеет свои цели и желания, которые он хочет достичь за время реализации проекта. Таким образом, требуется найти компромисс между личными интересами участников процесса и общей целью всего проекта.
Для рассмотрения взаимодействия между агентами используется имитационное моделирование и инструменты теории игр. На данный момент ученые в большей степени изучили однопериодные или статические игры, однако проект, выполняемый по методологии Scrum, характеризуется как динамическая игра с итеративным повторением. Данный факт усложняет вычисления и формализацию процесса в рамках теории игр.
Проблема, которая решается в данной работе, связана с несовершенством методов теории игр и их корректировкой под конкретные задачи. В этой работе не рассматривается проект, имеющий конкретную специфику или определенную сферу. Акцент смещен на стратегическое взаимодействие заинтересованных сторон в проекте, выполняемом с применением методологии Scrum.
Материалы, модели, эксперименты и методы
Основные параметры модели. В рамках исследования рассматриваются взаимодействия заинтересованных сторон в течении реализации проекта по Scrum методологии. Scrum процесс содержит правила и методы Agile методологии, являясь её «реализацией». Использование такого подхода обосновывается гибкостью разработки, быстрой адаптацией к изменениям. В сравнении с Kanban, Scrum имеет небольшую длительность спринта и оценку успешности его закрытия. Поэтому Scrum был выбран, как основной свод правил для реализации проектной деятельности. Таким образом, процесс выполнения проекта делится на этапы: Product Backlog, Sprint Planning, Sprint Backlog, Sprint, включающий Daily Meeting, Review и Retrospective [4]. Как правило, один спринт (этап) длится две недели, поэтому в рамках текущего исследования сохраняется такая продолжительность спринта.
Scrum процесс имеет особенности выполнения в виде ролей, однако не все роли считаются стратегическими в рамках текущего исследования. Такие роли, как Product Owner и Scrum-мастер, не будут участвовать в реализованной модели. Поскольку функции Scrum-мастера не оказывают прямого воздействия на конечный продукт, а Product Owner будет заменен на заказчика, чтобы упросить взаимодействие.
Так же было принято во внимание допущение о том, какие личные интересы и задачи имеют заинтересованные лица. Таким образом, основываясь на статьях [2, 5] и предыдущем допущении, можно выделить следующие основные заинтересованные стороны: заказчик, инвесторы/спонсоры, руководство, менеджер проекта, поставщики/подрядчики, проектная команда, конечные потребители/пользователи. По приведенному предположению можно классифицировать стейкхолдеров по этапам Scrum процесса, где они будут принимать участие. Таким образом, из статьи [6] видно, что этапы Sprint Planning, Sprint Backlog, Daily Meeting и Retrospective опущены, поскольку содержат всех внутренних стейкхолдеров, которые указаны на стадии Sprint.
Резюмируя вышесказанное, можно отметить, что основными ролями в реализации внешнего проекта по Scrum методологии являются заказчик, инвесторы/спонсоры, руководство, менеджер проекта, поставщики/подрядчики, проектная команда, конечные потребители/пользователи, которые оказывают влияние на определенных стадиях проекта: Product Backlog, Sprint и Review.
Инструменты. При составлении формального описания модели используются различные математические методы, в частности методы принятия решений. В статье [7] автор классифицирует методы по признаку формализации используемого аппарата, выделяя 4 класса: формальные, эвристические, экспертные и методы нечеткой логики.
Из статьи [8] видно, что наиболее популярными инструментами моделирования взаимодействия заинтересованных лиц в рамках разработки проекта являются: экспертные методы 54,9 %, имитационное моделирование 16,5 %, статистические методы 14,8 % и теория игр 7,8 %. При этом имитационное моделирование и теория игр являются экземплярами эвристического класса методов принятия решений.
Учитывая, что в текущей задаче происходит взаимодействие между различными людьми, то разумно применить агентное моделирование. Этот тип моделирования является одной из основных парадигм имитационного моделирования и описывает систему, как взаимодействие агентов, имеющихся своё собственное поведение.
Однако ясности в действиях стейкхолдеров нет: как будет приниматься решение определенным лицом? при каких обстоятельствах будет меняться мнение? В данном случае целесообразно использовать инструменты теории игр, которые позволяют рассмотреть процесс с более детальной точки зрения. Такой подход позволяет найти равновесное положение, где будут учитываться не только общие цели, но и личные пожелания каждого игрока.
Соответственно, совместный подход агентного моделирования и теории игр гарантирует более реалистичное описание модели со стороны взаимодействия заинтересованных лиц. Данный факт подтверждается рассмотренными статьями, где применялся совместный метод [9 – 13].
Таким образом, подход, где агентное моделирование рассматривает систему с более обобщённого ракурса, а инструменты теории игр позволяют смоделировать конкретные взаимодействия и рассмотреть различные сценарии и исходы событий, является наиболее полным и актуальным при описании модели взаимодействия заинтересованных сторон в проекте.
Результаты
Описание допущений модели. Моделирование будет осуществляться на основе трех этапов спринта: Product Backlog, Sprint и Review. При этом выделенными заинтересованными сторонами в проекте являются заказчик, инвесторы/спонсоры, руководство, менеджер проекта, поставщики/подрядчики, проектная команда, конечные потребители/пользователи. Однако можно разделить всех лиц на 3 категории: заказчик, исполнитель, руководитель-контролер. К заказчикам относятся: заказчик, пользователи, инвесторы/спонсоры; к исполнителям: члены проектной команды, подрядчики; к руководителям: менеджер, руководство. Поэтому при моделировании начальной модели рассмотрим 3 лица – заказчик, исполнитель, менеджер (человек, который принимает управленческие решения).
Также следует добавить несколько допущений к модели перед формированием математического описания. Заказчик должен иметь влияние на проект и диктовать условия его выполнения, такую функцию можно описать в модели как требуемое качество проекта. В начале реализации всего проекта заказчик выдвигает требуемое качество всего продукта, при котором проект будет завершен успешно. Во время исполнения проекта он не в праве менять утвержденное качество. При этом необходимое качество каждого спринта распределяется равномерно, исходя из общего требуемого качества. Кроме того заказчик указывает длительность проекта, которое не изменяется с течением времени. Готовность продукта по итогам реализации проекта подразумевается равной 100 %. В данном случае результативность не влияет прямым образом на получаемое качество проекта, а только определяет количество спринтов. Также требуемое качество и длительность проекта являются экзогенными параметрами в рамках модели. Поэтому в текущей версии заказчик является фиктивным агентом, не имеющим стратегий.
В свою очередь менеджер на основе входных данных высчитывает необходимую на спринт трудоемкость. После чего принимает решение (выбирает стратегию): либо в данном спринте участвуют только постоянные члены проектной команды, либо требуется привлечь дополнительную помощь в лице подрядчиков. В случае привлечения подрядчиков происходят дополнительные трудозатраты. При этом менеджер отвечает за весь проект, а не только за самого себя: увеличение трудозатрат будет отображаться только на выигрыше менеджера.
Имеющаяся трудоемкость распределяется равномерно между всеми спринтами, как и необходимое качество. Она рассчитывается на основе экспертных данных и различных параметров системы. В данном случае будет являться внешним входным параметром.
Стоит отметить, что заказчик и менеджер в модели находятся в единственном числе, но исполнителей может быть несколько, поскольку исполнитель – это и член проектной команды, и подрядчик. Исполнитель влияет на качество реализуемого продукта. Их действия в рамках игрового взаимодействия описываются, как вклад собственных сил в развитие проекта. Исполнитель не может затратить сил более 100 % за один спринт. Члены проектной команды участвуют во всех спринтах проекта, в другую очередь подрядчики участвуют только в тех спринтах, в которые их привлек менеджер.
Этап Review является «фиктивной» стадией, на которой определяется уровень результативности (количество пройденных спринтов) и качество инкремента, выполненного на пройденном спринте. На Review нет стратегического агента, решение принимается автоматически. Если качество результата инкремента оказалось ниже необходимого, то вычисляется коэффициент соответствия качества, который влияет на требуемое качество следующего спринта.
После завершения разработки продукта, если требуемое качество не было достигнуто, проект считает проваленным, т.к. не было выполнено требование заказчика о качестве продукции. Если полученное качество равняется требуемому или превышает его, то проект считается завершенным успешно.
Таким образом, рассматриваемая игра является последовательной. В последовательных играх участникам предоставляется выбор действий, исходя из предыдущих действий оппонентов. Ходы будут выполняться в заранее установленном порядке, поскольку проектная реализация проходит по определенным этапам.
Профили платежей будут иметь финансовый характер, потому что это позволяет однозначно и количественно оценить возможные исходы событий.
Формальное описание модели. Модель теории игр состоит из трех множеств: G = <P,S,F>, где P – множество стратегических агентов, влияющих на ход разработки продукта; S – множество наборов стратегий каждого агента; F – множество функций полезности каждого агента.
P = {P_i}, где P_i – агент, участвующий в стадии разработки продукта в проекте по методологии Scrum, где i = {1,..,n}, n – количество агентов, участвующих в процессе.
P {заказчик, менеджер проекта, исполнитель-1, …, исполнитель-m}, n = m+2.
Для каждого агента определяется набор чистых стратегий S_i, которые образуют множество наборов стратегий S.
P_1 – заказчик, который является фиктивным агентом, поэтому S_1= ∅; P_2 – менеджер проекта, S_2 = {участвует только постоянная команда, привлекать подрядчиков}; P_3,…,P_(m+2) – исполнитель. Исполнитель может приложить определенное количество усилий во время спринта для выполнения своей задачи. Соответственно, количество усилий варьируется от 0 % до 100 %. Тогда для учета качества текущего шага выполнения проекта для i ∈[3;m+2] S_i∈[0;1]. Количество исполнителей задается параметром извне, при этом набор действий у них одинаковый.
В данном случае совмещается два подхода – учет соотношения объема работ и фонда рабочего времени, которое определяет менеджер перед началом спринта, и возможность исполнителя выбирать с какой силой работать во время текущего этапа. Таким образом, менеджер определяет максимально достижимое качество спринта с учетом имеющихся ресурсов. Если ресурсов не хватает и менеджер принимает решение не использовать дополнительные трудозатраты, то качество инкремента снижается. Поскольку данное количество ресурсов не способно обеспечить полное качество. В таком случае пересчитывается понижающий коэффициент качества, однако он не влияет на работу исполнителей. Такой коэффициент занижает конечное качество инкремента, но не работу каждого исполнителя.
Например, в ходе оценки ресурсов менеджер решил не прибегать к дополнительным трудозатратам, при этом ресурсы полностью не покрывали требования заказчика. К примеру, фонд рабочего времени имеющихся исполнителей составляет 80 % от номинальной трудоёмкости задач заказчика, выделенных на данный спринт. Вследствие понижающий коэффициент равняется 80 %. Он влияет на конечное качество результата. Например, имеется три исполнителя в проектной команде. Первый прилагает 85 % своих усилий, второй – 95 %, третий – 96 %. Таким образом, выполненное качество итерации равняется 0,85·0,95·0,96 = 0,775. Но из-за наличия понижающего коэффициента качество равняется 0,775·0,8 = 0,62.
F = {F_i}, где F_i – функция полезности i-ого агента. Q – требуемое качество проекта, задаваемое заказчиком. Q∈[0;1] – качество варьируется от 0 % до 100 %. Таким образом, можно перевести проценты в шкалу от 0 до 1. T – длительность проекта, задаваемая заказчиком (в неделях). W – фонд рабочего времени, который рассчитывается на основе входных данных и экспертных оценок. В данной модели является внешним входным параметром (в человеко-часах). V – номинальный объем работ, который устанавливается исходя из требований заказчика. В данной модели является внешним входным параметром (в человеко-часах). P – количество имеющихся в штате сотрудников (исполнителей). Задается, как внешний параметр. k = T/2 – количество спринтов.
Поскольку один спринт имеет продолжительность 2 недели, где в каждой недели 5 рабочих дней по 8 часов, то человек тратит определенное количество часов за спринт, которое равняется 2·5·8 =80 часов.
Тогда нормативное количество человек, которое необходимо для реализации проекта, высчитывается по следующей формуле:
P =W/(80·k)
При этом каждый спринт содержит необходимый порог качества инкремента для того, чтобы достичь общее качество продукта Q. Поскольку общее качество полученного продукта рассчитывается по формуле среднего геометрического, то качество каждого инкремента соответствует следующей формуле:
q= √(k&Q^k )= Q – изначально необходимое качество инкремента на каждом спринте.
Тогда полученное качество на j-ом спринте будет обозначаться q_j, а общее полученное качество всего продукта по завершению разработки будет высчитываться по формуле:
Q_s= √(k&∏_(j=1)^k▒q_j ).
Однако есть случаи, когда полученное качество инкремента q_j меньше, чем необходимое q. В этом случае следует посчитать коэффициент соответствия качества инкремента и использовать его на последующей итерации. Следовательно, конечная формула необходимого качества каждого инкремента выглядит следующим образом:
〖q'〗_j=q·〖coef〗_j,
где 〖coef〗_(j+1)= {█(〖q'〗_j/q_j ,если q_j< 〖q'〗_j @1,иначе)┤, j={1,..k-1}, 〖coef〗_1=1.
Тогда минимальное количество человек, которое обеспечивает требуемое качество на каждом спринте 〖q'〗_j, можно вычислить по формуле:
P_(min_j)= P·〖q'〗_j.
Аналогичным способом можно вычислить минимальное необходимое количество человек на одном спринте, по требованиям заказчика:
〖CNT〗_(min_j)= (V·〖q'〗_j)/(80·k)
Понижающий (повышающий) коэффициент l = P_(min_j )/〖CTN〗_(min_j) . Соответственно, если P_(min_j ) не покрывает требуемого 〖CTN〗_(min_j), то коэффициент l будет понижающим, если полностью покрывает, то l =1, если P_(min_j ) превышает 〖CTN〗_(min_j), то l будет повышающим.
Менеджер проекта может принять решение повысить количество исполнителей, однако это повлечет дополнительные трудозатраты.
Качество на j-ом спринте высчитывается по формуле:
q_j =(√(|I_j |&∏_(i∈I_j)▒S_ij ))·l,
где I_j – множество индексов участвующих исполнителей в спринте j, S_ij – стратегия i-ого агента на j-ом спринте.
Визуализация процесса. После составления формального описания параметров модели следует отобразить процесс взаимодействия игроков. Теоретико-игровая модель представляет последовательную игру, в которой принятие стратегических решений происходит по очереди, в зависимости от совершенного действия ранее. Для визуализации игрового процесса в последовательных играх используется дерево решений:
Рис. 1. Дерево решений
Fig. 1. Decision tree
В данном случае узлы – агенты, которые принимают решения. От принятого ранее решения зависит дальнейший набор возможных решений. Ветки, исходящие из вершин, в данном графе обозначают действия, которые агент может выполнить.
Таким образом, заказчик, являясь фиктивным агентом, отображается на рис. 1 и сопровождает действие выбора требуемого качества всей продукции. Дальше менеджер проекта, рассчитав показатели, выбирает стратегию: привлекать в проект подрядчиков или команда разработки справится в одиночку. После это исполнители выбирают сколько усилий на текущем спринте они прилагают, и этап Review по выполнению или невыполнению условий определяет дальнейшее действие: перейти на следующий спринт, завершить проект с успехом, завершить проект с провалом. При переходе в терминальную вершину подсчитывается платеж каждого игрока.
Вычисление терминальных вершин. В рамках данного исследования рассматриваются только финансовые выгоды. Соответственно, для этого следует распределить финансовые показатели между участниками процесса, оценить проект и работу сотрудников.
Пусть прибыль от реализации проекта – w тыс. руб., сумма, которую заказчик готов платить компании за реализацию проекта – s тыс. руб.
Тогда зарплата одного сотрудника обозначается salary_worker руб./час., зарплата менеджера – salary_manager руб./час., а costs тыс. руб. – это доход, который получает компания, где s= ∑_i▒∑_j▒h_ij ·salary_worker+∑_j▒h_j ·salary_manager+ costs.
Таким образом, функция полезности заказчика принимает следующий вид:
F_1= w ·Q-s
Функция полезности менеджера выглядит следующим образом:
F_2=(∑_j▒h_j )·salary_manager-∑_i▒〖(∑_j▒h_ij ·salary_worker)〗,
где j={1,..,k}, i∈I_contr – индексы подрядчиков.
Функция полезности исполнителей:
F_i=∑_j▒〖h_ij·〖(salary_worker-S〗_i·salary_i)〗,
где salary_i – стоимость усилий сотрудника, которую исполнитель оценивает сам, i={3,..,n}.
Приведенные функции полезности действуют при условии, что проект завершился успешно.
Если проект был провален, то функция полезности у всех игроков равняется 0:
F_i=0,i={1,..,n}.
Исследование свойств равновесия. Распространённый способ решения последовательных игр – это обратная индукция. В данном случае для игроков наиболее благоприятным событием окажется терминальная вершина, которая соответствует успешному завершению проекта. Успешность проекта определяется полученным качеством продукта, значит как для проектной команды, так и для проектной команды + подрядчики выгодно достигнуть требуемого качества, чтобы проект завершился успешно. Тогда равновесное положение для исполнителей можно рассчитать по формуле:
Q_s≥Q,
√(k&∏_(j=1)^k▒q_j )≥√(k&∏_(j=1)^k▒〖q'〗_j ),
√(k&∏_(j=1)^k▒〖(√(|I_j |&∏_(i∈I_j)▒S_ij ))·l〗)≥√(k&∏_(j=1)^k▒〖q·〖coef〗_j 〗),
l·√(k&∏_(j=1)^k▒(√(|I_j |&∏_(i∈I_j)▒S_ij )) )≥q·√(k&∏_(j=1)^k▒〖coef〗_j ).
Каждый исполнитель хочет приложить меньше усилий, но получить большую выгоду:
S_i→min,F_i→max,
где i – индексы исполнителей.
Поскольку качество продукта зависит от сил, вложенных исполнителями, то их стратегии распределяются симметрично, так как они являются равными агентами без приоритета.
l·S^x≥q·√(k&∏_(j=1)^k▒〖coef〗_j ),
где x – сумма участвующих исполнителей со всех спринтов (x=x_1+x_2+...+x_k).
S≥√(x&(q·√(k&∏_(j=1)^k▒〖coef〗_j ))/l).
Таким образом, равные усилия между исполнителями являются равновесным положением. Исходя из вышеприведенных формул можно отметить, что усилия исполнителей зависят от требуемого качества инкремента на каждом спринте и от коэффициента, учитывающего нехватку сотрудников или их избыток. Требуемое качество дополняется коэффициентом соответствия, который увеличивает значение необходимого качества следующего инкремента, если на текущем спринте не удалось набрать нужное качество. Тогда, чтобы обеспечить необходимый результат всего продукта, невыполненное качество добавляется к следующему спринту.
Тогда, если x=k·team, где team – количество членов проектной команды, то данное условие гарантирует, что подрядчики не будут привлекаться. Значит функция полезности менеджера будет стремиться к максимуму: F_2→max.
Заказчик же в этой игре не имеет равновесного положения, поскольку не имеет набор стратегий. Тем самым выигрыш заказчика полностью зависит от работы менеджера и исполнителей.
Численный эксперимент на базе модели. Предположим, что Q = 0,8, T = 12 недель, W = 1440 человеко-часов, V = 1500 человеко-часов, P = 3 человека.
Также финансовые составляющие имеют следующие значения:
w= 600 тыс. рублей, s= 400 тыс. рублей; ssalary_worker= 150 рублей / час; salary_manager= 200 рублей / час; costs = 88 тыс. рублей; salary_i= 100 рублей / час, где i – члены проектной команды.
В сумме выходит 480 рабочих часов за всю длительность проекта. А количество спринтов k = 6.
Тогда каждый член команды получит зарплату за весь проект равную 480·150 = 72 тыс.руб. Менеджер получит – 480·200 = 96 тыс.руб.
Тогда q=Q=0,8, а l= (P·〖q^'〗_j·80·k)/(V·〖q'〗_j )=W/V= 1440/1500=0,96.
В данном случае для равновесного положения выходит, что x = 6·3 =18 человек, т.е. в проекте как исполнители участвуют только члены команды.
Отсюда можно найти равновесные стратегии исполнителей:
S≥√(18&(0,8·√(k&∏_(j=1)^k▒〖coef〗_j ))/0,96).
Можно принять, что q_j≥q_j^', т.е. исполнители выполняли свою работу добросовестно. Тогда 〖coef〗_j=1,∀j.
Следовательно стратегии исполнителей будут иметь следующее значение:
S≥√(18&0,83);
S≥0,98992.
Тогда F_1= 600·0,8 – 400 = 80 тыс. руб., F_2= 480·200 – 0 = 96 тыс. руб., F_i= 480·(150 – 0,98992·100) = 24 483,84 тыс. руб., i – члены проектной команды.
Обсуждение
В данной статье описывается базовая модель стратегического взаимодействия заинтересованных сторон в ходе реализации проекта по Scrum методологии. Модель учитывает три вида стейкхолдера, три этапа разработки в течение одного спринта и дополнительные трудозатраты агентов.
На основе данной модели можно смоделировать возможные сценарии развития событий и решить какое количество исполнителей необходимо для успешного завершения проекта. В дополнение, имея входные параметры, есть возможность просчитать количество усилий, которые должен приложить каждый исполнитель. В модели конечные платежи (исходы игры) рассматриваются в виде финансовых потоков. Это позволяет единым образом учитывать выгоды и затраты, связанные с проектной деятельностью, которые включают в себя, как количественные, так и качественные показатели. Использование модели позволит оптимизировать ресурсы и прийти к компромиссному решению в имеющейся ситуации.
В будущем модель можно расширить с помощью дополнительных допущений, стратегий и агентов. Добавить поощрение от заказчика при превышении требуемого качества. На данный момент, если полученное качество продукции будет выше требуемого качества, то возможные сценарии платежей останутся теми же. Дополнив перевыполнение плана дополнительным поощрением, изменится равновесное положение, поскольку добавится еще одна терминальная вершина.
Также можно добавить еще одну стратегию заказчику в виде возможности доработки проекта. Соответственно, если по истечении срока проекта продукция не достигла требуемого качества, заказчик может принять решение о доработке продукта за один дополнительный спринт. В данном случае требуется учитывать дополнительные расходы со всех сторон, а также изменение выигрыша при принятии работы со второго раза.
Заключение
В заключение стоит отметить, что приведенная модель позволяет корректно определить требуемые параметры, подстроиться под нужные условия проектной деятельности, которые могут изменяться, и рассмотреть ситуацию с различных точек зрения. Полученные вычисления позволят грамотно распределить усилия исполнителей и прийти к равновесному положению, в котором будут учтены не только личные цели участников, но и выполнен общий план проекта.
В будущем планируется расширить имеющуюся модель, добавив стратегии заказчику. В таком случае заказчик станет полноценным стратегическим агентом и сможет принимать решение о доработке продукта, если конечное качество не будет достигнуто вовремя. Также стоит добавить возможное поощрение за перевыполнение плана по качеству продукции.
1. Moiseenko Zh.N. Project Lifecycle. Forum of Young Scientists. 2021;6(58):538-542.
2. Kannan S, Natasha J. Agile - A Scrum-Based Approach to Identify and Evaluate Opportunities in a Mature Field. Proceedings of SPE Annual Technical Conference and Exhibition. OnePetro; 2022.
3. Dragos P. The Impact of Stakeholders in Agile Software. Annals of the University of Oradea, Economic Science Series. 2021;30:2.
4. The Scrum Guide [Internet]. 2020 [cited 2023 Mar 23]. Available from: https://scrumguides.org/scrum-guide.html
5. Shafiee S, et al. Behaviour-Driven Development in Product Configuration Systems. Proceedings of Twentieth Configuration Workshop; 2018.
6. Zubkova DA. Stakeholders’ Classification by Project Stages Implemented Using the Scrum Methodology. In: Proceedings of the All-Russian Student Scientific and Educational Conference: Youth Week of Science of the Institute of Industrial Management, Economics and Trade; 2022 Nov 29 - Dec 03; Saint Petersburg: Peter the Great St. Petersburg Polytechnic University: 2022. p. 344-346.
7. Demin G.A. Management Decision-Making Methods. Perm: Perm State National Research University; 2019.
8. Zubkova DA, Gintsyak AM. Approaches to Modelling Strategic Stakeholder Interactions to Support Decision-Making in Project Activities. In: Rodionov DG, Babkina AV, editors. Proceedings of the All-Russian International Scientific and Practical Conference: Digital Transformation of Economic Systems: Problems and Prospects (ECOPROM-2022); 2022 Nov 11-12. St. Petersburg: POLYTECH-PRESS: 2022. p. 726-728.
9. Hayashida T, Nishizaki I, Saiki K. Agent-Based Simulation for Simultaneous Ultimatum Games. In: 2014 IEEE International Conference on Systems, Man, and Cybernetics (SMC): 2014. p. 507-512.
10. Anand N, et al. Validation of an Agent Based Model Using a Participatory Simulation Gaming Approach: the Case of City Logistics. Transportation Research. Part C: Emerging Technologies. 2016;71:489-499.
11. Noori M, Emadi A, Fazloula R. An Agent-Based Model for Water Allocation Optimization and Comparison With the Game Theory Approach. Water Supply. 2021; 21(7):3584-3601.
12. Fu X, et al. Coupling Game Theory and Discrete-Event Simulation for Model-Based Ambulance Dispatching. Procedia Computer Science. 2018;136:398-407.
13. Svalestuen Y, et al. Agent-Based Simulation of Stakeholder Behaviour Through Evolutionary Game Theory. In: Proceedings of Australasian Conference on Artificial Life and Computational Intelligence: 2015. p. 100-111.
