ВНЕДРЕНИЕ AGILE ПРОЦЕССОВ НА ПРИМЕРЕ SCRUM

АННОТАЦИЯ

Относительно новые семейства методологий для создания программного обеспечения, называемые Agile Processes, внедряются для решения задач в индустрии информационно-коммуникационных технологий. Эти методологии сосредоточены на гибкости и приспособляемости и описываются как гибкие, в отличие от традиционных процессов, которые имеют ограничения во введении изменений. Применение таких методологий и практик дает возможность снизить риски и повысить качество и удобство использования конечного программного продукта.

Ключевые слова: гибкая модель (agile), scrum.

С течением времени менеджеры проектов пришли к понимаю, что практически невозможно найти такой проект, требования к которому могут быть полностью готовы в самом начале разработки.

Гибкая модель (Agile) описывает поход к разработке программного обеспечения, в соответствии с которым решения принимаются благодаря совместным усилиям многофункциональных команд и их клиентов или конечных пользователей [1]. Использование гибких моделей позволяет осуществлять адаптивное планирование, быструю разработку, постоянное усовершенствование продукта, а также способствует быстрому реагированию на изменения. Применение Agile позволяет максимально быстро начать выполнение проекта, детали же могут быть уточнены в процессе его реализации [2].

В 2001 г. семнадцать разработчиков впервые опубликовали Манифест гибкой разработки, содержащий описание ценностей и принципов гибкой разработки. Ценности гласят, что люди и взаимодействие важнее процессов и инструментов, работающий продукт важнее документации, сотрудничество с заказчиком важнее существующего контракта, готовность к изменениям, важнее изначального плана [3].

Гибкие модели разработки используют итеративно-инкрементный подход. Весь процесс разработки определенного программного продукта разрезается на части (инкременты), что сразу сводит к минимуму время на планирование и проектирование. Итерации (спринты) – это короткие временные рамки, которые обычно длятся от одной до четырех недель. Над каждой итерацией работает мультифункциональная команда, которая занимается планированием, анализом, проектированием, кодированием, тестированием. В конце каждой итерации рабочий продукт демонстрируется заказчикам. Это минимизирует общий риск и позволяет быстро адаптироваться к изменениям [4]. Во время итерации необязательно добавляется какая-то значительная функциональность, цель стоит в выпуске качественной продукции с минимально возможным количеством дефектов. Для выпуска целого программного продукта может потребоваться несколько итераций [5].

На данный момент существует много методологий, которые можно отнести к семейству гибких методологий, например, DSDM, XP, FDD, Lean, Kanban, Scrum и т.д. Далее будут рассмотрены самые популярные гибкие методологии.

Манифест гибкой разработки предоставляет ценности и принципы, однако не дает конкретных указаний, как их применять. Организации обычно ищут более специфичные методологии внутри Agile-движения. Одной из самых используемых в мире гибких методологий является Scrum.

Методология Scrum предполагает наличие трех основных ролей на проекте по разработке программного продукта: владелец продукта (product owner), скрам-мастер (scrum master) и команда разработки (development team) [6].

Владелец продукта обычно представляет интересы заказчика или конечного пользователя и отвечает за то, что разрабатываемый функционал принесет ценность для бизнеса. Он ведет коммуникацию между всей командой и заказчиком, организует совещания, приоритезирует задачи команды.

Команда разработки обычно состоит из бизнес-аналитиков, разработчиков и тестировщиков. Команда отвечает за создание качественного программного продукта в определенный срок.

Скрам-мастер следит за тем, чтобы у команды разработки не возникло никаких проблем или задержек, за тем, что команда точно выполняет постав¬ленные задачи и укладывается в срок. Его основная роль – контроль выполнения всех основных процессов методологии Scrum.

Разработка проекта по методологии Scrum начинается со стартового совещания (kick-off meeting). Его основные цели:

– обзор проекта;

– определение команды разработки;

– создание бэклога проекта;

– определение главных задач на ближайшую фазу разработки.

