Исследование применимости гибких методологий для территориально распределенных проектов по разработке программного обеспечения (на примере компании ЗАО "ЛАНИТ")

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Введение

За последние годы существенно выросли требования, которые предъявляются к предпринимателю в процессе ведения бизнеса. «Для успешного выживания на рынке и реализации стратегии развития, фирма должна быть гибкой и динамичной, поскольку ключевой фактор конкуренции сегодня -- время. Кроме того, внешняя среда бизнеса становится все более комплексной и неопределенной, что требует умения быстро адаптироваться и устойчивости организации бизнеса» - так отзываются о тенденциях современного подхода к управлению бизнесом российские ученые [1]. В контексте динамически меняющейся бизнес-среды, организации вынуждены изменять также и свои требования к программному обеспечению. Таким образом, можно выделить два ключевых аспекта важных для заказчика разработки программного обеспечения:

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

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

Согласно отчету, сделанному независимой международной исследовательской компанией Standish Group в 2011 году, проекты, использующие гибкие методологии разработки в три раза более успешные, чем проекты, использующие методологию «водопад» (см. Рисунок 1). Под гибкими методологиями (Agile software development) понимается концептуальный подход, в рамках которого выполняется разработка программного обеспечения [3].



Рисунок 1. Процент успешных проектов, использующих "водопад" и "agile" методологии

Большинство гибких методологий нацелены на минимизацию рисков, путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся одну-две недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре, и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, кодирование, тестирование и документирование. Список основополагающих принципов гибких методологий описан в Agile-манифесте [4].

Согласно восьмому ежегодному исследованию «State of Agile» за 2013 год процент компаний, практикующих гибкие модели разработки, увеличился до 88% по сравнению с 84% в 2012 и 80% 2011 годах. Большая часть компаний (53%) практикует гибкие методологии на протяжении последних 2-5 лет [5].

Все больше компаний перенимают опыт использования территориально распределенных проектных команд. Подобный подход позволяет оптимизировать организационную структуру компании: снизить затраты на заработную плату с помощью найма сотрудников в регионах, выбирать наиболее талантливых специалистов без привязки с конкретной территории. Особенно популярна практика территориально распределенных проектных команд среди крупных организаций в области ИТ. Однако вместе с достоинством территориально распределенных проектных команд возникает ряд затруднений, с которыми вынужден сталкиваться руководитель проекта. К проблемам проектных команд данного типа относят: сложность управления, поддержания уровня осведомленности о состоянии проекта всех членов команды, недопонимание в постановке задач, повторное выполнение работы и так далее. Данные проблемы приводят к увеличению длительности проекта, а также к финансовым потерям. В качестве методологии разработки программного обеспечения в территориально распределенных проектах многие компании отдают предпочтение agile методологиям. В рамках исследования «State of Agile» в 2013 году было выявлено, что количество людей, участвующих в территориально распределенных проектах, практикующих гибкие методологии разработки увеличилось почти вдвое: 76% по сравнению с 35% в 2012 году [5].

Территориально распределенные проекты по разработке программного обеспечения обладают определенной спецификой, что порождает ряд проблем особенно обостряющихся при использовании гибких методологий. Например, построение модели коммуникации, позволяющей воплотить принципы и идеи гибких методологий разработки, при ограниченности каналов коммуникации, а также различиях во временных зонах, представляет собой сложную задачу для руководителя проекта [6]. Большая часть проблем в проектах подобного типа возникает вокруг двух тем: передача информации и построение взаимоотношений в команде [7].

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

В работах таких авторов, как Вольфсон Б. [8], Сандип Д. [9], H. Вемулапалли Х. [6], Маннаро К. [10] рассматриваются различные гибкие методологии с точки зрения применения в территориально распределенных проектах по разработке программного обеспечения, также затрагивается вопрос масштабирования методологий и выявления основных аспектов, на которые необходимо обратить внимание руководителю при внедрении гибких методологий. В работах исследователей рассматриваются преимущественно следующие гибкие методологии: Scrum, Kanban и Экстремальное программирование (XP). Отдельно в литературе упоминается вопрос возможности комбинирования методологий для достижения целей проекта, так, например, использование Scrumban, сочетающего в себе компоненты Scrum и Kanban [11]. Однако в научных публикациях и статьях не рассматривается вопрос комбинирования гибких методологий для совершенствования управления процессами разработки программного обеспечения в территориально распределенных проектах, а также мало внимания уделено тому, какую именно методологию лучше выбрать для территориально распределенного проекта. Например, в случае использования методологии Srum в территориально распределенных проектах предлагается применение одного из трех подходов: автономный Scrum, Scrum of Scrums, имеющих пересечения в проектных командах, и полностью интегрированный Scrum [12] (см. Рисунок 2).

