Публикация научных статей.
Вход на сайт
E-mail:
Пароль:
Запомнить
Регистрация/
Забыли пароль?

Научные направления

Поделиться:
Статья опубликована в №74 (октябрь) 2019
Разделы: Управление и организация
Размещена 31.10.2019. Последняя правка: 23.11.2020.
Просмотров - 949

Улучшение результатов деятельности команд в IT-организациях с помощью гибкой методологии управления проектами

Пирштук Диана Ивановна

магистранка

Белорусский государственный университет

руководитель IT-проектов

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


Abstract:
The article presents the advantages of using scrum methodology. Team building is described according to a flexible project management methodology. Proposals to improve the effectiveness of the implementation of the methodology in IT companies are developed.


Ключевые слова:
скрам; команда; рекомендации; эффективность; гибкость

Keywords:
scrum; team; recommendations; efficiency; flexibility


УДК 332.8

Цель – разработка предложений по улучшению применения scrum-методологии в IT-компаниях. Цель исследования обусловила следующие задачи:

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

Методология: наблюдение, анализ, систематизация.

Актуальность: Применение скрам-методологии актуально, так как позволяет повысить качество выполняемой работы в IT-организациях.

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

Введение. Изменения характера видов деятельности, усиление разнообразия IT-проектов и их оригинальности диктует необходимость новых подходов к организации этих работ. Одним из них и является скрам. Скрам – это набор принципов, ценностей, политик, ритуалов, артефактов, на основе которых строится процесс скрам-разработки, позволяющий в жестко фиксированные и небольшие по времени итерации, называемые спринтами, предоставлять конечному пользователю работающий продукт с новыми бизнес-возможностями, для которых определен наибольший приоритет [1]. Философия скрама является актуальной, так как она позволяет организовать работу в ситуации неопределенности. К сегодняшнему моменту уже написано достаточно много книг по данной теме, проводятся курсы и тренинги такими известными организациями, как IBA, BelHard и др., по окончании которых возможно получить сертификат об успешном прохождении. Скрам гибкий, и у него широкая область применения, хоть и преимущественно используется в IT-компаниях.Сперва он применялся только в компаниях, занимающихся программных обеспечением, но уже в 2016 г. более пятой части от всех проектов, выполненных по методологии скрам, не имели отношения к сфере IT. Подразделениями, использующими скрам, также являются: промышленное производство, строительство, образование, продажи и маркетинг, персонал, финансы и бухгалтерский учет и др. [2]. Наиболее популярными компаниями, использующими скрам, являются Toyata, Amazon, Microsoft , Роснефть [2].

Гибкие методики быстро реагируют на возникающие проблемы и принципиально отличаются от классических моделей(например, водопад), используемых командами разработчиков в 90-е годы. Каскадные модели не учитывали внезапные задержки и сбои, поэтому команда не справлялась с работой в поставленный срок. Срок часто приходилось менять, стоимость работы находилась на высоком уровне, а качество не всегда соответствовало требуемому уровню. Этапы проекта не перекрывали друг друга, переход к следующему этапу осуществлялся только после завершения предыдущего, к тому же возрастали затраты на составление и подготовку документации. В водопадной модели в силу своей негибкости высока вероятность выявления проблем уже на завершающем этапе. Все это ухудшало взаимоотношения между разработчиками, заказчиками и пользователями. Управление проектами усложнялось по мере возрастания разнообразия и сложности создаваемых продуктов. Таким образом, появилась необходимость перехода на гибкие модели [1]. Скрам предполагает, что работа делится на короткие промежутки времени. По окончании каждого цикла работа показывается заказчику согласно согласованной степени готовности. Также преимуществом скрама являются ежедневные коммуникации между участниками проекта, что компенсирует недостаток квалификации и опыта у части из них. Регулярные митинги укрепляют команду, что, бесспорно, положительно сказывается на выполнении совместной работы. Заказчику постепенно представляется работающая часть проекта, он может вносить изменения по своему желанию, что означает высокую клиентоориентированность. При коротких циклах проблемы быстро идентифицируются и решаются, а результаты оперативно доступны для проверки. В скрам-методологии быстрая реакция на изменения, а не следование плану, тесное сотрудничество с клиентом, меньше бюрократизма [3].

