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

Правительство Российской Федерации

Федеральное государственное автономное образовательное учреждение

высшего профессионального образования

«Национальный исследовательский университет «Высшая школа экономики»

Факультет бизнеса и менеджмента

Кафедра управления информационными системами и цифровой инфраструктурой

ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА

На тему

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

Студент группы № 244-М

Филимонова Е. Б.

Руководитель ВКР

зам.зав.кафедрой, доцент Коровкина Н.Л.

Москва, 2015



Аннотация

В течение последних пяти лет территориально распределенные проекты в сфере разработки программного обеспечения набирают популярность. Параллельно с данным трендом, все больше компаний переходят с использования классических методологий типа «водопад» на гибкие методологии. По данным 2013 года процент компаний, практикующих гибкие модели разработки, увеличился до 88%, а количество людей, участвующих в территориально распределенных проектах практикующих гибкие методологии разработки, увеличилось почти вдвое.

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

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

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

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

Теоретическая часть ВКР представлена изучением проблем территориально распределенных проектов. Сформулированы основные области возникновения проблем, а также описаны сами проблемы, характерные для проектов данного типа. Проведен сравнительный анализ четырех наиболее популярных гибких методологий: Scrum, Kanban, eXtreme Programming и Feature Driven Development на предмет покрытия ими выявленного списка проблем. Обоснован вывод о необходимости разработки свода предложений по внедрению гибких методологий, который учитывал бы сильные стороны рассмотренных методологий и лучших практик и, в то же время, восполнял не решенную ими проблематику.

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

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

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

Работа содержит 10 таблиц, 15 рисунков, 1 приложение, состоит из 92 страниц и ссылается на 38 источников.

Ключевые слова

Гибкие (agile) методологии, синтез гибких методологий, территориально распределенный проект, разработка программного обеспечения, Scrum, Kanban, FDD, eXtreme Programming.



Содержание

Аннотация

Ключевые слова

Введение

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

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

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

1.2.1 Scrum

1.2.2 Kanban

1.2.3 eXtreme Programming

1.2.4 Feature Driven Development

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

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

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

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

2.3 Разработка содержания разделов документа

Глава 3. Апробация предложений и анализ результатов внедрения

3.1 Апробация набора разработанных предложений

3.2 Анализ результатов внедрения разработанных предложений

Заключение

Список литературы

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

Список иллюстраций

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

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

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

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

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

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

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

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

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

Рисунок 10. Предлагаемый жизненный цикл проекта

Рисунок 11. Схема взаимодействия проектной команды

Рисунок 12. Доска для визуализации работы над задачами

Рисунок 13. Диаграмма аккуратности оценки задач за период

Рисунок 14. Пример диаграммы сгорания спринта

Рисунок 15. Пример использования niko-niko календаря

Список таблиц

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

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

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

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

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

Таблица 6. План этапов внедрения гибких методологий

Таблица 7. Планирование работ на спринт

Таблица 8. Решение выявленных проблем в территориально распределенных проектах

Таблица 9. Этапы формирование команды в Scrum

Таблица 10. Дискретная логарифмическая шкала оценки задач



Введение

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

· высокая скорость разработки и поставки программного продукта;

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

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

Согласно отчету, сделанному независимой международной исследовательской компанией Standish Group в 2011 году, проекты, использующие гибкие методологии разработки в три раза более успешные, чем проекты, использующие методологию «водопад» (см. Рисунок 1).



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

Под гибкими методологиями (Agile software development) понимается концептуальный подход, в рамках которого выполняется разработка программного обеспечения [3]. Существует ряд методологий, входящих в семейство agile, которые более подробно будут рассмотрены в Главе 1.

Большинство гибких методологий нацелены на минимизацию рисков, путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся одну-две недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре, и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, кодирование, тестирование и документирование. Список основополагающих принципов гибких методологий описан в 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% от общего числа проектов (см. Рисунок 43), остальные методологии используются в 10 и менее процентах случаев.



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

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

1. Scrum;

