· проектирование

· дизайн

· программирование

· тестирование

· запуск

Поскольку состав участников за время проекта неоднократно менялся, последовательность этапов пришлось нарушать: пока не было дизайнера, участники команды выполняли задачи по программированию. После получения макетов пришлось выделять дополнительное время на внедрение дизайна взамен чернового варианта. Таким образом, выбор гибких методологий был продиктован не стремлением следовать популярным методам и не благодаря их преимуществам (ориентированным, безусловно, на зрелые команды), а необходимостью адаптации под неожиданные и частые изменения внутри проекта и его команды. Рассмотрим более подробно, насколько следование основным идеям и принципам гибких методологий оказалось совместимым с учебным проектом. Для каждого принципа, следующего из идей agile подхода, введем десятибальную шкалу оценки, где 10 - в полной мере удалось реализовать, 1 - никоим образом не относилось к учебному проекту.

Идея 1. Люди и взаимодействие важнее процессов и инструментов

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

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

Те же, кому нравилась идея самого приложения и задачи, которое оно сможет решать - не справлялись с поставленными задачами либо имели несколько иное видение реализации функционала, что приводило к дополнительным спорам с менеджером и замедляло общий процесс. Отсутствие результатов по какому-либо из направлений могло вызвать цепную подражательную реакцию (в команде должны работать все участники, а не делиться на “работающих” и “наблюдающих”), поэтому должно было пресекаться.

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

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

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

2. кто ничего не делает - в проекте не остается

3. нельзя оскорблять других участников и переходить на личности.

позже на основании прецедента с одним из бывших участников было сформулировано четвертое правило:

4) говорить только правду в части опыта работы и по рабочим вопросам

Таким образом, с первым правилом команда следовала принципу “На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.” Заказчика проекта в чистом виде не было, но частично его функции выполнял менеджер проекта, главной задачей которого становилось доведение проекта до релиза (публикации приложения). Разумеется, на начальной стадии учебного проекта это не всем нравилось, и поведение и полномочия заказчика пытались взять на себя разные участники. Оценка реализации: 6

Если рассматривать второй принцип, “Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды”, то общение осуществлялось непосредственно и максимально удобным для участников способом (асинхронно и большей частью текстом, чтобы каждый участник мог позже прочитать все, что обсуждалось). Если требовались звонки, то время для них всегда выбиралось заранее и с учетом пожеланий каждого участвующего в разговоре. Оценка реализации: 7

В случае с третьим принципом “Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им” - данный пункт не соблюдался, поскольку, как уже было обозначено ранее, профессионалы не хотели участвовать в неоплачиваемом проекте, а начинался он изначально как учебный для каждого из участников. Тем не менее, без формирования доверия вести проект было бы невозможно, поэтому отношения между участниками команды последние спринты перед запуском приложения можно назвать доверительными. Оценка реализации: 5

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

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

Например, в agile методологиях используется доска Kanban для формирования задач и отслеживания статусов по ним:

Рис 26 Классическая доска Kanban в офисной команде

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

Рис 27 Доска задач по учебному проекту

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

Идея 2. Работающий продукт важнее исчерпывающей документации

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

Рассмотрим соответствующие данной идее принципы.

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

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

Простота -- искусство минимизации лишней работы -- крайне необходима.

Данный принцип вынужденно не соблюдался. Приходилось искать новых участников, объяснять им основы работы с гитом и способы организации коммуникации в проекте; из-за отсутствия нужных участников приходилось нарушать последовательность работ, а позже делать исправления, замедляющие общий процесс проекта. По Android-версии, после того как четвертый по счету дизайнер покинул проект (временные затраты на поиск его составили две недели, отработал он немногим дольше), менеджером проекта было принято решение отказаться от дальнейших поисков дизайнера на Android-версию (по iOS приложению уже был готовый дизайн) до релиза продукта. В итоге Android-разработчику пришлось самостоятельно экспериментировать с отступами, размерами шрифтов и изображений, что также увеличило совокупное время работ. Оценка реализации: 4

Идея 3. Сотрудничество с заказчиком важнее согласования условий контракта

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

