25
спад, а качество ИТ-услуг, предоставляемых британскому правительству
различными поставщиками, было настолько низким, что существовавшее
тогда Центральное агентство по вычислительной технике и
телекоммуникациям (Central Computer and Telecommunications Agency,
CCTA, в настоящее время именуемое Office of Government Commerce, OGC)
получило от правительства этой страны указание разработать принципы
эффективного и рентабельного использования ИТ-ресурсов в министерствах
и других государственных учреждениях и уже на их основе формировать
подход к оказанию ИТ-услуг, не зависящий от их поставщика. Результатом
проведенных работ стала библиотека ITIL, объединившая описание лучших
методов, существовавших в индустрии ИТ-услуг.
5
Последняя версия
методологии ITIL v3 была выпущена в 2011. Она включает в себя пять книг,
которые разделены по принципу этапов жизненного цикла услуги:
Service Strategy (Стратегия для ИТ-услуг)
6
SS – этап жизненного цикла, основной которого является сочетание
четырех элементов: перспективы, текущей позиции, планов и моделей
спроса. На этом этапе производится анализ и оценка рынка, возможностей на
нем и поиск путей развития. Стратегия для ИТ-услуг включает в себя
следующие процессы: управление стратегией ИТ-услуг, управление
портфелем ИТ-услуг, управление ИТ-финансами, управление спросом на ИТ,
управление взаимоотношениями между ИТ и Бизнесом;
Service Design (Проектирование ИТ-услуг)
7
SD базируется на технологии, людях, партнерах и процессах. На этом
этапе проектируется, редактируется ИТ-услуга в соответствии с
требованиями бизнеса. Проектирование ИТ-услуг делится на следующие
процессы: координация проектирования ИТ-услуг, управление каталогом
ИТ-услуг, управление уровнями обслуживания, управление мощностями,
5
Компьютер пресс, Что такое ITIL
https://compress.ru/article.aspx?id=16572
6
«ITIL Service Strategy» («Стратегия сервиса»), ISBN 978-0-11-331045-6
7
«ITIL Service Design» («Проектирование сервиса»), ISBN 978-0-11-331047-0
26
управление непрерывностью, управление достижимостью, управление
информационной безопасностью, управление поставщиками;
Service Transition (Внедрение ИТ-услуг)
8
ST отвечает за внедрение ИТ-услуг, в рамках него находится
планирование мощностей и ресурсов в соответствии с требованиями бизнеса,
внедрение изменений. На этом этапе жизненного цикла услуги определены
такие процессы, как: планирование и поддержка внедрения, управление
изменениями, управление релизами, управление конфигурациями и ИТ-
активами, управление тестированием, управление знаниями;
Service Operation (Поддержание ИТ-услуг)
9
В SO рассматривается «видимая» часть СУИС, на этом этапе
предусмотрено наибольшее взаимодействие с пользователем. Ключевыми
объектами этого этапа являются технология, сервис, люди и процессы.
Только на этом этапе появляется понятие функции. Под функцией здесь
имеется в виду подразделение и его инструментарий, которые используются
для выполнения работ и достижение цели, количественных и качественных
результатов. Процессы, поддерживающие ИТ-услуги: управление
инцидентами, управление запросами, управление событиями, управление
проблемами и управление доступом. Функциями системы является Service
Desk, Technical management, Application management и IT-operational
management, последняя из которых делится на IT Operations control и
Facilities management;
Service Implementation (Непрерывное совершенствование ИТ-
услуг)
10
SI обуславливает постоянное изменение ИТ-услуг в соответствии с
требованиями бизнеса. Здесь важную роль играют KPI.
8
«ITIL Service Transition» («Передача сервиса»), ISBN 978-0-11-331048-7
9
«ITIL Service Operations» («Эксплуатация сервиса»), ISBN 978-0-11-331046-3
10
«ITIL Continual Service Improvement» («Постоянное улучшение сервиса»), ISBN 978-0-11-331049-4
27
В 2018 году ожидался выход обновления ITIL, версии 4, но на момент
написания данной работы обновление так и не вышло. По информации из
различных источников, можно предположить, что дата выхода обновления
будет в первом квартале 2019 года.
1.3 Подходы к разработке ПО – Scrum и Agile
Что такое Agile? Как и другие популярные методологии разработки
и управления проектами, Agile появился сравнительно недавно в США.
За появление гибкой методологии разработки ответственна сразу целая
группа людей — 17 американских IT-специалистов из штата Юта. Вместе
с «Манифестом гибкой разработки ПО», принятым в феврале 2011 года,
в котором впервые прозвучал термин «Agile» они прописали 12 принципов
Agile-разработки:
11
Удовлетворение потребностей клиента за счёт ранней и
бесперебойной поставки ценного программного обеспечения;
Приветствие изменений требований даже в конце разработки
(это может повысить конкурентоспособность полученного
продукта);
Частая поставка рабочего программного обеспечения (каждый
месяц или неделю или ещё чаще);
Тесное, ежедневное общение заказчика с разработчиками на
протяжении всего проекта;
Проектом занимаются мотивированные личности, которые
обеспечены нужными условиями работы, поддержкой и
доверием;
Рекомендуемый метод передачи информации — личный
разговор (лицом к лицу);
11
Agile manifesto
http://agilemanifesto.org/principles.html
28
Работающее программное обеспечение — лучший измеритель
прогресса;
Спонсоры, разработчики и пользователи должны иметь
возможность поддерживать постоянный темп на
неопределённый срок;
Постоянное внимание улучшению технического мастерства и
удобному дизайну;
Простота — искусство не делать лишней работы;
Лучшие технические требования, дизайн и архитектура
получаются у самоорганизованной команды;
Постоянная адаптация к изменяющимся обстоятельствам.
Команда должна систематически анализировать возможные
способы улучшения эффективности и соответственно
корректировать стиль своей работы
Так же было сформулировано 5 основных идей Agile:
Люди и взаимодействие важнее процессов и инструментов;
Работающий продукт важнее исчерпывающей документации;
Сотрудничество с заказчиком важнее согласования условий
контракта;
Готовность к изменениям важнее следования первоначальному
плану.
В свою очередь, на базе Agile, появилась такая методология разработки
программного обеспечения, как Scrum.
Scrum - методология гибкой разработки на основе Agile, в основе
которой лежит «спринт» — отрезок от 1 до 4 недель, по окончанию которого
должна быть получена рабочая версия продукта.
29
Scrum (Sprint Continious Rugby Unified Methodology
12
) — это набор
принципов, ценностей, политик, ритуалов, артефактов, на которых строится
процесс SCRUM-разработки, позволяющий в жестко фиксированные и
небольшие по времени итерации, называемые спринтами (sprints),
предоставлять конечному пользователю работающий продукт с новыми
бизнес-возможностями, для которых определен наибольший приоритет.
Методология основана на тактиках и стратегиях из регби и бега на короткие
дистанции (спринта), с помощью различных артефактов и «ритуалов»
Возможности к реализации в очередном спринте определяются в начале
спринта на совещании команды и планирования методом Planning Poker
(каждый член команды, оценивает каждую задачу с точки зрения своей
квалификации и опыта. Общая оценка являет собой усредненное значение
всех оценок в команде. Для демонстрации оценки используются карты с
числом условных баллов-трудозатрат (стори-поинт) – отсюда происходит
название связанное с покером, так как процесс напоминает игру в покер) и не
могут изменяться на всем его протяжении. При этом строго фиксированная
небольшая длительность спринта придает процессу разработки
предсказуемость и гибкость.
Спринт - итерация в scrum, в ходе которой создается инкремент бизнес-
продукта. Жестко фиксирован по времени. Длительность одного спринта от 1
до 4 недель. Чем короче спринт, тем более гибким является процесс
разработки, релизы выходят чаще, быстрее поступают отзывы от
потребителя, меньше времени тратится на работу в неправильном
направлении. С другой стороны, при более длительных спринтах scrum-
команда уменьшает издержки на совещания, демонстрации продукта и т. п.
Разные команды подбирают длину спринта согласно специфике своей
работы, кросс-функциональности команд и требований, часто методом проб
12
Кочешков Андрей, Публикация в журнале «Финансовый директор» - «Все что вам нужно знать про
методологию SCRUM»
https://fd.ru/articles/158926-metodologiya-scrum-17-m11
30
и ошибок. Для оценки объема работ в спринте можно использовать
предварительную оценку, измеряемую в очках истории. Предварительная
оценка длины спринта фиксируется в бэклоге проекта.
Наиболее популярными «ритуалами» в процессе разработки с
использованием данной методологии можно назвать:
Планирование спринта с «игрой в покер» - оценкой задач;
Проведение ежедневных коротких встреч участников команд,
длительностью не более 15 – 30 минут, на которых они
озвучивают свои успехи, проблемы, текущие статусы взятых на
себя задач;
Проведение демонстраций результатов спринтов бизнесу;
Проведение расширенных «ретроспектив», встреч как участников
команд, так и бизнеса, на которых обсуждаются успехи и
проблемы возникшие на протяжении спринта.
Груминг бэк-лога «парикмахерская», в рамках данного
«ритуала», задачи в бэк-логе проходят переоценку, уточнение,
что-то может быть исключено и т.п. Список задач проходит
своеобразную «стрижку» для приведения списка задач в
актуальное состояние, порядок.
Наиболее распространенными ролями в scrum командах считаются:
Scrum-мастер: Проводит совещания (Scrum meetings) следит за
соблюдением всех принципов scrum, разрешает противоречия и
защищает команду от отвлекающих факторов, проводит
фасилитацию митингов. Данная роль не предполагает ничего иного,
кроме корректного ведения scrum-процесса.
Владелец продукта: Представляет интересы конечных
пользователей и других заинтересованных в продукте сторон.
31
Стейк-холдеры: Лица, которые инициируют проект (бизнес-
заказчики) и для кого scrum-проект будет приносить выгоду. Они
вовлечены в скрам только во время обзорного совещания по
спринту (ретроспективы).
Scrum-команда, члены scrum-команды: Кросс-функциональная
команда разработчиков проекта, состоящая из специалистов разных
профилей: тестировщиков, архитекторов, аналитиков,
программистов и т. д. Размер команды составляет от 5 до 9 человек.
Команда является единственным полностью вовлеченным
участником разработки и отвечает за результат как единое целое.
Никто, кроме scrum-команды, scrum-мастера и владельца продукта
не может вмешиваться в процесс разработки на протяжении
спринта. Кросс-функциональность команды позволяет максимально
эффективно планировать затраты на реализацию бизнес-требований
и в сжатые сроки поставлять реально работающие бизнес-
приложения в полном соответствии с изменяющимися
требованиями заказчика.
Практически самым главным артефактом в scrum можно назвать бэк-
лог проекта. Бэк-лог представляет собой «хранилище» бизнес и технических
задач, которые должны быть решены в проекте. В него помещаются все
пожелания и требования, приходящие в проект и требующие реализации.
При помещении в бэк-лог такие требования должны быть приоритезированы,
но оценены в разрезе сложности реализации они будут при планировании
спринтов. Именно из бэк-лога, scrum-команда «забирает» требования на
реализацию. Требования и пожелания принято излагать в виде «историй
пользователя», однако это не является обязательным требованием, хотя и
считается очень желательным.
На основе представленной выше информации, можно отнести к
преимуществам гибкой методологии следующие утверждения:
32
Короткие и понятные итерации — циклы разработки длятся от 2
недель до 2 месяцев, по окончанию которых заказчик получает
рабочую версию продукта или рабочий новый или измененный
функционал;
Высокая степень вовлечения исполнителей, организаторов и
заказчиков проекта в процесс. Прозрачность проекта для бизнеса
на всех его стадиях;
Главное, это рабочий продукт как основной показатель прогресса
- это можно рассматривать как плюс, так и минус, ведь в таком
случае к команде проекта выдвигаются высокие требования по
самоорганизации;
Минимизация различных как бизнес, так и технологических
рисков, благодаря гибкой системе внесения изменений.
Однако, можно выделить и ряд недостатков, которые так же следует
принимать во внимание:
Стимулирование постоянных изменений проекта: гибкость
разработки продукта может привести к тому, что он никогда не
дойдёт до финальной версии, в связи с чем, следует особое
внимание уделять критериям завершенности функционала,
реализации требований и т.п.;
Повышенные требования к квалификации и опыту команды:
помимо непосредственно создания продукта команда должна
анализировать возможные способы улучшения эффективности
собственной работы, беспрерывно обмениваться информацией по
проекту, быть мотивированной и самоорганизованной. Далеко не
всегда ресурсы проекта позволяют привлечь таких специалистов;
Философский характер методологии: Agile - это не чёткая
инструкция к действию, а целая философская концепция.
33
Команда не может механически применить механики «гибкой»
разработки, нужно принять ключевые принципы системы;
Сложность подсчёта итоговой суммы работы: стимуляция
изменений и усовершенствования конечного продукта приводит
к плавающему значению стоимости проекта.
Таким образом, изучив идеи, принципы, подходы, положительные и
отрицательные стороны гибкой методологии разработки программного
обеспечения, можно сделать вывод, что Agile и Scrum способны органично
решить задачу «прозрачности» процесса разработки внутри ИТ-
подразделения для бизнеса. И будучи интегрированными в процессы внутри
ИТ-подразделения, данные методологии так же способны «нести» ценность
для бизнеса, как заказчика разрабатываемого продукта, так и для бизнеса, как
пользователя такого продукта.
1.4 Тестирование и управление качеством
Тестирование, QA, QC, качество, его обеспечение в разработке ПО –
эти термины стали популярны в ИТ среде на территории России, да и
глобально - не так уж и давно. Современный рынок стал диктовать новые,
более жесткие требования к качеству программных продуктов, в результате
чего стали активно развиваться практики обеспечения качества
программного обеспечения. И если еще около 10 лет назад, тестировщики и
менеджеры по качеству были редкостью, и позволить их себе могли только
очень большие и богатые корпорации, то на данном этапе развития
информационных технологий и рынка разработки программного
обеспечения, управление качеством и тестирование стали необходимостью.
Обусловлено это тем, что конкурентная среда на рынках ПО и разработки
стала более жесткой, стек используемых технологий разрастается с каждым
годом и самое главное, вопросы удовлетворения клиента и качество
34
выполненной работы стали более бескомпромиссно влиять не только на
прибыль, но и на репутацию как поставщика, так и заказчика, а
следовательно и на их будущее. Вспомните, как вы относитесь к ПО в
мобильном телефоне, которое «падает» в самый ответственный момент.
Купите вы ПО от этого разработчика снова? Закажите вы сайт в той же
студии, результат работы которой стал причиной жалоб клиентов и прямого
убытка?
13
В целом, управление качеством программного обеспечения и
тестирование программного обеспечения строится вокруг трех основных
понятий:
- QA (Quality Assurance) – Обеспечение качества
- QC (Quality Control) – Контроль качества
- Testing - тестирование
Quality Assurance - По сути, непосредственно тестирование и QC
входят в QA. Говоря языком разработчиков - мы наблюдаем инкапсуляцию.
Обеспечение качества - это совокупность мероприятий, покрывающих
все технологические стадии разработки, с момента абстрактной идеи и до
(включая) стадии релиза и эксплуатации ПО в промышленной среде,
направленных на обеспечение качества выпускаемого продукта. Иными
словами, это мозговой центр принятия решений в командах по обеспечению
качества продуктов, контрольный пункт.
Сам процесс обеспечения качества состоит из:
Проверки и аналитики различных спецификаций и требований к ПО.
Оценки рисков и управление рисками в разрезе качества продукта.
13
Сергей Терехов, terekhoff.org, qa-lab.org