ПРОБЛЕМЫ И СПОСОБЫ УЛУЧШЕНИЯ ГИБКОЙ МЕТОДОЛОГИИ РАЗРАБОТКИ SCRUM Текст научной статьи по специальности «Экономика и бизнес»

УДК 33

Экономические науки

Умеренков Даниил Игоревич, магистрант Московский финансово-промышленный университет «Синергия», Экономика и

управление народным хозяйством

ПРОБЛЕМЫ И СПОСОБЫ УЛУЧШЕНИЯ ГИБКОЙ МЕТОДОЛОГИИ

РАЗРАБОТКИ SCRUM

Аннотация: в статье исследуются проблемы методики Scrum и предлагается ряд улучшений для решения этих недостатков. Введение раскрывает актуальность, определяет цель, объект, предмет и методы исследования. В работе проводится анализ предметной области, описываются теоретические основы гибких методологий. Далее раскрываются тонкости работы Scrum, выявляются его особенности в сравнении с методикой Kanban.

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

Ключевые слова: модель управления проектом, Agile, методика, Scrum, разработка программного обеспечения, управление IT-проектом, Kanban, сравнение методик.

Abstract: the article explores the problems of the Scrum methodology and proposes a number of improvements to address these shortcomings. The introduction reveals the relevance, defines the purpose, object, subject and methods of research. The paper analyzes the subject area, describes the theoretical foundations of flexible methodologies. Further, the subtleties of Scrum work are revealed, its features are revealed in comparison with the Kanban methodology.

The conclusion reflects the results of the work done, contains conclusions.

Keywords: project management model, Agile, methodology, Scrum, software development, IT project management, Kanban, method comparison.

Введение

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

Целью данной работы является анализ методики Scrum, выявление основных проблем и предложение по улучшению методики. Для достижения поставленной задачи были проведены следующие работы:

- изучить предметную область;

- изучить основные принципы работы методики Scrum;

- проанализировать преимущества и недостатки Scrum;

- изучить отличия методики Scrum от Kanban;

- на основе анализа выявить проблемы Scrum;

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

Объектом исследования данной работы является модели управления процессами. Предметом исследования является изучение проблем методики Scrum. Методами исследования данной работы являются теоретический анализ, изучение соответствующей литературы, сравнение.

Для решения поставленных задач была изучена литература в области управления проектами на базе гибких методологий [3; 4; 5; 6; 7; 8].

Методики разработки программного обеспечения

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

функциональными командами.

Методика Agile - это набор практик, которые обеспечивает максимально возможное улучшение качества процесса разработки ПО с минимальными тратами.

Waterfall — методика управления проектами, которая подразумевает последовательный переход с одного этапа на другой без пропусков и возвращений на предыдущие стадии.В целом, сравнительная таблица Agile методик и Waterfall показана в таблице 1.

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

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

Таблица 1 - Сравнение Agile и WaterFall

Критерий Agile WaterFall

Суть Гибкая модель разработки, основанная на итеративных принципах Каскадная система разработки, основанная на жёсткой последовательности процесса разработки

Дата создания 2001 г. 1956 г., 1961 г., 1970 г.

Плюсы - высокий уровень взаимодействия между членами команды проекта; - быстрый результат (рабочий код) в итоге «спринтов»; - стимулирование изменения и улучшений продукта во время его разработки; - непосредственное - понятная и чёткая схема рабочего процесса; - возможность просчёта точного количества затраченных на проект ресурсов; - не требует затрат по налаживанию коммуникаций между всеми членами команды.

вовлечение заказчика к рабочему процессу.

Минусы - риск бесконечных изменений продукта; - большая зависимость от уровня квалификации и опыта команды; - практически невозможно точно подсчитать итоговую стоимость проекта. - приоритет формального подхода к последовательности процесса работы; - невозможность внесения изменений заказчиком до окончания разработки продукта; - в случае нехватки ресурсов страдает качество проекта из-за сокращения этапа тестирования.

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

Ч

Scrum

Рисунок 1 - Agile манифест

является подмножеством Agile. Это наиболее широко

используемая и облегченная модель процесса для гибкой разработки [16; 10; 18].

Scrum гибкий управленческий фреймворк

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

В Scrum принято выделять три основных роли: владелец продукта, Scrum мастер и команда.

Владелец продукта (Product owner - Менеджер продукта) - это человек, ответственный за приоритезацию требований и часто за их создание.

Scrum мастер - член команды, который дополнительно отвечает за процессы, координацию работы команды и поддержание социальной атмосферы в команде [1].

Команда - группа людей, которые реализуют требования владельца продукта.