Рассмотри принципы, связанные с данной идеей.

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

Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки. - были попытки поддерживать постоянный ритм, в частности благодаря правилу каждый день выходить на связь. Несмотря на то, что основная работа приходилась на выходные, новости по проекту, планы на будущее и другие задачи обсуждались практически каждый день. Вместе с тем поддерживать такой режим на протяжении девяти месяцев было сложно, тем более, что инвесторов по этому проекту никаким образом не было; уровень самомотивации, самоконтроля и приоритеты у каждого из участников различались, и не каждый справлялся с такой нагрузкой. В некоторой степени открытость проекта (публикация планов на неделю и итогов по итерациям в социальной сети) дополнительно мотивировала выполнять задачи и не прекращать процесс работы над проектом ни на неделю. Оценка реализации: 8

Идея 4. Готовность к изменениям важнее следования первоначальному плану

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

Рассмотрим более подробно принципы, следующие из данной идеи:

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



Рис 28 Сравнение экрана события на стадии прототипа и в версии, запущенной в App Store

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

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

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

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

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

Рассмотрим, насколько успешным оказалось формирование команды в условиях учебного проекта. Поскольку заранее предсказать про каждого нового участника, справится ли он с работой в виртуальной команде, не было возможным - процесс формирования команды был болезненным. За нарушение описанных выше правил участники исключались из проекта, а им на замену подбирались новые. Ключевым способом связи для всех участников являлся чат Slack, доступ и деактивация аккаунта в данном чате являлись обязательными условиями для вступления и исключения из команды соответственно. За отчетные даты также брались старт проекта и запуск приложений в AppStore и PlayMarket как финальные цели. Участники, дошедшие до этой вехи в проекте, считаются справившимися с проектом. Были выявлены основные причины для покидания проекта, и их оказалось две: первая - это проблемы с коммуникацией (конфликты, неправильная интерпретация письменной речи, неумение аргументированно отстаивать свою точку зрения и др.) и недостаток технической подготовки (переоценка своих сил для участия в проекте, неумение либо отсутствие мотивации быстро осваивать новое). Рассмотри более подробно участников проекта:

Таблица 3

Даты участия в проекте и количество коммитов

	Никнейм	Роль	Даты в проекте	Кол-во коммитов
1	alina	project manager	07 July 2015 - наст. время	1 (не требовалось)
2	bessmertny	Android developer	09 Sept 2015 - наст.время	147
3	pasha	iOS developer	14 Aug - 27 Aug 2015	0
4	piton	iOS developer	17 Jan - 17 Apr 2016	109
5	chebarasha	backend developer	14 Aug - 28 Aug 2015	0 (не требовалось)
6	deniskleev	iOS developer	7 July - 11 Jul 2015	0
7	maxim_tkachenko	iOS developer	7 July - 24 Aug 2015	4
8	town	iOS developer	7 July - 15 Jul 2015	0
9	maxk	iOS developer	7 July - 27 Jul 2015	0
10	geekellan	iOS developer	7 July - 16 Jul 2015	0
11	nikolay-sozinov	iOS designer	7 July - 19 Jul	1 (не требовалось)
12	sergei_kazberovich	iOS developer	7 July - 10 Jul 2015	0
13	abcdeiko	Android developer	21 Sept - 2 Oct 2015	9
14	erik	iOS developer	7 Sept - 16 Sept 2015	5
15	kbsko	Android developer	9 Sept - 2 Oct 2015	4
16	pasha_dy	Android designer	24 Nov - 20 Dec 2015	0 (не требовалось)
17	pingvinenysh	Android designer	9 Sept - 25 Sept 2015	0 (не требовалось)
18	rapax	iOS developer	15 Aug - 25 Oct 2015	32
19	rustam	iOS designer	22 Sept - 17 Nov 2015	0 (не требовалось)
20	sasha	iOS developer	18 Aug - 27 Sept 2015	0
21	sergey_lyubeznov	iOS developer	7 July - 7 Sept 2015 20 Sept -17 Jan 2016	80
22	tommy	tester	19 Sept - 8 Oct 2015	0 (не требовалось)
23	vovapuh	iOS developer	23 Sept - 24 Sept 2015	0

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

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

Табл. 4

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

	Никнейм	Причины покидания проекта	Способы связи внутри проекта	Формат общения	Дней в проекте
