CC BY
48
ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ
УДК 004:332.8(470.42)
В. Г. ТРОНИН, В. В. МОИСЕЕВ, Е. М. ХРАМКОВ
ИСПОЛЬЗОВАНИЕ ПРИНЦИПОВ ГИБКИХ МЕТОДОЛОГИЙ УПРАВЛЕНИЯ ПРОЕКТАМИ ПРИ РАЗРАБОТКЕ РЕГИОНАЛЬНОЙ СИСТЕМЫ ЖКХ УЛЬЯНОВСКОЙ ОБЛАСТИ
Посвящена оценке эффективности реформирования рабочего процесса в небольшой команде (до 10 человек) на примере разработки региональной системы ЖКХ Ульяновской области. Рассмотрены изменения в управлении проектом с применением гибкой методологии разработки, значительно повысившие эффективность работы и качество программного продукта. Представлена статистика проекта с использованием анализа системы учёта заданий Redmine.
Ключевые слова: управление проектом, Scrum, гибкая методология
Введение
Управление проектом направлено на достижение определённых целей с ограничениями так называемого треугольника: стоимость, время, функционал. Управление также способствует обеспечению качества конечного продукта, снижению проектных рисков в условиях неопределённости и развитию команды. Рост команды, работающей над крупным проектом, непременно ведёт к изменению организации рабочего процесса. Некогда успешные решения могут вызывать множество проблем, а техники стать неэффективными [2]. Необходимо вовремя идентифицировать проблему и изменить рабочий процесс. В статье описаны шаги, которые предпринимали разработчики региональной информационно-аналитической системы ЖКХ Ульяновской области (РИАС ЖКХ УО) для того, чтобы наладить процесс разработки системы.
Всех участников проекта РИАС можно разделить на несколько команд:
• сопровождения;
• интеграции с внешними информационными системами;
• контроля качества.
Команда сопровождения состоит из двух бакалавров-выпускников и двух магистрантов УлГТУ, из которых один является старшим разработчиком. Под сопровождением системы понимается разработка новой и доработка существующей функциональности системы под нужды заказчика.
© Тронин В. Г., Моисеев В. В., Храмков Е. М., 2016
Команда интеграции состоит из двух магистрантов, один из которых старший разработчик, и бакалавра-четверокурсника УлГТУ. Под интеграцией с внешними системами понимается разработка модулей взаимодействия, отвечающих за синхронизацию данных в РИАС и внешних информационных системах, таких как государственная информационная система ЖКХ (ГИС ЖКХ) и портал «Реформа ЖКХ».
Отдел контроля качества состоит из трёх человек и занимается тестированием системы, общением с заказчиком и системной аналитикой.
Предпосылки реформ
В процессе разработки РИАС команда сопровождения столкнулась с множеством трудностей, которые требуют незамедлительных решений. Условно эти проблемы можно разделить на несколько категорий: проблемы взаимодействия с заказчиками, проблемы качества написания исходных текстов РИАС, отсутствие коллективного духа и желания работать.
Проблемы взаимодействия с заказчиками в основном, возникают из-за отсутствия чётких регламентов взаимодействия, что приводит к проблемам при постановке задач заказчиком. Все задачи заказчика, как принято, являются срочными и нужны ему «вчера». За счёт этого на выходе получается некачественный продукт, так как невозможно в сжатые сроки выполнить и протестировать задачу. Описание задач от заказчика в большинстве случаев является неполным, так как он сам не всегда понимает, что ему требуется. По этой причине аналитикам приходится додумывать, что в конечном итоге необходимо сделать для реализа-
ции задачи. Как правило, всё это приводит к многочисленным конфликтам и недовольству заказчика из-за несоответствия полученного продукта ожиданиям. Аналогичные сложности возникают из-за отсутствия актуального технического задания на разработку РИАС и актуальной документации по использованию системы.
Проблемы с качеством написания исходных текстов ПО появились по нескольким причинам. Большинство разработчиков системы являются студентами, поэтому не каждый разработчик имеет высокую квалификацию. Качество написания кода сильно меняется от одного разработчика к другому из-за отсутствия единого стиля программирования. Из-за отсутствия как такового процесса обучения разработчики сразу начинают работу с мелких задач в коммерческом продукте, что также приводит к некачественному коду. В дополнение ко всему вышеперечисленному, код, написанный новичками и младшими разработчиками, зачастую публикуется клиенту без какого-либо контроля старших разработчиков и командного лидера, что нередко приводит к тому, что некогда работающий модуль стал работать некорректно. В совокупности с отсутствием полного системного тестирования всё это приводит к некачественному продукту на выходе и недовольству заказчика.
Все перечисленные проблемы являются рисками, непосредственно влияющими на проект и требующими управления для обеспечения достижения целей проекта [3].
Внедрение изменений в рабочий процесс
Первым шагом к началу внутренних административных реформ послужили многочисленные жалобы заказчиков на некорректно работающие модули системы, что произошло из-за низкого качества исходных текстов и плохого описания задач. Остро встал вопрос повышения качества исходного текста. В ноябре 2015 года было принято решение ввести в процесс разработки ревью (просмотр) кода. Под термином «ревью» понимается проверка старшим разработчиком исходного кода, написанного другим разработчиком, перед сдачей задачи отделу контроля качества. Вначале введение ревью кода снизило общую производительность, при этом сильно повысилось качество кода, написанного новичками и младшими разработчиками.
Одновременно с введением ревью началось описание регламентов общения с заказчи-
ками и описания задач, а также программа роста квалификации разработчиков. Одним из пунктов в программе роста разработчиков было обучение ревью кода. Для обучения ревью была введена балльная система. Младшие разработчики, которые были заинтересованы в росте своей квалификации, начали проводить ревью за другими разработчиками, которое в дальнейшем проверялось одним из старших разработчиков. После проверки младший разработчик получал различное количество баллов как в плюс, так и в минус. После достижения определённого порога младшему разработчику разрешалось проводить ревью самостоятельно, без последующей перепроверки старшим разработчиком.
В течение месяца ревью кода стало обыденным явлением, производительность вернулась на прежний уровень, а изменение процедуры привело к улучшению качества исходного текста. Одним из положительных эффектов введения ревью оказалось то, что младшие разработчики, начав проводить ревью исходного текста, написанного другими разработчиками, стали видеть типичные ошибки и старались не повторять их. В дальнейшем появился регламент, описывающий типичные ошибки, который пополняется до сих пор. В совокупности с новыми регламентами, которые так же были описаны и опробованы в течение первого месяца, качество продукта стало выше, но этого было всё так же недостаточно, так как в системе оставалось большое количество ошибок.
Вторым шагом было изменение регламентов и договорных отношений с клиентами и внесение изменений в регламенты взаимодействия с заказчиками. В декабре 2015 года важной задачей было донести до заказчика, что минимальные сроки выполнения задачи -2 недели. В это время включено первоначальное согласование задачи с заказчиком, проводящееся до полного понимания требуемой функциональности, разработка и качественное тестирование. К концу года новые сроки по выполнению задач всё-таки были приняты. С новыми сроками задач качество продукта стало выше, но всё же ещё осталось достаточно много ошибок при увеличивающемся количестве задач. Данные изменения соответствуют таким элементам Scrum, как Backlog - формирование перечня задач по проекту, Sprint - реализация выбранных задач без отвлечения разработчиков в течение фиксированного интервала времени [1].
Третьим шагом, который длился весь январь 2016 года, было внедрение ежедневного планирования задач (летучек) и еженедельного обсуждения проблем и ошибок, возникающих в процессе разработки и сопровождения ПО. Это помогло снизить нагрузку и расширить горизонт планирования задач. Данное изменение в терминологии Scrum именуется daily meeting.
Четвёртым шагом, который начался в феврале 2016 года и длится до сих пор, стало внедрение системы версий продукта. Система версий должна решить три важных задачи:
• повышение качества продукта за счёт внедрения полного системного тестирования перед релизом новой версии;
• снижение количества непроверенного кода в версии RC (Release Candidate), соответственно снижение потенциально неработающих модулей, которые могут быть выложены заказчику;
• введение еженедельного планирования задач (спринты по методологии Scrum) с последующим расширением срока планирования до месяца.
Также в рамках четвёртого шага были созданы тестовые развёртки РИАС ЖКХ всем клиентам, чтобы они могли убедиться в корректности работы системы перед публикацией продукта в промышленную эксплуатацию.
На данный момент система версий уже хорошо зарекомендовала себя и значительно снизила количество ошибок системы за счёт полного тестирования. За 3 месяца было выпущено 5 версий продукта, и количество жалоб, поступающих от заказчиков на ошибки системы, значительно уменьшилось.
Третьим и четвёртым шагом команды разработки подходят к введению методологии управления проектами Scrum. Осуществляется переход от спиральной модели разработки к движению по спринтам (sprint). В каждой команде происходят ежедневные совещания (daily meeting), в конце запланированного интервала происходит ретроспектива, на которой старшие разработчики делятся проблемами и приобретённым опытом в управлении командами.
В планах на будущее стоят задачи: внедрения частных технических заданий на разработку нового функционала системы, что поможет приносить дополнительную прибыль компании, реализовать автоматизированное системное тестирование, которое должно полностью покрывать тестами весь функционал системы.
Результаты изменений рабочего процесса
Результаты изменений приведены в графическом виде с наглядным отображением, как вышеописанные изменения повлияли на рабочий процесс и на качество продукта в целом. Данные для статистики были получены из системы учёта заданий Redmine, которая используется участниками проекта для контроля выполнения задач. Redmine — открытое серверное веб-приложение для управления проектами и задачами (в том числе для отслеживания ошибок). Redmine написан на Ruby и представляет собой приложение на основе широко известного веб-фреймворка Ruby on Rails. Распространяется согласно GNU General Public License. Использование системы управления проектом позволило организовать качественный мониторинг за ходом выполнения проекта и количественно отслеживать качество принимаемых проектных решений. На рисунке 1 представлено количество задач, вернувшихся к доработке после внутреннего тестирования с группировкой по месяцам за последний год работы над системой.
По рисунку видно, что наибольшее количество задач вернулось к доработке в ноябре 2015 года, что потребовало принятия оперативных мер по улучшению качества разрабатываемого продукта. После ноября количество вернувшихся задач стало значительно уменьшаться, что положительно сказывается на процессе разработки. Это связано с введением в процесс разработки ревью кода, которое помогло значительно повысить качество исходного кода, и, соответственно, разрабатываемого продукта.
На рисунке 2 представлено количество задач, вернувшихся к доработке после тестирования задач с группировкой по месяцам за последний год работы над системой.
Отметим, что наибольшее количество задач вернулось к доработке в сентябре 2015 года, затем наблюдается небольшой спад, и в ноябре снова рост количества вернувшихся задач. После ноября следует описание точных регламентов и улучшение качества разрабатываемого продукта, количество вернувшихся задач стало уменьшаться. С одной стороны, это связано с введением в процесс разработки всё того же ревью кода, с другой - за счёт более корректного описания задач заказчика, связанного с появлением чётких регламентов описания задач и изменением договорных отношений с заказчиком, которое позволило увеличить сроки ожидания выполнения задачи.
Рис. 1. Количество задач, вернувшихся к доработке после внутреннего тестирования по месяцам
б
Рис. 2. Количество задач, вернувшихся к доработке после тестирования заказчиком по месяцам
250
50 О
Апрель Май Июнь Июль Август Сентябрь Октябрь Ноябрь Декабрь Январь Февраль Март Апрель ZD15 2015 2015 2015 2015 2D15 2015 2015 2015 2016 2016 201Ь 2016
Рис. 3. Общее количество закрытых задач по месяцам
Это изменение соответствует принципу гибких методологий - лучше качественный продукт, чем строгое соответствие формальным требованиям по срокам.
На рисунке 3 представлено общее количество закрытых задач с группировкой по месяцам за последний год работы над системой.
По данному рисунку также можно отследить, что количество ежемесячно закрываемых задач постепенно растёт. Спад количества закрытых задач обусловлен новогодними праздниками и зимней сессией, так как большинство разработчиков системы являются студентами УлГТУ.
Выводы
Работа над региональной информационной системой принесла участникам много опыта как с технической точки зрения, так и с точки зрения методов управления проектом. При разработке, длящейся более года, были опробованы многие решения по организации рабочего процесса. Положительным эффектом проведённых изменений стало более эффективное взаимодействие между участниками разработки. Если кратко резюмировать полученный опыт по управлению проектами, можно сделать следующие выводы:
• изменение организации рабочего процесса неизбежно при работе с большим проектом и при растущем количестве заказчиков;
• невозможно в максимально сжатые сроки реализовать продукт высокого качества;
• работа без чётких регламентов становится практически неконтролируемой;
• между этапом разработки и этапом передачи на тестирование задачи должен быть дополнительный этап, на котором устраняются типичные ошибки разработчиков;
• без системы версий и полного системного тестирования невозможно контролировать качество продукта;
• реализованы некоторые элементы управления рисками;
• применение элементов гибкой методологии разработки возможно проводить постепенно с повышением качества (backlog, sprint, повышение прозрачности и качества обмена данными внутри команды, daily meeting, ретроспектива).
СПИСОК ЛИТЕРАТУРЫ
1. Сазерленд Д. Scrum. Революционный метод управления проектами. - М. : МИФ, 2015. -288 с.
2. Брукс Ф. Мифический человеко-месяц, или Как создаются программные. - СПб. : Символ-плюс, 2000. - 150 с.
3. Тронин В. Г., Галныкина К. С., Стенина А. С. Математические методы анализа рисков в инновационных проектах // Вестник Ульяновского государственного технического университета. - 2015. - №1(69). - С. 48-56.
Тронин Вадим Георгиевич, кандидат технических наук, начальник научно-исследовательского отдела УлГТУ, доцент кафедры «Информационные системы». Сфера научных интересов - наукометрия, моделирование вычислительных сетей на прикладном уровне, технологии эффективного управления. Моисеев Владислав Валерьевич, магистрант УлГТУ.
Храмков Евгений Михайлович, магистрант УлГТУ.
Поступила 07.06.2016 г.