Scrum мастер должен ежедневно следить за тем, чтобы скрам-митинг начинался и заканчивался вовремя.

Рекомендуется выделять определенное время каждому участнику, чтобы общая протяженность Scrum митинга не превышала заранее оговоренного времени (например, 15 минут).

Рисунок 2 - Элементы Scrum

Scrum мастер в начале спринта помогает команде проводить планирование спринта и запуск спринта.

В конце спринта Scrum мастер организует демонстрацию результатов спринта при участии всех заинтересованных лиц и проводит ретроспективу при участии всех членов проектной команды.

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

Артефакты. Бэклог продукта (Product Backlog) - приоритезированный список требований с оценкой трудозатрат [9].

Обычно он состоит из бизнес-требований, которые приносят конкретную бизнес-ценность и называются «элементы бэклога».

Бэклог спринта (Sprint Backlog) - часть бэклога продукта, с самой высокой важностью и суммарной оценкой, не превышающей скорость команды, отобранная для спринта.

Инкремент продукта - новая функциональность продукта, созданная во время спринта. Большинство процессов Scrum носят характер встреч, так как данная методика основана на качественных коммуникациях.

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

Основным результатом планирования спринта является бэклог спринта -список задач, которые команда планирует реализовать в рамках спринта. Поскольку длина спринта в Scrum жестко фиксирована, то команда определяет количество элементов бэклога (объем работ), которые она может реализовать.

Можно данную ситуацию отобразить на классическом «треугольнике управления проектами», представленную на рисунке 3.

Команда

Рисунок 3 - Проектный треугольник в Scrum

Обзор спринта - показ владельцу продукта (и заинтересованным лицам) работающего функционала продукта, сделанного за спринт.

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

Scrum мастер собирают всю команду для обсуждения результатов спринта. Рекомендуется на ретроспективу приглашать владельца продукта для получения дополнительной обратной связи. [12] Команда должна обязательно в том или ином виде составить план улучшений для контроля их исполнения [21].

Управление продуктом в Scrum

Методика Scrum дает уникальную возможность сосредоточиться на требованиях, вместо того, чтобы заниматься диспетчеризацией задач или иной оперативной деятельностью забывая о стратегии [11]. Ключевой частью методики является понятие «бэклог» [2].

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

Используя нотацию «грозовых туч» Э.Голдратта представленную на рисунке 4, это противоречие можно изобразить следующим образом: какой бы размер беклога не существовал, существует конфликт, для решения которого

необходимо инновационное решение [19].

Рисунок 4 - Противоречие между тактическим и стратегическим планированием

Решение достаточное известное: использовать метод «набегающий волны» («rolling wave planning»). В рамках Scrum такой подход означает, что существуют истории пользователей на несколько ближайших спринтов.

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

Рассмотрим более точную модель - модель удовлетворения потребностей

Кано.

Японский профессор Нориаки Кано предложил в работе «Привлекательное качество и необходимое качество» еще в 1982 году. Разделим всю функциональность продукта на три категории в соответствии с удовлетворенностью пользователя и полнотой функциональности продукта (рисунок 5).

Таким образом, можно выделить три типа функций продукта:

- Обязательные функции - пользователь ждет этих функций от продукта, без них ему продукт не нужен. Например, для сотового телефона -эта возможность совершать звонки;

- Линейные функции - чем больше и качественней они реализованы, тем больше доволен пользователь. Например, долгая работа сотового телефона без перезарядки;

- Привлекательные функции - функции, которые придают продукту «wow» - эффект. В качестве примера можно рассмотреть эргономику и юзабилити Apple IPhone [14].

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

Рассмотрим, как мотивировать команду, как оценивать и как развивать ее в сторону гибкости [20].

Что такое команда? Определений «команды» существует несколько десятков. Будем придерживаться следующего определения, которое дал Майкл Армстронг: «Команда — это небольшая группа людей, взаимодополняющих и

взаимозаменяющих друг друга, которые собраны для совместного решения задач производительности и в соответствии с подходами, посредством которых они поддерживают взаимную ответственность» [15; 17]. Этапы командобразования представлены на рисунке 6.

Рисунок 6 - Этапы командообразования

Чтобы работать эффективно, команда должна находиться на этапе «Функционирование». Соответственно главной задачей команды (и в частности лидера команды) является максимально быстрый переход между этапами.

Scrum уже имеет инструмент, нацеленный на достижение этой цели который давно зарекомендовал себя и многими специалистами уже считается неотъемлемой частью процесса разработки по Agile методикам. Речь идет о доске задач [15].

Сравнение Scrum и Kanban

