Масштабирование scrum-методологии на уровень enterprise на примере компании российского IT-рынка Текст научной статьи по специальности «Экономика и бизнес»

Масштабирование scrum-методологии на уровень enterprise на примере компании

российского it-рынка

Scaling of scrum-methodology at the enterprise level by the example of the Russian it-market

company

Резанцева Екатерина Яковлевна,

магистр,

Национальный Исследовательский Ядерный Университет «МИФИ»,

Россия, г. Москва. erezantseva@gmail.com

Rezantseva Ekaterina,

master,

National Research Nuclear University "MEPhI",

Russia, Moscow. erezantseva@gmail.com

Аннотация.

В данной статье рассматриваются проблемы малых IT-компаний на Российском рынке на этапе роста компании, возможное решение и инструмент для него. Объясняется выбор данного типа компаний, описываются причины появления таких проблем. Как возможное решение предлагается повысить гибкость компании путем реорганизации компании. Выставляются требования к методологиям и критерии соответствия этим требованиям. Для реорганизации предлагается использовать scrum-методологию в компании1, обосновывается выбор данного решения и альтернативы ему. Фиксируются преимущества данной методологии и ее недостатки. При наложении описывается сама методологи, исходное состояние компании и будущая архитектура компании по scrum.

Annotation.

This article examines the problems of small IT companies in the Russian market at the stage of company growth, a possible solution and a tool for it. The choice of this type of company is explained, the reasons for the appearance of such problems are described. As a possible solution, it is proposed to increase the flexibility of the company by reorganizing the company. Requirements for methodologies and criteria for compliance with these requirements are set out. For reorganization it is proposed to use the scrum-methodology in the company, the choice of this solution and the alternative is justified. The advantages of this methodology and its shortcomings are fixed. When superimposed, the methodology itself is described, the initial state of the company and the future architecture of the company by scrum.

Ключевые слова: архитектура предприятия, методология, scrum, команда по трансформации компании, команда по развертыванию scrum, бэклог трансформации компании.

Key words: enterprise architecture, methodology, scrum, enterprise transformation team, scrum development team, transition product backlog.

Введение

IT-рынок товаров и услуг в России сейчас, как и многие другие, нестабилен и переживает кризис, в 2015 году он сократился на 41% [1, с.5]. Выжить в таких условиях смогли только самые приспособленные, а исходя из

1 В виду коммерческой тайны название компании не будет фигурировать в статье

рейтинга Российских IT-компаний за 2016, это в основном большие компании, у которых основным заказчиком является государство [1, c.2-5]. Доля госзакупок у малого и среднего бизнеса от общего числа закупок составляет всего 12% [2, с.2]. А в связи с тем, что покупательский спрос на продукцию малых и средних предприятий в условиях кризиса значительно снизился, им нужно быть максимально гибкими и уметь делать буквально любые заказы в установленные сроки, даже если они будут ориентироваться на госзаказы, а не на прямого потребителя [2, с.1-2]. Каким образом компания может обеспечить себе соответствующую гибкость? Необходимо организовать работу компании и ее обеспечения таким образом, чтобы это стало возможно. Существует множество различных методологий по построению архитектуры предприятия, позволяющих описать компанию для организации или реорганизации ее работы и построения различных структур в ней, способствующих прямому достижению поставленных компанией целей.

Многие авторы видят проблему малых и средних предприятий в отсутствии ключевых бизнес навыков, а также отсутствии у управленцев понимания, что необходимо принимать разные решения для разных этапов жизненного цикла компаний [3, с.1]. Некоторые авторы предлагают накладывать такую архитектуру, которая позволила бы компании вырасти из малого бизнеса в средний, т.е. видят проблему в трансформации компании, при этом стараются учитывать ограниченность ресурсов малого бизнеса [4]. Также есть статьи, в которых авторы предлагают не накладывать огромный и сложный enterprise architecture фрэймворк, а использовать упрощенную модель из нескольких компонентов [5].

Проблематизация

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

На стадии «Выхаживания» it-компания ничем не отличается от других: есть бизнес-идея и есть основатель.

На стадии «Младенчества» формируется совокупность людей, объеденных для выполнения какого-то проекта, или заказа, или продукта во главе с основателем. В общем, деятельность эта представляет собой проект. У каждого сотрудника есть множество функций и очень объемные роли. Все эти люди разбираются в том, что делают. В it-сфере обычно все люди на данной стадии обладают сильными техническими навыками, но не обладают навыками управления, рекрутинга, аналитики и тестирования. Основатель выступает не как руководитель или управленец, а как член команды и лидер. На первых двух этапах построение архитектуры не является необходимым, так как нечего строить. Основатель может справлять со всеми управленческими функциями сам: он может сам управлять финансовыми потоками, может сам искать заказчиков, сам с ними общаться, сам делать продукт и т.д.