2. eXtreme Programming (XP);

3. Feature Driven Development (FDD);

4. Kanban.

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
Коммуникация	Проблема инициации процесса коммуникации	Устраняет полностью, используются единые подходы для всех гибких методологий
	Недопонимание между членами команды	Устраняет полностью	Устраняет полностью	Устраняет полностью	Устраняет полностью
	Низкая частота коммуникации	Устраняет полностью, используются единые подходы для всех гибких методологий
	Высокие затраты на коммуникацию
	Различия во временных зонах
Контроль проекта	Сложность контроля процесса разработки	Устраняет частично	Устраняет полностью	Устраняет полностью	Устраняет полностью
	Сложность контроля качества программного продукта	Устраняет полностью	Не устраняет	Устраняет полностью	Устраняет полностью
Формирование доверительных отношений	Недостаток доверия между членами команды	Устраняет полностью	Устраняет полностью	Устраняет полностью	Не устраняет
	Отсутствие боевого командного духа	Устраняет полностью	Не устраняет	Устраняет полностью	Не устраняет
Управление знаниями	Отсутствие обмена опыта между частями команды ...

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

Подобные документы

• Инженерный менеджмент и информационные технологии

  Понятие жизненного цикла программного обеспечения. Два вида деятельности, различаемые в технических проектах: проектирование и производство. Основные постулаты манифеста последователей гибких методологий. Базовые принципы экстремального программирования.
  
  презентация [170,8 K], добавлен 14.08.2013
  

• Анализ факторов, способствующих повышению уровня групповой осознанности сотрудников в проектах по разработке программного обеспечения

  Информационные технологии как отрасль, занимающаяся сбором, обработкой и хранением данных, с применением компьютерных ресурсов. Описание ключевых моделей разработки программного обеспечения. Основные черты проявления групповой осознанности персонала.
  
  дипломная работа [69,6 K], добавлен 29.06.2017
  

• Методы и средства выявления и представления требований к разработке ПО

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

• Логические слои программного обеспечения распределенных информационных систем

  Виды архитектуры распределенных информационных систем. Сущность синхронного и асинхронного, блокирующего и неблокирующего взаимодействия в распределенных информационных системах. Основные проблемы и принципы реализации удаленного вызова процедур.
  
  реферат [26,4 K], добавлен 22.06.2011
  

• Системы распределенной обработки информации на предприятии ООО "Ростбизнесторг"

  Анализ видов обеспечения автоматизированных систем предприятия. Средства программирования распределенных систем обработки информации. Изучение особенностей использования технологии распределенных объектов. Эксплуатация программного обеспечения системы.
  
  отчет по практике [486,0 K], добавлен 23.11.2014
  

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

  Понятие и ключевое отличие распределенной разработки программного обеспечения, его достоинства и недостатки. Концептуальное решение и выбор типа разработки. Особенности программного обеспечения с открытым исходным кодом. Идея и развитие Open Source.
  
  курсовая работа [97,7 K], добавлен 14.12.2012
  

• Разработка прикладного программного обеспечения для многоканального измерительного прибора Ш9327

  Современные инструменты разработки программного обеспечения для СУТП. Универсальные языки программирования и сравнение их со SCADA-системами. Разработка программного обеспечения с использованием многоканальных измерительных преобразователей Ш9327.
  
  дипломная работа [2,3 M], добавлен 13.07.2011
  

• Модели проектных групп

  Применение промышленных технологий создания программного продукта. Описания принципов, методов, применяемых процессов и операций. Общие понятия методологии разработки программного обеспечения (ПО). Сравнение современных методологий проектных групп.
  
  курсовая работа [1,6 M], добавлен 04.12.2009
  

• Особенности управления разработкой программного обеспечения

  Понятие программного обеспечения, вопросы его разработки и использования. Общая характеристика системного программного обеспечения и работа операционной системы. Специфика процесса управления разработкой программного обеспечения и его особенности.
  
  курсовая работа [636,2 K], добавлен 23.08.2011
  