Существует еще одна гибкая методика, которая на данный момент менее распространена чем Scrum, но при этом не менее эффективна. Имя этой методики - Kanban. Считается, что Kanban является той методикой, к которой переходят, в случаях, когда возможностей Scrum недостаточно.

Kanban не подразумевает обязательного наличная спринтов и всего того

количества ролей которые есть в Scrum. И это делает методику более простой для внедрения, т.к. не надо обучать людей играть роли, которые они до этого не играли. Также очень большим плюсом с точки зрения внедрения является отсутствие в Kanban предписания иметь кроссфункциональную команду не очень большого размера.

Когда речь заходит о внедрении Agile-методик, то всегда встает извечная проблема выбора, а какую именно методику необходимо внедрить. Теперь можно сравнить Scrum и Kanban [13].

Сходства:

- обе являются Agile методиками;

- обе ограничивают незавершенную работу;

- обе полагаются на самоорганизующиеся команды разработки;

- обе нацелены на частые поставки продуктов;

- обе предполагают наличие приоритезированного бэклога.

Сходства методик, их разницу легче показать с помощью таблицы 2.

Таблица 2 - Отличия методик

Критерий Scrum КапЬап

Итерации Обязательное наличие итераций Наличие итераций не обязательно

Команда Команда должна быть обязательно кросс-функциональной Кросс-функциональность команды не обязательна

Задачи Обязательных

Размер обязательно правил по

задач должны биться величине

на более мелкие задач нет

Обязательной

Метрики метрикой являются Burn-down диаграммы Обязательных метрик нет

Обязательно

Оценивание надо оценивать задачи формирования Оценивать задачи не обязательно

бэклога на

спринт

Добавление Добавление задач в текущую Можно добавлять задачи в любое время.

задач итерацию запрещено

Есть

Роли обязательные роли (Product Owner/Scrum Master) Нет обязательных ролей.

Scrum доску Kanban доска

Доска надо отчищать постоянна на

после каждого протяжении всего

спринта проекта.

Ежедневные Нет никакого

Митинги митинги и ретроспективы обязательны регламента по проведению митингов

Если абстрагироваться от того, каких целей хочется добиться, и думать, лишь о сложности внедрения, то в таком случае, более подходящим вариантом является Kanban. Но всегда надо помнить, что если что-то не предписано, то это не значит, что это нельзя использовать. И любая Agile методика может трансформироваться в нечто более сложное путем добавления практик из других методик. Но на практике оказывается так, что большинство команд используют те или иные практики одновременно. Чистое использование одной методики встречается крайне редко. Поэтому команды и их лидеры находятся в постоянном поиске наиболее лучших вариантов управления процессами.

В отличии от других итеративных методик, Agile делает упор на коммуникации, выводит на первый план команду разработки, а также задает структуру итерации.

Проблемы методики Scrum

На основе проведенного анализа можно выделить ряд недостатков Scrum. К основным недостаткам методики относятся:

- успех проекта во многом зависит от Scrum-мастера (организатор процесса), квалификации команды и их приверженности своему делу;

- далеко не всегда можно адаптировать метод Scrum под сферу деятельности, поскольку есть проекты, требующие исключительно планового подхода в работе;

- требует регулярной коммуникации с заказчиком, что порой тормозит процесс из-за невозможности получения обратной связи;

- если член команды выходит из середины спринта, может быть трудно закончить вовремя;

- сложность внедрения в масштабных и сложных проектах, так как больше подходит для малых и средних проектов.

Методы, позволяющие улучшить Scrum

На основе проведенного анализа и выявленных слабых сторон Scrum можно выделить ряд моментов, которые позволят улучшить Scrum. В частности, предлагаются следующие шаги:

1. Улучшить знания Agile методологии среди членов команды. Хороший Scrum Master активно внедряет идеологию гибких методик, тем самым пытаясь улучшить продуктивность команды. Но это крайне сложно, если команда (или часть команды) не верят в Agile. На то и создана роль Scrum мастера, чтобы решать эту проблему.

Однако проверка на этапе набора команды на верность идеологии, в частности, повышения приоритета знаний в области Agile, позволит облегчить роль Scrum мастера и сделать команду более продуктивной, поскольку каждый член команды будет сам «мини Scrum мастером». Для более лучшей реализации этого улучшения предлагается назначать каждого члена команды на один день (по очереди) помощником Scrum мастера. Член команды будет выполнять данную роль, а настоящий Scrum мастер его страховать. Это позволит снизить значимость успеха проекта от Scrum мастера.

2. Позволить Scrum не следовать строгим требованиям идеологии, например, не использовать фиксированные сроки спринтов, если на то есть необходимость в зависимости от проекта или желаний команды.

