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

Содержание

Введение

1. Теоретическая часть

1.1 Управление проектами: краткий обзор

1.2 Методология управления проектами: определения и структура (виды и способы как вести проекты)

1.3 Управление проектами в сфере ИТ: особенности и отличия от классических моделей

1.4 Описание гибких методологий и их применимость

1.5 Гибкие методологии в контексте удаленной работы

2. Удаленная работа

2.1 История возникновения понятия “удаленная работа”

2.2 Распространение удаленной работы и тенденции развития

2.3 Преимущества и недостатки/отличительные черты удаленной работы

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

3.1 Цель, задачи и предпосылки формирования учебного проекта и команды

3.2 Адаптация элементов/принципов гибких методологий для разработки программного обеспечения / к учебному проекту

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

Заключение



Введение

гибкий методология управление проект

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

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

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

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

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

Объектом исследования является работа распределённой команды по созданию ПО.

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

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

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

· Люди и взаимодействие важнее процессов и инструментов;

· Работающий продукт важнее исчерпывающей документации;

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

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



1. Теоретическая часть

1.1 Управление проектами: краткий обзор

Проекты как вид деятельности применялись на протяжении всей истории человечества. Такие достижения, как построение Великой Китайской стены или египетских пирамид безусловно требовали определения требований, планирования сроков, мотивации и контроля, как и в современном управлении проектами. Если же рассматривать данный вид деятельности с научной точки зрения, то началом данной дисциплины можно считать работы классиков менеджмента - Г.Гантта, А.Файоля, Ф.Тейлора. Генри Гантт был американским инженером, первым предложившим использование горизонтальных диаграмм для календарного планирования работ. Диаграмма Гантта оказалась насколько эффективным инструментов, что в течение почти ста лет не видоизменялась при использовании в различных отраслях. Позже в 1990г. были добавлены связи - с целью описания зависимостей между различными задачами. А. Файоль был создателем классической теории управления, в рамках которой были определены основные функции менеджмента и заложена научная основа управления проектами. Иерархическая структура работ и многие современные инструменты для управления проектами были основаны на работах второго основоположника современного менеджмента - Ф.У. Тейлора.

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

В 1950х годах появляются математические методы для управления проектами - метод критического пути CPM и метод оценки и анализа программ PERT, в 1966г. - система GERT (Graphical Evaluation and Review Technique), использующая новую генерацию сетевых моделей. Данный метод использовался для определения вероятностных оценок наступления событий и позволял планировать управление многовариативными проектами. В 1970х годах формировался системный подход к управлению проектами, развитие организационных структур управления проектами и определение системы ролей в ее рамках. 1980е годы можно считать стартом формирования управления проектами как профессиональной деятельности. В это время появляются существенные дополнения и новые области знаний. Появляется первый свод правил в рамках работы института PMI - Project Management Body Of Knowledge (Свод знаний по управлению проектами), в которой определены место, контроль и структура методов и средств управления проектами, их вклад в общее управление.

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

Начиная с конца 1990х и по настоящее время в мире наблюдается рост числа организаций, применяющих гибкие методологии управления проектами (agile). Данный подход противопоставляется традиционному управлению проектами, поскольку делает акцент на командной работе, гибкости и приветствию изменений, короткие и частые итерации в ходе ведения проекта. Более подробно гибкие методологии будут рассмотрены в следующих разделах.

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

Управление проектами - это методология (также искусство) планирования и организации, а также координации трудовых, финансовых и материально-технических ресурсов при помощи современных методов, техники и технологии управления, направленная на достижение определенных результатов по составу и объему работ, стоимости, времени и качеству.

Признаки проекта:

- Наличие целей;

- Наличие изменений;

- Ограниченность во времени;

- Замкнутость;

- Специфичность организации.

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

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

Однако количество проектов, завершенных неудачно, остается все еще значительным.

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

1.2 Методология управления проектами: определения и структура (виды и способы как вести проекты)

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

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

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

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

-- международные: стандарты, получившие международное значение в процессе своего развития или предназначенные для международного использования;

