Исследование применимости гибких методологий для территориально распределенных проектов по разработке программного обеспечения (на примере компании ЗАО "ЛАНИТ") - Дипломная работа
Анализ семейства методологий agile. Структура документа предложения по внедрению гибких методологий. Организация внутрипроектных коммуникаций в территориально распределенной команде. Метрики оценки качества проектов по разработке программного обеспечения.
Аннотация к работе
Таким образом, можно выделить два ключевых аспекта важных для заказчика разработки программного обеспечения: · возможность изменять требования по ходу выполнения проекта. Согласно отчету, сделанному независимой международной исследовательской компанией Standish Group в 2011 году, проекты, использующие гибкие методологии разработки в три раза более успешные, чем проекты, использующие методологию «водопад» (см. В качестве методологии разработки программного обеспечения в территориально распределенных проектах многие компании отдают предпочтение agile методологиям. [10] рассматриваются различные гибкие методологии с точки зрения применения в территориально распределенных проектах по разработке программного обеспечения, также затрагивается вопрос масштабирования методологий и выявления основных аспектов, на которые необходимо обратить внимание руководителю при внедрении гибких методологий. Однако в научных публикациях и статьях не рассматривается вопрос комбинирования гибких методологий для совершенствования управления процессами разработки программного обеспечения в территориально распределенных проектах, а также мало внимания уделено тому, какую именно методологию лучше выбрать для территориально распределенного проекта.В таком случае многие проекты используют в качестве средства коммуникации письма и документы, как наиболее простой способ поддержания осведомленности удаленной части команды о происходящем. Различия во временных зонах уменьшает количество часов, которые команда находится в контакте - это может быть критично для многих проектов по разработке программного обеспечения, в особенности при переходе от этапа формирования требований к этапу разработки, когда аналитики вынуждены плотно сотрудничать с разработчиками. Контроль соответствия программного продукта требованиям в первую очередь ложится на плечи руководителя проекта, который отвечает за корректирование процесса разработки для успешного завершения проекта. По результатам 8-го ежегодного исследования «State of Agile», проводившегося в 2013 году, были выявлены самые популярные гибкие методологии управления проектами, использующиеся в проектах по разработке программного обеспечения. К вопросу формирования доверия в команде в Scrum подходят основательно, существует ряд техник и методик, которые помогают команде сплотиться и сформировать открытые дружеские отношения как внутри команды, так и с владельцем продукта.В качестве критериев будем также использовать уже выделенные проблемы территориально распределенных проектов по разработке программного обеспечения. Для проведения анализа построим структуру команды на проекте «as-is» (как есть) и выявим характерные особенности данного проекта. В качестве примера территориально распределенного проекта по разработке программного обеспечения был выбран проект по созданию системы анализа логистической деятельности ФГУП «Почта России» (САД Логистика). Разработка ведется в двух офисах: главный офис в Москве, где проводится большая часть аналитической работы и общение с заказчиков, удаленный офис в Минске, где ведется все разработка системы, а также несколько удаленно работающих специалистов по тестированию (см. Из диаграммы становится понятно, что руководитель проекта взаимодействует только с членами команды в рамках своего офиса, которые в свою очередь уже контактируют с членами команды из удаленного офиса.1.1. роли в проекте; 1.2. процессы жизненного цикла проекта; 1.3. управление качеством проекта;На момент начала внедрения гибких методологий на проекте действительно наблюдались проблемы, характерные для территориально распределенных проектов по разработке программного обеспечения, например, отсутствие информации у участников проекта на каком этапе находится проект, какие работы являются приоритетными, какой фидбек заказчик дает о продукте, а также общая рассинхронизация действий, приводящая к дублированию работ или недопониманию внутри команды. Ключевой особенностью внедрения гибких методологий на проекте САД Логистика является тот факт, что внедрение начинается не с нулевой фазы проекта, а в середине этапа разработки. 4 30.03 - 5.04 Старт второго спринта · планирование спринта, исходя из скорости работы команды на предыдущем спринте; · тренинг по практике коллективного владения кодом: o выработка и внедрение стандартов кодирования; o определение правил непрерывной интеграции. 8 27.04-3.05 Начала четвертого спринта · Отработка практик по планированию релиза: o переоценка историй пользователей командой на основании полученного опыта o начинаем вести диаграмму сгорания релиза o отбор владельцем продукта наиболее приоритетных историй пользователей · контроль процесса исполнения с помощью доски, оптимизация процесса работы с целью снижения WIP. 10 11.05-17.05 Старт пятого «идеального» спринта · анализируем продуктивность работы команды на предыдущих спринтах и подстраиваем диаграмму сгорания; · тренинг по практикам FDD (проведение инспекций, доработка общей схемы системы)Данная работа была посвящена разработке п
Введение
За последние годы существенно выросли требования, которые предъявляются к предпринимателю в процессе ведения бизнеса. «Для успешного выживания на рынке и реализации стратегии развития, фирма должна быть гибкой и динамичной, поскольку ключевой фактор конкуренции сегодня - время. Кроме того, внешняя среда бизнеса становится все более комплексной и неопределенной, что требует умения быстро адаптироваться и устойчивости организации бизнеса» - так отзываются о тенденциях современного подхода к управлению бизнесом российские ученые [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 департамента корпоративных систем (ДКС) на проекте разработки системы анализа логистической деятельности в Почте России (проект САД Логистика).
Результатом ВКР станет разработанные предложения, применение которых позволит снять описанные проблемы, возникающие в территориально распределенных проектах по разработке ПО, а также анализ результатов внедрения созданных предложений на проекте, соответствующем заданным ограничениям.
Практическая значимость исследования заключается в возможном использовании разработанных предложений по внедрению гибких методологий на других территориально распределенных проектах по разработке ПО.
Исследование включает в себя три главы. В первой главе рассматриваются основные проблемы, которые возникают в территориально распределенных проектах по разработке ПО. В работе анализируется семейство гибких методологий на предмет покрытия выявленных проблем. Далее проводится отбор метрик, подходящих для оценки общей производительности территориально распределенных проектов по разработке ПО, использующих гибкие методологии. На примере проекта САД Логистика производится оценка производительности проекта на основании выделенных метрик.
Во второй главе рассмотрен процесс разработки предложений по внедрению гибких методологий, а также ее основных элементов. В первую очередь определяются требования к предложению на основании проблем, выявленных в первой главе. Затем описывается структура предложения, и определяется содержание разделов предложения. Сами предложения вынесены в приложение к работе.
В третьей главе приводится описание процесса апробации предложений на проекте САД Логистика. Сначала был разработан план внедрения предложений, включающий в себя последовательность шагов, а затем проведена оценка эффективности предложений.