1	alina	-	Slack, vk, skype, viber, fb	текст, голос	285
2	bessmertny	-	Slack, vk, skype, viber, fb	текст, голос	221
3	pasha	техн.	Slack, vk	текст	13
4	piton	-	Slack, vk	текст	91
5	chebarasha	техн.	Slack, vk	текст	14
6	deniskleev	комм.	Slack, vk, skype	текст, голос	4
7	maxim_tkachenko	комм.	Slack, vk	текст	48
8	town	комм.	Slack, vk	текст	8
9	maxk	техн.	Slack, vk	текст	20
10	geekellan	техн.	Slack, vk	текст	9
11	nikolay-sozinov	комм., техн.	Slack, vk	текст	12
12	sergei_kazberovich	комм.	Slack, vk	текст	3
13	abcdeiko	комм.	Slack, vk	текст	11
14	erik	комм.	Slack, vk, skype	текст, голос	9
15	kbsko	комм.	Slack, vk	текст	23
16	pasha_dy	комм.	Slack, vk, skype	текст, голос	26
17	pingvinenysh	техн.	Slack, vk, skype	текст, голос	16
18	rapax	комм., тех.	Slack, vk, skype	текст, голос	71
19	rustam	комм.	Slack, vk, skype	текст, голос	56
20	sasha	тех.	Slack, vk	текст	40
21	sergey_lyubeznov	комм.	Slack, vk, skype, viber, fb	текст, голос	181
22	tommy	комм.	Slack, vk	текст	19
23	vovapuh	тех.	Slack, vk	текст	1

По результатам обеих таблиц проанализируем результаты и выявим тенденции:

Общение и текстом, и голосом осуществляли 9 участников из 23, из них 3 дошли до конца проекта, а у остальных 5 участников проблемы покидания были связаны с коммуникацией, у 1 участника - и коммуникация, и технические причины.

Среди покинувших проект участников средняя продолжительность участия тех, кто осуществлял коммуникацию и текстом, и голосом - составляет 51,86 дней.

Общение только текстом осуществляли 14 участников, из них 1 дошел до конца проекта, 6 имели технические проблемы связанные с покиданием, 6 - коммуникативные мотивы для покидания проектов, 1 - обе причины для исключения из проекта.

Среди покинувших проект участников средняя продолжительность участия тех, кто осуществлял коммуникацию только текстом, - составляет 15,78 дней.

Участники, покинувшие проект из-за обеих проблем, учитывались дважды в каждом из подсчетов.

Вывод: использование голоса как одного из способов коммуникации увеличило среднее число дней участия в проекте в 3,29 раз!

Рекомендация: возможно проведение очной встречи увеличит продолжительность участия в проекте еще сильнее.

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

Таблица 5

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

идея	принцип	оценка (из 10)	рекомендация
Идея 1. Люди и взаимодействие важнее процессов и инструментов	На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.	6	Ежедневную совместную работу можно организовать, используя современные средства связи. Важно определить наиболее эффективные способы взаимодействия с заказчиком(почта, Skype, Slack, видеосвязь) и комбинировать несколько способов связи внутри команды
	Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды	7	Нужно поддерживать неформальное общение между участниками команды - как в письменной, так и в устной форме. По возможности организовывать встречи вживую
	Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им	5	При прочих равных (опыт, квалификация) стоит обращать на способность работать в команде (наличие завершенных командных проектов, не только в одиночку выпущенных приложений), а также способность ясно изъясняться письменно(это основной способ коммуникации)
	Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.	2	Коллективные решения и правда внедряются проще и без сопротивления по сравнению с директивными задачами, однако для самоорганизации нужен опыт и высокий самоконтроль у каждого из участников команды
	Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы	5	В работе команды должна быть договоренность о времени для проведения собраний и ретроспектив, и эти элементы рабочего процесса необходимо регулярно соблюдать
Идея 2. Работающий продукт важнее исчерпывающей документации	Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.	7	Нужно поддерживать ответственность всей команды за успехи и иметь возможность демонстрировать промежуточные результаты
	Работающий продукт -- основной показатель прогресса	8	При определении приоритетов в задачах необходимо сконцентрировать усилия на задачах, способствующих ускорению запуска продукта
	Простота -- искусство минимизации лишней работы -- крайне необходима.	4	Для того, чтобы достигать простых решений, от участников команды требуется опыт и стабильный состав в течение проекта
Идея 3. Сотрудничество с заказчиком важнее согласования условий контракта	Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.	2	совмещение роли менеджера проекта и заказчика иногда приводит к конфликту ролей. Если есть возможность, это должны быть разные лица с общей конечной целью.
	Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.	8	Нужно регулярно вовлекать в процесс заказчика/инвестора, даже в учебных/некоммерческих проектах наличие внешнего заказчика обеспечило бы большую ответственность участников и более близкие к реальным условия ведения проекта