3. Разрешать команде менять частично требования (в рамках первоначальных договоренностей) в случаях, если заказчик долго не выходит на связь или не может себе этого позволить.

4. Делать всех членов команды взаимозаменяемыми, насколько это возможно. Это позволит снизить риски от потери члена команды на середине проекта (спринта). Например, если разработчик закончил свою задачу раньше времени, он присоединяется к QA инженеру и тестирует вместе с ним.

5. Ещё одно улучшение про внедрение в сложные проекты вытекает из второго пункта. При необходимости нужно позволять Scrum не следовать строгим требованиям методики, что позволит ему становится ещё более гибким. Отсутствие согласованного расписания позволяет методике Kanban быть более продуктивной при сложных проектах. Именно этот момент и предлагается интегрировать из Kanban в Scrum. В целом, важно сделать Scrum максимально гибким.

Заключение

В рамках работы решены следующие задачи:

- изучена предметная область;

- изучены основные принципы работы методики Scrum;

- проанализированы преимущества и недостатки Scrum;

- изучены отличия методики с Kanban;

- на основе анализа выявлены проблемы Scrum;

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

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

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

пользователей/заказчиков, что позволяет эффективнее управлять наполнением продукта с целью получения максимально ожидаемого результата. На этом и строятся все преимущества Scrum.

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

Библиографический список:

1. Богданов В. Управление проектами. Корпоративная система - шаг за шагом. — Манн, Иванов и Фербер (МИФ), 2017. — 241 с.

2. Вольфсон Б. Гибкое управление проектами и продуктами. — Питер, 2016. — 160 с.

3. Грей, Клиффорд Ф. Управление проектами: учебник: пер. с англ. третьего, полн. перераб. изд./ Клиффорд Ф. Грей, Эрик У. Ларсон; [науч. Ред. перевода В. М. Дудников]. - М.: Издательство «Дело и Сервис», 2015. - 608 с. -Доп. тит. л. англ.

4. Грекул В. И., Коровкина Н. Л., Куприянов Ю. В. Методические основы управления ИТ-проектами. - Интернет-университет информационных технологий, 2018. - 392 с.

5. Джефф Паттон Пользовательские истории. Искусство гибкой разработки ПО. — Питер, 2016. — 400 с.

6. Джефф Сазерленд Scrum. Революционный метод управления проектами. — Манн, Иванов и Фербер (МИФ), 2016. — 320 с.

7. Дженнифер Дэвис, Кэтрин Дэниелс Философия DevOps. Искусство управления IT. — Питер, 2016. — 610 с.

8. Мартин Клеппман Высоконагруженные приложения. Программирование, масштабирование, поддержка. — Питер, 2017. — 640 с.

9. Филимонова Е.В. Информационные технологии в профессиональной деятельности. — КноРус, 2017. — 483 с.

10. Швабер, К. Авторитетное руководство по Скраму: Правила Игры /

К. Швабер, Дж. Сазерленд. - 2014. - 19 с.

11. Эндрю Стеллман, Дженнифер Грин Постигая Agile. — Манн, Иванов и Фербер (МИФ), 2015. — 650 с.

12. Abrahamsson P., Salo O., Ronkainen J. Agile Software Development Methods - Review and Analysis, by Technical Research Centre of Finland, 2015. -107 p.

13. Adkins L. Coaching Agile Teams / Addison-Wesley, 2015.

14. Banks Alex, Learning React: Functional Web Development with React and Redux. — O'Reilly Media, 2017. — 350 p.

15. Bittner K., Spence I. Managing Iterative Software Development Projects. - Addison Wesley Professional, 2016.

16. Cervone H.F. Understanding agile project management methods using Scrum/ H.F. Cervone// OCLC Systems & Services.-2011.-27(1). pp. 18-22.

17. Chris Sims, Hillary Louise Johnson Scrum: a Breathtakingly Brief and Agile Introduction. — Dymaxicon, 2012. — 54 p.

18. Holtsnider В., Wheeler T., Stragand G. Agile Development & Business Goals / Elsevier Inc, 2015. - 256 p.

19. WorkSection [Электронный ресурс] Методология Agile. Матерь драконов или всех гибких методологий. Режим доступа: https://worksection.com/blog/agile.html. Дата обращения (12.12.2021).

20. Технология программирования [Электронный ресурс] Технология разработки программного обеспечения. Режим доступа: http://www.tehprog.ru/index.php_page4ecture12.html. Дата обращения (12.12.2021).

21. Life-Prog [Электронный ресурс] Основные понятия. Программный продукт Режим доступа: https://life-prog.ru/2_13687_osnovnie-ponyatiya-programmniy-produkt.html. Дата обращения (12.12.2021).