-- национальные: созданные для применения внутри одной страны или получившие общенациональный статус в процессе своего развития;

-- общественные: подготовленные и принятые сообществом специалистов;

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

-- корпоративные: разработанные для применения внутри одной компании или внутри группы родственных компаний.

Среди стандартов по управлению проектами наиболее распространенными являются следующие:

1. Project Management Body of Knowledge (PMBOK), подготовленный американским институтом управления проектами (Project Management Institute -- PMI). Данный стандарт регулярно обновляется, в частности, сейчас идет работа над шестой его версией. В основе данного стандарта лежит процессный подход к управлению проектами, формализованные принципы и подходы, подходящие для управления проектами в большинстве случаев. Детально описываются десять областей знаний, связанных с управлением проектами:

1. Управление интеграциеи? проекта

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

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

4. Управление стоимостью проекта

5. Управление качеством проекта

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

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

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

9. Управление закупкам проекта

10. Управление заинтересованными сторонами

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

2.Методология IW URM (Unique Reliable Method) - ориентирована на гарантированное достижение успеха и строится с учетом того, чтобы заявленные цели клиента были достигнуты. Имеет набор различных технологий, документов и процедур для различных проектов.

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

4. Методология P2M(A Guidebook of Project and Program Management for Enterprise Innovation) ориентирована на улучшение организации, а не на продукт или процессы, и представляет собой систему знаний. Ведение проектов создает новый дополнительный опыт и помогает организации на его основе реализовывать последующие проекты. Важными аспектами методологии являются создание ценности в итоге реализации проекта и признается наличие неопределенности на всех его стадиях. Внешние обстоятельства выступают также как одно из ограничений проекта, что отличает данную методологию от стандартов PMBOK. Вместе с тем, данный стандарт менее популярен и содержит меньше информации о способах применения на конкурентных примерах.

5. ISO 21500 (...5…) - это стандарт, практически копирующий процессы PMBOK. Отличия заключаются лишь в четырех процессах, раскрытых в ISO 21500 иначе: извлечение уроков, определение оргструктуры, управление коммуникаций и управление ресурсами. ISO удобен тем, что сочетается со стандартами качества ISO и является распространенным и перспективным стандартом управления проектами, однако неудобен для малых проектов и имеет сравнительно мало доступной в свободном виде документации.

6. PRINCE2 (PRojects IN Controlled Environments 2) - это методология, включающая в себя три важные составляющие - планирование, управление изменениями и управление качеством. Каждый процесс в данном подходе состоит из стадий, подстадий и связей. К отличительным чертам данной методологии можно отнести то, что в планировании используется PBS (Product Breakdown Structure) вместо классического WBS. Задачей PBS является разбиение целевого продукта на подпродукты, которые не должны пересекаться. При этом не все компоненты имеют достаточное описание и имеются ограничения доступа к актуальной документации.

7. ASAP (Accelerated SAP) (ValueSAP) - методология, созданная компанией SAP AG для внедрения программного обеспечения. В данную методологию входят три компонента - ASAP карта, инструменты и R/3 сервис и обучение, что позволяет оптимизировать эффективность по срокам и качеству. Методология идеально подходит при внедрении продуктов SAP и достаточно подробно документирована, для остальных программных продуктов подходит в меньшей степени.

8. ГОСТ (Россия) - российский стандарт, являющийся адаптацией требований PMBOK для малых проектов. Имеет те же преимущества и недостатки, что и PMBOK, только в локальном масштабе.

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

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

· Группа процессов планирования содержит определение содержания проекта, конкретизацию целей и последовательности действий, которые требуются для ее достижения.

· Группа процессов исполнения объединяет применяемые в работе процессы с целью удовлетворения спецификаций проекта.

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

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

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

1.3 Управление проектами в сфере ИТ: особенности и отличия от классических моделей

В рамках анализа управления проектами в сфере информационных технологий целесообразно рассмотреть такое понятие, как технология. Довженко А.И. (37) дает ей следующее определение:

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

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

· управление и отслеживание деятельности всех участников проекта