Скрам предполагает, что работа делится на короткие промежутки времени. По окончании каждого цикла работа показывается заказчику согласно согласованной степени готовности. Также преимуществом скрама являются ежедневные коммуникации между участниками проекта, что компенсирует недостаток квалификации и опыта у части из них. Регулярные митинги укрепляют команду, что, бесспорно, положительно сказывается на выполнении совместной работы. Заказчику постепенно представляется работающая часть проекта, он может вносить изменения по своему желанию, что означает высокую клиентоориентированность. При коротких циклах проблемы быстро идентифицируются и решаются, а результаты оперативно доступны для проверки. В скрам-методологии быстрая реакция на изменения, а не следование плану, тесное сотрудничество с клиентом, меньше бюрократизма. Скрам не нужен, когда проекты делаются полностью, вовремя, в полном объеме и когда команда выполняет краткосрочный проект [4,5].

В скрам-проекте есть владелец разрабатываемого продукта, члены команды и скрам-маенеджер(руководитель проекта). Владелец продукта помогает команде понять ценность продукта. Он ответственный за доходность от проекта, поэтому старается увеличить стоимость продукта. Скрам-мастер управляет процессами принятия командных решений, он ежедневно проводит недолгие встречи – около 15 минут для обсуждения того, что было сделано предыдущим днем, каков план действии на сегодня и с какими проблемами столкнулись, выясняются пути их решения [2].Самоорганизация, видимость, проверка и адаптация упрощают систему для работы с изменениями [6].

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

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

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

3. Найти подходящего скрам-менеджера. Скрам-менеджер должен уметь организовать команду и воспитать в ее членах чувство ответственности, то есть по своей сути скрам-менеджер является наставником, коучем, учителем. Он должен уметь найти индивидуальный подход к каждому члену команды и замотивировать его на выполнение задач в указанный срок и/или вести переговоры с заказчиком по поводу откладывания срока представления продукта. Высокая вовлеченность клиента в начале сходит к минимуму в конце разработки. Заказчику постепенно представляется проделанная работа, он может вносить изменения и в любой момент он может отказаться от разработки[7]. К личным качествам скрам-менеджера в первую очередь следует отнести стрессоустойчивость, иначе данная должность нанесет вред здоровью человека. Если участники команды не привержены достижению цели проекта, то это значит, что скрам-менеджер плохо выполняет свои функции, так как не сумел замотивировать всех членов команды [8].

4. Если не получается воспитать ответственность у сотрудников, то применяется другая методология. Причиной провала применения скрам может быть отсутствие практического опыта у скрам-менеджера (теоретические знания, наличие сертификатов в данной области не в счет), а также нечеткое представление целей проекта.

5. Не распылять внимание. Опытный скрам-менеджер может руководить несколькими командами одновременно, но лучше сосредоточиться на одной команде [8].

6. Не создавать препятствий для команды. Препятствием для скрам-команды является жесткое административное управление, которое негативно сказывается на команде. Скрам-менеджер должен способствовать работе команды [8].

7. Адаптировать всех работников к гибкой методике. Люди определенного менталитета часто не могут перейти на скрам. Бюрократическим организациям довольно сложно перейти к скрам-методологии, так как на предполагает собой ежедневную генерацию идей и минимум документации. Некоторые работники предпочитают фиксировать идеи в документах, но это занимает довольно много времени, что противоречит гибкости методики скрама. Для интровертов довольно сложно работать по данной методологии.

8. Планировать длительность интервалов, на которые делится процесс разработки, основываясь на расчетах, сколько можно работать без внесения изменений в план работы. Скорость работы рассчитывается исходя из объема работ, приходящихся на короткий цикл. Объем работы должен превышать возможности команды. Увеличение объема влечет падение качества выполнения работы.

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

10. Радоваться маленьким победам. Выполнение подзадач может превратиться в бесконечный марафон, последствием которого является эмоциональное выгорание работников. Хороший скрам-менеджер всегда говорит об успехах и отпразднует маленькую победу с командой, тем самым стимулируя ее на дальнейшее выполнение разработки продукта. Успех проекта зависит от всех участников, от их способности поддерживать стабильно высокий уровень коммуникации на протяжении каждого шага и анализа. Переход к применению скрам-методологии требует не только освоить новый подход к управлению проектами, но и подобрать людей, способных работать в скрам-режиме. А выполнение вышеуказанных рекомендаций позволит успешно применить данную гибкую методологию и посредством этого улучшить результаты работы.

Заключение. 

Таким образом, в нашем исследовании мы приходим к следующим выводам:

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

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

3. Переход к применению скрам-методологии требует не только освоить новый подход к управлению проектами, но и подобрать людей, способных работать по гибкой методологии управления проектами. А выполнение вышеуказанных рекомендаций позволит успешно применить данную гибкую методологию и посредством этого улучшить результаты работы.

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