На стадии «Давай-давай!» организатор понимает, что не может управлять всей организацией один, «тянуть» груз управления на себе, поэтому-то именно здесь появляется потребность в изменении структуры с простейшей: 1 управляющий элемент и управляемая совокупность других элементов на какую-то более сложную. И. Адизес говорит о том, что для того, чтобы попасть на следующий этап, ей необходимо стать более управляемой и предсказуемой. Что касается IT-компаний, то ввиду большого объема работы и для удобства совместной разработки используется системы централизованного управления версиями, соответственно отсюда идет возможность инкрементального выпуска продукта. А ввиду простоты и того, что члены каждой команды плотно работают вместе, обычно используется agile-методология уже на этой стадии развития компании (иногда осознано, а иногда нет). В IT-сфере у основателей на данном этапе возникают следующие проблемы: Как распространять знания между проектами? Данная проблема возникает, так как все проекты допускают одни и те же ошибки, а основатель не может уже все контролировать и выступать в роли единого для всех центра хранения опыта и знаний? Основатель перестает понимать, как ему управлять этими командами одному, он не справляется. Не хватает сотрудников для новых направлений и проектов, а на рынке нет хороших специалистов и поэтому хочется

2

растить своих, но нет ресурсов для обучения. Организации на данном этапе хочется делать какие угодно проекты в своей области, а для этого нужна соответствующая архитектура, определенная гибкость компании, а сейчас это просто совокупность обособленных проектов и единственная гибкость заключается в том, что можно перекидывать людей с проекта на проект. Каждый проект -это кросс-функциональная, самостоятельная команда. И. Адизес предупреждает о рисках, которые появляются, когда компания хочет объять «всё». И. Адизес определяет главную организационную задачу этого этапа "от обратного": фирма должна четко определить для себя, чем она не должна заниматься. Стремление объять необъятное, в том числе неведомое работникам компании, может в один момент уничтожить организацию. Но в то же время на Российском рынке невозможность «подхватить» новый проект тоже может уничтожить организацию. Поэтому в первую компания должна для себя определить границы той гибкости, которая ей нужна, с одной стороны, чтобы удержаться на Российском рынке, а с другой стороны, чтобы не прийти к хаосу и дезорганизации. Т.е. компания должна выделить для себя направления движения, расставить между ними приоритеты и строить гибкость внутри компании такую, которая позволит этим планам действовать.

Выбор методологии для построения архитектуры компании

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

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

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

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

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

гибкой.

Методология должна подходить для IT-сферы, с ее спецификой.

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

SOA (Service-oriented architecture)

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

Эталонная модель SOA представлена на рисунке 1, в ней отображены ключевые характеристики [7].

Рисунок 1 Эталонная модель 80Л Методология построения архитектуры предприятия по Захману

Данная методология достаточно проста в понимании. Она представляет собой описание каждого компонента архитектуры в координации со всеми остальными (см. Рисунок 2 [12]).

с ®

£ Плани-

ч: ровщик ■

о

в >»

9- Владелец.

V менеджер

х

о

х

ш

Конструктор, х архи-х теклюр

1

0

то Проекти-Я" ровщик

9 о.

х

2

а Разра-* ботчик

1

г <в Г:

Данные ЧТО

Функции КАК

Дислокация, сеть ГДЕ

Люди Время Мотивация КТО КОГДА ПОЧЕМУ

Список важных понятий и объектов Список основных бизнес-процессов Территориальное располо- Ж6ИИ0 Ключевые организации Важнейшие события Бизнес-цели и стратегии

Концептуальная модель данных Модель бизнес-процессов Схема логистики Модель потока работ (workflow) Мастер-план реализации Бизнес-план

Логические модели данных Архитектура приложений Модель распределенной архитектуры Архитектура интерфейса пользователя Структура процессов Роли и модели бизнес-правил

Физическая модель данных Системный проект Технологии архитектура Архитектура презентации Структуры управления Описания бизнес-правил

Описание структуры данных Программный код Сетевая архитектура Архитектура безопасности Определение временных привязок Реализация бизнес-логики