Рисунок 2. Подходы организации территориально распределенных проектов, использующих Scrum

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

Практика agile в России только начинает набирать популярность. В настоящий момент существует несколько известных компаний, оказывающих консалтинговые и коучинг услуги по применению agile методологий на российском рынке. Ежегодно в Росси проводятся конференции AgileDays [13] и другие, в рамках которых обсуждаются методологии, применяемые для гибкого управления процессами - Scrum, Kanban, Lean и т.д., продуктовая разработка, инженерные практики и DevOps и многое другое.

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

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

Предметом исследования являются гибкие методологии управления проектами по разработке программного обеспечения.

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

Для достижения заданной цели необходимо решить следующие задачи:

1. Выделение основных проблем характерных для территориально распределенных проектов по разработке программного обеспечения;

2. Сравнительный анализ семейства методологий agile на предмет покрытия выявленных проблем;

3. Исследование возможности совместного использования компонент различных методологий для территориально распределенных проектных команд;

4. Разработка требований к предложениям по внедрению гибких методологий;

5. Формирование ключевых компонентов предложения по внедрению;

6. Проведение апробации предложений на примере одного проекта;

7. Оценка результатов внедрения предложений.

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

В ходе работы использовались следующие методы исследования: анализ, формализация, моделирование, наблюдение и измерение.

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

Разработка предложений рассмотрена на примере компании ЗАО «ЛАНИТ» - ведущей в России и СНГ многопрофильной группе ИТ-компаний. В настоящее время ЛАНИТ является одним из крупнейшим российских системных интеграторов и партнером более двухсот основных мировых производителей оборудования и программных решений в области высоких технологий. В частности внедрение предложений производилось в отделе хранилищ данных и BI департамента корпоративных систем (ДКС) на проекте разработки системы анализа логистической деятельности в Почте России (проект САД Логистика).

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

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

Исследование включает в себя три главы. В первой главе рассматриваются основные проблемы, которые возникают в территориально распределенных проектах по разработке ПО. В работе анализируется семейство гибких методологий на предмет покрытия выявленных проблем. Далее проводится отбор метрик, подходящих для оценки общей производительности территориально распределенных проектов по разработке ПО, использующих гибкие методологии. На примере проекта САД Логистика производится оценка производительности проекта на основании выделенных метрик.

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

В третьей главе приводится описание процесса апробации предложений на проекте САД Логистика. Сначала был разработан план внедрения предложений, включающий в себя последовательность шагов, а затем проведена оценка эффективности предложений.

Глава 1. Анализ проблем внедрения гибких методологий в территориально распределенных проектах по разработке программного обеспечения

1.1 Формирование списка проблем управления проектами в территориально распределенных проектах

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

Тенденция к применению территориально распределенных команд, разрабатывающих ПО, подпитывается со стороны экономики и желанием компаний получить конкурентные преимущества и развивать бизнес-модель. Компании, ищущие способы снизить затраты и желающие иметь наиболее талантливые кадры, отдают бизнес-процессы на аутсорсинг или усиливают свое присутствие в регионах [14].

Параллельно с распространением территориально распределенных проектов, растет процент проектов по разработке программного обеспечения, использующих гибкие методологии. Более половины опрошенных в рамках исследования State of Agile в 2014 году заявили, что используют гибкие методологии в большинстве проектов (см. Рисунок 3. Процент проектов по разработке ПО, использующих Agile).



Рисунок 3. Процент проектов по разработке ПО, использующих Agile

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

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