· распределение работ внутри команды проекта

· формулирование списка требований к документации и отдельным элементам проекта

· определение критериев качества программного продукта.

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

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

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

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

В рамках реализации интернет проектов есть свои особенности выполнения:

· наличие проблемы в установлении эффективных коммуникаций между клиентом и исполнителем. Заказчиком обычно является бизнес, а в роли исполнителя выступает коллектив IT-специалистов, и в рамках такой коммуникации возникают сложности в формировании требований, технического задания и ожиданий от конкретного проекта;

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

· сильная взаимосвязь IT-процессов и бизнеса. Нередки случаи, когда в ходе реализации интернет проекта организации приходится перестраивать часть своих бизнес-процессов;

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

· в крупных компаниях затраты на реализацию масштабных IT-проектов составляют миллионы долларов и требуют больших и регулярных финансовых вложений. Масштабность проекта накладывает дополнительную ответственность и требует более высокого уровня компетенции руководителей таких проектов;

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

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

В настоящее время среди IT-проектов наиболее распространены следующие группы проектных методологий:

· методология управления процессом разработки проекта;

· методология внедрения современных информационных систем.

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

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

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

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

Водопадная модель - это последовательный метод разработки с четко определенными выходными продуктами на каждом этапе.

Главной особенностью водопадной модели является то, все этапы выполняются последовательно. Это означает, что новая фаза не может начаться, если не завершена предыдущая. Для этого необходимо четкое планирование в самом начале проекта, и это обычно связано с написанием больших технических заданий, и результат работающей программы можно наблюдать только в конце. В IT-проекте при использовании водопадной модели руководит менеджер проекта, он ставит задачи разработчикам, а также устанавливает бюджет и сроки. И на протяжении всего жизненного цикла команда проекта отчитывается по проделанной работе только перед менеджером. При этом коммуникации непосредственно с заказчиком отсутствуют. Если требования, определенные в начале проекта не меняются, то руководствоваться техническим заданием весьма целесообразно. Но сложность в том, IT-проект практически нереально спроектировать таким образом, чтобы заранее предугадать все требования пользователей, его функционал и так далее. Помимо всего прочего, если что-то было упущено в работе проекта на его начальных стадиях, исправить это, находясь на завершающих этапах, очень сложно и требует дополнительных затрат.

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



Рис 1 Водопадная модель управления проектом

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

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



Рис 2 Итеративная модель управления проектом

Спиральная модель. Развитием идеи итеративной разработки программного обеспечения является спиральная модель жизненного цикла. Её предложил Барри Боэм в 1986 году. Главная её идея - это минимизация рисков в начале каждой итерации путем повышения коммуникации внутри команды проекта. В начале каждой итерации определяют:

· Цели разрабатываемого в течение данной итерации фрагмента программного обеспечения;

· Основные и альтернативные пути к достижению поставленных целей;

· Анализ возможных ограничений.

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

Каждая последующая итерация в спиральной модели добавляет степень завершенности общего проекта и соответственно обеспечивает более глубокий уровень детализации(Рис. 3):

Рис 3 Спиральная модель управления проектом

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

Циклическая модель (Rational Unified Process, сокращённо RUP) - это процесс разработки программного обеспечения, а именно частично упорядоченный набор шагов, которые нужно проделать для достижения цели; при разработке программного обеспечения цель состоит в формировании или расширении существующего программного продукта.

Рис 4 RUP - циклическая модель управления проектом

Rational Unified Process (RUP) является итеративной моделью разработки, которая содержит в себе четыре фазы: начало, исследование, построение и внедрение. Каждая фаза может быть разделена на этапы (итерации), в результате выполнения которых промежуточная версия. Прохождение через четыре основные фазы называется циклом разработки, в рамках которой каждый цикл должен завершаться генерацией версии системы.

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

· очень широкий диапазон решений в части формализации процесса разработки;

· можно использовать как основу для водопадного стиля разработки, так и в качестве гибкого процесса;

· снижение основных рисков заказчика и разработчика;

· экономия ресурсов за счет автоматизации регрессионного тестирования;