Данные Работающие программы Сеть Реальные люди, организации Бизнес-собьггия Работающие бизнес-стратегии

Данные Функции, Процессы

Сеть, расположение систем

Люди, Время, Мотивация органи- расписа-зации ния

Сфера

действия

(контекст)

Модель предприятия

Модель системы

Технологическая

(физическая) модель

Детали реализации

предприятие

Рисунок 2 Фрэймворк для построения архитектуры по Захману

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

Enterprise scrum - методология построения архитектуры предприятия

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

Наложение scrum на компанию X

Рассмотрим структуру компании, как уже было сказано ранее, компания находится на стадии «Давай-давай!» и у нее нет жесткой структуры, во главе стоит основатель, у основателя есть помощник, который выполняет примерно те же функции, что и основатель. Если разделить компанию на блоке по типу основной компетенции у каждого сотрудника, то получится вид, изображенный на рисунке 1. Бухгалтерия и поддержка ПО не входят в компанию с правовой точки зрения и с точки зрения участия людей с данным типом компетенций во внутреннем развитии компании.

Рисунок 3 Декомпозиция компании X по типу основной компетенции у сотрудников

С точки зрения создания продукта, деятельность компании можно разделить на внешнюю - создание итогового продукта для внешнего заказчика и внутреннюю - развитие компании. Внешняя деятельность представлена в виде проектов. Один и тот же сотрудник может участвовать в нескольких проектах. Поиском новых проектов занимается владелец компании, его помощник, а также могут подключаться проектные менеджеры. Поиском и наймом новых сотрудников занимается HR отдел (3 человека) совместно с главными специалистами,

5

если необходимо найти специалиста с типом компетенции аналитик, то участвуют главный аналитик и HR-специалист или просто главный аналитик. Все главные специалисты так или иначе участвуют в проектах. Обучением сотрудников занимаются главные специалисты, а также ведущие специалисты, курирует обучение один из проектных менеджеров, обучение, как правило, подразумевает набор стажеров, есть также индивидуальное развитие. Разработкой внутренних ИС (информационных систем) занимаются стажеры разработчики и специалисты, которые занимаются по данному набору стажеров обучением сотрудников. Поддержкой внутренних ИС занимаются специалисты по тестированию и разработчики.

Владелец продукта -предприятия

О

Помощник основателя

О

Внешняя деятельность компании, создание продуктов

Проект 1

Проект 15

Поиск новых проектов

Найм сотрудников

Обучение сотрудников

Разработка внутренних ИС

го к

с 5

£ о-

§ 5 £

и с

° I

* I

Ё 3

I 2-

к а>

I £

X X

О) го

О- Ч

Ь т

>• о

X и ой

Поддержка внутренних ИС

Рисунок 4 Декомпозиция компании X по типу деятельности

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

Разработка, аналитика, тестирование

Главный специалист

О

Стажер

Рисунок 5 Иерархия компетентностных направлений тестирования, аналитики и разработки

Для управления проектами и HR иерархия представлена на рисунке 6.

HR-отдел, проектное управление

Управление грейдами

О /-\

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

О о

/■-ч f--

специалист специалист

Рисунок 6 Иерархия компетентностных направлений управления проектами и HR

Для принятия Scrum необходимо использовать три типа Scrum- команд (см. Рисунок 7 [11]). Первый тип -Scrum-команда, ответственная за управление внедрением Scrum, она называется Enterprise Transition team (команда по трансформации предприятия). Команда второго типа отвечает за выполнение работы по внедрению и подвергает предприятие изменениям, заставляет компанию меняться. Эти команды называются командами развертывания Scrum. Scrum-команды третьего типа создают итоговые продукты. Они называются командами разработки [10].

Команда внедрения Scrum

ETC Scrum-команда

Команда внедрения Scrum

Команда внедрения Scrum

Рисунок 7 Организация проекта по трансформации компании

Высшим менеджментов в таком случае занимается ETC команда. Основатель компании так и остается во главе, он является владелец продукта- компании.

ScrumMaster ETC команды отвечает за единство ETC команды. Роль ScrumMaster должен выполнять полноправный, уважаемым в компании и способный человек, который имеет глубокие знания о предприятии. Он должен обладать достаточной решимостью, чтобы внедрить Scrum и должен уметь работать с людьми [11]. В рассматриваемой компании таким человеком является главный аналитик, который работает с самого начала и который является лидером в компании, также он курирует аналитиков.

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