Наиболее сложной задачей в проекте представляет собой организация процесса коммуникации между членами команды. Основным ограничением и причиной возникновения проблем является ограниченность каналов коммуникации, а также уменьшение невербального общения. Успешность территориально распределенных проектов сильно зависит от процесса коммуникации, то есть от того насколько хорошо члены команды будут проинформированы о текущем состоянии проекта. Различия во временных зонах снижает возможность взаимодействия «лицом к лицу» даже с помощью различных программных решений. В таком случае многие проекты используют в качестве средства коммуникации письма и документы, как наиболее простой способ поддержания осведомленности удаленной части команды о происходящем. На написание писем у рядового сотрудника, согласно исследованиям International Data Corp (IDC), в день уходит около 20% рабочего времени. В случае территориально распределенного проекта затрачиваемый процент времени на написание писем и документов существенно возрастает, поэтому руководителю приходится сталкиваться с проблемой высоких издержек на коммуникацию, как временных, и так стоимостных. Различия во временных зонах уменьшает количество часов, которые команда находится в контакте - это может быть критично для многих проектов по разработке программного обеспечения, в особенности при переходе от этапа формирования требований к этапу разработки, когда аналитики вынуждены плотно сотрудничать с разработчиками. Для территориально распределенных команд также характерны проблемы инициации процесса коммуникации, когда сотрудник либо не знает к кому конкретно обратиться, либо выбранный канал коммуникации не позволяет получить ответ. Процесс коммуникации занимает много времени, поэтому частота взаимодействия между частями команды снижается, что может привести к формированию объема информации, которым владеет только одна сторона и ошибкам в реализации.

Программный продукт, разработанный командой, должен соответствовать определенным требованиям: к функционалу, к качеству и так далее. Контроль соответствия программного продукта требованиям в первую очередь ложится на плечи руководителя проекта, который отвечает за корректирование процесса разработки для успешного завершения проекта. В территориально распределенном проекте значительно сложнее организовать контроль процесса разработки из-за различий во временных зонах [15].

В контексте того, что территориально распределенные команды практически не встречаются вживую, но при этом работают вместе для достижения общих целей, сложной задачей является формирование ощущения доверия внутри коллектива. Члены распределенной команды не участвуют в жизни друг друга в отличие от команды, находящейся в одном офисе, чей уровень доверия формируется по ходу работы над проектом. Доверие способствует большей открытости в команде, позволяет принимать и высказывать конструктивную критику процесса реализации проекта. Формирование чувства доверия является одним из ключевых факторов успеха проекта, так как доверие является объединяющим фактором команды [16].

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

Объединив результаты изученных исследований, сформируем единый перечень проблем территориально распределенных проектов по разработке программного обеспечения (см. Таблица 1).

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

Область возникновения сложностей	Сложности
Коммуникация	Проблема инициации процесса коммуникации Недопонимание между членами команды Низкая частота коммуникации Высокие затраты на коммуникацию Различия во временных зонах
Контроль проекта	Сложность контроля процесса разработки Сложность контроля качества программного продукта
Формирование доверительных отношений	Недостаток доверия между членами команды Отсутствие боевого командного духа
Управление знаниями	Отсутствие обмена опыта между частями команды

1.2 Анализ семейства гибких методологий по разработке программного обеспечения

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

По результатам 8-го ежегодного исследования «State of Agile», проводившегося в 2013 году, были выявлены самые популярные гибкие методологии управления проектами, использующиеся в проектах по разработке программного обеспечения.

Самой популярной гибкой методологией по результатам 2013 года признан Scrum, составивший 55% от общего числа проектов (см. Рисунок 4), остальные методологии используются в 10 и менее процентах случаев.

Для целей настоящего исследования были отобраны следующие методологии:

1. Scrum;

2. eXtreme Programming (XP);

3. Feature Driven Development (FDD);

4. Kanban.



Рисунок 4. Статистика популярности гибких методологий за 2013 год

1.2.1 Scrum

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

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

Всю работу лучше вести короткими (от 1 до 4 недель) фиксированными итерациями - спринтами, поставляя в конце каждого из них законченный функционал, который можно при необходимости вывести на рынок - инкремент продукта. Команда согласно своей скорости набирает задачи на неизменяемую по времени итерацию - спринт. Каждый день проводится скрам-митинг, на котором команда синхронизирует свою работу и обсуждает проблемы. В процессе работы члены команды берут в работу элементы беклога согласно приоритету.

В конце каждого спринта проводится обзор спринта, чтобы получить обратную связь от владельца продукта, и ретроспективу спринта, чтобы оптимизировать процессы. После этого владелец продукта может изменить требования и их приоритеты и запустить новый спринт (см. Рисунок 54) [8].

Рисунок 5. Общая схема Scrum