· улучшение качества ПО за счет многократных проверок изменений;

· улучшение качества тестирования за счет использования современных технологий.

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

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

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

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

1.4 Описание гибких методологий и их применимость

Гибкая методология разработки (англ. Agile software development, agile-методы) -- представляет собой серию подходов к разработке программного обеспечения (ПО), которые ориентированы на применение интерактивной разработки, адаптированы к динамически формируемым требованиям и способны обеспечить реализацию проекта за счет постоянного взаимодействия в рамках команд, состоящих из специалист различного профиля. Существует несколько методик, которые принято относить к семейству гибких методологий разработки, наиболее применяемыми из них являются Scrum, FDD, AUP, DSDM, экстремальное программирование, бережливая разработка и их комбинации. Каждая из данных методологий применяется как эффективная практика для организации труда в случаях, когда небольшая по размеру группа людей выполняет творческую работу с целью запуска проекта либо внедрения определенного программного продукта.

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

Гибкие методологии следуют Agile-манифесту разработки программного обеспечения, принятому в феврале 2001г. в штате Юта, США, в котором декларируется:

“Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что:

· Люди и взаимодействие важнее процессов и инструментов

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

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

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

Основополагающими принципами Agile-манифеста являются следующие утверждения:

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

· Изменение требований приветствуется, даже на поздних стадиях разработки.

· Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.

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

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

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

· Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.

· Работающий продукт -- основной показатель прогресса.

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

· Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.

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

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

· Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

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

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

Таблица 1

Различия между гибкими методологиями и традиционными (...2...)

Иными словами, различия между гибкими (agile) и традиционными (как, например, водопадная) методологиями заключаются в следующем:

Рис. 5 Сравнение гибкой методологии и водопадной (...3...)

При этом если рассматривать сферы применения гибких методологий, VersionOne (...) приводит следующие данные по использованию данного способа ведения проектов:

Рис 6 Отрасли, в которых наиболее часто используется Agile (...4…)

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

В качестве основных преимуществ использования гибких методологий отмечаются возможность управлять изменением приоритетов(87%), увеличение продуктивности команды(85%) и улучшение прозрачности проекта(84%)

При этом наблюдается следующее распределение гибких методологий по популярности:

Рис. 7 Распределение по популярности использования гибких методологий

На приведенном рисунке видно, что самой популярной гибкой методологией является Scrum(58%). С значительным отрывом за ним следует сочетание Scrum+XP (17%), в то время как оставшиеся методологии набирают 5 и менее процентов от общего числа. Популярность обусловлена следующими его отличительными чертами:

· основан на простых и понятных базовых принципах,

· работает с любыми технологиями и инструментами,

· проверен временем и реальными проектами.

Рассмотрим более подробно методологии, которые придерживаются ценностей и принципов, заявленных в Agile Manifesto:

· Agile Unified Process (AUP) упрощенная версия IBM Rational Unified Process (RUP), разработанная Скоттом Амблером, которая описывает простое и понятное приближение (модель) для создания программного обеспечения по большей части для создания бизнес-приложений. В отличие от RUP имеет только семь дисциплин: модель, реализация, тестирование, развертывание, управление конфигурацией, управление проектом и окружающая среда.

· Scrumban - это методология, комбинирующая элементы Scrum и принципов Kanban, которые, в в свою очередь, не являются методологией и основывается на принципе уменьшения выполняющейся в данный момент работы (work in progress). Сочетание данных подходов позволяет решать стратегические задачи и работать с, радиционными циклами обратной связи и прозрачностью, характерных для Scrum методологии. С помощью Kanban в рамках проекта решаются тактические задачи внутри Спринта и выравнивается общий поток задач.

· Метод разработки динамических систем (Dynamic Systems Development Method, DSDM) основан на концепции быстрой разработки приложений (Rapid Application Development, RAD). В рамках данного подхода особое значение уделяется продолжительности участия в процессе пользователя или потребителя. Самая последняя версия DSDM была названа DSDM Atern в честь Arctic Tern, что в переводе значит полярная крачка. Этим термином обозначается птица, которая может путешествовать на большие расстояния. Методологии свойственно наличие множества аспектов, например определение приоритета или кооперирование, которые являются естественным способом ведения рабочего процесса.

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