Рассматриваемая компания находится на этапе «Давай-давай!» и, как уже говорилось ранее, в ней нет явного управленца, кроме основателя, но есть много единомышленников, лидеров и способных людей, они и входят в данную команду, а именно (см. Рисунок 8):

• Помощник основателя (см. Рисунок 3, рисунок 6) - это человек, который на одном проекте выполняет роль project manager, он же пресейл менеджер, он же занимается нахождением новых проектов, у него процент постоянного присутствия в команде разработки равен двадцати процентам;

• Главный аналитик - лидер, работал уже на множестве различных проектов компании, занимался не только аналитикой, выступал в роли управленца, в роли тестировщика, разработчика, в общем кем было необходимо, занимается развитием кадров, используется, как «тяжелая артиллерия», на срочных проектах работает на 90%, как консультант в области аналитики участвует на 5 проектах из 12 существующих на 50%;

• Руководитель HR (см. Рисунок 6), пришла через год после основания, берет на себя по максимуму ответственности, отлично отбирает кадры;

• Главный разработчик. Он же выступает в роли консультанта-архитектора информационных систем на многих проектах компании, умеет все, что угодно: тестировать, писать документацию, знает множество языков программирования, пришел через 6 месяцев после основания, на срочных проектах на 60%, на одном проекте на 20%;

• Главный аналитик. Он также выступает в роли архитектора информационных систем, используется, как «тяжелая артиллерия», на срочных проектах работает на 40%, на постоянной основе задействована на проекте на 50%;

• Главный тестировщик. Он участвует на четырех проектах, в качестве поддержке внедренных систем, курирует внутреннюю поддержку ИС.

ETC Scrum-команда

Главный Главный

аналитик 1 разработчик

о А о

о

Помощник основателя

О

С

о

Главный | Руководитель

аналитик 2 Главный HR

тестировщик

Рисунок 8 Команда трансформации компании

Бухгалтеры и поддержка ПО не входят в состав ETC, т.к. они определены, как внешние специалисты по отношению к предприятию, услугами бухгалтера пользуются на периодической основе. Юридическая помощь также является внешней, ее структура не постоянна.

Команда ETC Scrum фиксирует цель на каждую итерацию или Sprint. Затем члены команды работают вместе и делают все, что необходимо для достижения этой цели. Они составляют приоритезированный список работ, который необходимо выполнить для стимуляции принятия scrum, он называется бэклогом продукта трансформации (Transition Product Backlog). TPB - это тип бэклог продукта, продуктом которого является измененное предприятие. Элементы TPB определяются командой ETC, а также исходят от команд разработки Scrum. Наивысшим приоритетом в TPB обладают задачи по запуску проектов разработки продукта с использованием Scrum. Остальная часть TPB - это работа, необходимая для принятия Scrum. Часть элементов - это масштабирование Scrum на всех проектах. Часть - изменения в организационной, инженерной и производственной деятельности. Некоторые из них - это работа, необходимая для устранения препятствий, разрешения конфликтов и внесения изменений [11]. Команда ETC Scrum создает команды развертывания Scrum для выполнения задач из TRB с наивысшим приоритетом. Работа с бэклогом изображена на рисунке 9.

Бэклог для одного спринта

Scrum проекты, новые или измененные процессы

Команды разработки

Бэклог трансформа ции компании

Команда внедрения скрама

Рисунок 9 Работа с бэклогом Один из членов команды ETC выступает владельцем продукта для каждой команды развертывания в течение каждого спринта.

Команда развертывания состоит из сотрудников, которые работают не на внешний продукт, а на внутренний: развитие и поддержка предприятия. В него входят: отдел поддержки (системные администраторы), отдел HR и т. д. В рассматриваемой компании обслуживанием ПО занимается внешний по отношению к компании отдел. Есть отдел HR, состоящий из одного руководителя и двух специалистов. Развертыванием будет заниматься HR отдел, Люди, которые сами вызвались совершенствовать компанию, каждый из них входит в какую-либо команду разработки - это два аналитика, а также главные аналитик 2 и разработчик из ETC команды (см. Рисунок 10). Продуктоунером у первой команды развертывания будет второй аналитик, а у второй команды - руководитель HR.

Команды развертывания scrum

О

f-ч

Главный аналитик 2

О

/---

Менеджер проекта

О --

Главный разработчик

О О

S-N

Аналитик Аналитик

HR

Рисунок 10 Команды развертывания scrum