В части проблем, связанных с процессом коммуникации на проекте, большинство гибких методологий предлагают идентичные подходы и практики [17], которые будут описаны в подразделе, посвященному методологии Scrum. Таким образом, будем считать, что все рассматриваемые гибкие методологии полностью покрывают проблемы: инициации процесса коммуникации, низкой частоты коммуникации, различий во временных зонах, высоких затрат на коммуникацию.

Для того чтобы сделать процесс коммуникации в команде наиболее эффективным, то есть требующим минимальных трудозатрат, предлагается использовать наиболее «богатые» каналы коммуникации - различные варианты видеоконференций (см. Рисунок 6) [18].

Рисунок 6. Эффективность каналов коммуникации

Упрощение процесса инициации взаимодействия между членами команды достигается с помощью создания общедоступного списка контактов, в котором дополнительно указывается пересечение в рабочих часах, в случае различия во временных зонах. Все члены команды в течение рабочего дня должны быть доступны в онлайн-мессенджерах или скайпе, чтобы снизить процент использования почты. Перманентная доступность членов команды в онлайн-мессенджерах и скайпе также позволяет уменьшить число вопросов, которые возникают в рамках ежедневных митингов, тем самым снизив затраты на коммуникацию [19].

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

Недопонимание между членами команды может быть сведено к минимуму в результате применения таких методик, как совместная работа в рамках первых спринтов, общение вне работы (возможно виртуальное) и так далее [9].

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

К вопросу формирования доверия в команде в Scrum подходят основательно, существует ряд техник и методик, которые помогают команде сплотиться и сформировать открытые дружеские отношения как внутри команды, так и с владельцем продукта. Популярной техникой сплочения команды является совместная работа в рамках первого спринта, а также дополнительные нерабочие мероприятия, на которых члены команды сближаются и начинают лучше понимать друг друга. Предлагается организовать первичную встречу всей команды с владельцем продукта вживую, для того, чтобы команда получила представление о бизнес-целях и задачах проекта, а также сформировала понимание об ожиданиях заказчика от команды разработчиков - это позволит поднять боевой дух команды и мотивировать сотрудников на реальные цели. Гибкие методологии также предлагают ряд игр для проектной команды, направленных на построение доверительных отношений, самыми известными среди них являются Scrum из ада, XP игра по планированию, производство бумажных шляп, холст доверия и т.д.[20]. Следует отметить, что игры применяются также и в других гибких методологиях, например, для методологии Kanban существуют специализированные игры для проектной команды.

Однако Майкл Кон, специалист в области гибких методологий, заявляет, что важно не увлекаться мероприятиями по сплочению команды в начале проекта. Таким образом, он призывает в первую очередь сфокусироваться на получении первого рабочего образца продукции, а уже после проводить нерабочие мероприятия, чтобы позволить участникам проекта разбиться на подгруппы с учетом их умений, навыков и интересов [21].

Одним из вариантов решения проблемы управления знаниями в территориально распределенных проектах по разработке программного обеспечения в Scrum является применение политики «амбассадоров». Под политикой «амбассадоров» понимается подход, когда один из членов команды, который обычно работает с одной группой людей, на определенный промежуток времени, уезжает и работает с другой частью команды, перенимая ее опыт и навыки. Промежуток времени может составлять один спринт или менее. После возвращения «амбассадор» делится полученными знаниями со своими коллегами и выдвигает предложения по оптимизации взаимодействия между частями команды. У данного подхода есть существенный недостаток, он требует высоких затрат на частые командировки, что может быть существенно для проектов, находящихся в разных странах [22]. Дополнительным ограничением является сложность достижения мобильности членов команды, по причине привязанности к локальным ресурсам. По этой причине будем считать, что Scrum покрывает проблему управления знаниями частично, так как данная практика может применяться в ограниченных случаях.

Контроль качества программного продукта в Scrum возложен в первую очередь на владельца продукта, таким образом, в случае если владелец продукта находится в другом городе или стране, данный контроль ослабевает и требуется применение дополнительных методик, например, использование уполномоченного владельца продукта. Однако использование уполномоченного владельца продукта порождает ряд дополнительных трудностей (недостаточная глубина знаний о предметной области, недостаток взаимодействия с владельцем продукта и последующие расхождения в требуемом функционале), и не может полностью заменить владельца продукта [23]. С точки зрения проводимого исследования, рассматривается территориально распределенная команда, при этом владелец продукта находится рядом с одной частью команды, поэтому будем считать, что проблема контроля качества покрывается в Scrum полностью.

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