Рис. 8 Этапы работ в экстремальном программировании

· Feature driven development (FDD) -- представляет собой функционально-ориентированную разработку. Используемый в данном контексте термин “свойство”(feature) близок по своему смыслу к преценденту использования в методологии RUP, однако использует дополнительное ограничение на сроки реализации - каждая итерация должны занимать не более двух недель. Если сценарий использования занимает мало времени, то такой функционал считается свойством. Если же функционал достаточно большой, то его требуется разбить на несколько сравнительно независимых функций.

· Lean software development - бережливая разработка программного обеспечения, основанная на подходах концепции бережливого производства. Основной принцип в данном случае заключается в минимизации потерь, к которым относится все, что не добавляет ценности для потребителя, как например излишняя функциональность; ожидание (паузы) в процессе разработки; нечёткие требования; бюрократизация; медленное внутреннее сообщение. Принятие решений в данной методологии принципиально откладывается, поскольку предпочтительно предпринимать действия не на основе предположений и прогнозов, а после открытия существенных фактов.

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

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

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

Рис 9 Общая схема использования модели Scrum

Согласно Scrum методологии работа должна быть организована в небольших кроссфункциональных командах, которые содержат всех необходимых специалистов. Рассмотрим роли согласно данной методологии:

Команда - группа людей, способных помогать друг другу, ответственных за разработку самого продукта или проекта (4-8 человек).

Product Owner - единственный полномочный представитель заказчика, кто определяет видение, расставляет приоритеты работ и определяет критерии приемки.

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

А также внешние участники, не относящиеся непосредственно к команде, но влияющие на ход проекта:

Пользователь - разноликий «конечный пользователь», кто действительно будет пользоваться продуктом.

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

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

Менеджеры - ответственны за бухгалтерию, отчеты и подсчеты, но в фактическую разработку не вовлечены.

У каждой команды должен быть scrum-master, который отвечает за соблюдение процессов в команде и конструктивную атмосферу. Требования должны быть разбиты на небольшие, ориентированные на пользователей, функциональные части, которые максимально независимы друг от друга, и список таких требований называется беклогом. После формирования всех задач в беклоге необходимо ранжировать их по степени важности и произвести относительную оценку объемов каждой истории. Product owner - владелец продукта - еще одна необходимая роль в команде, задачей такого сотрудника является формирование требований и приоритетов для конечного продукта.

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

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

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

Бахтизин и Кузиков(...) отмечают, что scrum команды периодически сталкиваются с нарушением сроков выполнения работ, запланированных в рамках одной итерации вследствие изменения приоритетов пользовательских требований. Предусмотреть время наступления таких сценариев в течение всего проекта проблематично, однако оценить риски выполнения незапланированных работ в течение одной итерации реально. Для этого необходимо учитывать и придерживаться следующих особенностей методологии Scrum:

· Решения в рамках команды принимаются коллективно

· Вся команда является ответственной за итоговый результат

· Общая цель должна быть понятна и разделяться участниками проекта

· Необходимость в наличии взаимной ответственности и доверия

· В рамках проекта необходимо достижение прозрачности

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

1.5 Гибкие методологии в контексте удаленной работы

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

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

Основные признаки команды:

· совместная деятельность;

· общие цели;

· взаимная и коллективная ответственность;

Таким образом, при организации работы над проектом по гибкой методологии критически важно решить две главные задачи:

· как сформировать команду проекта

· как организовать эффективную работу команды

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

При подборе профессиональной команды следует обращать на наличие у потенциальных участников следующих навыков:

1. технические и/или функциональные, т.е. профессиональные навыки;

2. навыки по решению проблем и принятию решений;

3. навыки межличностного общения (принятие риска, полезная критика, активное слушание и т.д.)

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

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

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

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

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



2. Удаленная работа

2.1 История возникновения понятия “удаленная работа”

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

...