Идея 4. Готовность к изменениям важнее следования первоначальному плану	Изменение требований приветствуется, даже на поздних стадиях разработки	9	Участники проекта с самого начала должны быть ознакомлены с понятием “гибкая разработка” и понимать, что их ждет. Готовность к изменениям лучше закладывать как требование к психологическим качествам участника, чем как вынужденную стратегию поведения
	Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества	3	Agile-процессы хорошо подходят для стартапов и проектов, в которых часто меняется рынок, условия, технологии, поскольку действительно позволяет адаптироваться и оперативно внести изменения в проект
	Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта	3	В идеале в команде должен быть опытный тимлид, способный вести за собой разработчиков и ставить задачи, повышающие качество проекта
Итого оценка:		69

Таким образом, средняя оценка составляет 5,30 балла. С учетом того, что проект носил учебный характер, занимала свободное, а не рабочее время, и при этом не оплачивался; с учетом того, что коммуникация носила асинхронный характер, а состав команды был нестабильным, можно заявить о возможности использования удаленных команд для разработки программного обеспечения, применяя гибкие методологии. Сформулированные рекомендации в таблицы выше позволяют адаптировать процесс применительно к специфике удаленной команды. Учитывая непростые условия ведения проекта, связанные с отсутствием инвестора (заказчика), занятостью исключительно в свободное (нерабочее) время, а также трудностями в коммуникации в связи с отсутствием опыта в ведении проектов в таком формате, можно предположить увеличение (в процентах) успешности внедрения гибких методологий в виртуальные офисы, если хотя бы одно из базовых условий объективно лучше, чем в рассматриваемом проекте. Удаленная работа и организация команды в таком формате - само по себе очень сложное задание, поэтому нагружать проект дополнительными рисками, связанными с отсутствием зарплаты, необходимостью обучать новичков и нестандартным режимом работы - несет в себе серьезные риски провалить проект.



Заключение

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

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

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

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

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



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

1. Алешин А. В., Аньшин В. М., Багратиони К. А. и др. ; под ред. В. М. Аньшина, О. Н. Ильиной. Управление проектами: фундаментальный курс [Текст]: учебник / Нац. исслед. ун-т «Высшая школа экономики». М.: Изд. дом Высшей школы экономики, 2013. 620, [4] с. (Учебники Высшей школы экономики)

2. Архангельский Г. Работа 2.0. Прорыв к свободному времени. М.: Манн, Иванов и Фербер, 2010. 208 с. (10).

3. Бахтизин В.В, Кузиков А.А.. Минимизация рисков при разработке программных средств. Журнал “Программные продукты и системы”, 2013 г №3.

4. Бек Кент. Экстремальное программирование. Библиотека программиста. СПб.: Питер, 2003. 224 с. (2).

5. Вольфсон Б. Гибкое управление проектами и продуктами. СПб: Питер, 2016. 300 с.

6. Грекул В.И., Коровкина Н.В., Куприянов Ю.В.. Проектное управление в сфере информационных технологий. М.: БИНОМ. Лаборатория знаний, 2013. 336 с.

7. Долженко А. И. Технологии командной разработки программного обеспечения информационных систем М.: Национальный Открытый Университет «ИНТУИТ», 2016. 301 с. Дополнительная информация:2-е изд., исправ.

8. Мазур И.И., под общ.ред. И.И. Мазура и В.Д. Шапиро. Управление проектами: учебное пособие для студентов. / М.: Издательство “Омега-Л”, 2014.

9. Новиков Д.А. Управление проектами: организационные механизмы. М.: ПМСОФТ, 2007. 140 с.

10.Проектное управление в сфере информационных технологий. М.: БИНОМ. Лаборатория знаний, 2013. 336 с.

11.Руководство к Своду знаний по управлению проектами (Руководство PMBOK®). Пятое издание. Project Management Institute, Inc. 2013.

12.Скопин И. Н. Основы менеджмента программных проектов. М.: Интернет-Университет Информационных Технологий, 2004. 336 с.

13.Юдин А.В. Стратегия управления дистанционной формой занятости. Журнал Вестник Омского университета. Серия «Экономика» Выпуск № 4 / 2012.

14.Erskine, L. (2009). A question of leadership. Leadership in Action, 28(6),