· Создание отдельной скрам-команды для каждой территории, обладающей самостоятельностью (Scrum of Scrums). Такой подход возможен только если удаленная часть команды является функционально целостной, то есть состоит из всех необходимых для разработки членов команды, что не применимо для целей настоящего исследования.

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

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

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

1.2.2 Kanban

По словам Бориса Вольфсона, Kanban является самой «не директивной методологией», и в сфере информационных технологий может рассматриваться как инструмент визуального менеджмента в дополнение к Scrum, нежели чем полностью самостоятельная методология. Kanban основывается на 4 основных принципах:

1. визуализируйте процесс;

2. ограничивайте объем незавершенной работы;

3. фокусируйтесь на процессе;

4. совершенствуйте процесс.

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

Несмотря на то, что основой Kanban является визуализация процесса разработки, существует также практика применения данного методологии для территориально распределенных команд. Контроль проекта осуществляется с помощью доски, перенесенной в виртуальное пространство (см. Рисунок 7).



Рисунок 7. Виртуальная доска

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

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

Хорошей практикой является формирование отдельных самостоятельных подкоманд, каждая из которых располагается в одном офисе. Такие команды имеют свой пул задач и доску, а также проводят раздельные ежедневные встречи. Для того чтобы члены команды были в курсе, чем занимается другая подкоманда, каждому сотруднику назначается «товарищ» из другой подкоманды, с которым происходит обмен опытом и информацией о проводимых работах. «Товарищ» может меняться каждые две недели. Такой подход позволяет не только сформировать понимание общего хода проекта, но и установить доверительные отношения в команде, чего обычно сложно достигнуть в территориально распределенных проектах по разработке программного обеспечения [24]. Применение практики «товарищей» покрывает следующие проблемы: недостаток доверия между членами команды, отсутствие обмена опытом между частями команды и частично сложность контроля процесса разработки. Также необходимо отметить, что данную практику следует применять, когда территориально распределенные команды примерно равны по количеству человек, и «товарищем» является человек, имеющий схожие рабочие обязанности или понимающий специфику работы другого человека.

Несмотря на ряд книг и публикаций, описывающих применение методологии Kanban для разработки программного обеспечения в том числе и для территориально распределенных проектов, один из основателей подхода Kanban Дэвид Андерсон заявляет, что Kanban не создан для управления жизненным циклом разработки программного обеспечения. Практики Kanban должны применяться только к существующему процессу разработки для того, чтобы сделать текущий процесс более управляемым и гибким [25].

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

1.2.3 eXtreme Programming

eXtreme Programming (XP) или экстремальное программирование - это легковесная методология, которая набирает все большую популярность в проектах по разработке программного обеспечения. XP продвигает разработку программного обеспечения, опирающуюся на принципы итеративности, активного взаимодействия внутри команды, взаимодействия с заказчиком, смелости и готовности идти на риск. Экстремальное программирование включает в себя 12 практик:

1. Игра в планирование (Planning Game)

2. Тестирование (Testing)

3. Повторное кодирование (Refactoring)

4. Коллективное владение кодом(Collective Code Ownership)

5. Простота проектирования (Simple Design)

6. Парное программирование (Pair Programming)

7. Небольшие релизы (Small Release)

8. Постоянная интеграция (Continuous Integration)

9. Заказчик в команде разработки (On-site Customer)

10. Стандарты кодирования (Coding Standards)

11. Метафора (Metaphor)

12. 40-часовая рабочая неделя (40-hour Work Week)

Уже на конференции «Экстремальное программирование и гибкие процессы в программной инженерии XP2000» [26] затрагивалась тема использования экстремального программирования для территориально распределенных команд. Позднее идея сформировалась как ответвление данной методологии в виде распределенного экстремального программирования (DXP). Для использования DXP члены команды должны быть хорошо знакомы и понимать друг друга, для того, чтобы применять практики, предлагаемые экстремальным программированием. Данная методология не рекомендуется для новых команд, которые сразу начали свою работу как территориально распределенные и никогда не встречались, а также командам, которые состоят больше, чем из 5 человек.