1. Сазерленд Д. Scrum. Революционный метод управления проектами / Д.Сазерленд. – Манн, Иванов и Фербер, 2016. – 288 с.
2. Scrum или не-Scrum – какой подход выбрать? [Электронный ресурс]. – Режим доступа: https://worksection.com/blog/scrum.html (дата обращения: 16.10.2019).
3. Топ-7 методов управления проектами: Agile, Scrum, Kanban, PRINCE2 и другие. [Электронный ресурс]. – Режим доступа: https://www.pmservices.ru/project-management-news/top-7-metodov-upravleniya-proektami-agile-scrum-kanban-prince2-i-drugie/(дата обращения: 16.10.2019).
4. Advantages and Disadvantages of the Scrum Project Management Methodology [Электронный ресурс]. – Режим доступа: https://smallbusiness.chron.com/advantages-disadvantages-scrum-project-management-methodology-36099.html (дата обращения: 26.10.2019).
5. Преимущества и недостатки методологии Scrum в разработке сайтов и программного обеспечения [Электронный ресурс] – Режим доступа: https://sonikelf.ru/preimushhestva-i-nedostatki-metodologii-scrum-v-razrabotke-sajtov-i-programmnogo-obespecheniya/ (дата обращения: 16.10.2019).
6. Швабер К., Сазерленд Дж. Исчерпывающее руководство по Скрам: Правила Игры, 2013. – 17 c. [Электронный ресурс] – Режим доступа: https://www.scrumguides. org/ (дата обращения: 16.10.2019).
7. Обзор методологии Scrum Auriga Inc. [Электронный ресурс] – Режим доступа: http://www.myshared.ru/slide/898/ (дата обращения: 16.10.2019).
8. 7 вещей, которые я хотел бы знать, когда стал Скрам-мастером [Электронный ресурс] – Режим доступа: http://gibtech.ru/blog/discus?entry_id=38 (дата обращения: 16.10.2019).




Рецензии:

31.10.2019, 7:27 Ашмаров Игорь Анатольевич
Рецензия: Статья на данную тему вызывает практический интерес и является актуальной. Однако автору необходимо писать по-русски и больше использовать понятную терминологию на русском языке с дублированием иностранными терминами. Цитирую: "Скрам – это одна из методологий agile". Из этого мне лично понятно очень немногое, точнее вообще ничего не понятно. Если автор претендует на публикацию в научном журнале, то он должен потрудиться излагать свои мысли яснее. Заключение также нужно сделать более значимым и оригинальным, сформулировать выводы: 1-ый, 2-ой, 3-ий. Кроме того, следует расширить аннотацию статьи (на русском языке) и сделать качественный англо-русский перевод. Рекомендуется также расширить список литературы (всего три источника информации были изучены автором, и автор пытается что-то обобщить). Статью следует доработать и расширить аннотацию.

01.11.2019 18:18 Ответ на рецензию автора Пирштук Диана Ивановна:
Уважаемый Игорь Анатольевич, благодарю за рецензию!Статья доработана, ваши замечания были устранены: расширен список литературы, доработана аннотация на русском и английском языках, заменены английские термины, как ретроспектива, спринт и т.д., выводы сделаны более значимыми и сформулированы по пунктам.

1.11.2019, 20:11 Ашмаров Игорь Анатольевич
Рецензия: Автор статьи глубоко знает предмет своего исследования, оперативно устраняет замечания рецензента, статья структурирована, расширена библиография к ней, выводы уточнены. Можно было бы расширить аннотацию. Тем не менее, уже сейчас могу рекомендовать данный материал для опубликования в научном журнале.

2.11.2019, 9:22 Попова Галина Валентиновна
Рецензия: Статья Улучшение результатов деятельности команд в IT-организациях с помощью гибкой методологии управления проектами", Пирштук Диана Ивановна, НЕ рекомендуется к публикации В ПРИНЦИПЕ И ПО СУЩЕСТВУ - отсутствует научное основание (теоретическая / методологическая основа), научное обоснование, научная новизна (для-???наук) и, соответственно, - собственно, научный результат. Обращаем внимание автора на то, что в статье не показано однозначно - В КАКИХ НАУКАХ И В КАКОМ ПРОЦЕНТЕ / ДОЛЕ автором получен лично научный результат (какой?) Автору настоятельно рекомендуется самостоятельно ознакомиться с Паспортами научных специальностей ВАК на официальном сайте. Обращаем внимание редколлегии на то, что никакая "доработка" в данном случае неприемлема. Статья должна однозначно идентифицироваться с конкретной научной отраслью и степенью достижения автора в конкретных науках.



Комментарии пользователей:

Оставить комментарий


 
 

Вверх