Greenhaus J. H., Powell G. N. When Work and Family Are Allies: A Theory of WorkFamily Enrichment // Academy of Management Review. 2006. № 31. P. 72-92.

15.Greenhaus J. H., Powell G. N. When Work and Family Are Allies: A Theory of WorkFamily Enrichment // Academy of Management Review. 2006. № 31. P. 72-92. (8).

16.Handbook of Research on Virtual Workplaces and the New Nature of Business Practices. Zemliansky, Pavel. Idea Group Inc (IGI), 30 апр. 2008 г.

17.Mulki, J, Bardhi, F, Lassk, F, & Nanavaty-Dahl, J. (2009). Set up remote workers to thrive. MIT Sloan Management Review, 51(1) (...28....)

18.Peter Weimann1, Christian Hinz1, Elsje Scott2 and Michael Pollock2 1Beuth-Hochschule. Changing the Communication Culture of Distributed Teams in a World Where Communication is Neither Perfect nor Complete --, Berlin, Germany (31).

19.Брагина Т. И., Табунщик Г. В. Сравнительный анализ итеративных моделей разработки программного обеспечения. [Электронный ресурс] Режим доступа: http://cyberleninka.ru/article/n/sravnitelnyy-analiz-iterativnyh-modeley-razrabotki-programmnogo-obespecheniya.

20.Вольфсон Б. Гибкие методологии разработки. Версия 1.2 [Электронный ресурс] Режим доступа: http://adm-lib.ru/books/10/Gibkie-metodologii.pdf (3).

21.Гебриаль В. Н. Социальные аспекты феномена дистанционной работы как нового вида трудовых отношений. Журнал Государственное управление. Электронный вестник Выпуск№ 17 / 2008 (9). [Электронный ресурс] Режим доступа: http://ejournal.spa.msu.ru/uploads/vestnik/2008/vipusk_17._dekabr_2008_g./gebrial.pdf.

21.Исследование SuperJob. Труд удаленных сотрудников использует почти треть российских компаний.Про жизнь [Электронный ресурс] Режим доступа:http://www.superjob.ru/community/life/69559/ (...18...).

22.Карпов Д.В. Гибкая методология разработки программного обеспечения. Журнал. Вестник Нижегородского университета им. Н.И. Лобачевского. Выпуск №3-2/2011. [Электронный ресурс] Режим доступа: http://cyberleninka.ru/article/n/gibkaya-metodologiya-razrabotki-programmnogo-obespecheniya.

23.Карпов Д.В. Гибкая методология разработки программного обеспечения. Нижегородский госуниверситет им. Н.И. Лобачевского. 2011. [Электронный ресурс] Режим доступа: http://www.unn.ru/pages/issues/vestnik/99999999_West_2011_3(2)/36.pdf

Международный Стандарт по Управлению Проектами ISO 21500:2012. Утвержден Россией, США и Евросоюзом. [Электронный ресурс] Режим доступа: http://www.projectprofy.ru/articles.phtml?aid=473 (6).

24.Управление проектами. Фундаментальный курс. Коллектив авторов (1) из серии: Учебники Высшей школы экономики [Электронный ресурс] Режим доступа: http://biblio.litres.ru/kollektiv-avtorov/upravlenie-proektami-fundamentalnyy-kurs/.

25.Фунтов В.Н. Управление проектами развития фирмы. Теория и практика. [Электронный ресурс] Режим доступа: http://biblio.litres.ru/valeriy-funtov/upravlenie-proektami-razvitiya-firmy-teoriya-i-praktika/ учебник

26.10 annual State of Agile [Электронный ресурс] Режим доступа: https://versionone.com/pdf/VersionOne-10th-Annual-State-of-Agile-Report.pdf (4)

27.10 Stats That'll Change the Way You Think About Remote Work.Ade onRemote Work [Электронный ресурс] Режим доступа: https://s-media-cache-ak0.pinimg.com/736x/cb/d2/f5/cbd2f5c8416a63392402b27c99274e96.jpg (...20...).

28.Anderson David J. Kanban Kindle Edition/ [Электронный ресурс] Режим доступа: https://www.amazon.com/Kanban-David-J-Anderson-ebook/dp/B0057H2M70/189-1907454-6924812?ie=UTF8&keywords=kanban&qid=1370762645&ref_=sr_1_1&sr=8-1.