Практики, используемые в XP, рассматривались на предмет покрытия проблем выявленных в первом разделе (см. Таблица 2). Не все практики способствуют перекрытию проблем, а также не все проблемы имеют конкретные практики для решения.

Таблица 2. Покрытие проблем территориально распределенных проектов практиками экстремального программирования

Недопонимание между членами команды	Pair Programming, Coding Standards, Metaphor, Collective Code Ownership
Низкая частота коммуникации	-
Высокие затраты на коммуникацию	-
Различия во временных зонах	-
Сложность контроля процесса разработки	Planning Game, Small Release
Сложность контроля качества программного продукта	On-site Customer
Недостаток доверия между членами команды	Pair Programming
Отсутствие боевого командного духа	Pair Programming
Отсутствие обмена опыта между частями команды	Pair Programming

Проблемы контроля и координации работ предлагается предотвращать с помощью подробного планирования и разбивания работ на небольшие релизы.

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

Проблема недопонимания между членами команды устраняется с помощью ряда практик: парного программирования, коллективного владения кодом, стандартов кодирования, применения метафор. Применение метафор и стандартов кодирования позволяет сделать код более понятным и легко читаемым, позволив реализовать принципы коллективного владения кодом. Коллективное владение кодом в свою очередь позволяет снизить зависимость от конкретных сотрудников и временных поясов, распределяя ответственность за код и его качество между всеми разработчиками [27].

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

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

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

1.2.4 Feature Driven Development

Feature Driven Development (FDD) - это гибкая методология разработки программного обеспечения, появившаяся в 1980 году, в результате сотрудничества Джеффа Де Люка и Питера Кода, совместившая преимущества других гибких подходов таких как Scrum и eXtreme Programming с методами модели-ориентированных подходов.

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

Согласно FDD, вся работа на проекте разбивается на 5 процессов (см. Рисунок 8). В первую очередь, в рамках нулевой итерации, или как это называется в методологии FDD, первичной проектной деятельности [30] реализуются три процесса: разработка общей модели, составление иерархического списка необходимых функций и оценка каждой функции с точки зрения трудозатрат и ответственных за реализацию.

Рисунок 8. Схема 5 процессов методологии FDD

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

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

Большое внимание в методологии FDD уделяется проверкам для того, чтобы обеспечить высокое качество проектирования и разработки. У проверок есть дополнительные преимущества:

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

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

Например, Страховая компания Aetna с помощью практики проверок нашла 82% ошибок в программе и, тем самым, снизила затраты на разработку на 25% [31].

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

1.3 Синтез гибких методологий для покрытия выявленных проблем

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

На основании проведенного анализа, была составлена таблица перекрытия рассматриваемыми методологиями выявленных проблем (см. Таблица 3).

Таблица 3. Степень покрытия проблем территориально распределенных проектов гибкими методологиями

Область возникновения сложностей	Сложности	Scrum	Kanban	XP	FDD
Коммуникация	Проблема инициации процесса коммуникации	Устраняет полностью, используются единые подходы для всех гибких методологий
	Недопонимание между членами команды	Устраняет полностью	Устраняет полностью	Устраняет полностью	Устраняет полностью
	Низкая частота коммуникации	Устраняет полностью, используются единые подходы для всех гибких методологий
	Высокие затраты на коммуникацию
	Различия во временных зонах
Контроль проекта	Сложность контроля процесса разработки	Устраняет частично	Устраняет полностью	Устраняет полностью	Устраняет полностью
	Сложность контроля качества программного продукта	Устраняет полностью	Не устраняет	Устраняет полностью	Устраняет полностью
Формирование доверительных отношений	Недостаток доверия между членами команды	Устраняет полностью	Устраняет полностью	Устраняет полностью	Не устраняет
	Отсутствие боевого командного духа	Устраняет полностью	Не устраняет	Устраняет полностью	Не устраняет
Управление знаниями	Отсутствие обмена опыта между частями команды	Устраняет частично	Устраняет полностью	Устраняет полностью	Устраняет полностью

Вариант «Не устраняет» выбирался в том случае, если методология не предлагает никаких вариантов решения рассматриваемой проблемы. Вариант «Устраняет частично» выбирался в том случае, если для решения проблемы в методологии приводились ссылки на другие практики или вариант предлагаемый методологией сложно повсеместно применять в территориально распределенных проектах.

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