• Разработка ЭИС управления проектами для ЗАО "Диакон"

  Разработка системы управления проектами для компании ЗАО "Диакон". Экономические параметры разработки и внедрения электронной информационной системы. Технология разработки программного обеспечения. Выбор типа графического интерфейса, его составляющие.
  
  дипломная работа [1,4 M], добавлен 10.06.2014
  

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

  Возможности среды программирования delphi при разработке приложения с визуальным интерфейсом. Разработка спецификации программного обеспечения и на ее основе кода программного продукта. Отладка программы "трассировкой", ее тестирование и оптимизация.
  
  курсовая работа [501,4 K], добавлен 07.12.2016
  

• Профессиональная практика программной инженерии

  Понятие программной инженерии как применения определенного систематического измеримого подхода при разработке, эксплуатации и поддержке программного обеспечения. Модели процесса разработки программного обеспечения. Управление программными проектами.
  
  презентация [870,6 K], добавлен 12.11.2014
  

• Разработка автоматизированной системы расчета себестоимости и длительности разработки программного обеспечения

  Порядок автоматизации расчетов себестоимости и длительности программного обеспечения производственного предприятия. Выбор языка программирования и системы управления базами данных. Разработка алгоритмов расчета себестоимости программного обеспечения.
  
  дипломная работа [1,7 M], добавлен 13.06.2017
  

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

  Исследование программного средства для управления базой данных с информацией о фильмах. Составление алгоритма удаления и добавления элемента в указанное место двунаправленного списка. Характеристика поиска, вывода на экран и сортировки элементов списка.
  
  курсовая работа [94,5 K], добавлен 23.09.2011
  

• Разработка программного обеспечения для обработки данных о товарах зоомагазина

  Возможности среды программирования delphi при разработке приложения с визуальным интерфейсом. Отладка программных модулей с использованием специализированных программных средств. Тестирование программного обеспечения. Оптимизация программного кода.
  
  курсовая работа [974,0 K], добавлен 21.12.2016
  

• Качественное программное обеспечение и пути его достижения. Стандарты качества программного обеспечения. Современные модели качества программного обеспечения

  Схемы взаимодействия между заказчиком и разработчиком программного обеспечения. Качество программного обеспечения и определение основных критериев его оценка на современном этапе, особенности управления на стадиях жизненного цикла, анализ достаточности.
  
  презентация [114,7 K], добавлен 14.08.2013
  

• Разработка, внедрение и адаптация программного обеспечения отраслевой направленности

  Практические аспекты использования прикладного программного обеспечения при разработке базы данных "Аудиторный фонд ГБОУ СПО "Старооскольский педагогический колледж". Системы управления базами данных. Описание и функциональные возможности приложения.
  
  курсовая работа [360,4 K], добавлен 07.10.2014
  

• Специфицирование программного обеспечения

  Этапы разработки технического задания. Спецификация программного обеспечения при структурном подходе. Дерево диаграмм, базовые понятия сетевой модели данных. Разработка пользовательского интерфейса. Разработка сценария диалога на основе экранных форм.
  
  курсовая работа [2,0 M], добавлен 24.06.2012
  

• Создание распределенных информационно-управляющих систем на базе агентно-ориентированного подхода

  Агентно-ориентированная программная архитектура систем обработки потоковых данных. Обеспечение гибкости и живучести программного обеспечения распределенных информационно-управляющих систем. Спецификации программных комплексов распределенной обработки.
  
  реферат [1,1 M], добавлен 28.11.2015
  

• Разработка программы обновления программного обеспечения

  Разработка программы, осуществляющей контроль за своевременностью обновления программного обеспечения с помощью рассылки электронных писем. Анализ требований к системе; выбор метода решения, алгоритма, выбор языка программирования, описание программы.
  
  дипломная работа [5,6 M], добавлен 29.06.2011
  

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

• главная
• рубрики
• по алфавиту
• вернуться в начало страницы
• вернуться к началу текста
• вернуться к подобным работам