29. Bloom N. Nicholas, Roberts J. A Working from Home Experiment Shows High Performers Like It Better. [Электронный ресурс] Режим доступа: https://hbr.org/2015/01/a-working-from-home-experiment-shows-high-performers-like-it-better (...21...).

30.Bradford S. Remote Work: Examining Current Trends and Organizational Practices. Bell Cornell University [Электронный ресурс] Режим доступа: http://digitalcommons.ilr.cornell.edu/cgi/viewcontent.cgi?article=1943&context=articles (...19...).

31.Busch, E., Nash, J., & Bell, B. S. (2011). Remote work: An examination of current trends and emerging issues. Ithaca, NY: Center for Advanced Human Resource Studies, Cornell University. [Электронный ресурс] Режим доступа: http://distantjob.com/Spring2011_CAHRSRemoteWorkReport.pdf (34).

32.Caldow Janet. Working Outside the Box: A Study of the Growing Momentum in Telework. Institute for Electronic Government, IBM Corporation. January 21, 2009 [Электронный ресурс] Режим доступа: http://www-01.ibm.com/industries/government/ieg/pdf/working_outside_the_box.pdf.

33.Cisco Research 2009 [Электронный ресурс] Режим доступа: https://newsroom.cisco.com/dlls/2009/prod_062609.html (...23...)

34.CultureWizard - Cross Cultural Solutions. [Электронный ресурс] Режим доступа: http://www.rw-3.com/ (...30...).

35. Donna Ferguson. Why aren't we all working from home today? [Электронный ресурс] Режим доступа: http://www.theguardian.com/money/work-blog/2014/apr/30/what-happened-to-remote-working.

36.Evans L. Want More Sleep (And Better Productivity)? Work From Home. [Электронный ресурс] Режим доступа: https://www.entrepreneur.com/article/242934 (...22...).

37.From the Field: John Henry Krahenbuhl on Collaborating with a Distributed Team. [Электронный ресурс] Режим доступа: http://www.axure.com/c/blog/179-field-john-henry-krahenbuhl-collaborative-design-distributed-team.html?utm_source=Axure+Newsletter&utm_campaign=21def9a5e7-From_the_Field_Krahenbuhl12_14_2015&utm_medium=email&utm_term=0_a7535690e8-21def9a5e7-742333.

38.Gallup Research. Remote Workers Log More Hours and Are Slightly More Engaged. [Электронный ресурс] Режим доступа: https://www.google.com/url?q=http://www.gallup.com/opinion/gallup/170669/remote-workers-log-hours-slightly-engaged.aspx&sa=D&ust=1463436639621000&usg=AFQjCNGl6bEIWyZRU3fSwu98wszKbcLK4w (13).

39.GlobalWorkplaceAnalytics.com [Электронный ресурс] Режим доступа: http://globalworkplaceanalytics.com/telecommuting-statistics (...16...).

40.Going remote: Leading dispersed teams. [Электронный ресурс] Режим доступа:https://www.i-l-m.com/About-ILM/Research-programme/Research-reports/Going-remote (...29...).

41.Henrik Kniberg. Scrum and XP from the Trenches - 2nd Edition. [Электронный ресурс] Режим доступа: http://www.infoq.com/minibooks/scrum-xp-from-the-trenches-2.

42.Hess K. Death of the office and rise of the telecommuter. [Электронный ресурс] Режим доступа: https://www.google.com/url?q=http://www.zdnet.com/article/death-of-the-office-and-rise-of-the-telecommuter/&sa=D&ust=1463436639620000&usg=AFQjCNEPQJey_WHGCjH-b-ZYyuE3gd14zA (...14...).

43.Hugo Messer. How To Get Prepared For Managing A Remote Team. [Электронный ресурс] Режим доступа: https://books.google.ru/books?id=xBFGBAAAQBAJ&pg=PT46&lpg=PT46&dq=remote+team+research&source=bl&ots=s00pD43mwm&sig=Mi_8GzBd38hYTDSF7JFQil-UcPQ&hl=ru&sa=X&ved=0ahUKEwjmt_7m95_MAhWGDiwKHapsC3EQ6AEIUTAH#v=onepage&q=remote%20team%20research&f=false.

44.Kevin G. Acceptance of Telecommuting Project Management Grows [Электронный ресурс] Режим доступа: https://www.google.com/url?q=http://www.amanet.org/training/articles/Acceptance-of-Telecommuting-Project-Management-Grows.aspx&sa=D&ust=1463439249018000&usg=AFQjCNFflPbBZGf66s42DNKzW41yrxAvRA (11).