Цель спринта для ETC команды заключается в устранении командой развертывания этих препятствиях и в создании корпоративных изменений, которые оптимизируют производительность и эффективность. Эти спринты короче, чем спринты для команд разработки, чей спринт обычно длятся один месяц [10]. Более короткая длина позволяет команде ETC более внимательно следить за изменениями предприятий и их воздействием. Каждая команда по развертыванию проводит ежедневную 15 минутную встречу «daily scrum». Команда ETC также проводит ежедневные встречи, где члены команды договариваются, как будут наставлять команды по развёртыванию и помогать им.

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

Команда трансформации и разработки

Рисунок 11 Жизненный цикл спринта

Кен Швабер в своей книге «Enterprise and scrum» составляет план по внедрению scrum, который состоит из того, какого рода встречи и действия должны быть осуществлены и в какое время: первый месяц, второй месяц, третий месяц и последующее время, а также какие риски у компании будут и какие ошибки могут возникнуть у компании [11].

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

Заключение

В данной статье были рассмотрено основные проблемы малых IT-компаний на Российском рынке. Они возникают на стадии «Давай-давай!». Как способ системно решить возникшие проблемы было предложено повысить гибкость компании путем реорганизации компании, для чего было предложено использование в компании методологии построения архитектуры предприятия для управления этой компанией. Были описаны предоставленные ниже варианты решения по применению к компании методологии построения архитектуры предприятия:

1. Сервисно-ориентированная методология SOA;

2. Методология построения архитектуры предприятия по Захману;

3. Scrum.

Из них была выбрана методология scrum, т.к. она соответствовала требованиям, предъявляемым к

методологии, она проста в понимании, легка в наложении, позволяет компании быть гибкой и управлять изменениями подходит для IT-области, но она не позволяет управлять всеми основными направлениями, а именно правовой сферой. Было описано применение scrum для рассматриваемой компании.

Данное решение позволит подстраиваться под меняющийся, бедный и непостоянный рынок и обеспечит постоянное развитие компании для ее дальнейшей трансформации на из стадии «Давай-давай!» на стадию «Юность».

Список используемой литературы

1. Рейтинг Российских IT-компаний - 2016//Тематическое приложение к ежедневной деловой газете РБК. 2017 №075 (2572).

2. Малый и средний бизнес. Как подобраться к госзаказу//Тематическое приложение к ежедневной деловой газете РБК. 2017 №033 (2530).

3. Jones, N.: SMEs Life Cycle - Steps to Failure or Success?// AU-GSB e-Journal 2,2 2009.

4. Dina Jacobs1, Paula Kotze, Alta van der Merwe, Aurona Gerber. Enterprise Architecture for Small and Medium Enterprise Growth// First Enterprise Engineering Working Conference (EEWC 2011), Antwerp, Belgium, May 1617, 2011

5. Maxime Bernaert, Geert Poels. Enterprise Architecture for Small and Medium-Sized Enterprises//Proceedings of the 7th SIKS Conference on Enterprise Information Systems (EIS2012) [ Электронный ресурс]. 2012. URL:https://www.researchgate.net/publication/239636037_Enterprise_Architecture_for_Small_and_Medium-Sized_Enterprises (Дата обращения: 03.06.2017).

6. Жизненный цикл организации [Электронный ресурс]. URL: http://adizes.ru/adizes-methodology/life-cycle-of-organization/ (Дата обращения: 03.06.2017).

7. Bertrand Portier. Service, architecture, governance, and business terms [Электронный ресурс]. URL: https://www.ibm.com/developerworks/webservices/library/ws-soa-term1/index.html?S_TACT=105AGX99&S_CMP=CP (Дата обращения: 03.06.2017).

8. Zachman Framework [Электронный ресурс]. URL: https://en.wikipedia.org/wiki/Zachman_Framework (Дата обращения: 03.06.2017).

9. Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham,Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas. Agile-манифест разработки программного обеспечения [Электронный ресурс]. URL: http://agilemanifesto.org/iso/ru/manifesto.html (Дата обращения: 03.06.2017).

10. Кен Швабер, Джефф Сазерленд. Руководство по Скраму [Электронный ресурс]. URL: http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-Russian.pdf (Дата обращения: 03.06.2017).

11. Ken Schwaber. The Enterprise and Scrum: Microsoft Press. Washington. 2007. с. 176

12. Применение модели Захмана для проектирования ИТ-архитектуры предприятия [Электронный ресурс]. URL: http://www.interface.ru/home.asp?artId=25945 (Дата обращения: 03.06.2017).