CC BY
35ИМИТАЦИОННАЯ МОДЕЛЬ СМО В СРЕДЕ
ANYLOGIC ДЛЯ ПРОГНОЗИРОВАНИЯ КОЭФФИЦИЕНТА СОСРЕДОТОЧЕННОСТИ СКРАМ КОМАНДЫ
© Сачек Е.А.*
Российская академия народного хозяйства и государственной службы при Президенте РФ, г. Москва
В данной статье рассмотрена модель системы массового обслуживания в среде AnyLogic для прогнозирования коэффициента сосредоточенности команды на итерацию в ИТ проекте по разработке программного обеспечения. Рассмотрены результаты, собранные в течение месяца работы Скрам команды. Уникальность модели состоит в том, что она учитывает совокупный вклад не только разработчиков, но и менеджеров при создании ценности продукта. Совместно с такими моделями и методологиями как CMMI, Бережливая разработка, 6 Сигма представленная модель может выступать в качестве инструмента для повышения эффективности управления Скрам проектом. Модель также может быть использована для учета затрат методом ABC для расчета стоимости инкремента ПО и определять области для сокращения издержек в процессах проекта.
Ключевые слова инструмент управления проектом, имитационное моделирование, Скрам, AnyLogic, СМО, бережливая разработка, CMMI, метод ABC, 6 сигм.
Познай свою команду...
Введение
Проектное управление сегодня активно использует современные информационные технологии для повышения эффективности деятельности сотрудников, управляемости функциональных подразделений, повышения прозрачности всех процессов (планирование, прием и выполнение заказов, взаимодействие с клиентами и многое другое) [2]. В современной литературе можно встретить подробное описание функциональных особенностей интеграции информационных систем управления проектами, содержимым и ресурсами на предприятиях малого бизнеса [4].
В инновационных ИТ-проектах по разработке программного обеспечения (ПО) ввиду специфики предметной области, обусловленной высокой долей неопределенности, даже на уровне операционного планирования [2] не существует простой математической формулы для определения объема
* Магистрант кафедры Стратегии, территориального развития и качества жизни факультета Государственного и муниципального управления.
работы, который способна освоить команда с учетом текущих факторов динамической среды (количество сотрудников, полнота требований, декомпозиция задач и прочее). Однако, применение имитационного моделирования, наряду с его широким распространением во многих сферах управления в качестве инструмента поддержки принятия решений, является актуальным и перспективным направлением исследования в такой области проектной деятельности как ИТ-проекты с гибкими методологиями [7].
Создателям информационных систем для гибкой разработки ПО требовалась эффективная методология управления подобными проектами, однако впервые ее зачатки, так называемая технология Скрам, были представлены на общее обозрение Швабером и Джефом Сазерлендом на OOPSLA'96 в Остине, и в авторитетные классификации того времени не попали [5]. Только позднее произошла популяризация подобных методологий в проектном менеджменте [1].
Известно, что методология Скрам, доказавшая свою эффективность в разработке ПО, располагает небольшим набором программных инструментов для планирования. Это объясняется смещением фокуса управления с инструментов и процессов на участников проектной команды и их взаимодейства [16].
Как правило, планирование объема трудозатрат на итерацию осуществляется на основе результатов других проектов, предыдущих итераций (метод «вчерашней погоды») или интуиции [14].
Автор статьи предлагает инновационное решение - применение имитационного моделирования в качестве инструмента поддержки принятия решений в Скрам проектах - и представляет реализацию имитационной модели, разработанной в среде AnyLogic, для прогнозирования коэффициента сосредоточенности Скрам команды на предстоящую итерацию.
Данная модель позволяет связать сроки и объем работы, входящие в треугольник менеджмента, для определения коэффициента сосредоточенности команды (уровень качества считается достаточно высоким благодаря частым итерациям, регулярному общению с заказчиком и применению практик разработки XI', что, в свою очередь, гарантирует удовлетворение требований к программному продукту [18]).
Результатом работы модели является прогноз на предстоящий спринт коэффициента сосредоточенности команды, который зависит от набора показателей:
- размера команды;
- производительности каждого разработчика, влияющей на производительность всей команды [13];
- времени проверки результатов менеджером (владельцем продукта);
- вероятности успешного выполнения истории;
- времени, требующегося для доработки задачи разработчиком.
Коэффициент сосредоточенности покажет способность команды выполнить запланированный объем.
Описание модели и параметров
Библиотека Process Modeling Library в среде имитационного моделирования AnyLogic 7 поддерживает дискретно -событийный подход моделирования, с помощью объектов которого можно моделировать системы реального мира в терминах агентов (транзакций, заказчиков, продуктов, компонентов, транспортных средств, и т.д.), процессов (последовательности операций, обычно включающих очереди, задержки, использование ресурсов) и ресурсов [9].
На рис. 1 представлена дискретная имитационная модель системы массового обслуживания (СМО) для обработки заявок (пользовательских историй), построенная в среде AnyLogic 7.1.
sprint_backlog implementation checking acceptance increment
Рис. 1. Модель СМО выполнения пользовательской истории в среде AnyLogic
Для определения параметров модели в течение одного месяца были собраны данные в сработавшейся Скрам команде на проекте по разработке ВЕБ проектов.
Далее приводится описание реализации модели, настроенной на основании полученных данных.
Время имитации (длина итерации) составляет 40 часов (рабочая неделя).
Из источника (sprint_backlog) в блок реализации (implementation) с интенсивностью 80 (с запасом) в итерацию поступают заявки - подготовленные пользовательские истории, которые образуют входящий поток требований. Заявки размещаются в очереди.
Пул ресурсов «разработчики» (developers) состоит из 5 универсальных разработчиков (кроссфункциональная команда). Каждый разработчик берет пользовательскую историю из очереди на выполнение.
Время обработки заявки зависит от размера пользовательской истории и производительности исполнителя.
Поэтому формула расчета длительности выполнения пользовательской истории определяется как Tt = St / Pj, где Tt - время, требуемое для выполне-
ния г-ой пользовательской истории, Ъ) - размер пользовательской /-ой истории, Ру - скорость разработки '-го разработчика.
В AnyLogic функция распределения вероятности задается с помощью экспериментального распределения [12].
На рис. 2 представлен фрагмент табличной функции оценок пользовательских историй: в первой колонке - номер истории, во второй - её оценка.
Рис. 2. Фрагмент табличной функции: оценки пользовательских историй в очках истории
Аналогичным образом с помощью табличной функции задается производительность каждого разработчика, которая выражается в очках пользовательских историй в час.
После выполнения история попадает в очередь на проверку (checking) менеджеру (managers). Вместимость блока ожидания не ограничена. Пул ресурсов «менеджеры» состоит из 1 человека. Время задержки заявки (проверки задачи) менеджером для упрощения задано в виде распределения Симпсона (треугольное распределение): triangular(.0005, 0.2, 0.01).
Затем в ходе приемочного тестирования (acceptance) история с вероятностью 0.82 успешно попадает в инкремент. Вероятность успешного прохождения тестирования является интегральным показателем и определяется на основе данных из предыдущих спринтов, например, в простейшем случае, как среднее арифметическое отношений количества историй, прошедших проверку, к количеству выполненных разработчиками историям.
В модели было введено ограничение - не более одного повторного открытия для пользовательской истории, что в 93.4 % случаев соответствовало показаниям проекта.
Время, требуемое на доработку, выражается как коэффициент от времени выполнения истории и составляет 0.26 в данном случае.
Стоит отметить, что во время доработки пользовательской истории её оценка сохраняется, и, как результат, требуемое на внесение правок дополнительное время негативным образом сказывается на результативности команды.
По окончании эксперимента над моделью отношение количества выполненных заявок к количеству запланированных заявок покажет коэффициент сосредоточенности команды как Е = N / Ы0, где Е - коэффициент сосредоточенности, N - количество решенных пользовательских историй в конце итерации, N - количество запланированных пользовательских историй в начале итерации.
Этот коэффициент в представленной модели зависит не только от разработчиков, но и эффективной работы менеджеров.
Рассмотрим результаты работы модели для случая, когда количество запланированных очков истории на текущий спринт равно 227.
На рис. 3 показано конечное состояние работы модели в среде AnyLogic в результате проведения имитационного эксперимента.
Рис. 3. Результат работы модели в результате имитационного эксперимента в среде AnyLogic
Как видим, к концу спринта выполнены практически все истории (последние 5 находятся в разработке). За время итерации было отправлено на доработку 17 пользовательских историй. Разработчики были заняты полностью, менеджер проекта - на 18 %.
Дополнительную информацию могут предоставить графики проекта.
Одной из основных в Скраме является диаграмма количества оставшихся очков истории (burndown chart), сокращающихся каждый раз на размер пользовательской истории по ее завершению (рис. 4).
Это наглядная демонстрация динамики работы команды в течение спринта. Например, первые 10 часов итерации прослеживается пологий характер графика, что объясняется процессом реализации требований, в котором, в основном, участвуют разработчики, и сосредоточением больших пользовательских историй в начале недели.
На рис. 5 показаны диаграммы выполненных и завершенных (прошедших проверку) историй. В период с 20 по 25 часов наблюдается влияние
фактора ошибок - большое количество отправок на доработку выполненных историй. Этот фактор говорит о ненадлежащем качестве работы или недостаточной полноте требований к программному продукту. Последнее может быть актуальным для сложных проектов. Кроме того, повторная отправка на доработку нескольких крупных историй привела к разрыву в графиках, что может послужить поводом для декомпозиции крупных задач в следующих спринтах.
Рис. 5. Графики общего количества выполненных и завершенных историй (нижний график - выполненные истории)
На рис. 6 представлена динамика коэффициента сосредоточенности команды во время имитационного эксперимента.
Рис. 6. График изменения коэффициента сосредоточенности команды в течение спринта
В конце графика коэффициент приближается к единице. Это говорит о том, что при таком стечении обстоятельств команда способна справится с текущим объемом работы.
Чтобы сделать более обоснованные выводы, необходима статистика серии экспериментов.
Рис. 7. Распределение коэффициента сосредоточенности команды для 500 экспериментов
В AnyLogic эксперимент по вариации параметров позволяет оценить эффект случайных факторов в стохастической модели. Для этого необходимо выполнить серию одиночных запусков модели с фиксированными значениями параметров. По завершению эксперимента, AnyLogic может продемонстрировать результаты прогонов на диаграмме, чтобы помочь понять, какие результаты следует ожидать для указанных значений параметров.
Рис. 7 демонстрирует распределение сосредоточенности команды в результате проведения 500 экспериментов.
В табл. 1 содержатся статистические показатели, автоматически сформированные в AnyLogic с помощью модуля Статистика (Statistics). В модуле Статистика вычисляются минимальное и максимальное значения коэффициента сосредоточенности, математическое ожидание, стандартное отклонение, а также ширина доверительного интервала для математического ожидания.
Таблица 1
Статистические данные результатов вариационного эксперимента в 500 повторений по определению коэффициента сосредоточенности команды
Свойство Значение
Объем выборки 500
Математическое ожидание 0.923
Минимальное значение 0.776
Максимальное значение 0.973
Стандартное отклонение 0.026
Доверительный интервал 0.004
На основе данной информации, менеджер может принять более взвешенное решение относительно объема работы на итерацию (например, на какие границы коэффициента сосредоточенности стоит рассчитывать), скорректировать план таким образом, чтобы команда могла работать в условиях с нормальным уровнем стресса, и предоставить заказчику более точную оценку сроков для запланированного объема.
Выводы
Как известно, корректность модели может быть проверена в результате ее применения. Так, пробное использование данной модели на проекте в последующие после настройки полмесяца оказало положительный эффект на точность оценки коэффициента сосредоточенности команды. Например, в первую итерацию реальный коэффициент сосредоточенности оказался на 10.2 % меньше математического ожидания спрогнозированного значения и на 14.7 % ожидаемого, во вторую - на 3.7 % больше спрогнозированного и на 8.1 % ожидаемого.
Кроме того, после анализа результатов модели были введены изменения, в частности, на стороне клиента был выделен сотрудник, ответствен-
ный за оперативное предоставление необходимой информации во время спринта.
Модель позволяет определить, насколько реальным является выполнение набора пользовательских историй командой до начала работы над ними, принять меры по предотвращению срыва сроков и созданию более комфортных условий для работы разработчиков.
В процессе имитационного эксперимента можно увидеть «узкие места» в текущих процессах. Например, слишком частые возвраты на доработку при достаточно подробных требованиях говорят об отсутствии надлежащего качества в процессе разработки.
Стоит отметить, что вместо оценки объема трудозатрат в очках истории, возможно использование оценки времени, требуемого для выполнения истории. В этом случае коэффициент сосредоточенности будет заменен на параметр предсказуемость сроков (Schedule Predictability), который показывает, насколько команда укладывается в запланированные сроки [11].
AnyLogic определяет занятость ресурсов, что может быть использовано для оценки издержек и распределения равномерной нагрузки на персонал. Например, в данной реализации менеджер был загружен на 18 %. Это говорит о том, что при постоянной ставке менеджер может быть задействован в других проектах или видах деятельности.
В модели можно ввести автоматический расчет стоимости одного единицы объема трудозатрат по модели описания ABC. В нашем случае под затратами подразумеваются оплата труда менеджеров и разработчиков, аренда офисного помещения, амортизация оборудования и прочее. Этот вопрос особенно актуален, если в компании есть разработчики с почасовой оплатой или нестандартным графиком работы [6].
Согласно 3 и 4 уровням зрелости модели CMMI вместо интуитивного планирования надо полагаться на исторические данные. Четвертый уровень зрелости модели совершенствования процессов CMMI-DEV требует систематического сбора статистических данных по процессам, их обработку и применение на практике, последующую корректировку инструментов и методов сбора, в результате чего принятие управленческих решений становится более обоснованным [19].
Данная модель стимулирует к действиям по улучшению предсказуемости процессов управления разработкой ПО. Согласно методологии «6 сигм», повышение предсказуемости процессов проявляется на сужении графика и увеличении его высоты в точке математического ожидания (с увеличением частоты попадания и устранением влияния случайных факторов в разработке) [8].
Кроме того, представленный инструмент согласуется с философией «бережливого производства» [15], оказавшей определенное влияние на методологию Скрам благодаря Мэри и Тому Попендик [17].
Предложенная реализация модели для прогнозирования коэффициента сосредоточенности команды в Скрам проекте агрегирует основные этапы процесса создания программного продукта и стимулирует поиск и устранение издержек. В модели заложено влияние качества требований и выполнения, скорость коммуникаций на точность оценки планирования работы на спринт, и производительность команды.
В результате настройки модели, в распоряжении менеджера Скрам проекта появляется инструмент для анализа общей производительности команды и планирования объема работ на итерацию, позволяющий увеличить эффективность управления проектом.
Список литературы:
1. Алесковский В.В., Козырев А.А., Слуцкая Ю.Г. Основы управления проектами. Ч. I: Управление командой проекта. - СПб.: СЗАГС, 2011. - 288 с.
2. Козырев А.А. Информационные технологии в экономике и управлении: учебник. - Издание 4-е перераб. и доп. - СПб.: Изд-во В.А. Михайлова, 2005. - 448 с.
3. Козырев А.А. Развитие информационных технологий интегрированных цифровых сетей // Информационные технологии в моделировании и управлении. Труды II Международной научно-практической конференции 20-22 июня 2000 г. - СПб.: Изд-во СПбГТУ 2000. - С. 186-188.
4. Козырев А.А., Хорунжий И.В. Интеграция информационных систем управления проектами, содержимым и ресурсами на предприятиях малого бизнеса // Государство и бизнес. Вопросы теории и практики: моделирование, менеджмент, финансы: Материалы III Международной конференции. Санкт-Петербург, 21 апреля 2011 г. - СПб.: Изд-во СЗАГС, 2011. - С. 305-311.
5. Козырев А.А., Юдин А.П. Программно-технические средства информационных технологий. - СПб.: Изд-во СПбГТУ, 1997. - 104 с.
6. Расчёт себестоимости по видам деятельности [Электронный ресурс] // Википедия - свободная энциклопедия. - Режим доступа: https://ru.wikipe-Ша.ощ^1к1/Расчёт_себестоимости_по_видам_деятельности (дата обращения: 22.09.2015).
7. Сачек Е.А. Применение имитационного моделирования в управлении проектами по разработке программного обеспечения с гибкими методологиями // Научные труды Северо-Западного Института Управления РАНХиГС. -2015. - Т. 6, Вып. 3 (20).
8. Шесть сигм [Электронный ресурс] // Википедия - свободная энциклопедия. - Режим доступа: https://ru.wikipedia.org/wiki/Шесть_сигм (дата обращения: 14.06.2015).
9. AnyLogic About Process Modeling Library [Электронный ресурс]. -Режим доступа: http://www.anylogic.com/anylogic/help/index.jsp?topic=/com. xj.anylogic.help/html/_ELR/PML.html (дата обращения: 07.09.2015).
10. Cohn M. Agile Estimating and Planning. - Publisher Prentice Hall, 2005. -P. 35, 43.
11. Data Specification for Software Project Performance Measures: Results of a Collaboration on Performance Measurement [Электронный ресурс]. - Режим доступа: http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=8715, p. 15 (дата обращения: 12.08.2015).
12. Help AnyLogic advanced: table functions [Электронный ресурс]. - Режим доступа: http://www.anylogic.com/anylogic/help/index.jsp?nav=/0_14_1 (дата обращения: 19.09.2015).
13. Kenneth S.R. Essential Scrum: a practical guide to the most popular agile process. - Addison-Wesley, 2012. - P. 134.
14. Kniberg H. Scrum and XP from the trenches. - 2nd edition. - C4Media, publisher of InfoQ.com, 2015. - P. 33.
15. Lean thinking [Электронный ресурс] // Википедия - свободная энциклопедия. - Режим доступа: https://en.wikipedia.org/wiki/Lean_IT (дата обращения: 29.08.2105).
16. Manifesto for Agile Software Development [Электронный ресурс]. -Режим доступа: http://agilemanifesto.org/ (дата обращения: 07.08.2015).
17. Mary P., Tom P. Leading Lean Software Development: Results are not the Point. - Pearson Education, 2009. - 312 pages.
18. Mike C. Succeeding with Agile: Software Development Using Scrum. -Addison-Wesley, 2010. - P. 307.
19. SEI CMMI ® or Agile: Why Not Embrace Both! [Электронный ресурс]. - Режим доступа: http://resources.sei.cmu.edu/library/asset-view.cfm? assetid=8533 (дата обращения: 07.08.2015).