45.Kniberg Henrik. Scrum and XP from the trenches. 2015 [Электронный ресурс] Режим доступа: http://www.infoq.com/minibooks/scrum-xp-from-the-trenches-2.

46.Manifesto for Agile Software Development. [Электронный ресурс] Режим доступа: http://agilemanifesto.org/principles.html http://agilemanifesto.org/

47.Matos K., Galinsky E. National Study jf Employers. [Электронный ресурс] Режим доступа: https://www.google.com/url?q=http://familiesandwork.org/site/research/reports/NSE_2012_.pdf&sa=D&ust=1463436639597000&usg=AFQjCNFjROiOi35utkqA0e94evOt2Vmc4w (12).

48.Milhauser, Kathy L. Distributed Team Collaboration in Organizations: Emerging Tools and Practices - Emerging Tools and Practices [Электронный ресурс] Режим доступа: https://www.google.com/url?q=https://books.google.ru/books?id%3DhAl8T1dkpFkC%26pg%3DPR17%26lpg%3DPR17%26dq%3Ddistributed%2Bteam%2Bresearch%26source%3Dbl%26ots%3DFbIzh7B-JD%26sig%3DBZyO-9GTbfH8M99krdjo9TwhvFg%26hl%3Dru%26sa%3DX%26ved%3D0ahUKEwjg2q7F-J_MAhUBWiwKHYTdCsEQ6AEIPDAE%23v%3Donepage%26q%3Ddistributed%2520team%2520research%26f%3Dfalse&sa=D&ust=1463675946624000&usg=AFQjCNGHDwRirPOPEXk5oTH1oBkDiGKmAA (35).

52.Nader Ale Ibrahim, Shamsuddin Ahmed and Zahary Taha. Virtual Teams: A Literature Review. [Электронный ресурс] Режим доступа: http://cogprints.org/7814/1/2653-2669.pdf.

53.National Survey Findings. Microsoft. 2010 U.S. Remote Working Research Summary. [Электронный ресурс] Режим доступа: https://news.microsoft.com/download/features/2010/NationalRemoteWorkingSummary.pdf.

54.Scott B. Why Isn't Remote Work More Popular? [Электронный ресурс] Режим доступа: https://www.google.com/url?q=http://scottberkun.com/2015/why-isnt-remote-work-more-popular/&sa=D&ust=1463436639597000&usg=AFQjCNHH5abHL6x2QfcaMmlgW4Fhzb9s8Q (...15...).

55.Scrum: революция в проектном менеджменте. Следуйте смыслу, а не плану. Executive.ru. [Электронный ресурс] Режим доступа: http://www.e-xecutive.ru/management/practices/1985055-scrum-revolutsiya-v-proektnom-menedzhmente-sleduite-smyslu-a-ne-planu?utm_source=newsletter_exe&utm_term=&utm_medium=edition&utm_content=20160427&utm_campaign=daily_stat.

56.Sedghi А., Arnett G.How does commuting affect wellbeing? The Guardian. [Электронный ресурс] Режим доступа: http://www.theguardian.com/news/datablog/2014/feb/12/how-does-commuting-affect-wellbeing (...24...).

57.Stanford University Research. Why Remote Workers Work Better. [Электронный ресурс] Режим доступа: http://www.pbxl.co.jp/en/remote-work-research/ (...26...).

58.The Mind Tools Editorial Team. Managing a Geographically Dispersed Team. Achieving Your Goals Together, While Apart. [Электронный ресурс] Режим доступа: https://www.google.com/url?q=https://www.mindtools.com/pages/article/newTMM_40.htm&sa=D&ust=1463675946629000&usg=AFQjCNHyrKLrtHA9mryl3dX6EgLnwRkubw (32).

59. Tugend А.It's Unclearly Defined, but Telecommuting Is Fast on the Rise.Shortcuts. [Электронный ресурс] Режим доступа: http://www.nytimes.com/2014/03/08/your-money/when-working-in-your-pajamas-is-more-productive.html?_r=3 (...25...).

60. VersionOne 10th Annual State of Agile Report. [Электронный ресурс] Режим доступа: https://versionone.com/pdf/VersionOne-10th-Annual-State-of-Agile-Report.pdf (5).

Размещено на Allbest.ru

...