75
руководством компании в виде Регламента предоставления сервиса.
Соглашение подписывается на уровне всей организации.
Процедура изменения спецификации и SLA
В случае необходимости внесения изменений в Спецификацию или
Соглашение необходима процедура согласования, описанная выше.
Инициацию внесения изменений могут производить пользователи,
заказчик или ИТ отдел. Рассмотрение предложений должно быть
осуществлено не более чем в 30-дневный срок.
Процедура инициации поставки сервиса
В случае необходимости предоставления сервиса новому пользователю
руководитель его подразделения инициирует стандартный запрос на
обслуживание «Установка нового рабочего места» согласно
утвержденным правилам.
Процедура информирования об инцидентах
В случае возникновения инцидента пользователь сообщает об этом
сотруднику ИТ отдела в соответствие с утвержденными правилами.
Процедура запроса на изменение
В случае необходимости внесения изменений пользователь обращается
в ИТ-отдел с запросом, согласно утвержденным правилам.
Так же компании ЗАМПА предложено составить и утвердить основные
документы, регламентирующие работу ИТ-подразделения компании. В
данном случае таковыми являются: Регламент использования ИТ-ресурсов в
компании, регламент использования доступа в глобальную сеть Интернет,
положение по ИТ-подразделению компании.
Ознакомится с разработанными и предложенными вариантами
документов можно в Приложениях 3 и 4 соответственно.
76
Использование сервисного подхода и использование понятных и
измеримых показателей качества оказания ИТ-услуг ИТ-подразделением
бизнесу, способно разрешить возникшие проблемы во взаимоотношениях
бизнеса компании и ИТ-подразделения в самые кротчайшие сроки с момент
начала использования такого подхода.
Подготовительный этап к переходу на сервисную модель услуг был
оценен в 3 месяца. Этап внедрения и пилотного использования данного
подхода – 1 месяц. Переход на сервисную модель не имеет рисков простоя
предприятия.
3.4 Организация процесса разработки ПО в компании
Для решения проблем в компании ЗАМПА, связанных с разработкой
программного обеспечения, а именно проблем с частыми срывами сроков
разработки и поставки нового или измененного функционала конечным
пользователям (time 2 market), недопониманием бизнеса процесса разработки
и возникновения конфликтных ситуаций с разработчиками и ИТ-директором
компании, выработано предложение по организации процесса разработки
программного обеспечения в компании с применением гибких методологий
разработки, а именно использование Scrum, на основе принципов Agile.
Описание данных подходов дано в Главе 1 данной работы.
Схема процесса приведена на Рисунке 6
14
14
Neon Rain interactive – Agile for all
https://www.neonrain.com
77
Рисунок 6 Схема процесса разработки ПО в SCRUM
В Scrum подходе существует 3 основных роли:
Product owner (Владелец продукта);
Scrum master;
Команда разработки (Development team);
Product owner (PO) является главным связующим звеном между
командой разработки и заказчиком. Основная задача владельца продукта,
это максимальное и эффективное увеличение бизнес ценности находящегося
в разработке продукта и работы команды.
Заказчиком продукта на рассматриваемом предприятии является один
из управляющих партнеров. Владельцем продукта предлагается назначить
ИТ-директора компании.
Одним из основных инструментов владельца продукта является Product
Backlog (бэклог продукта). Product Backlog содержит все необходимые для
выполнения задачи и требования (например пользовательские истории,
78
найденные дефекты, отдельные задачи и др.), отсортированные в порядке их
приоритета и срочности.
Scrum master (SM) в процессе Scrum по сути является «служащим
лидером» (англ. servant-leader). Задача Scrum Master — осуществлять помощь
команде и максимально увеличивать ее эффективность через устранение
препятствий для работы, решении коммуникационных проблем, помощи в
обучении и мотивации команды, помощи PO, проведении основных
«ритуалов» Scrum, таких как ретроспективы, планирования и т.д.
Scrum Мастером предлагается назначить ИТ-менеджера компании (данная
позиция должна быть введена в штатное расписание компании. Предложение
по модернизации штатной структуры ИТ-подразделения будет дано ниже)
Команда разработки (Development team, DT) состоит из специалистов,
производящих разработку и другие работы над продуктом. В соответствии с
The Scrum Guide
15
(документу, являющимся официальным описанием Scrum
от его авторов), DT обязаны обладать такими качествами и
характеристиками:
Команда должна быть самоорганизующейся. Никто (включая SM и PO)
не может указывать команде каким образом и посредствам каких
технологий преобразовать Product Backlog в работающий продукт;
Команда должна быть многофункциональной, обладать всеми
необходимыми навыками и знаниями для выпуска работающего
продукта;
За выполняемую работу отвечает вся команда, а не индивидуальные
члены команды
15
The Scrum Guide 2017
https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Russian.pdf
79
Рекомендуемый размер команды — 7 (плюс-минус 2) человек. Согласно
идеологии Scrum, команды большего размера требуют слишком больших
ресурсов на коммуникации, в то время как команды меньшего размера
повышают риски (за счет возможного отсутствия требуемых навыков) и
уменьшают размер работы, который команда может выполнить в единицу
времени.
16
Основой Scrum является Sprint, в рамках и течении спринта выполняется
работа над продуктом. По окончанию спринта должна быть получена новая
рабочая версия продукта. Sprint всегда ограничен по времени (1-4 недели) и
имеет одинаковую продолжительность на протяжении все жизни продукта.
Перед началом каждого спринта необходимо производить планирование
спринта с участием всей команды, на котором будет производиться оценка
содержимого бэклога продукта и формирование бэклога спринта, который
будет содержать задачи, которые должны быть выполнены в текущем
спринте. Каждый спринт должен иметь цель, которая является
мотивирующим фактором и достигается с помощью выполнения задач из
бэклога спринта. (например, реализация определенного функционала,
улучшения стабильности и исправления дефекта приводящего к негативным
отзывам пользователей и т.п.).
Каждый день необходимо проводить Daily Scrum meeting (ежедневную
короткую, не более 15 – 30 минут встречу всех участников процесса), на
которой каждый член команды отвечает на вопросы «что я сделал вчера?»,
«что я планирую сделать сегодня?», «какие препятствия на своей работе я
встретил?». Задача этой встречи - определение статуса и прогресса работы
над продуктом в рамках текущего спринта, раннее обнаружение возникших
препятствий и проблем, выработка и принятие решений по изменению
стратегии в случае серьезных изменений или других факторов, оказавших
16
The Scrum Guide. The definitive Guide to Scrum: The Rules of the Game. (Ken Schwaber, Jeff
Sutherland)
80
влияние на ситуацию, и других необходимых решений для достижения целей
спринта.
По окончанию спринта проводится демонстрация продукта заказчику
(роли стейкхолдеров рекомендуется дать управляющим партнерам, как
лицам, получающим бизнес выгоду от продукта) в рамках которой
демонстрируются результаты спринта бизнесу. После проведения
демонстрации, проводится ретроспектива спринта, в которой участвуют все
участники процесса, задача ретроспективы оценить эффективность
(производительность) команды в прошедшем спринте, спрогнозировать
ожидаемую эффективность в следующем спринте, выявить и обсудить
имеющиеся проблемы, оценить вероятность завершения всех необходимых
работ по продукту в будущем и другое. Повестка ретроспектив является
очень гибким инструментом.
Для автоматизации процесса учета работ, задач, планирования и
управления ресурсами рекомендуется использовать уже имеющуюся в
компании автоматизированную систему JIRA. Для создания и ведения базы
знаний по проектам – рекомендуется приобрести и установить программное
решение Confluence, которое производится той же организацией что и JIRA
(компания Atlassian) и легко интегрируется с ней.
Перед непосредственным завершением работы над задачами спринта, их
реализация должна быть протестирована, т.е. проверена на соответствие
требуемым параметрам качества. Предложение по организации тестирования
будет дано ниже, в параграфе 3.5 данной работы.
Технически, процесс разработки в компании, можно представить схемой,
представленной на рисунке 7.
81
Рисунок 7 Техническая схема разработки по в SCRUM
Так же, с учетом того, что разработчики компании имеют
определенные специализации, и с учетом того, что основной продукт
компании состоит из серверного решения, клиентского решения и большой
поддерживаемой базы данных, выработано предложение разделить
разработчиков на 3 команды, что полностью укладывается в рекомендации
Scrum. В каждой команде предложено определить роль лидера команды
(Team Lead), являющегося ведущим команды, с точки зрения технического
профессионального опыта.
Для лучшей мотивации разработчиков компании, и в связи с
появлением новых зон ответственности, таких как владелец продукта, скарм-
мастер, тестирование, а так же по причине изменения принципов работы ИТ-
подразделения на сервис-ориентированный подход, выработано предложение
по изменению штатной структуры ИТ-подразделения и введения новых
позиций. Новое предложенное штатное расписание представлено на Рисунке
8.
82
1 штатная позиция
Системный
администратор
2 штатных позиции
Специалист
технической
поддержки
1 штатная позиция
ИТ - Директор
17 штатных позиций
Программист
Управляющий партнер
3 штатных позиции
Ведущий
программист
3 штатных позиции
Специалист по
тестированию
1 штатная позиция
ИТ-Менеджер
Рисунок 8 Новая структура штата ИТ-подразделения
Новое штатное расписание ИТ-подразделения позволит «разгрузить»
позицию ИТ-директора от операционной нагрузки, которая возрастет при
переходе на сервисную модель обслуживания бизнеса и переводе
активностей разработки программного обеспечения на гибкую методологию
разработки.
Изменение трех позиций штатных разработчиков на позиции ведущих
разработчиков, позволит повысить мотивацию разработчиков, определить
трех лидеров команд. Эти три позиции должны определять увеличенную
ответственность сотрудников, но и иметь большую денежную компенсацию.
Ввод новых позиций специалистов по тестированию обусловлен
введением процесса тестирования и управления качеством в ИТ-
подразделении.
Финансовый отдел предприятия совместно с управлением предприятия
провели оценку предложения по вводу новых штатных позиций и
пересмотром имеющихся. Дана положительная оценка данному
предложению, так как финансовые затраты на новое штатное расписание ИТ-
подразделения способны значительно уменьшить риски связанные с
разработкой программного обеспечения, в особенности репутационные
83
риски, а так же уменьшить количество жалоб пользователей программных
продуктов.
3.5 Организация процесса управлением качества ПО в компании
Так как ИТ-подразделение компании ЗАМПА ставит перед собой
одной из целей создание качественного программного обеспечения, при этом
работая в реалиях гибкой методологии разработки программного
обеспечения, классические подходы к обеспечению качества ПО не могут в
полной мере удовлетворить требования к оперативности проведения
мероприятий по контролю и управлению качеством ПО.
В связи с этим, ИТ-подразделению предложено использовать сочетание
статического анализа кода разрабатываемого ПО, юнит-тестирования кода,
тестирования нового функционала посредством анализа требований
(пользовательских историй) и регрессионного тестирования. Данный подход
находит свое подтверждение в том числе и опираясь на «Пирамиду
тестирования» (Рисунок 9), согласно которой, самые быстрые и эффективные
тесты – это юнит тесты.
17
Тестирование поведения системы под нагрузкой, в связи со спецификой
разрабатываемых решений компании, не требуется.
17
Mike Cohn “Succeeding with Agile”
84
Рисунок 9 Пирамида тестирования
В качестве статического анализатора кода предложено использовать
программное решение «Sonarqube».
SonarQube измеряет качество программного кода в соответствии с семью
показателями (и соответствующими метриками) качества программного
обеспечения, которые разработчики называют англ. Seven Axes of Quality
18
Потенциальные ошибки;
Стиль программирования;
Юнит тесты;
Повторения участков кода;
Комментарии;
Архитектура и проектирование;
Сложность.
Так, юнит-тесты оцениваются не только с точки зрения успешности
исполнения, но и по тестовому покрытию исходного кода
19
.
Юнит-тестирование (англ. unit testing) – это процесс в программировании,
позволяющий проверить на корректность отдельные модули исходного кода
программы, наборы из одного или более программных модулей вместе с
18
Campbell, Papapetrou, 2013, 1.3. Seven Axes of Quality
19
Campbell, Papapetrou, 2013, 1.3.2. Tests.