Бэклог (backlog) – это список всех функциональностей, которые должны быть разработаны для данного проекта. Функциональность в бэклоге обычно называют пользовательской историей (user story). Пользовательская история обычно имеет структуру: «Будучи пользователем [тип пользователя] я хочу сделать [действие], чтобы получить [результат]» [7].

После того как все пользовательские истории помещены в бэклог, они ранжируются в порядке приоритета. Иногда в этом случае происходит группировка историй, так как разработка одних невозможна без существования других. После каждого спринта бэклог пересматривается и приоритеты могут быть изменены. Более того, после каждого спринта возможно добавление новых историй в бэклог. Длина спринта для методологии Scrum обычно равна двум неделям.

Для того чтобы определить, что можно сделать в спринте необходимо оценить, сколько по времени займет разработка одной пользовательской истории. Однако из-за того, что иногда очень сложно оценить в часах время на разработку одной крупной функциональности, оценка проходит в относительных единицах сложности (story points). Каждой функциональности присваивается значение до трех единиц, так как считается, что с этой цифрой легко проводить сравнение. Если же при оценке команда считает, что на разработку функциональности уйдет больше трех единиц, то это означает, что пользовательскую историю нужно поделить на более мелкие истории [8].

Также важно определить скорость команды (team velocity), работающей над спринтом. Скорость определяется количеством поинтов, за которое команда может закончить спринт. Ее можно узнать, посмотрев на результаты предыдущих спринтов. Данная метрика помогает команде понять, сколько пользовательских историй она может сделать за один спринт [9].

Каждый день команда разработки проводит совещание, длиной не более пятнадцати минут, где каждый участник команды отвечает на вопросы о том, что было сделано вчера, что будет сделано сегодня и что блокирует выполнение работы [10].

В конце каждого спринта проводится еще одно совещание – ретроспектива. Каждый член команды отвечает на вопросы о том, что было хорошо, что было плохо и как улучшить работу команды в следующем спринте.

Таким образом по методологии Scrum главным залогом успеха команды является хорошая коммуникация между всеми членами команды и качественное планирование нагрузки команды.

Все основные процессы модели Scrum: создание бэклога, планирование спринта, выполнение спринта, обзор спринта и ретроспектива, после которой снова начинается процесс планирования спринта.

Список литературы:

1. Николаенко, В С. Разработка принципов управления ИТ-проектом / В.С. Николаенко // Вестник Томского государственного университета. – 2015. – № 390. – С. 155–160.
2. Деева, Н.В. Гибкие методологии как метод практико-ориентированного подхода при подготовке студентов технических специальностей / Н.В. Деева // Гродненский государственный университет имени Янки Купалы – 2014. – № 3. – С. 104.
3. Двенадцать принципов Agile разработки / Кент Бек [и др.] // Agile-манифест разработки программного обеспечения. – Уосотч, 2001. – 10 c.
4. What is Agile model – advantages, disadvantages and when to use it? / ISTQB Foundation Level and Agile Tester Certification guide [Electronic resource]. – 2013. – Mode of access: http://istqbexamcertification.com/what-is-agile-model-advantages-disadvantages-and-when-to-use-it/. – Date of access: 18.04.2020.
5. Moran, A. Agile Risk Management / A. Moran. – Cham: Springer, 2014. – 101 p.
6. Карпов, Д.В. Гибкая методология разработки программного обеспечения / Д.В. Карпов // Вестник Нижегородского университета им. Н. И. Лобачевского. – 2011. – № 3. – С. 228–229.
7. Schwaber, K. The Scrum Guide / K. Schwab. – Springfield: ScrumOrg, 2013. – 16 p.
8. Leybourn, E. Introduction to Scrum / E. Leybourn. – New York: Attribution-ShareAlike, 2014. – 16 p.
9. Deemer, P. A lightweight guide to the theory and practice of scrum / P. Deemer. – San Francisco: InfoQ Enterprise Software, 2012. – 20 p.
10. Kniberg, H. Kanban vs Scrum / H. Kniberg. – San Francisco: InfoQ Enterprise Software, 2011. – 41 p.