Согласно статистике использования гибких методологий наиболее часто встречаются гибриды Scrum и XP, Scrum и Kanban (Scrumban), однако Scrum по своей сути обладает крайне низкой степенью формализации и не рассчитан на крупные и сложные проекты. Для того чтобы разрабатываемые предложения могла быть использована на проектах высокой сложности, будут дополнительно применены практики методологии FDD, которые позволят формализовать модель системы.

В результате для методики были выбраны компоненты всех четырех методологий (см. Таблица 4): основной, на которой строится процесс работы над проектом, был выбран Scrum.

Таблица 4. Компоненты методологий, выбранные для методики

Scrum	Kanban	XP	FDD
Организация процесса работы (спринты), роли, практики командообразования	Практики визуального менеджмента	Практики коллективного владения кодом и стандартов кодирования	Процессы первичной проектной деятельности (нулевой спринт) и практика инспекций

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

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

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

2.1 Разработка требований к документу

Для разработки методики необходимо сформировать требования, которым она должна удовлетворять. В качестве критериев будем также использовать уже выделенные проблемы территориально распределенных проектов по разработке программного обеспечения. Перед этим проанализируем текущую ситуацию на примере проекта в отделе хранилищ данных и BI в крупной российской ИТ-компании ЛАНИТ. Для проведения анализа построим структуру команды на проекте «as-is» (как есть) и выявим характерные особенности данного проекта.

В качестве примера территориально распределенного проекта по разработке программного обеспечения был выбран проект по созданию системы анализа логистической деятельности ФГУП «Почта России» (САД Логистика). Проект относится к числу крупных и инновационных, так как наработки в данной сфере у компании отсутствуют. Разработка ведется в двух офисах: главный офис в Москве, где проводится большая часть аналитической работы и общение с заказчиков, удаленный офис в Минске, где ведется все разработка системы, а также несколько удаленно работающих специалистов по тестированию (см. Рисунок 9).

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



Рисунок 9. Структура проекта САД Логистика

Проектная команда состоит из 11 человек. Основной используемый канал коммуникации между членами команды - электронная почта, вследствие чего команда тратит большую часть времени на уточнение требований и в 60% случаев на последующее переделывание. По причине того, что руководитель проекта взаимодействует преимущественно с аналитиками, у него формируется искаженное представление о ходе проекта. Разработчики не успевают поставлять функциональный инкремент к программному обеспечению каждые две недели.

Таким образом, проведенный анализ подтверждает актуальность проблем, которые были выделены как наиболее типичные для территориально распределенных проектов по разработке программного обеспечения в первой главе. Используя выявленные проблемы и особенности проекта, выявленные в результаты проведенного анализа, определим требования к формируемой методике (см. Таблица 5).

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

№	Критерий	Требование к методике управления проектом
1	Проблема инициации процесса коммуникации	Предложения должны регулировать организацию внутренних коммуникаций
2	Низкая частота коммуникации
3	Высокие затраты на коммуникацию
4	Различия во временных зонах
5	Недопонимание между членами команды
6	Сложность контроля процесса разработки	Предложения должны регулировать процессы управления проектом
7	Сложность контроля качества программного продукта
8	Недостаток доверия между членами команды	Предложения должны регулировать процесс командообразования в проекте
9	Отсутствие боевого командного духа
10	Отсутствие обмена опыта между частями команды	Предложения должны регулировать обмен опытом между членами команды
11	Проектная команда размером в 11 человек	Предложения должны быть применимы для проектных команд размером от 8 до 15 чел.
12	Реализация сложных и инновационных проектов	Предложения должна быть применимы для проектов, по которым отсутствуют какие-либо предварительные наработки

2.2 Формирование структуры документа

Структура разрабатываемой методики зависит от требований, предъявляемых к методике, и должна соответствовать как общепризнанным положениям, так и корпоративной культуре компании, в которой она будет использоваться. Таким образом, стоит отметить, что разрабатываемое предложение должно содержать следующую информацию:

1. Разделы, посвященные управлению территориально распределенным проектом:

1.1. роли в проекте;

1.2. процессы жизненного цикла проекта;

1.3. управление качеством проекта;

1.4. управление коммуникациями проекта;

1.5. управление человеческими ресурсами проекта;

1.6. управление сроками и содержанием проекта.

2. Описание должностных лиц и требования к их ответственности для обеспечения выполнения положений методики.

...