CC BY
588
DOI 10.26425/1816-4277-2018-2-13-20
SCRUM: ГИБКОСТЬ В ЖЕСТКИХ РАМКАХ
Аннотация. На сегодняшний день традиционные методы проектного управления устаревают, именно поэтому необходимо внедрять во многие сферы жизни современные гибкие методологии, одной из которых является Scrum, которая позволяет повысить эффективность и продуктивность работы в целом. В данной статье представлены основные принципы Scrum, исследование опыта внедрения данной методологии в Google, Информационной службе штата Вашингтон, Информационно-аналитическом центре Санкт-Петербурга, Администрации Главы Республики Саха (Якутия) и Правительства Республики Саха (Якутия), а также в одной из школ нидерландского города Алфен-ан-ден-Рейн.
Ключевые слова: менеджмент, управление проектами, гибкая методология, Agile, Scrum, эффективность.
SCRUM: FLEXIBILITY WITHIN A RIGID FRAMEWORKS
Abstract. Nowaday, traditional methods of project management are becoming obsolete, which is why it is necessary to introduce modern flexible methodologies into all spheres of life, one of which is Scrum, which improves the efficiency and productivity of the work as a whole. The article presents the basic principles of Scrum, a study of the experience of implementing this methodology in Google, the Washington Information Service, the Information and Analytical Center of St. Petersburg, the Administration of the Head of the Republic of Sakha (Yakutia) and the Government of the Republic of Sakha (Yakutia), and in one of the schools of the Dutch city Alphen-an-den-Rijn. Keywords: management, project management, flexible methodology, Scrum, Agile, efficiency.
В современном быстро развивающемся мире мы начали больше уделять внимания общению с людьми, чем выстраиванию жестких процессов. Мы стали сосредотачиваться на конечном продукте, а не зацикливаться на документации, которую редко кто внимательно читает. Мы предпочитаем выстраивать доверительные отношения с нашими заказчиками вместо предъявления требований и ограничений, прописанных условиями договора. И наконец, мы перестали бояться изменений, а наоборот открылись им, ведь мир не стоит на одном месте. Именно поэтому перед многими компаниями, связанными с проектной деятельностью, сейчас стоит нелегкий выбор: закрыться от всего, что их окружает, и придерживаться традиционных методов управления, или достигать любых вершин с внедрением гибких методологий управления проектами.
История гибких методологий начинается с февраля 2001 г., когда на лыжном курорте The Lodge at Snowbird в горах Юты встретились 17 успешных менеджеров по управлению проектами, чтобы выяснить, что есть общего между их подходами и выработать новую методологию. В результате появился набор ценностей, на которых базируется вся их работа. Так появился на свет Agile-манифест, который включал 4 главных идеи:
- люди и взаимодействие важнее процессов и инструментов;
- работающий продукт важнее исчерпывающей документации;
- сотрудничество с заказчиком важнее согласования условий контракта;
- готовность к изменениям важнее следования первоначальному плану [2].
Суть гибких методологий заключается в разделении задач проекта на итерации (части) с детально продуманным планированием и четко ограниченным временем выполнения (1-4 недели). Все решения принимаются в зависимости от промежуточных прозрачных результатов проекта, то есть каждый член команды в режиме реального времени следит за статусом работы по проекту, его изменениями и возникшими проблемами.
Если рассмотреть каскадную (водопадную) модель управления проектами (рис. 1), то можно заметить, что такая система не в состоянии быстро реагировать на изменения и адаптироваться под новые реалии времени, поскольку принцип данной модели подразумевает разделение рабочего процесса на поочередные задания, которые должны быть выполнены в строгой последовательности: перед началом новой задачи необходимо завершить пре-
© Андреева Р.Н., Синяева О.Ю., 2018
УДК 005.9 JEL M16 O22
Андреева Р.Н. Синяева О.Ю.
Andreeva Rozaliia Sinyaeva Olga
дыдущую. Более того, отношение каскадной модели к изменениям крайне негативное, так как любые изменения могут быть внесены только после завершения всего процесса разработки. В связи с этим возникает основной недостаток водопадной модели - ее немобильность. Agile, в свою очередь, славится своей гибкостью: возможностью быстрого реагирования и внесения корректировок в программный продукт. Именно поэтому многие компании делают свой выбор в пользу гибкого подхода.
Источник: [3]
Рис. 1. Каскадная (водопадная) модель управления проектами.
На данный момент существует огромное количество гибких методологий. Все они похожи друг на друга, однако каждая из них имеет свою особенность. Так, например, Lean добавляет к принципам Agile схему потока операций с целью выполнения всех итераций одинаково качественно. Это позволяет параллельно выполнять несколько задач на разных этапах, в результате чего повышается гибкость и увеличивается скорость исполнения проектов [12]. Kanban, созданный инженером Toyota Тайити Оно еще в 1953 г., охотно применяются в различных компаниях и сегодня. Данный подход похож на схему промышленного производства, чем и привлекателен для своих сторонников. Его особенностью является то, что в этом гибком методе разрешается оставить неоконченную задачу на одном из этапов, если появится что-то более важное, чей приоритет окажется выше. Более того, при этом подходе нет четкой структуры, поскольку нет ограничений во времени спринтов, и есть только одна роль - владелец продукта [1].
Тем не менее, самым известным и популярным среди гибких подходов управления проектами сегодня является Scrum, поскольку он более структурирован в своем семействе, так как сочетает элементы водопадного процесса и идеи гибкого подхода. Согласно результатам исследования Agile survey о популярности гибких методологий Scrum используется в несколько раз чаще, чем его аналоги [2] (см. рис. 2).
Методология Scrum впервые предложена Джефом Сазерлендом и Кеном Швабером в 1990-е гг. в виде четко формализованного документа, названного «Руководство по Scrum». Scrum - новый подход к решению вопросов, принципиально отличающийся от традиционных методов управления проектами. Его принцип аналогичен эволюционным, адаптивным, самокорректирующимся системам [9].
Если кратко охарактеризовать Scrum, то это один из процессов Agile, позволяющий сконцентрироваться на самых важных задачах в строго ограниченные сроки. В результате чего каждые 2-4 недели все желающие (заинтересованные лица) могут увидеть работающий функционал и решить: выпускать его или же улучшать в следующей итерации (спринте).
2 % 4 %
■ Scrum Scrum+XP ■ Kanban ■ Lean Другие
Источник: [2]
Рис. 2. Популярность гибких методологий.
Перед тем как начать работать, вовлеченные в проект люди выстраивают глобальные цели и стратегию, с помощью которой впоследствии будут достигать цели. После этого стороны (заказчик и исполнитель) обговаривают рамки проекта и дату начала первой итерации. Итерация в Scrum получила название спринт, который длится обычно 1-4 недели.
Scrum основывается на эмпирических процессах, то есть знание приходит лишь с опытом, а решения могут приниматься на основании известных действий. Scrum использует итеративно-инкрементальный подход для оптимизации прогнозируемости и управления рисками [11].
Scrum состоит из трех элементов: ролей, артефактов и процессов (табл. 1). Разберем каждый из компонентов более подробно.
Таблица 1
Элементы Scrum
Роли Артефакты Процессы
Владелец продукта Scrum-мастер Команда Беклог продукта Беклог спринта Инкремент продукта Планирование спринта Обзор спринта Ретроспектива Scrum-митинг Спринт
Составлено авторами по материалам исследования
В свою очередь, роли проекта подразделяют на владельца продукта, Scrum-мастера и команду.
1. Владелец продукта (product owner) в большинстве случаях является заказчиком. Он отвечает за беклог (backlog) продукта. Основной его задачей выступает предъявление четких требований к продукту, чтобы максимально дать понять разработчикам, что он хочет видеть в конце проекта. Именно он выставляет приоритеты: то, что является наиболее срочным и важным на данный момент.
2. Scrum-мастер играет ключевую роль в работе над проектом. Ведь именно в его руках лежит ответственность за понимание сущности всего процесса, поддержания благоприятной атмосферы в команде. Его основная
задача - обеспечение слаженной работы разработчиков и помоь при возникновении каких-либо проблем. В его компетенцияю также входит ежедневный контроль за происходящими событиями, чтобы они проводились регулярно и с высокой эффективностью.
3. Команда (team) - прежде всего разработчики, чье оптимальное количество составляет 7±2 человека. В соответствии с The Scrum guide команда должна быть самоорганизующейся (никто не вправе вмешиваться в их преобразование product backlog в продукт), многофункциональной, а также должна отвечать за совместное выполнение работы коллективно, а не индивидуально.
Рассмотрим артефакты в методологии Scrum. Принято выделять беклог продукта, беклог спринта и инкремент (increment) продукта. Рассмотрим каждый из них подробно.
Беклог продукта (product backlog) - список требований, расставленных по приоритету, с оценкой трудозатрат. Он создается, как сказано выше, владельцем продукта, или заказчиком, после проведения анализа потребностей рынка. Всем требованиям выставляются по степени важности (приоритеты). В ходе работы над проектом владелец продукта может корректировать беклог. Именно эта особенность делает подход гибким. Выбранные для спринта требования заносят в беклог спринта. Беклог продукта состоит из пользовательских историй (user stories). Они, в свою очередь, делятся на: идентификатор (порядковый номер), название, важность, предварительную оценку, метод демонстрации, примечания.
Беклог спринта (sprint backlog) - внесенные требования из беклога продукта с высокой степенью важности и суммарной оценкой, которые должны быть выполнены в текущем спринте. В отличие от беклога продукта, он не может быть изменен и подкорректирован в ходе работы над проектом, то есть остается фиксированным на время конкретной итерации. Задачи из беклога спринта могут быть исключены только в непредвиденных форс-мажорных ситуациях [8].
Более того, для ведения учета объема выполненной и предстоящей работы используется диаграмма сгорания. Перед любой итерацией команда оценивает количество усилий, времени, необходимых для выполнения задач из беклога спринта. После завершения каждой задачи Scrum-мастер пересчитывает количество невыполненных работ на данный спринт. Все эти оставшиеся задачи отмечают на графике, по оси абсцисс которого отмечена длительность спринта, а по оси ординат - количество оставшейся работы. Диаграмма сгорания выступает отличным вспомогательным инструментом, которая позволяет оценить траекторию работы команды: верно или неверно команда движется в рамках конкретного спринта.
Инкремент продукта - это необходимый результат работы каждого спринта. Иными словами, это объединенная версия продукта, которая поддерживается на высоком уровне качества, чтобы поставлять продукт пользователям, если владелец продукта решит, что это будет целесообразно.
Теперь перейдем к процессам методологии Scrum, которые состоят из Scrum-митинга планирования и обзора спринта, а также ретроспективы. Рассмотрим их более детально.
Все начинается с планирования спринта. В самом начале владелец продукта презентует беклог продукта, где собраны все требования к проекту со степенью важности (с расставленными приоритетами). Следует акцентировать внимание на том, что у каждого продукта должен быть только один беклог и один владелец продукта. Затем команда отбирает наиболее важные задачи и вносит их в беклог спринта с определением необходимого количества времени на выполнение данных задач. И только потом они приступают к обсуждению путей реализации требований заказчика. Планирование спринта обычно длится 3-4 часа, в результате чего достигается договоренность между владельцем продукта и командой по поводу уверенности правильного восприятия и понимания требований, количества задач, которые необходимо реализовать, дат демонстрации готового продукта и мест, времени проведения Scrum-митинга. Существуют еще тонкости планирования: фокус-фактор, то есть насколько разработчик сконцентрирован на задании; «все оценивают всё» - делается для распространения опыта; «покер-планирование» - разработчики играют в покер для того, чтобы индивидуально оценить, сколько дней, в идеале, они готовы потратить на решение той или иной задачи. Более того, в Scrum есть возможность парной работы (парного программирования), что обеспечивает распространение опыта, умений и навыков во всем коллективе.
После планирования организовывают так называемые Scrum-митинги (планерки) - общее собрание всех вовлеченных в проект людей для обсуждения работы и выявления проблем, которое обычно длится 15 минут. Каждый член команды должен ответить на следующие вопросы:
- Что было сделано вчера?
- Что я планирую сделать сегодня?
- С какими трудностями я столкнулся?
При выявлении проблем, Scrum-мастер должен сделать все от него зависящее для их устранения после окончания планерки. Scrum-митинги особо важны в Scrum, так как эта 15-минутная встреча позволяет всем членам команды быть в курсе дел, еще раз переоценить задачи, а также получить новые. При получении новых задач существуют некоторые тонкости: задачи достаются наименее компетентному исполнителю (для распределения опыта), проводится выстраивание объективного группового мнения работе конкретного исполнителя для исключения неправильного понимания требований («паучье чутье»).
Далее, проводится обзор спринта - показ владельцу продукта (или заинтересованным лицам) функциональности продукта. Основная цель данного процесса - получение обратной связи (feedback) (рис. 3). На встрече обзора спринта может присутствовать любой желающий.
Владелец продукта
Составлено авторами по материалам исследования
Рис. 3. Организация обратной связи в рамках обзора итогов спринта.
И наконец, после обзора спринта проводят ретроспективу, но, в отличие от обзора спринта, здесь могут присутствовать только члены команды, Scrum-мастер и владелец продукта. Длительность встречи зависит от количества обсуждаемых пунктов, обычно она варьируется от 15 минут до 3-х часов. В ходе ретроспективы разработчики делятся между собой проблемами, с которыми столкнулись в процессе работы над проектом, опытом, который получили в прошедшем спринте, или мнениями о том, как можно было бы улучшить процесс в следующем спринте.
На сегодняшний день многие крупные компании начинают внедрять в свой рабочий процесс гибкие методологии. Самым ярким примером среди компаний, которые придерживаются Scrum, является Google. Рассмотрим их методы, приемы более подробно.
Все началось с появления значимой личности в истории данной компании - Уэйна Розинга в 2001 г. До этого Google не применяла в своих технологиях методологию Scrum, возможно, поэтому сталкивалась с огромным количеством проблем при реализации продуктов. Одной из проблем выступала перегруженность членов команды в одном проекте и их некомпетентность, из-за чего решения принимались не так быстро, как хотелось бы, в результате сроки заканчивались, а продукты так и не разрабатывались до конца. Тогда Уэйн предложил заменить менеджеров на инженеров - профессионалов своего дела, затем разбил их по командам и назначил в каждой команде ответственное лицо - руководителя проекта. Ключевым изменением стало также то, что команда имела полное право корректировать продукт в процессе работы, никого об этом не спрашивая. Более того, Розинг говорил, что нельзя ни в коем случае допустить централизованность, при которой все приказы и команды будут диктоваться сверху. Напротив, он допускал, что нужно дать команде полную свободу действий, ведь именно она
хорошо знает, что нужно сделать и как работать. Все это совпало с 5, 9, 12 принципами Agile [3]. В результате правильно построенной работы был создан проект Google AdWords, который на сегодняшний день является основным доходом данной компании [10].
В государственном секторе также используют гибкую методологию Scrum. Президент и председатель Сбербанка России Г. О. Греф, побывав в Кремниевой долине, узнал, что правительство Норвегии два министерства США упорно начали изучать Agile, в том числе Scrum, в то время как Россия только начинает внедрять гибкие методологии в сфере бизнеса [5].
Обычно в систему государственного управления внедряют водопадную модель управления проектами, при которой необходимо четко следовать определенному набору шагов на протяжении жизненного цикла. Этот метод больше подходит государственной сфере, так как все идет постепенно, имеется под руками подробная документация, а требования всегда согласованы и утверждены. Но бывают ситуации, когда необходимо реализовать проект при отсутствии четкого плана и понимания, то есть действовать в условиях повышенной неопределенности. Обычно это бывает при создании государственных информационных систем, сайта, оптимизации процессов оказания государственных услуг и так далее. В данном случае Scrum может выступить эффективным средством.
Именно поэтому в свое время информационная служба штата Вашингтон внедрила в свою работу методику Scrum. Были сформированы Scrum-команды, а для максимальной прозрачности все единогласно пришли к решению снести стены в рабочем помещении. Более того, проводили ежедневные планерки (Scrum-митинги), еженедельно выводили новый готовый продукт и опробовали его на практике, в необходимых случаях прерывались на корректировку плана стратегии. Начав с себя в качестве примера, информационная служба штата в настоящее время активно занимается внедрением Scrum уже во все бюрократические системы штата [9].
Однако, каким бы эффективным на первый взгляд не казался Scrum, у него есть свои недостатки. Во-первых, это проблемы с заключением договоров. Как мы знаем, данная методология не подразумевает наличие фиксированного бюджета и фиксированного технического задания, что, в свою очередь, затрудняет процесс юридического оформления договоренностей. На данный момент в России многие заказчики пока не готовы идти на гибкость бюджета и технического задания, в то время как на западе все клиенты давно перешли на такую систему работы. Эту проблему можно решить следующим образом: заключать договоры на разработку не целого проекта, а его этапов и при этом устанавливать дополнительные соглашения на возникшие в ходе работы поправки и корректировки. И тогда вполне возможно, что через несколько лет Scrum заработает в нашей стране. Во-вторых, данная гибкая методология имеет огромное количество исключений: риск бесконечных изменений продукта, огромная зависимость от уровня квалификации и опыта работы команды проекта, невозможность точного подсчета итоговой стоимости проекта (по времени, по финансовым средствам). Ввиду этого, она неприменима для государственных заказов, а также при наличии некомпетентных специалистов, заниженных сроках или бюджете. При таком раскладе дел другие методологии хотя бы завершат проект, пусть и на низком уровне, в то время как Scrum априори не сработает. Напротив, во всех остальных случаях он превосходит традиционные методы управления проектами.
В настоящее время на российском рынке Scrum стал эффективно внедряться в большие корпоративные проекты с протяженностью год и более, особенно в банковском секторе, что неудивительно после выступления Г. О. Грефа на Гайдаровском форуме [4]. Более того, в нашей стране есть успешные практики внедрения Scrum в государственный сектор. Так, например, с 2009 г. в Информационно-аналитическом центре Санкт-Петербурга в ряде проектов по созданию и развитию государственных информационных систем успешно применяют гибкие подходы Scrum к управлению проектной деятельностью и ведению разработки. За это время у организации накопился опыт применения гибких методов для реализации государственных контрактов в существующей нормативно-правовой базе. Были достигнуты следующие результаты: кардинально сократились сроки создания новых продуктов, изменения и приоритеты оперативно управлялись, не происходили ситуации, при которых денежные ресурсы выходили за рамки бюджета, значительно повысилось качество продукта [7].
Некоторые государственные структуры внедряют Scrum, адаптировав их под свои условия. Так, например, Департамент проектного управления Администрации Главы Республики Саха (Якутия) и Правительства Республики Саха (Якутия) частично внедрил Scrum в свой рабочий процесс. С понедельника по четверг ровно в 9 часов 15 минут утра проводятся Scrum-митинги для того, чтобы каждый сотрудник департамента ответил на три клю-
чевых вопроса данной методологии. Итерации длятся в зависимости от сложности задач либо одну неделю, либо две. Соответственно, после окончания итерации, организовываются ретроспектива и планирование следующего спринта. Департамент проектного управления Якутии использует Scrum для реализации проекта по внедрению проектного управления в исполнительные органы государственной власти.
Если Scrum так успешен и популярен в частных и государственных структурах, может ли эта методология оказать такой же положительный эффект в социальной сфере? Для этого разберем опыт внедрения Scrum в образовательную сферу Голландии.
В одной из школ нидерландского города Алфен-ан-ден-Рейн учитель химии Вилли Вейнандс, ознакомившись с методологией Scrum, загорелся идеей попробовать внедрить его в образовательный процесс. Он повесил на доске бумажный плакат, который весь был усыпан стикерами и разделен на столбики: «все задачи», «необходимо выполнить», «в работе», «сделано». Под данными столбиками располагались еще четыре записи: «характеристики выполненного», «кривая» — диаграмма исполнения заданий, «взгляд в прошлое» — ретроспектива и «динамика» - наработанный объем баллов. Более того, мистер Вейнандс разделил учебный курс на четырехнедельные и пятинедельные спринты, после завершения которых сдается тест. Во время занятий Вейнандс ходил по классу и наблюдал за перемещением разноцветных стикеров на Scrum-доске, рассматривал графики и анализировал диаграммы выполнения задач. Если вдруг он заметил, что кто-то из учеников столкнулся с трудной задачей, которую он не в силах решить, то подходил к нему и помогал с трудной ситуацией. Что касается контроля правильного выполнения и понимания заданий, то Вилли наугад выбирал любую задачу из столбика «выполнено» и проверял знания каждого из присутствующих в классе. Если хотя бы один школьник не смог ответить на его вопросы, то он возвращал этот стикер в столбик «необходимо выполнить». Получается, у класса рождался командный дух. Такой подход получил название EduScrum [6].
А чем нам может помочь Scrum в бытовой жизни? Разберем эффективность внедрения Scrum на примере ремонта дома. Ни для кого не секрет, что ремонт дома - неприятное дело, поскольку в большинстве случаев он занимает вдвое больше времени, чем планировалось, и, соответственно, обходится вдвое дороже. Всего этого можно избежать, если вовремя отнестись с полным серьезом и внедрить Scrum. Приведем пример. Сосед Джефа Сазерленда однажды решил полностью отремонтировать свой дом: сменить дизайн всех комнат, заменить всю технику, провести новую проводку, обновить везде краску. При этом он поставил перед собой срок в 6 недель, который сначала кажется нереальным. В первую очередь, он решил разделить период ремонта на 6 итераций — получается, один спринт у него длился ровно неделю. После этого подготовил проекты на неделю, которые должны были привести в состояние «сделано», а в трейлере рабочих, стоявшем перед домом, повесил Scrum-доску. Каждое утро он проводил Scrum-митинги. В итоге все были в курсе того, кто чем был занят, и у кого какие проблемы возникали. Например, нехватку нужных материалов обнаруживали до того, как их отсутствие начинало влиять на процесс. Пожалуй, самым главным преимуществом ежедневных Scrum-митингов стало то, что работники были освобождены от зависимости. Обычно на любом строительном проекте огромное количество времени тратится на ожидания, когда будет завершена одна часть работы. В конце концов, он уложился в срок и остался довольным ремонтом.
Таким образом, благодаря постоянному анализу выполненной работы и возможностью вносить корректировки между спринтами Scrum является продуктивной гибкой методологией, позволяющей эффективно достигать результатов. Данная методология подразумевает, что члены команды вольны в своих действиях: отсутствует давление сверху, существует возможность самостоятельного определения и выбора приоритетных задач. Все это способствует тому, что участники проекта чувствуют себя не только полностью вовлеченными в процесс, но и наделенными ответственностью, ведь от них зависит качество продукта. А это, в свою очередь, стимулирует их активность и энтузиазм. Более того, самостоятельное определение объема работ и времени, которое понадобится на их выполнение, сводит на минимум риски отклонения от графика, в отличие от традиционного подхода управления, когда все диктуется сверху, ведь никто лучше самих членов команды не знает, за какой срок они справятся с данной работой. Немаловажным преимуществом также является возможность отслеживания в режиме реального времени процесса работы. Это позволяет быстро обнаруживать и исправлять возникшие ошибки на самых ранних этапах. При внедрении данной гибкой методологии в российских компаниях, государственном секторе, социальной сфере повысятся эффективность и продуктивность работы в целом.
Библиографический список
1. Андерсон, Д. Канбан. Альтернативный путь в Agile / пер. с англ. А. Карабейников - М.: «Манн, Иванов и Фербер», 2017.- 350 с.
2. Вольфсон, Б. Гибкие методологии разработки, версия 1.2 [Электронный ресурс]. - СПб.: Питер, 2012. - 112 с. - 1 эл. опт. диск (CD-ROM).
3. Вольфсон, Б. Гибкое управление проектами и продуктами. - СПб.: Питер, 2015. - 144 с.: ил.
4. Выступление Германа Грефа на Гайдаровском форуме 2016 [Электронный ресурс]. - Режим доступа: http://tocpeople. com/2016/01/gref-gajdarovskij-forum-2016/ (дата обращения: 06.02.2018).
5. Греф: России требуется новая система управления [Электронный ресурс]. - Режим доступа: http://www.bbc.com/russian/ business/2016/05/160522_gref_skolkovo_lecture (дата обращения: 08.02.2018).
6. Методика Scrum в образовательной системе (EduScrum). [Электронный ресурс]. - Режим доступа: https://webformula. pro/article/metodika-scrum-v-obrazovatelnoy-sisteme-edu-scrum/ (дата обращения: 09.02.2018).
7. Первые результаты применения гибких подходов в государственном секторе РФ. [Электронный ресурс]. - Режим доступа: http://pmolimp.ru/files/content/1218/3-dubrovin-i-s-pervye-rezultaty-primeneniya-gibkih-podhodov-v-gosudarstvennom-sektore-pdf.pdf (дата обращения: 06.02.2018).
8. Родионов, В. В. Проблемы внедрения проектного управления, связанные с документированием и регламентированием деятельности / В. В. Родионов, Т. А. Суетина // Теоретические и прикладные аспекты современной науки. - 2015. - № 7 (7). -С. 126-128.
9. Сазерленд, Д. Scrum. Революционный метод управления проектами, 2-е изд. / пер. с англ. М. Гескина - М:. «Манн, Иванов и Фербер», 2017.- 288 с.
10. Agile Project Management: Lessons Learned at Google. [Электронный ресурс].- Режим доступа: https://www.infoq.com/ presentations/Agile-Management-Google-Jeff-Sutherland (дата обращения: 07.02.2018).
11. Schwaber, Ken, Sutherland, Jeff. The Scrum Guide. The definitive Guide to Scrum: The Rules of the Game, 2016 - 23 p.
12. Scaling Agile to Work with Distributed Teams [Online] / auth. Cohn Mike. Режим доступа: http://www.mountaingoatsoftware. com/system/presentation/file/133/Scaling-Distributed- Agile-Cohn-NDC2010.pdf (дата обращения: 06.02.2018).
References
1. Anderson D. Kanban. Al'ternativnyj put' v Agile [Kanban. An Alternative Path to Agility]. Moscow, 2017. 350 p.
2. Vol'fson B. Gibkie metodologii razrabotki, versija 1.2 [Flexible Product Development, version 1.2]. Saint Petersburg, 2012. 112 p.
3. Vol'fson B. Gibkoe upravlenie proektami i produktami [Flexible Project and Product Management]. Saint Petersburg, 2015. 144 p.
4. Vystuplenie Germana Grefa na Gajdarovskom forume 2016 [Speech by German Gref at the Gaidar Forum 2016]. Available at: http://www.bbc.com/russian/business/2016/05/160522_gref_skolkovo_lecture (accessed 06.02.2018).
5. Gref: Rossii trebuetsja novaja sistema upravlenija [Gref: Russia needs a new management system]. Available at: http://www.bbc. com/russian/business/2016/05/160522_gref_skolkovo_lecture (accessed 08.02.2018).
6. Metodika Scrum v obrazovatel'noj sisteme (EduScrum) [The Scrum method in the educational system (EduScrum)]. Available at: https://webformula.pro/article/metodika-scrum-v-obrazovatelnoy-sisteme-edu-scrum/ (accessed 09.02.2018).
7. Pervye rezul'taty primenenija gibkih podhodov v gosudarstvennom sektore RF [First results of applying flexible approaches in the public sector of the Russian Federation]. Available at: http://pmolimp.ru/files/content/1218/3-dubrovin-i-s-pervye-rezul-taty-primeneniya-gibkih-podhodov-v-gosudarstvennom-sektore-pdf.pdf (accessed 06.02.2018).
8. Rodionov V. V Problemy vnedrenija proektnogo upravlenija, svjazannye s dokumentirovaniem i reglamentirovaniem dejatel'nosti [Problems of implementing project management related to documenting and regulating activities] / V V. Rodionov, T. A. Suetina // Teoreticheskie i prikladnye aspekty sovremennoj nauki Theoretical and applied aspects of modern science, 2015, I. 7, pp. 126-128.
9. Sazerlend D. Scrum. Revoljucionnyj metod upravlenija proektami, 2-e izd. [Scrum. The Art of Doing Twice the Work in Half the Time, 2nd edition]. Moscow, 2017. 288 p.
10. Agile Project Management: Lessons Learned at Google. Available at: https://www.infoq.com/presentations/Agile-Management-Google-Jeff-Sutherland (accessed 07.02.2018).
11. Ken Schwaber, Jeff Sutherland. The Scrum Guide. The definitive Guide to Scrum: The Rules of the Game, 2016. 23 p.
12. Scaling Agile to Work with Distributed Teams [Online] / auth. Cohn Mike. Available at: http://www.mountaingoatsoftware.com/ system/presentation/file/133/Scaling-Distributed-Agile-Cohn-NDC2010.pdf (accessed 06.02.2018).
