CC BY
58
©АВТОР, 2017 УДК 615.072:004.42
Применение методов Agile и Scrum при разработке программного обеспечения для автоматизации экспертизы лекарственных средств
К. А. Кошечкин
Федеральное государственное бюджетное учреждение «Научный центр экспертизы средств медицинского применения» МинистерстваздравоохраненияРоссийскойФедерации, 127051, Москва, Россия
Статья поступила 30.01.2017 г. Принята к печати 01.03.2017 г.
Резюме: Проведен анализ применения методов Agile и Scrum при разработке программного обеспечения для автоматизации экспертизы лекарственных средств. Обозначены основные роли участников и выполняемые ими действия. Описаны общие принципы ориентации на коммуникацию и контроль объема планируемых для реализации требований. Приведены числовые характеристики влияния методов Agile и Scrum на сокращение сроков разработки программного обеспечения. Показано, что внедрение данных методов позволяет управлять имеющимися ресурсами с целью эффективной реализации наиболее ценных возможностей информационных систем в кратчайшие сроки.
Ключевые слова: Agile; Scrum; CALS/PLM-технологии; жизненный цикл лекарственных средств; лабораторная информационная система; единое информационное пространство в сфере обращения лекарственных средств; информатизация здравоохранения; информатизация фармации.
Библиографическое описание: Кошечкин КА. Применение методов Agile и Scrum при разработке программного обеспечения для автоматизации экспертизы лекарственных средств. Ведомости Научного центра экспертизы средств медицинского применения 2017; 7(1): 64-68.
Ежегодно в Российской Федерации процедуру научной экспертизы материалов регистрационного досье и лабораторной экспертизы образцов лекарственных препаратов проходят более 6000 препаратов. Проведение экспертизы возложено на Федеральное государственное бюджетное учреждение «Научный центр экспертизы средств медицинского применения» Министерства здравоохранения Российской Федерации (ФГБУ «НЦЭСМП» Минздрава России) и является хорошо налаженной функциональной системой, позволяющей в определенные законодательством сроки выполнять необходимый объем работ по заданиям Минздрава России и обеспечивать тем самым реализацию государственной политики в сфере регулирования обращения лекарственных средств. В свою очередь, важную роль в проведении научной экспертизы выполняют системы автоматизации.
Высокая квалификация и накопленный за годы работы опыт сотрудников ФГБУ «НЦЭСМП» Минздрава России, занимающихся разработкой информационных систем, позволяет в большинстве случаев осуществлять создание требуемого программного обеспечения без привлечения внешних подрядчиков. В настоящий момент в учреждении эксплуатируется более 20 информационных систем, автоматизирующих различные сферы деятельности. В их число входят как программные продукты общего назначения, например, Информационная система «План бюджета учреждения», так и высокоспециализированные, например, Информационная система «Оценка взаимозаменяемости». Для организации создания и развития такого количества и ассортимента информационных систем необходимо применение специализированных методик разработки.
Одна из них — Agile management, или Agile process management, — эта методология управления пред-
ставляет собой способ создания новой продукции, технологии или решения с высокоитеративным, гибким подходом. Именно такой метод управления наиболее продуктивен в сфере разработки информационных систем для экспертизы лекарственных средств. Оперативность возникающих задач и частые изменения в нормативно-правовой среде приводят к тому, что привычный метод иерархического управления в данном случае плохо применим. Agile можно рассматривать как расширение и генерализацию методологии Serum, применяемой в разработке программного обеспечения.
Serum — это набор принципов, на которых строится процесс разработки, позволяющий в жестко фиксированные и небольшие по времени итерации, называемые спринтами (англ. sprints), предоставлять конечному пользователю продукт с новыми свойствами, для которых определен наибольший приоритет. При этом строго фиксированная небольшая длительность спринта придает процессу разработки предсказуемость и гибкость [1].
Также в Agile нашли свое отражение такие принципы управления бизнесом, как Lean projeet management (в пер. с англ. — бережливое управление проектами), Кайдзен и Шесть сигм [2].
В методологии Agile постулируется главенство живого взаимодействия участников проекта над следованием стандартным процедурам. Фокус должен быть в первую очередь на создании действующего продукта, а не документировании полученного результата, а также на необходимости взаимодействия с потребителями продукции и открытости к внесению изменений вместо следования в рамках предустановленного курса.
Преимущества данного подхода заключаются в возможности быстрого создания прототипа, на основе которого принимаются решения о доработке,
изменении и моделировании его свойств и возможностей.
Для каждого разрабатываемого проекта определяется владелец. Обычно это лицо, обладающее представлением о решаемых разрабатываемым приложением задачах. Также владелец проекта решает вопросы, связанные с выделением ресурсов, необходимых для реализации проекта. Далее определяются заинтересованные лица, которые будут в дальнейшем использовать продукт, поддерживать его или будут вовлечены в разработку. На основе информации, полученной от заинтересованных лиц, формируются требования пользователей. В них излагаются основные алгоритмы использования программного продукта, какие действия выполняются в каком порядке и с использованием каких настроек. Обычно пожелания заинтересованных лиц представляют собой расплывчатое облако, которое не подходит для передачи в разработку. Роль владельца проекта заключается в отсечении желаемого функционала для сохранения фокуса и объема требуемых ресурсов. Часть требований должна быть отклонена, часть отложена, часть перенесена для реализации в виде отдельного продукта. Далее отфильтрованные пользовательские истории передают в отдел разработки, где будет создаваться рабочая система.
Так как отдел разработки использует гибкую методологию разработки, требования не собирают в единое техническое задание, требуемое для выпуска программного продукта в полной готовности. Наоборот, новый функционал выпускают как можно чаще и дробно. Обычно реализуются 6—10 пользовательских требований в неделю. Количество реализуемых пользовательских требований в единицу времени составляет пропускную способность отдела разработки. Конечно, измерение производительности в количестве реализуемых требований является сугубо условным, так как сложность реализации сильно различается в зависимости от содержания требований.
Кроме реализации новых требований значительный объем времени занимают вопросы тестирования функционала. Для снижения временных издержек внедряются системы автоматизированного тестирования, которые позволяют проверить контрольные точки работы приложения посредством ввода тестовых наборов данных.
Обычно количество требований пользователей растет по мере реализации функционала. Значительное превышение количества требований пользователей относительно пропускной способности приводит к необходимости спешить, переключаться между задачами, и как следствие происходит потеря мотивации. В итоге снижаются производительность и качество создаваемого продукта. Во избежание данной ситуации применяется метод Scrum «вчерашняя погода» [3], в рамках которого оценивается количество требований, реализованное за предыдущий отчетный период, и на основании этой оценки владельцу проекта предлагается выбрать, какие из требований будут реализованы в следующий период с учетом этого количества. Все остальные требования, которые были одобрены, но не попали в план разработки на следующий период, включаются в очередь задач с учетом их приоритета (англ. Backlog) [3]. Приоритет и факт включения требования в очередь определяет владелец проекта. При этом ключевым фактором для успешного выполнения роли владельца проекта является осуществление коммуникаций между разра-
Рис. 1. Ценность для заказчика в зависимости от этапа разработки проекта
ботчиками, авторами требований и самим владельцем. Методология Scrum определяет коммуникациям ведущее место в организации успешного выполнения проекта. Для правильной расстановки приоритетов владелец продукта должен понимать ценность каждого требования и затраты на его реализацию. Информацию о ценности в большинстве случаев может предоставить заинтересованное лицо, а затраты на реализацию оценить разработчик.
Другой важной задачей является деление пользовательских требований на представляющие самостоятельную ценность фрагменты, которые могут быть реализованы в течение 1—2 дней. Порядок реализации требований рекомендуется ранжировать следующим образом: вначале выполняются маленькие и четкие требования, а в конце — большие и неопределенные. В ходе реализации нового функционала появляются представления о затратах и ценности реализации тех требований, которые ранее казались неопределенными.
Периодически должна производиться процедура так называемой очистки Backlog, в ходе которой требования, утратившие актуальность, удаляются, и происходит пересмотр приоритета оставшихся. Обычно эти работы выполняются в рамках встречи разработчиков, заинтересованных лиц и владельцев услуги.
В ходе разработки программного продукта можно выделить 3 стадии в зависимости от повышения ценности для заказчика (рис. 1).
На начальном этапе идет накопление знаний, и риски, которые несет заказчик, являются максимальными. Неопределенность проекта очень высокая. По мере появления прототипов интерфейса и результатов экспериментов у разработчиков формируется понимание будущего облика продукта. Далее разработчики концентрируются на реализации ценности для заказчика. Неопределенность снижается, и реализуются требования заинтересованных лиц. Согласно принципу Парето, «20 % усилий дают 80 % результата, а остальные 80 % усилий — лишь 20 % результата», оставшееся время на реализацию будет потрачено на незначительные улучшения. В принципе, процесс внесения улучшений может быть ничем не ограничен. В большинстве проектов, реализованных в ФГБУ «НЦЭСМП» Минздрава России, доработка и реализация новых требований не останавливаются после выпуска продукта. В общем случае в определенный момент процесс разработки должен быть остановлен, функциональные возможности продукта заморожены, а все новые требования должны передаваться для реализации в рамках нового проекта.
120
100
80
« 60
£
40
20
Пессимистическая — Оптимистическая
О&ьем реализации
nporao^perip^^*^^^ на определенный момент^ремени^^^.
1 I реализации требований j
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
Время, нед.
Рис. 2. Определение диапазона срокареализации определенного функционала
В ходе реализации продукта необходимо учитывать, какие приоритеты должны быть у отдела разработки. Необходимо соблюдение баланса между доступностью функций, надежностью и безопасностью. Определение приоритетов по каждому проекту осуществляется индивидуально. При этом должна учитываться критичность корректной работы создаваемого продукта для автоматизируемого бизнес-процесса, а также критичность самого бизнес-процесса для работы организации. С другой стороны, необходимо анализировать срочность потребности в реализуемом функционале и требуемый уровень конфиденциальности. Исходя из оценки этих параметров, определяется фокус команды разработчиков, например, на устранении ошибок, разработке сложного функционала или переносе системы на более защищенную платформу. Если реализовать критичную для бизнеса систему, которая будет содержать большое число ошибок при богатом функционале, общий эффект от ее внедрения будет отрицательный, так как из-за ошибок могут возникать нарушения работы организации. В то же время система, которая упрощает работу, но без проблем дублируется, например, бумажным документооборотом, может разрабатываться, в первую очередь реализуя требуемые возможности, исправляя возникающие ошибки по мере их обнаружения в ходе эксплуатации. Применение максимально безопасной архитектуры приводит к увеличению сроков реализации функционала.
Коммуникации в ходе разработки сводятся к здоровому противостоянию заинтересованных лиц, требующих создания максимального функционала, разработчиков, способных реализовать ограниченное количество требований с заданным уровнем качества, и владельца проекта, определяющего порядок, очередность и приоритеты в ходе реализации проекта.
После окончания разработки проект переходит в стадию сопровождения, в ходе которой в большинстве случаев выявляются новые требования: как в связи с объективными причинами на основе изменений во внешней среде, например, изменение нормативно-правовых актов, так и за счет переосмысления эксплуатирующим подразделением логики работы с сис-
темой и пересмотра ранее сформулированных требований. Таким образом, в очередь разработки попадают задачи не только по создаваемым проектам, но и по находящимся в эксплуатации. Таким образом, в масштабе организации приходится осуществлять управление очередью разработки не только в рамках проектов, но и всей работы компании в целом. При этом используются те же принципы оценки ценности и затрат, что и в рамках отдельных проектов. Таким образом, в общем случае Backlog содержит задачи, относящиеся ко всей команде разработки, а не к отдельному продукту.
В ходе разработки регулярно возникают вопросы о сроке реализации того или иного функционала, поступающие от заинтересованных лиц. При этом оценка может быть произведена на основе пессимистичного и оптимистичного прогнозов производительности (рис. 2).
В зависимости от близости к точке реализации план становится более определенным, т.е. чем дальше требование отложено в очереди на разработку, тем менее определенным является срок реализации. Также по этому графику может быть определен перечень функциональных требований, которые будут реализованы на определенный момент времени. В обоих случаях предоставление информации о ходе выполнения работ учитывает реально существующую степень неопределенности. В большинстве случаев предоставление сведений с указанием диапазона вероятных значений является более верной практикой при разработке программных продуктов, чем указание точной оценки [4].
Применение гибкой методологии разработки программного обеспечения в ФГБУ «НЦЭСМП» Минздрава России позволило при сохранении небольшого штата сотрудников (6 разработчиков) осуществить создание и сопровождение большого числа проектов (более 20). При этом среднее время реализации требования сократилось с 24-70 дней в 2012-2013 гг. до 5-18 дней в 2014-2016 гг.,какпока-зано в таблице 1.
Также снизилось и общее количество запросов за счет снижения числа принимаемых в работу требова-
Таблица 1
ДИНАМИКА КОЛИЧЕСТВА ТРЕБОВАНИЙ И СРЕДНЕЕ ВРЕМЯ ИХ РЕАЛИЗАЦИИ ПО ГОДАМ
По видам информационных систем
Виды информационных систем Период
2012 2013 2014 2015 2016
Экспертные системы (требования, шт.) 447 514 307 301 307
Среднее время решения (дни) 24 42 3 10 1
Административные системы (требования, шт.) 228 232 226 93 175
Среднее время решения (дни) 145 132 22 44 12
Реализованы суммарно (требования, шт.) 675 746 533 394 482
Среднее время решения (дни) 65 70 11 18 5
По типам требований
Типы требований Период
2012 2013 2014 2015 2016
Новые возможности (требования, шт.) 177 139 65 62 156
Среднее время решения (дни) 199 203 41 58 1
Модули (требования, шт.) 0 15 12 0 12
Среднее время решения (дни) 0 123 1 0 1
Улучшения имеющегося функционала (требования, шт.) 153 217 189 116 172
Среднее время решения (дни) 9 50 10 15 1
Изменение функционала (требования, шт.) 345 375 267 216 142
Среднее время решения (дни) 21 31 4 8 12
Решенные запросы суммарно (требования, шт.) 675 746 533 394 482
Среднее время решения (дни) 65 70 11 18 5
ний. Таким образом, повышение фокуса проводимых работ позволяет ускорить реализацию функциональных возможностей, что в свою очередь положительно сказывается на общей скорости реализации проектов.
Схожим образом обстоит ситуация с влиянием гибкой методологии разработки на исправление ошибок. Как показано в таблице 2, общее количество выявленных и исправленных ошибок снизилось в 2 раза при сравнении данных по 2012 и 2016 годам. При этом среднее время исправления также сокращается с 12—26 дней в 2012—2013 годах до 1—6 дней в 2014-2016 годах.
Таким образом, применение гибкой методологии разработки положительно сказывается на качестве и количестве создаваемых решений, что в свою очередь снижает затраты на создание элементов информационного пространства организации.
За счет применения гибкой методологии разработки программных продуктов может быть повышена доступность решений автоматизации для всех участников сферы обращения лекарственных средств. В контексте концепции внедрения САЬ8/РЬМ-тех-нологий [5] этот фактор является существенным для перевода бизнес-процессов всех субъектов жизненного цикла лекарственного средства в электронную форму. Это обеспечивает возможность надежной и моментальной передачи информации между различными представителями фармацевтического рынка, автоматизацию документооборота, сбора статистики и отчетности.
Развитие информационных технологий в сфере здравоохранения в последние годы имеет экспоненциальный характер. Только классификация разновидностей информационных систем и их подсистем
Таблица 2
ДИНАМИКА КОЛИЧЕСТВА ОШИБОК И СРЕДНЕЕ ВРЕМЯ ИХ РЕШЕНИЯ ПО ГОДАМ
Период Исправленные ошибки (шт.) Среднее время исправления (дни)
2012 142 12
2013 190 26
2014 111 6
2015 69 6
2016 75 1
насчитывает более 100 элементов [6]. При этом электронное здравоохранение является одним из важнейших инструментов поддержки эффективного оказания медицинской помощи. За счет информационных технологий создаются широкие возможности одновременного воздействия на большое количество граждан [7, 8]. Для эффективного проектирования, разработки, внедрения и эксплуатации его составных элементов требуются значительные затраты. Внедрение методов Agile и Scrum позволяет управлять имеющимися ресурсами с целью эффективной реализации наиболее ценных для заказчика возможностей информационных систем в кратчайшие сроки.
ЛИТЕРАТУРА
1. Сазерленд Дж. Scrum. Революционный метод управления проектами. М.; Манн, Иванов и Фербер; 2016.
2. Lenton A. Book review: Agile Project Management by Jim Highsmith. C. Vu. 16(4). Retrieved 16.07.2006.
3. Schwaber K, Beedle M. Agile software development with Scrum. Upper Saddle River: Prentice Hall; 2002.
4. Sutherland J, Schwaber K. The Scrum Papers: Nut, Bolts, and Origins of an Agile Framework. Cambridge, MA; 2007. Available from: http://www.hbagency.com/scrum/tl_files/scrum_inc/documents/ ScrumPapers.pdf.
5. Кошечкин KA, Олефир ЮВ, Меркулов ВА. Управление информационным сопровождением жизненного цикла лекарственных средств. Концепции применения элементов CALS/PLM-техноло-
0Б АВТОРАХ
гий для информационной поддержки жизненного цикла лекарственных средств. М.: Полиграф-Плюс; 2015.
6. Лебедев ГС, Мухин ЮЮ. Классификация медицинских информационных систем. Транспортное дело России 2012; (6-2): 98-105. Available from: https://goo.gl/Wvhy6F.
7. Карпов 03, Клименко ГС, Лебедев ГС, Лосев АЮ. Электронное здравоохранение в Российской Федерации. Стандарты и качество 2016; (8): 62-7.
8. Зарубина ТВ. Направления информатизации здравоохранения России на современном этапе. Информационно-измерительные и управляющие системы 2013; 11(10): 4-8.
Федеральное государственное бюджетное учреждение «Научный центр экспертизы средств медицинского применения» Министерства здравоохранения Российской Федерации. Российская Федерация, 127051, Москва, Петровский бульвар, 8, стр. 2. Ношечкин Нонстантин Александрович. Начальник Управления информатизации, канд. биол. наук.
АДРЕС ДЛЯ ПЕРЕПИСКИ
Кошечкин Константин Александрович; [email protected]
APPLICATION OF AGILE AND SCRUM METHODS IN SOFTWARE DEVELOPMENT FOR AUTOMATION OF MEDICINAL PRODUCTS EVALUATION
K. A. Koshechkin
Federal State Budgetary Institution «Scientific Centre for Expert Evaluation of Medicinal Products» ofthe Ministry ofHealth ofthe Russian Federation, 127051, Moscow, Russia
Abstract: Medicinal products evaluation is quite impossible without automation systems. In order to develop and update a large number of information systems, it is necessary either to have considerable resources, or to apply the methodology of adaptive management to projects development. The article analyzes application of Agile and Scrum methods in software development and outlines the key roles of the participants and the actions they perform. It also describes general principles of commitment to communication and control of the scope of proposed requirements. The article illustrates how these methods can reduce the time spent on software development and help manage available resources to harness information systems capacity.
Key words: Agile; Scrum; CALS/PLM-technologies; medicines lifecycle; Laboratory Information Management System; framework of common information space in medicinal products lifecycle; health informatics; pharmacy informatics.
For citation: Koshechkin KA. Application of Agile and Scrum methods in software development for automation of medicinal products evaluation. The Bulletin ofthe Scientific Centre for Expert Evaluation of Medicinal Products 2017; 7(1): 64—68.
REFERENCES
1. Sutherland J. Scrum. A revolutionary approach to building teams, beating deadlines and boosting productivity. Moscow: Mann, Ivanov i Ferber; 2016 (in Russian).
2. Lenton A. Book review: Agile Project Management by Jim Highsmith. C. Vu. 16(4). Retrieved 16.07.2006.
3. Schwaber K, Beedle M. Agile software development with Scrum. Upper Saddle River: Prentice Hall; 2002.
4. Sutherland J, Schwaber K. The Scrum Papers: Nut, Bolts, and Origins of an Agile Framework. Cambridge, MA; 2007. Available from: http://www.hbagency.com/scrum/tl_files/scrum_inc/documents/ ScrumPapers.pdf.
5. Koshechkin KA, Olefir YuV, Merkulov VA. Management information support life cycle of medicines. Concept of the use of elements of CALS/PLM-technologies for information support of the life cycle of medicines. Moscow: Poligraf-Plus; 2015 (in Russian).
6. Lebedev GS, Mukhin YuYu. Classification of medical information systems. Transportnoe delo Rossii 2012; (6-2): 98-105. Available from: https://goo.gl/Wvhy6F (in Russian).
7. Karpov OE, Klimenko GS, Lebedev GS, Losev AYu. Electronic healthcare in the Russian Federation. Standarty i kachestvo 2016; (8): 62-7 (in Russian).
8. Zarubina TV. Directions of the informatization of Russian Healthcare at the present stage. Informatsionno-izmeritelnye i upravlyauschie sistemy 2013; 11(10): 4-8 (in Russian).
AUTHORS
Federal State Budgetary Institution «Scientific Centre for Expert Evaluation of Medicinal Products» of the Ministry of Health of the Russian Federation, Petrovsky boulevard 8, bld. 2, Moscow 127051, Russian Federation. Koshechkin KA. Head of Informatization Division. Candidate of Biological Sciences.
