Будь умным!

У вас вопросы?
У нас ответы:) SamZan.net

Керування географічно-розподіленими проектами у Web-середовищі

Работа добавлена на сайт samzan.net: 2017-02-07

Поможем написать учебную работу

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

Предоплата всего

от 25%

Подписываем

договор

Имя

Выберите тип работы:

Принимаю Политику конфиденциальности

Скидка 25% при заказе до 27.4.2024

Цей матеріал нам люб’язно надано сайтом Репетиторы Украины

Національний університет «Києво-Могилянська академія»

Магістерська програма

«Інтелектуальні управляючі системи та технології»

kma

Кваліфікаційна робота

на здобуття ступеня магістра

на тему:

Керування географічно-розподіленими проектами у Web-середовищі

Виконав:

студент МП-2

Пустовіт І. С.

Науковий керівник:

к.т.н. Кислоокий В.М.

Київ – 2012

Календарний план виконання магістерської роботи

Тема: Керування географічно-розподіленими проектами у Web-середовищі

Календарний план виконання роботи:

№ п/п	Назва етапу дипломного проекту	Термін виконання етапу	Примітка
1.	Отримання завдання на дипломну роботу.	02.11.2011
2.	Огляд літератури за темою роботи	15.11.2011
3.	Визначення критеріїв порівняння web-застосувань, що використовуються для керування проектами	25.11.2011
4.	Порівняння існуючих web-застосувань	10.12.2011
5.	Огляд методології Agile Scrum	15.01.2012
6.	Дослідження проблем географічно-розподіленої розробки	15.02.2012
7.	Аналіз результатів, отриманих у ході дослідження	30.03.2012
8.	Підхід до вирішення проблем географічно-розподіленої розробки	10.04.2012
9.	Створення слайдів для доповіді та написання доповіді.	22.04.2012
10.	Аналіз отриманих результатів з керівником, попередній захист магістерської роботи.	19.04.2012
11.	Корегування роботи за результатами попереднього захисту.	25.04.2012
12.	Остаточне оформлення пояснювальної роботи та слайдів.	15.05.2012
13.	Захист магістерської роботи	18.05.2012

Студент: Пустовіт Ілля Степанович

Керівник: Кислоокий Володимир Микитович

“______”______________

ЗМІСТ

Анотація ………………………………………………………………………. 4

ВСТУП ………………………………………………………………………... 5

РОЗДІЛ 1. ПОСТАНОВКА ЗАДАЧІ ……………………………………….. 7

1.1 Сучасний стан проблеми ………………………………………….. 9

1.2 Задачі досліджень ………………………………………………… 12

РОЗДІЛ 2. ПОРІВНЯННЯ СУЧАСНИХ WEB-ЗАСТОСУВАНЬ ДЛЯ КЕРУВАННЯ ПРОЕКТАМИ ……………………………………………… 13

2.1 Підхід до порівняння …………………………………………….. 13

2.2 Порівняння сучасних Web-застосувань для керування проектами 17

РОЗДІЛ 3. ДОСЛІДЖЕННЯ ПРОБЛЕМ ВПРОВАДЖЕННЯ МЕТОДОЛОГІЇ AGILE SCRUM ДЛЯ РОЗПОДІЛЕНИХ ПРОЕКТІВ ……………………… 24

3.1 Основи методології Agile Scrum ………………………………….. 28

3.2 Принципи роботи географічно-розподілених команд ………….. 38

3.2.1 Керування процесом розробки проекту …………………. 38

3.2.2 Керування знаннями в географічно-розподіленій команді 40

3.3 Аналіз проблем методології Agile Scrum у географічно-розподіленому середовищі ……………………………………………. 44

РОЗДІЛ 4. ПРАКТИЧНА ЧАСТИНА ……………………………………….. 54

4.1 Підхід до вирішення проблем координації розподілених команд 54

4.2 Вдосконалення існуючої web-базованої системи керування проектами Redmine. Орієнтація на географічно-розподілену розробку ………………………………………………………………………………….. 60

ВИСНОВКИ …………………………………………………………………. 64

ПОСИЛАННЯ ……………………………………………………………….. 67

ДОДАТКИ …………………………………………………………………….

АНОТАЦІЯ

до магістерської роботи під назвою "Керування географічно-розподіленими проектами у Web-середовищі ".

Магістерська робота: 72 сторінки, 8 рисунків, 39 джерел, 1 додаток.

Проводиться дослідження сучасних Web-базованих систем для керування проектами на предмет їх функціональності і придатності для роботи віртуальних команд. Розглядається методологія Agile Scrum з метою її адаптації до роботи в географічно-розподіленому середовищі.

Метою роботи є вирішення проблем, що виникають на шляху керування географічно-розподіленими проектами у Web-середовищі.

Результати: методологія Agile Scrum адаптована до роботи в географічно-розподіленому середовищі. Вироблені критерії, яким має відповідати робота віртуальних команд. Створена модель середовища, що поєднує в собі загальні вимоги до розробки проектів та вимоги, що усувають проблеми, властиві саме географічно-розподіленим проектам. Розроблений новий модуль для Web-застосування Redmine з метою адаптації системи до географічно-розподіленої розробки.

КЕРУВАННЯ ГЕОГРАФІЧНО-РОЗПОДІЛЕНИМИ ПРОЕКТАМИ, АДАПТАЦІЯ SCRUM ДО ГЕОГРАФІЧНО-РОЗПОДІЛЕНОГО СЕРЕДОВИЩА, GEORGAFICALLY DISTRIBUTED DEVELOPMENT, SCRUM IMPROVEMENTS

ВСТУП

Розподілені команди розробників програмного забезпечення існують досить давно. Причинами виникнення такого виду розробки проектів є не лише економія коштів на пошуку кваліфікованих спеціалістів, а й його зручність безпосередньо для робітників. Глобалізація і розвиток міжнародної торгівлі спричинили ситуацію, коли компаніям необхідно швидко реагувати на потреби ринку і збільшувати продуктивність в рази, залишаючись при цьому економічно ефективними. Доступних локально талановитих спеціалістів, як правило, не вистачає, а витрати на них помітно вищі за вартість аутсорсингу. З іншого боку, аутсорсинг вигідний лише тоді, коли розподілені команди здатні забезпечувати високу якість роботи. Таким чином, основним фактором розвитку розподілених проектів є збільшені технічні можливості, які, в свою чергу, збільшують можливості компанії, що займається розробкою того чи іншого продукту. Економічна ефективність залишається на другому плані.

В роботі розподілених (віртуальних) команд розробників існує багато проблем як технічного, так і не технічного характеру. Як стверджують дослідники, основною проблемою є збільшення часу на розробку фінального продукту [1, 5]. Також помітні проблеми відсутності неформального спілкування між учасниками, міжкультурні конфлікти, часова та географічна віддаленість команд. В даній роботі буде розглянута більшість аспектів цих проблем.

Ключовим кроком для подолання вищезгаданих складностей є чітка структуризація процесу розробки проекту та керування цим процесом. Важливою складовою цього процесу є аналіз існуючих методологій розробки програмного забезпечення і їх адаптація до потреб розподілених команд В якості інструмента, що покликаний полегшити розподілену роботу, найчастіше виступає Web-вузол. Таке рішення вирішує питання крос-платформеності, не залежить від обчислювальних потужностей комп’ютерів, знижує витрати на підтримку системи, а також забезпечує її широку доступність як для географічно розподілених користувачів, так і для користувачів внутрішніх мереж компанії. На даному етапі існує певна кількість спеціалізованих систем та систем широкого призначення, що задовольняють вимогам розробки віртуальних команд розробників та мають різний функціонал. Проте, для загального аналізу ефективності і створення рекомендацій щодо їх використання, необхідно визначити чіткі критерії їх порівняння.

Отже, дану роботу присвячено:

- дослідженню основних проблем, з якими стикаються розподілені команди розробників;

- порівняльному аналізові сучасних web-систем, призначених для координації розподілених проектів;

- дослідженню методології гнучкої розробки розподілених проектів та її адаптації з метою усунення існуючих проблем.

РОЗДІЛ 1. ПОСТАНОВКА ЗАДАЧІ

Впродовж останніх двох десятиліть процеси розробки та підтримки програмного забезпечення зазнали суттєвих перетворень. Для роботи над багатьма проектами стало економічно доцільно використовувати команди розробників, що розміщені в різних точках світу; стала відігравати першочергову роль координація та комунікація цих команд через глобальну мережу Інтернет. Як наслідок, постала необхідність розробки інструментів, які би підтримували усі звичні процеси розробки для розподілених (віртуальних) команд. Зрозуміло, що дані інструменти повинні мати високу доступність по всьому світу в будь-який час, а також не накладати додаткових системних обмежень на користувачів. Реалізація цих засобів у вигляді Web-вузла автоматично задовольнить ці основні вимоги.

З історичної точки зору, в 1980х рр. управління проектами було зосереджене на якості, в 1990х – на глобалізації процесів; зараз же основним фактором, що диктує засоби керування проектами, є швидкість: щоб залишатися попереду конкурентів, організаціям доводиться не лише знижувати витрати шляхом використання розподілених груп розробників, але й намагатися прискорювати їх роботу. Крім цього, зростає необхідність у крос-функціональних знаннях всередині цих груп. Таким чином, поряд із класичними завданнями керування проектами, як планування, облік часу, додаються цілком нові – координація та співпраця людей і груп, розділених не лише географічно, а й по часових поясах [2, 1]. Детальне вивчення цих нових проблем є ключовим у створенні інструменту керування проектами.

Впродовж останніх 10-15 років активно тривають роботи із розробки таких Web-базованих застосувань. До них входять модулі керування проектом (планувальники, засоби збереження знань та онлайн-спілкування), засоби візуалізації (діаграми Ганта), та засоби роботи безпосередньо із артефактами розробки (інструменти контролю версій, обліку дефектів і покращень). Існує значна кількість таких систем, як комерційних, так і з вільним доступом; при цьому набір їх можливостей може сильно коливатися. Отже, важливим для подальшого розвитку подібних web-застосувань є аналіз існуючих розробок, що передбачає вироблення критеріїв для порівняння та аналіз вимог, яким мають задовольняти такі системи керування проектами.

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

1.1 Сучасний стан проблеми

Глобалізація бізнесу та широке впровадження аутсорсингу в 1990х рр. зробили актуальними дослідження у галузі координації розподілених проектів. Суть розподілення полягає в тому, що різні групи спеціалістів, які належать до проекту, можуть знаходитися в географічно віддалених точках країни і світу. Такий підхід стали називати «географічно розподіленою розробкою» (“Geographically Distributed Development”). В результаті такого підходу з'явилися нові проблеми і завдання, які потребують вирішення. Найбільш важливими проблемами є, зокрема: застосування і розширення існуючих форм групової розробки до розподілених команд, впровадження засобів комунікації і спільної роботи над проектом, проблема міжкультурної взаємодії учасників.

Одним із питань, яке потрібно вирішити, це майже повна неможливість неформального спілкування між географічно розподіленими учасниками проекту. В роботі Гербслеба, Грінтера і Перрі [3, 309] дається опис чотирьох можливих підходів для вирішення цієї проблеми:

· Розподіл працівників за функціональними областями/областями професійних знань (дизайнери, тестувальники, аналітики тощо);

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

· Фокусування на внутрішній структурі продукту – на ранньому етапі знання про архітектуру кінцевого продукту дадуть можливість визначитися, хто із ким буде координувати свою роботу;

· Акцентування уваги працівників на поетапну розробку за стадіями (в т.ч. ітераціями).

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

Для вчасного обміну робочою інформацією та оперативного прийняття рішень необхідні додаткові технології, з гарантованою надійністю та зручністю для користувачів. Так, згідно з дослідженням Бейкера, додавання відео до аудіо спілкування у віртуальних командах покращує якість прийнятих рішень. Іншим важливим фактором у розподіленій розробці є координація. Оскільки бізнесові і технічні процеси виконуються різними організаціями, контроль над циклом розробки продукту стає нетривіальною задачею для керівників, особливо якщо до них додається координація підтримки готового продукту. У праці [4, 1] проблеми координації роботи розглядаються з точки зору різниці часових поясів, і, як наслідок, необхідності у асинхронному обміні знаннями. Варто згадати ще одну важливу проблему, а саме адаптацію членів віртуальних команд до розподіленої роботи. Необхідність пристосовуватися до розподілених процесів суттєво впливає на ефективність роботи як окремих працівників, так і команд в цілому.

Проблематика реалізації Web-застосувань для координації проектів також включає в себе розробку основних модулів для забезпечення типових функцій розробки програмного забезпечення. Так, важливим елементом такого застосування має стати засіб для контролю версій і зберігання коду проектів. Зазвичай ця функціональність реалізується шляхом інтеграції у Web-вузол інтерфейсу до однієї з широко розповсюджених систем контролю версій (CVS, Subversion тощо). Цей підхід є дуже гнучким, тому що дозволяє роботу із файлами проектів як через Web-вузол, так і шляхом використання традиційних середовищ розробки, що мають підтримку даних систем, без необхідності дублювання інформації. Приклад такої інтеграції наведено в роботі [5, 276].

У розподілених проектах великого значення набувають засоби візуалізації різноманітних даних, які покращують їх розуміння працівниками і частково сприяють вирішенню проблем комунікації. Сюди входять як традиційні інструменти, наприклад діаграми Ганта для розподілу завдань, так і нові ефективні засоби аналізу дефектів і залежностей в архітектурі проектів. Описаний в роботі [6, 7] засіб на основі аналізу хронологічної інформації про дефекти (звіти про зміни, звіти про проблеми, інформації про функціональність) дає змогу побудувати і графічно відобразити приховані залежності між окремими модулями програми. Це дає змогу знаходити вади у самій архітектурі системи і наглядно їх демонструвати. Даний підхід був випробуваний в широковідомому відкритому проекті Mozilla.

Варто зазначити про важливість вибору методології керування розподіленими проектами. Завдяки новітнім дослідженням з'являється можливість застосування парадигм, які раніше вважалися непридатними для розподіленої координації проектів, зокрема мова йде про технології гнучкої розробки і методологію Scrum.

1.1 Задачі досліджень

Основною метою даної роботи є вирішення проблем, що виникають на шляху керування географічно-розподіленими проектами у Web-середовищі. Зокрема, основні задачі, які потрібно вирішити для досягнення мети:

1. Розглянути сучасні Web-базовані системи для керування проектами на предмет їх функціональності і придатності для роботи віртуальних команд. Задача включає в себе вироблення ефективних критеріїв оцінки даних систем та їх порівняння.

2. Дослідити проблеми, що виникають у процесі керування розподіленими проектами.

3. Запропонувати шляхи вирішення проблем, що постають на шляху застосування систем керування розподіленими проектами. Показати ефективність цих рішень шляхом їх впровадження в систему керування проектами.

РОЗДІЛ 2. ПОРІВНЯННЯ СУЧАСНИХ WEB-ЗАСТОСУВАНЬ ДЛЯ КЕРУВАННЯ ПРОЕКТАМИ

2.1 Підхід до порівняння

Розробка систем керування проектами потребує чіткого структурованого підходу до проблеми. Коли ж йдеться про засоби для координації діяльності розподілених чи віртуальних команд, окрім стандартних питань потрібно врахувати всі особливості розподіленої роботи, зокрема, інструментарій розробки, деталі організації роботи розробників тощо.

Для початку варто визначити ті критерії порівняння для систем підтримки Web-вузлів для координації проектів, що властиві в загальному випадку будь-яким програмним продуктам.

Безперечно, при дослідженні програмних продуктів для підтримки Web-вузлів призначених для керування проектами, буде важливим зазначити згідно якої ліцензії вони поширюються. Програмні засоби з відкритим кодом роблять можливим гнучке налаштування та редагування відповідно до потреб фірми чи групи розробників; особливо це стосується модулів, що відповідають за облік дефектів, розподіл завдань, спілкування, контроль версій програмного коду тощо.

Як і для будь-якого програмного забезпечення, важливою характеристикою є наявність локалізації, що значно покращує можливість використання системи непідготованою в мовному плані частиною користувачів. Істотний вплив на вибір тієї чи іншої системи для підтримки Web-вузлів можуть стати вимоги до сервера та СУБД , а також інші системні вимоги.

Іншою групою критеріїв оцінки систем підтримки Web-вузлів для координації проектів є критерії, властиві саме для програмного забезпечення, призначеного для керування проектами.

Одним зі складових менеджменту проектами є керування та розподіл ресурсів, що включає детальний перелік всіх розподілених завдань, обробку раптової недоступності ресурсу, обліки доступних ресурсів, тощо.

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

Ще однією з вимог до систем підтримки Web-вузлів для координації проектів є інтегрованість системи контролю версій. Забезпечення можливості перегляду репозиторію програмного коду, а також даних про здійснені зміни в ньому покращує координацію роботи команди, дає краще розуміння ходу виконання робіт, та загалом зменшує потребу використання учасниками команди додаткових програмних засобів. При аналізі систем керування проектами варто також дослідити, з якими саме системами контролю версій можлива інтеграція.

Завдання (tasks) є головними складовими проекту, таким чином засоби для їх групування, розподілу та контролю за їх виконанням є головною вимогою для системи керування проектами. Додаткові засоби візуального представлення, наприклад, діаграми Ганта, є значним плюсом в реалізації таких складових, оскільки дають різноплановий погляд на ситуацію.

Концепція критичного шляху дозволяє ідентифікувати ключові завдання в реалізації проекту. Засоби для on-line планування дозволяють користувачам ефективніше обрати метод для застосування при вирішення цих ключових завдань.

Однією з характеристик системи для керування проектами, буде наявність в ній засобів для керування портфелями проектів. Керування портфелями проектів, являє собою термін, що використовується для опису методів аналізу і керування групою поточних чи планованих проектів. Головна мета полягає у визначенні оптимального поєднання і послідовності пропонованих проектів для найкращого досягнення організацією загальної, спільної мети. Процес керування портфелем проектів полягає головним чином у визначенні бізнес-стратегій, і цілей, при наявності загальних обмежень на портфель проектів в цілому; в породженні і постійному контролі та зміни проектів для досягнення вказаних цілей.

Важливим компонентом в системах керування проектами є засоби для організації та підтримання ведення документації. Основною функціональністю, що мусить бути реалізована у модулях для підтримки керування документами є індексування, зберігання, структуризація та контроль версій (подібно до аналогічної функції щодо контролю версій програмного коду). Наявність такої компоненти значно розширює можливості системи підтримки Web-вузлів для координації проектів, зокрема дозволяє ефективно зберігати організаційний досвід та забезпечувати команди розробників потрібними в роботі знаннями.

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

· Інтегрована система контролю версій і зберігання кодів програм, в т.ч. перегляд списків змін; важливою є підтримка кількох різних систем контролю версій;

· Система розподілу завдань серед членів команд та обліку їх поточного стану і виконання; додатковою зручністю є візуалізація цих даних;

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

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

· Зручні засоби для планування вирішення тих чи інших завдань (milestones, to-do lists тощо).

Для порівняння було обрано ряд програмних продуктів, призначених для керування проектами різних виробників таким чином, щоб вдало проілюструвати весь спектр існуючих продуктів такого типу та їх можливості. В рамках цієї роботи розглядаються тільки Web-застосування для керування проектами.

2.2 Порівняння сучасних Web-застосувань для керування проектами

Basecamp

Basecamp є популярним комерційним продуктом компанії 37 signals. Дане програмне рішення написане на платформі Ruby on Rails. Воно не розповсюджується серед замовників, натомість пропонується реєстрація і безпосереднє користування продуктом на офіційному сайті. Це знімає необхідність для компаній проводити інсталяцію та підтримку системи, оновлення тощо. Донедавна Basecamp був доступний лише англійською мовою, але на початку червня 2010 року з'явилися перші локалізації на кілька інших мов, цей процес триває і надалі.

Basecamp дозволяє керувати одночасно багатьма різними проектами, у зручному вигляді відображаючи інформацію, в тому числі і про клієнтів. Підтримуються списки завдань (to-do lists), як відкриті, так і приватні. Також є зручні можливості для обміну документами та іншими файлами серед учасників проектів. До цього слід додати важливу функцію Milestones, яка дозволяє планувати дії команд і визначати відповідальних працівників; даний засіб інтегрується в поширені системи календарів за стандартом iCalendar.

Важливою стороною Basecamp є його засоби для координації команд, такі як відстеження робочих годин працівників та інтеграція із to-do lists і Milestones.

Звичайно, опис даного продукту був би неповним без згадки про наявність засобів для онлайн і офлайн спілкування учасників. Також Basecamp має досить потужну систему API, що дозволяє інтегрувати його функціональність в інші Web- та десктоп застосування [7, 1].

Bugzilla

Система є програмним продуктом з відкритим кодом, і розповсюджується згідно ліцензії Mozilla Public License. Даний програмний продукт написаний мовою Perl і для роботи потребує будь-який Web-сервер з підтримкою CGI, та систему керування базами даних MySQL, PostgreSQL, або Oracle.

В цілому даний програмний продукт є системою обліку дефектів – bugtracker. Однак досить потужний функціонал Bugzilla дозволяє розглянути її як систему корисну при керуванні проектами. Важливою рисою даного програмного продукту є потужний Google-подібний механізм пошуку інформації, повнотекстовий пошук інформації про помилки, занесеної до системи та пошук за різними параметрами, зокрема за часовими. До цього слід додати інструмент для перегляду історій зміни коду, зокрема з полагодження певного дефекту. Інформацію, що накопичена в системі, можна переглянути у вигляді звітів у різних форматах (Atom, iCal, CSV), присутня можливість генерації графіків та діаграм.

Координація учасників розподіленої команди здійснюється за допомогою набору іструментів, таких як повідомлення через e-mail про зміни та надсилання звітів щодо роботи системи у вказаний термін; присутня можливість “спостерігати” за іншими користувачами; можливість надсилати прохання користувачам тощо. Існує можливість створення різних груп користувачів, з можливістю створення змісту з доступом для певної групи [8, 1].

Collabtive

Розробка проекту почалася в 2007 році. Основною метою створення цього Інтернет-застосування є надання користувачам безкоштовного програмного забезпечення, що могло б конкурувати з такими комерційними продуктами, як BaseCamp. Даний програмний продукт написаний мовою PHP5 з використанням JavaScript\AJAX, для роботи потребує систему керування базами даних MySQL вище версії 4.0 та Web-сервер з підтримкою РНР5.

Collabtive призначена для малих і середніх підприємств, а також фрілансерів. В якості платних доповнень існують додаткові модулі для розширення функціональності: шаблони проектів, інтерактивні діаграми Ганта та ін. Однією з важливих особливостей системи є можливість її встановлення як на окремому сервері, так і в хмарі. Підтримуються усі основні веб-браузери, такі, як Internet Explorer (7/8), Firefox, Opera, Safari, Chrome.

Із засобів планування проекті в системі реалізовано визначення підгруп завдань (Milestones), створення та керування списків завдань, а також перегляд завдань через календар. До даного програмного продукту включено механізми експорту даних (Zip, XML, RSS, iCal) та імпорту даних. Присутній також вбудований файлових менеджер [9, 1].

GitHub

GitHub – найбільший веб-сервіс для хостингу проектів та їх розробки. Оснований на системі контролю версій Get, розробка велася мовою Ruby та Erlang. Сервіс повністю безкоштовний, він пропонує усі можливості для розробки проектів з відкритим програмним кодом, для приватних проектів існують платні тарифні плани.

Розробники називають проект «соціальною мережею для розробників». Окрім основних функцій, таких як розміщення коду, коментування та ведення документації, учасники можуть спілкуватися між собою, об’єднувати репозиторії для спільної роботи. Для проектів існують приватні сторінки, інформація у вигляді Wiki, bugtracker. Сервіс дозволяє переглядати файли проектів з підсвіткою синтаксису для більшості мов. GitHub також дозволяє скопіювати файли проекту у вигляді архіву на локальний комп’ютер [10, 1].

Launchpad

Launchpad – це Web-застосування, розроблене компанією Canonical Ltd. В 2009 році його коди було оприлюднені за ліцензією GNU Affero GPL. Основною задачею продукту стала підтримка розробки ОС Ubuntu та інших програм з відкритим доступом. До складу Launchpad входять наступні компоненти:

· Answers – сайт для спілкування і підтримки бази знань про проекти у формі wiki

· Blueprints – система для керування новими можливостями і специфікаціями

· Bugs – потужний баг-трекер

· Code – система контролю версій і зберігання кодів програм на основі системи Bazaar

· Translations – сайт, що забезпечує зручний процес локалізації застосувань

Також існує можливість інтеграції такого потужного продукту як Trac [11, 1].

Redmine

Redmine є Web-застосуванням з відкритим кодом, що розповсюджується за ліцензією GNU GPL 2. Цей продукт написаний на платформі Ruby on Rails і є крос-платформеним. Крім того, існує підтримка різних СКБД, в т.ч. MySQL, PostgreSQL та SQLite. Архітектура Redmine зазнала суттєвого впливу з боку системи Trac і має багато схожих із нею рис. Redmine локалізовано багатьма мовами, зокрема українською.

Дана система підтримує багато проектів одразу, а розмежування доступу здійснюється на основі гнучкої системи ролей. Це дозволяє зручно формувати віртуальні команди розробників для вирішення конкретних задач за фіксований час. Важливою рисою продукту є підтримка одразу багатьох систем контролю версій – SVN, CVS, Git, Mercurial, Bazaar, Darcs. Для зберігання знань і обміну досвідом пропонується вбудована система Wiki із системою контролю версій документації і засобами її групової розробки, а також форуми для спілкування і обговорення поточних задач учасниками проектів.

Redmine також містить гнучку систему відстеження і розподілу задач із можливістю їх візуалізації в діаграмах Ганта та у вбудованому календарі. Важливою для багатьох компаній буде можливість аутентифікації та розподілу ролей на основі систем LDAP, які використовуються у внутрішніх мережах для обліку працівників[12, 1].

Для порівняння web-застосувань на предмет їх функціональності та придатності для роботи географічно-розподілених команд було ретельно розглянуто шість з них: BaseCamp, BugZilla, Collabtive, GitHub, Launchpad, Redmine. Вибір оснований на популярності серед відомих компаній-розробників, відгуках та поширеності цих програмних додатків у мережі Інтернет. Для вироблення чітких критеріїв порівняння ретельно досліджена та проаналізована кожна з програм. Під час аналізу зроблений поділ критеріїв на дві групи: загальні (ті, що притаманні будь-якому веб-базованому застосуванню) та спеціальні (ті, що властиві саме для систем керування географічно-розподіленими проектами. До перших належать: тип ліцензії, ціна продукту, специфічні вимоги до сервера (такі як тип СКБД, версія PHP та ін.). Важливим критерієм визначено останню дату оновлення продукту, адже цей показник вказує на стан актуальності програмного застосування, його перспективність та, у деякій мірі, рівень функціоналу. До спеціальних критеріїв належать такі, як механізми конфігурування проекту, наявність Bug Tracker, планувальників, календарів, додаткових засобів візуалізацій, таких як діаграми Ганта. Також важливими є засоби контролю версій, документування, можливість експорту та імпорту інформації в інші web-застосування, що призначені для керування проектами.

За результатами дослідження можна зробити висновок, що найбільший набір функцій, необхідних для керування розробкою проекту, має комерційна програма BaseCamp. Особливостями є реалізація широкого набору інструментів керування ресурсами, інтегровані засоби обміну миттєвими повідомленнями та ін. Однак, великим недоліком цієї програми є закритість коду та тип ліцензії, що унеможливлює власноручне модифікування та налаштування для власних потреб.

Безкоштовним аналогом BaseCamp можна вважати Collabtive. Власне, програма створювалася з метою забезпечити розробників широким функціоналом для керування процесом розробки проекту без необхідності матеріальних витрат на сам інструментарій. Додаток здатний задовольнити вимоги як малого, так і середнього бізнесу. Розробники також передбачили платні модулі для користувачів, яким не вистачає поточного функціоналу. До таких модулів належать шаблони проектів, інтерактивні діаграми Ганта, автоматичний тайм-трекер та ін.

Досить оригінальним є web-застосування GitHub, що є соціальною мережею для розробників, як стверджують самі автори проекту. Окрім розміщення коду, учасники проекту мають змогу спілкуватися, коментувати правки один одного, слідкувати за новинами друзів. У рамках проекту є можливість використання Bug-Tracker та власної Wiki-сторінки для опису та документування проекту. Але, незважаючи, на свою привабливість, цей проект є незручним для роботи географічно-розподіленої команди, він більше орієнтований на індивідуальних розробників та команди розробників, що співпрацюють в межах одного офісу. Відсутність інструментів для сегментування задач та їх розподілу серед виконавців тощо значно ускладнює процес розробки серед географічно-розподілених команд. Великої уваги серед розглянутих проектів заслуговує BugZilla, що по суті являє собою багтрекер з веб-інтерфейсом. З одного боку, BugZilla є досить простою, з іншої, вона містить все, що потрібно для моніторингу помилок типового проекту. Якщо ж говорити про цільову аудиторію, то цей додаток більш орієнтований на окремо взятого розробника, або групу розробників, що не є географічно-розподіленими.

Найбільш гнучким інструментом для керування проектами серед вищезазначених є Redmine. По-перше, незаперечною перевагою цього продукту є ліцензія GPL, що дозволяє вільне копіювання, розповсюдження та модифікацію. По-друге, за функціональними можливостями Redmine не поступається своїм комерційним аналогам, а у деяких випадках, навіть перевершує їх. Наприклад, інструменти керування портфелем проектів та інтерактивні діаграми Ганта присутні тільки в цьому продукті. По-третє, цей веб-додаток постійно оновлюється, про що свідчить дата випуску останньої версії: 20.04.2012. Велика кількість модулів та плагінів, що доступні для вільного завантаження на офіційному сайті, здатна перетворити базовий продукт на потужний інструмент, що задовольнить потреби як початківців, так і професіоналів IT-бізнесу. Результати порівняння відображені у Таблиці А1.

РОЗДІЛ 3. ДОСЛІДЖЕННЯ ПРОБЛЕМ ВПРОВАДЖЕННЯ МЕТОДОЛОГІЇ AGILE SCRUM ДЛЯ РОЗПОДІЛЕНИХ ПРОЕКТІВ

При порівнянні програмних застосувань, що використовуються для керування географічно-розподіленими проектами, з’ясувалося, що найбільш ефективними та зручними для розробки є саме ті, що характеризуються ітеративністю та інкрементальним підходом до роботи. Такий підхід прискорює швидкість процесу розробки за рахунок співпраці крос-функціональної команди спеціалістів, яка проходить крізь послідовні фази розробки як одне ціле. Водночас, він орієнтований на мінімізацію ризиків шляхом виконання серії коротких циклів. Основною метрикою даного підходу є робочий продукт. Завдяки засобам спілкування, що забезпечує система, спрощується процес написання документації, необхідної для розуміння окремо взятої частини коду, і основна увага зосереджується саме на розробці [13, 1].

Як стверджує Кен Швабер [14, 21], найбільшого успіху досягають ті компанії-розробники, що здатні пристосовуватися до внутрішніх та зовнішніх змін середовища, в якому вони працюють. Для існування в умовах, що динамічно змінюються, потрібен підхід, що надасть компанії стабільність та розвиток. Такий підхід має забезпечувати адаптацію команди до постійних змін та нечітких інструкцій, надавати максимальну гнучкість та адаптацію. Ленгтон стверджує, що рівень організованості команди за умов постійних змін є прямим відображенням професіоналізму, конкурентоспроможності та попиту на цю команду. Його робота стала основою фундаментальної теореми в теорії складності.

Найвагомішим фактором, що визначає ймовірність успіху проекту, є вибір методології. Традиційні методології, такі як водоспад та спіраль, зарекомендували себе позитивно в умовах, коли складність проекту невисока, а час, необхідний на розробку, можна чітко визначити ще до початку роботи. Коли ж команда розробників є географічно-розподіленою, а складність проекту висока, необхідний інший підхід, що забезпечить гнучкість роботи та адаптацію до змін без негативних наслідків [14, 20].

Якщо зобразити графік залежності між складністю проекту та ймовірністю його успіху, то стає зрозумілим, що гнучкий підхід до розробки є набагато ефективнішим, ніж його попередник водоспад (Рисунок 3.1).

Ймовырнысть успыху

Рисунок 3.1 - Графік залежності успіху проекту від його складності

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

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

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

Даний підхід є сімейством процесів розробки, а не єдиним методом в розробці програмного забезпечення, і визначається документом під назвою Agile Manifesto [15, 5]. Він не включає в себе практики, а визначає цінності і принципи, якими керується команда при розробці певного продукту. Основними ідеї, визначені в документі:

- взаємодія важливіша, ніж процеси та інструменти;

- співпраця з замовником важливіша, ніж контрактні забов’язання;

- реакція на зміни важливіша, ніж дотримання плану;

- програмне забезпечення важливіше, ніж його документація.

На основі цього концептуального каркасу виник ряд методологій, основною метою якого є підвищення якості продукту, що розробляється: Agile Data Method, Rapid Application Development, Extreme Programming, Agile Scrum та ін. Найбільшою популярністю серед методологій гнучкої розробки користується Scrum. Вона була формалізована в 1997 році Кеном Швабером та Джефом Сатерлендом і широко використовується як початківцями, так і професіоналами, серед яких Yahoo!, Microsoft, Google, Lockheed Martin, Motorola, SAP, Cisco та ін. Згідно з твердженнями зазначених компаній, завдяки Scrum вони досягли значних успіхів, у деяких випадках повністю трансформували процес розробки проектів, що позитивно вплинуло на результати.

3.1 Основи методології Agile Scrum

Scrum – це ітеративний підхід, основний на інкрементації результатів. Деякі дослідники називають його фреймворком. Scrum передбачає поділ проекту на цикли, що називаються спринти (sprints), - ітерації, які, як правило, тривають від одного до чотирьох тижнів і характеризуються своєю неперервністю. Кожен спринт має фіксований час на виконання – він не подовжується і закінчується у зазначений момент незалежно від того, встигла команда виконати роботу за відведений їй час чи ні. На початку спринту кожен крос-функціональний член команди вибирає зі списку завдання, що поділені за пріоритетом, які він має виконати. Під час спринту завдання не можна змінювати. Кожного дня команда збирається для звітування щодо виконаної роботи та заповнення графіку, що відображає стан виконання проекту. Після закінчення спринту команда обговорює отриманий продукт та демонструє його замовнику. Основна мета цього процесу – отримати рекомендації щодо проекту та визначити задачі, які будуть реалізовані під час наступного спринту. Важливим є моментом є той факт, що замовнику демонструється тільки «робоча» версія продукту, у випадку з програмним забезпеченням, це означає, що код програми скомпільований, і програма дійсно працює [16, 23].

Поділ користувачів у Scrum відбувається на три групи: замовник, розробники та ScrumMaster. Роль замовника полягає у співпраці з командою з метою отримання саме того продукту, на який він очікує. Як правило, вимоги, яким має відповідати фінальний продукт, формуються шляхом спілкування безпосередньо з командою, інвестором, кінцевими користувачами. У більшості випадків замовник і є користувачем, але трапляються ситуації, коли під останніми розуміється широке коло людей. Додатково, замовник бере на себе роль PR-менеджера, або будь-яку іншу, якщо це необхідно.

Розробники відповідають за створення того чи іншого продукту, який необхідний замовнику. Як правило, команда розробників крос-функціональна – включає в себе усі необхідні ролі, необхідні для отримання робочого продукту в кінці кожного спринту (кодер, дизайнер, тестувальник тощо) і автономна, з високим рівнем самозабезпечення та відповідальності. Саме команда вирішує, що робити на певному етапі і як досягти цього результату. Типова команда в Scrum містить від п’яти до десяти людей, хоча відомі успішні команди, що містять більше, ніш 15 розробників. Якщо завданням проекту є написання програмного забезпечення, то команда може включати аналітиків, розробників, дизайнерів, тестувальників і т.д. Окрім власне виконання проекту, команда також відповідальна за надання замовнику корисної інформації, пропозицій, що можуть покращити фінальний продукт. Для підвищення ефективності рекомендується повна зайнятість розробників в одному Scrum проекті одночасно. За результатами досліджень, ефективність робітників, що одночасно працюють в кількох Scrum проектах, або ж виконують будь-яку іншу роботу поза проектом, знижується. Проекти, що передбачають роботу більше, ніж 15 розробників разом, як правило розділяються на окремі Scrum, кожна з яких фокусується на окрему аспекті розробки продукту, з чіткою координацією всередині команди та між окремими командами [16, 15].

Роль ScrumMaster є вирішальною для успішного завершення будь-якого проекту. ScrumMaster не є менеджером команди, він відповідає за збереження принципів гнучкої розробки та взаємодію та координацію між учасниками. Основне його завдання – впевнитися, що кожен учасник команди (організація-розробник та замовник включно) розуміють і керуються принципами Scrum на кожному етапі роботи. Оскільки Scrum має також слабкі сторони, для ефективної роботи команди потрібен досвідчений та сильний керівник, що допоможе уникнути потенційних проблем та зможе вирішити існуючі. Як правило, роль ScrumMaster – це повна зайнятість, яку бере на себе людина, що вже була менеджером проектів, однак малі команди допускають суміщення обов’язків керівника з додатковими (з меншим навантаженням). Для успішного керування проектом ScrumMaster мусить мати знання та навички у таких сферах: менеджмент, розробка, дизайн, тестування та аналітика. Не допускається виконання обов’язків замовника та ScrumMaster однією людиною. Наприклад, в ситуації, коли замовник пропонує зміни в проекті до закінчення спринту, керівник не утримується таких змін і відповідає за збереження принципів методології. На відміну від менеджера проекту, ScrumMaster не вказує команді, що робити і не розподіляє завдання, які автономна команда здатна робити самостійно. Основний його обов’язок – запобігання утворення потенційних проблем, вирішення існуючих питань та контроль дотримання методології [17, 1].

На додаток до цих трьох ролей, існують інші, що роблять важливий внесок в успіх проекту. Можливо, найбільш важлива з них є роль менеджера. Менеджери критично необхідні для команди, вони допомагають усунути проблеми, виявлені розробниками, використовують досвід, отриманий командою для координації проекту. Ця робота включає в себе аналіз звітів, розподіл завдань, коучинг, моніторинг і т.п. Вона передбачає вироблення власного стилю управління. Прикладом гарного тону, наприклад, є пропозиція менеджера для команди знайти рішення проблеми самостійно замість того, щоб керуватися власними принципами.

Перший крок у розробці Scrum-проекту – це визначення задачі та вимог до очікуваного продукту. Вимоги формують список задач із зазначеною пріоритетністю кожного пункту для замовника. Найбільш пріоритетні задачі розташовуються на початку. Такий список називається Product Backlog. Він існує на протязі усього періоду розробки продукту. У будь-який момент часу Product Backlog – це єдиний список дефініцій «всього, що може бути зроблено командою в порядку черговості». Існує тільки одна версія такого списку. Це означає, що розробники та замовник відповідальні за своєчасне оновлення цього списку і контроль його вмісту [16,20].

Product Backlog

Рисунок 3.2 - Приклад списку вимог до проекту (Product Backlog)

Product Backlog містить велику кількість пунктів, що включають в себе елементи функціоналу («можливість додати книгу до кошика», вимоги («доопрацювати модуль трансакцій, щоб зробити його масштабованим»), дослідницькі завдання («знайти рішення для прискорення перевірки кредитної карти»), помилки («виправити помилку в обробці замовлення») і т.д.

Product Backlog постійно оновлюється замовником і розробниками для відображення змін у потребах, нових ідей, реакції конкурентів, технічних перешкод и т.п. Команда надає замовнику приблизну інформацію щодо технічних рішень того чи іншого завдання, часу його виконання з метою встановлення замовником пріоритетності їх виконання. Розміри задач у Product Backlog можуть значно варіюватися в розмірі, однак великі часто розбиваються на підзадачі під час наради з планування спринту, а малі – навпаки об’єднуються. Один з міфів про Scrum полягає в тому, що методологія зосереджується тільки на розробці і не надає можливості для написання детальної документації. Насправді усе залежить від власника продукту і команди: вони визначають, наскільки необхідно деталізувати опис задач. Загальна рекомендація з цього приводу: документувати таким чином, щоб опис був компактним, а інформація в цьому описі – детальна [18, 19].

Перед початком кожного спринту відбувається нарада з планування задач. У першій частині наради замовник і команда аналізують Product Backlog, обговорюючи цілі і контекст питань, зазначених у ньому. Друга частина зустрічі присвячується вибору завдань з Product Backlog, які мають бути виконані до кінця спринту. Зазвичай, завдання виконуються в порядку їх пріоритетності, починаючи з найвищого. Одна з ключових практик цього процесу полягає в тому, що саме команда, а не замовник, вирішує, який обсяг роботи буде виконаний. Такий крок обумовлений тим, що, як правило, команда розробників краще орієнтується в задачах, ніж замовник, а по-друге, підвищується рівень відповідальності кожного члена команди перед іншим. Замовник чітко не орієнтується в обсязі задач, які бере на себе команда під час спринту, але він знає степінь їх пріоритетності. Команда має можливість змінювати пріоритетність задач, якщо це має сенс (наприклад, посунувши в кінець списку елемент, що може бути швидко завершений в рамках іншого більш важливого завдання).

Нарада з планування спринту, як правило, триває кілька годин – команда робить забов’язання перед замовником вчасно завершити зазначений обсяг роботи, і це забов’язання вимагає ретельного обміркування. Наприкінці наради команда визначає, скільки часу потрібно кожному виконавцю для успішного завершення відведеної йому частини [17,10]. Цей час включає в себе планування, безпосередню роботу, перевірку пошти, звітування, обідні перерви. У більшості випадків необхідно 4-6 годин роботи в спринті на день для успішного його завершення (Таблиця 3.1).

Без имени-1

Таблиця 3.1 - Планування робочих годин під час спринту

Після завершення планування команда починає виконання першого пункту в Product Backlog – найбільш пріоритетного завдання, - розбиває його на індивідуальні завдання, які документуються у таблиці під назвою Sprint Backlog (Таблиця 3.2).

spring backlog

Таблиця 3.2 - Sprint Backlog

Після визначення задач група розподіляє їх між собою, враховуючи залежності та послідовності, що будуть виникати на шляху виконання [19, 10]. Основною складністю цього процесу є визначення правильної часової оцінки та рівномірний розподіл навантаження на кожного члена команди. Кожне з підзавдань обговорюється з замовниками з метою уточнення інформації, і, взагалі, для того, щоб переконатися, що команда розуміє поставлені задачі. Команда послідовно аналізує завдання, що знаходяться в Product Backlog, в порядку їх пріоритетності до того часу, коли закінчується час зібрання. Наприкінці зустрічі у команди є сформований список завдань, відповідальний за кожне з цих завдань і приблизна часова оцінка виконання (зазвичай, години або частини дня). Серед команд існує практика використання візуальних інструментів планування та відстеження ходу виконання завдань. Як правило, завдання записуються на дошці у вигляді нотаток з помітками «Не зроблено», «Працюю», «Тестування», «Виконано» та ін.

Особливістю роботи в Scrum є той факт, що будь-які зміни до проекту вносяться тільки після завершення спринту. Це означає, що в ситуації, коли замовник вирішить змінити завдання, він має дочекатися звітування ходу виконання задач, що були сформовані раніше. Інколи трапляються ситуації, коли під впливом зовнішніх факторів, спринт зупиняється, формується новий список задач, і робота починається знову. Проте, це є винятком з правил Scrum, що обумовлений серйозною зміною концепції продукту та іншими екстремальними факторами. Необхідно розуміти, що такі кардинальні зміни мають негативний вплив на продуктивність команди, тому їх краще запобігати [20, 1]. Коли кожен розробник переконаний, що його завдання не буде змінене в процесі його виконання, то він фокусується на результаті, покращуючи свою продуктивність. По-друге, це обмеження спонукає замовника ретельно обдумувати проект та підзадачі, які необхідно виконати під час спринту. У відповідь замовник залишається впевненим, що завдання будуть виконані вчасно, а також отримує робочий продукт наприкінці кожної ітерації. Водночас, замовник є зацікавленим у проекті, він працює в інтерактивному режимі з командою після завершення та на початку кожного спринту.

Після того, як розпочався спринт, команда приймає участь у короткій нараді ( не більше 15 хвилин), яка називається щоденний Scrum (Daily Scrum). Ця зустріч відбувається кожного дня в призначений час. На ній мають бути присутні усі члени команди. Вони звітують один за одним про стан виконання завдань, проблеми, що виникають на шляху та ін. [21, 5] Як правило, звіт складається з трьох частин:

1. що було зроблено за день;

2. що буде зроблено до наступної наради;

3. які перешкоди виникають на шляху.

Якщо необхідне обговорення якогось з проблемних питань, то воно відбувається після зустрічі за участю ScrumMaster. Під час щоденного Scrum дискусія не відбувається, кожен член команди звітує згідно з вищезазначеним планом, що складається з трьох пунктів. Замовник, менеджери та інші зацікавлені особи можуть відвідувати збори, проте вони утримуються від обговорення, тому що основною метою зустрічі є взаємодія членів команди один з одним, а не звітування перед замовником, менеджерами та ScrumMaster. У деяких випадках звітування перед замовником вважається хорошою практикою, однак воно відбувається за бажанням команди.

Після засідання команда оцінює час, який залишився на виконання завдань, записаних в Sprint Backlog. ScrumMaster в цей час оновлює інформацію на діаграмі, що вказує, який обсяг роботи залишається до завершення спринту (Рисунок 3.3). В ідеалі, це має бути низхідний графік, який виходить в нуль в останній день спринту, хоча інколи виникають ситуації, коли вчасно завершити роботу на вдається. Цей графік є важливим показником прогресу для команди, що допомагає оцінити продуктивність виконання завдань та скоригувати темп роботи за умов, якщо команда не вкладається в час [16, 25].

burndown

Рисунок 3.3 - стан виконання завдань під час спринту

Хоча цю схему можна було б розробити в Excel, більшість команд вважають більш ефективним малювати її на папері або на дошці і оновлювати вручну. Таке нетехнологічне рішення є швидким, простим і привертає більше уваги, ніж зображення на моніторі [16, 26].

Після закінчення спринту відбувається його огляд, де команда демонструє свої досягнення. Під час огляду присутні замовник, команда розробників, ScrumMaster, покупці, експерти та інші зацікавлені сторони. Огляд, як правило, триває не більше 30 хвилин і не приймає форму презентації. Під час цієї зустрічі розробники демонструють продукт, а присутні задають питання, пов’язані з ним.

Наступний етап розробки після огляду спринту – це ретроспектива, під час якої учасники мають змогу висловити свою думку щодо виконаних завдань, обговорити що працює добре в системі, а що підлягає доопрацюванню. Найпростіший спосіб провести ретроспективу – це створити дві колонки, одна з яких буде називатися «добре працює», а інша – «потребує доопрацювання». Потім, в порядку черги, розробники додають завдання зі Sprint Backlog до створеного списку. Ці задачі паралельно обговорюються з метою знаходження кращого їх рішення. На жаль, багато команд недооцінюють корисність цієї практики і умисно уникають її.

Наступним кроком в розробці є планування наступного спринту. Замовник аналізує усі дані, отримані під час огляду спринту та ретроспективи, приймає до уваги нові обставини та пріоритети та відображає їх у Product Backlog; додаються нові завдання, змінюються поточні та видаляються непотрібні. Як тільки список сформований, команда знову береться за роботу, починаючи з наради щодо планування спринту. Як правило, в той же день, або наступний розпочинається доопрацювання проекту в рамках нового спринту. Такий стійкий темп досягається завдяки помірному навантаженню та точній оцінці щодо складності завдання і часу його виконання [20, 1].

3.2 Принципи роботи географічно-розподілених команд

При розробці складних систем, робота над проектом може тривати до року і більше, а кількість розробників перевищує сотню. У цьому випадку неможливо швидко і без зайвих витрат знайти спеціалістів, які б задовольняли усім необхідним вимогам. Розподілений Scrum - прагматичний підхід, що забезпечує рішення проблеми та дозволяє балансувати між використанням існуючих спеціалістів і пошуком нових талантів.
Використання такого підходу відкриває для розробників нові можливості. Керуючи розподіленими ресурсами і гнучко комбінуючи їх для роботи в проектах, компанія може підвищити рівень складності виконуваних проектів. Значно зменшуються ризики, пов'язані з персоналом. При вмілому управлінні значно скорочується розмір витрат, а, значить, зростає прибуток компанії.

3.2.1 Керування процесом розробки проекту

Керування процесами під час розробки є важливою складовою успіху команди на фінальному етапі. Ця галузь є найбільш динамічною складовою управління проектами. Водночас, в ній зроблено небагато досліджень, що могли б допомогти у розвитку географічно-розподілених команд. Один зі способів розгляду процесу – через життєвий цикл розробки. Життєвий цикл проекту проходить через чотири основних етапи: постановка задачі; планування проекту; виконання, трекінг та контроль; закриття проекту. Під час керування вхідними \ вихідними даними, відбувається перевиконання кроків 1, 2 та 4 за рахунок кроку 3. Трекінг процесу забезпечує ефективне та дієве керування змінами. За винятком простих та повторюваних проектів, зміни, зазвичай, відбуваються у вхідних та вихідних даних, вимогах, використаній технології, та доступних ресурсах (напр. час, гроші та персонал). Без ретельного моніторингу цього процесу, поточний статус проекту може бути незрозумілим навіть керівникам проектів, не кажучи про розробників. Якщо статус виконання завдання невідомий, буде складно, або ж зовсім не можливо прорахувати ризики чи визначити альтернативні рішення для пом’якшення цих ризиків ефективним чином. Процеси проектів можуть бути вкрай різними за своєю природною динамікою і тому можуть значно відрізнятись від плану проекту та очікуваних результатів під час виконання проекту. Тривалість процесу часто призводить до змін у вхідних та вихідних даних, відтак, спричиняючи подальші зміни у самому проекті [22, 80].

Недостатнє розуміння поточного стану виконання проекту має за результат бачення процесу як «чорної скриньки», що спричиняє появу численних проблем: поява помилок, позапланові зусилля, недостатній контроль. З іншого боку, належний трекінг забезпечує прозорість процесів проекту, таким чином збільшуючи ймовірність визначення ризиків на ранніх стадіях. Засоби колаборативного розподіленого керування проектами дозволяють учасникам проекту переглядати роботу інших учасників та вивчати заходи, до яких вдавались інші учасники (зокрема ресурси витрачені на виконання певного завдання). Такий механізм трекінгу допомагає учасникам проекту супроводжувати керування процесами в більш ефективний і дієвий спосіб. Якщо завдання виконане, виконавець може про це повідомити всім іншим. Якщо завдання стає доступним до встановленої дати, учасники, що чекають виконання завдання можуть бути повідомлені і почати наступну задачу раніше, ніж очікувалося, таким чином вносячи незначні зміни в розкладі. Якщо наявні вихідні дані для конкретного проекту, його учасники можуть порівняти поточний стан з вихідними даними, і таким чином прогнозувати успішність їхнього процесу. Загальна мета керування процесами - це утримання проекту під контролем та в напрямку до поставленої цілі.

3.2.2 Керування знаннями в географічно-розподіленій команді

Існує декілька суттєвих відмінностей між керуванням знаннями та керуванням проектами. По-перше, керування проектами є скінченним процесом, в той час як керування знаннями мусить тривати постійно. По-друге, керування проектами є орієнтованим на досягнення певної мети і виникає, незважаючи на відмінності в культурі на рівні виконавців проекту чи організацій [23, 11].

Попри ці відмінності, ми можемо знайти зв’язки між цими двома концептами. Знання використовуються для досягнення мети проекту, а проекти генерують знання для виконавців. Виконавці щодня продукують та поширюють значну кількість інформації та знань. Згідно теорії Ґранта [24, 11], створення знань відбувається на індивідуальному рівні, і головна роль виконавців проекту у цьому процесі – це збирання, поєднання та використання інформації в оптимальній формі. Однак, для успішної генерації нових знань потрібно використовувати попередній досвід, навички і нові джерела інформації. Таким чином, керування проектами та керування знаннями є значною мірою взаємозалежними дисциплінами.

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

Одна з таких моделей запропонована в праці [23, 8]. В цілому керування знаннями в ній зводиться о трьох дій: накопичення, здатність до передачі та надання змісту. Технічна частина цієї моделі включає в себе: механізми відбору знань, інструменти для координації, фільтрації та категоризації, сховища.

Знання, зазвичай, містяться в умах працівників у формі навичок, крім того вони часто виражені в неявній формі. Для поширення цих знань у колективі, вони мусять бути виражені в явному (експліцитному) форматі. Зазвичай такими знаннями працівники обмінюються під час неформального спілкування, а не за наказом керівництва, тому варто надавати достатньої уваги зустрічам команди, що відбувається поза робочим часом. Засоби збору інформації таким чином стають суттєвою відправною точкою у цьому процесі. Вони повинні бути простими для використання, інакше співробітники будуть неохоче ними користуватись, та гнучкими, тобто враховувати схильності різних учасників проекту вносити дані у зручному для них форматі.

Інформація, отримана від учасників команди, повинна бути відфільтрована за релевантністю та категоризована для полегшення доступу до неї та ефективного і дієвого використання. Відомі підходи до категоризації включають сортування чи організацію знань за темою, походженням чи датою. Механізми ранжування забезпечують користувачам пошук документів за релевантністю, на зразок того, як це реалізовано в пошукових системах. Розглянемо наступний приклад: згідно з дослідженням, що проводилося компанією Gartner Group кількість даних, що накопичується організацією, подвоюється щороку. Працівники, що відповідальні за роботу з інформацією, аналізують лише 5% усіх даних. Ці ж працівники проводять 60% їхнього часу, аналізуючи дані для знаходження важливих залежностей, 20% – на аналіз виявлених залежностей, і тільки 10% часу витрачається на впровадження результатів аналізу, наприклад на прийняття рішень, впровадження стратегій та планів. Більш того, Gartner Group стверджує що інформаційна переповненість зменшує здатність до прийняття рішень на 50%. Інформаційна переповненість може бути охарактеризована як основна причина того, що занадто великі масиви кодифікованих знань залишаються ніколи не використаними [23, 13].

Існує два способи подолати проблему переповненості. По-перше, фільтрацію слід проводити на двох рівнях: глобальному та локальному. Глобальні фільтри являють собою перегляд інформації членами організації, що займається розробкою програмних продуктів. Ці інструменти повинні вводитись в дію у визначені відрізки часу і не можуть бути змінені окремими членами команди в індивідуальному порядку. Однак, кожен учасник команди розробників повинен мати змогу опрацьовувати документи згідно з визначеною фільтраційною схемою. Іншим важливим аспектом, є те, що, при визначенні категорій знань, потрібно бути обережним при розгляді контексту. Контекст може бути визначений як взаємопов’язані умови, в яких щось існує чи відбувається. Контекст також може розглядатись як з локального, так і з глобального рівня. Знання одного проекту можуть бути накопичені разом зі знаннями подібних проектів у високорівневу структуровану глобальну одиницю, однак організація знань проектах сильно залежить від локалізованого контексту проекту і, таким чином, кожен проект може мати внутрішню схему представлення знань.

Під поняттям координації мається на увазі сумісна участь учасників команди в певній діяльності включаючи обмін інформацією, визначення спільних цілей, та спільне прийняття рішень. В роботі [25, 81] вказується, що найбільшою перешкодою у використанні знань є блокування каналу між джерелом знань і тими, кому ці знання потрібні. Блокування, зазвичай, зумовлене такими факторами, як непостійність зберігання знань та відсутність стимулів для обміну ними. У вищезгаданій праці також наведено результати досліджень, проведених в європейських та американських компаніях, згідно з якими «створення мереж працівників, для роботи зі знаннями» та «планування внутрішніх знань» є двома головними задачами в керуванні знаннями. Знання, згенеровані в проектах, зазвичай, потрібні для координації діяльності учасників команди. Зокрема, такі знання включають в себе обговорення перед складанням плану проекту, розкладів, доповіді щодо стану виконання кожного завдання чи роботи учасника тощо. Таким чином, вони мають бути доступні для передачі та використання всім учасникам проекту. Більше того, вони мають відображати поточний стан проекту. Обмін явними знаннями можливий через системи обміну документами, систему обміну миттєвими повідомленнями, відеозв’язок чи звичайну електронну пошту. Однак обмін неявними знаннями значно спрощується, коли існує спільний контекст або спільна мова (словесні чи не словесні символи), оскільки це значно підвищує рівень взаєморозуміння між членами команди.

Соціалізація зберігає знання неявними під час передачі, в той час як екстерналізація робить неявні знання явними. Прикладами соціалізації можуть бути робочі тренування чи навчання. Екстерналізація включає використання метафор та аналогій для спонукання людей до діалогу, забезпечуючи при цьому засіб для фільтрування корисних знань. Частина інформації при цьому втрачається.

Покращення координації потребує чіткого визначення джерел знань «про проекти» та знань «в проектах». З цього виникає потреба в ефективних та дієвих механізмах для зменшення часу доступу до джерел знань. Належні механізми координації мусять забезпечувати доступ до сховищ знань. В Web-базованих системах це питання вирішується найкраще завдяки інтегрованим модулям збереження та категоризації інформації.

При розгляді сховищ знань виникають кілька важливих проблем. По-перше, питання скільки і які знання зберігаються в базі знань, є важлива задачею в розробці будь-якої бази знань. З іншого боку, перенаповнення баз знань - поширена помилка в багатьох організаціях. Воно призводить до збільшення часу для пошуку, а також часу на виправлення застарілої та недоречної інформації. З іншого боку, малий об’єм даних не задовольняє потребам розробників [26, 3]. Таким чином, доводиться балансувати між переповненням бази та недостатнім обсягом інформації. Іншим предметом зацікавлення є місцезнаходження бази: централізоване сховище або розподілена система.

3.3 Аналіз проблем методології Agile Scrum у географічно-розподіленому середовищі

Повністю розподілені команди Scrum зазвичай складаються з крос-функціональних розробників, які працюють в різних регіонах, в результаті чого вона містить представників різних культур. Наприклад, команда може включати чотирьох розробників зі Сполучених Штатів в той час, як ще чотири офшорні працівники знаходяться в Шрі-Ланці. У такому випадку кожен член команди бере на себе відповідальність за вчасне завершення виконання завдань під час спринту [27, 21].

За вищезазначених умов виникло кілька моделей розподілених команд Scrum [28, 88]:

- Розподілені команди зі збігом робочих годин;

- Розподілені команди без збігу робочих годин.

Ефективні розподілені команди використовують спільні робочі години для тісного спілкування з колегами. Збіг робочих годин допомагає у створенні відчуття єдиної команди, а також полегшує співпрацю. Тим не менш, велика частина розробників не мають перекриття робочих годин, тому для їх роботи необхідні зустрічі, що відбуваються поза робочим часом (наприклад, Індія і США). Користуються, зазвичай, відеоконференціями, сервісами миттєвих повідомлень та аудіо зв’язком. Найбільшим попитом користуються відеоконференції. Зустрічі віч-на-віч, як правило, обмежені, це обумовлено високою їх ціною (фінансові фактори, час).

Географічно-розподілені проекти є значно складнішими, ніж ті, що розроблюються у межах одного офісу. Така складність обумовлюється, перш за все, культурними відмінностями учасників проекту. Географічна розподіленість є причиною складності доступу до інформації, що необхідна для аналізу роботи крос-культурних команд. За таких умов існує певна обмеженість та неточність при перевірці гіпотез, що стосуються проблем розподіленої розробки. У зв’язку з цим, виникає потреба детального дослідження проблем, що виникають при розробці проектів у географічно-розподіленому середовищі з метою вдосконалення існуючої методології гнучкої розробки та покращення програмних засобів, що використовуються в даній сфері. Це дослідження буде мати пошукову форму, тобто ідентифікуватиме культурні проблеми за допомогою критичного аналізу інформації, отриманої з вторинних ресурсів. Також це дослідження можна розглядати як вторинне, що залежить від результатів відповідних первинних досліджень, проведених по всьому світу. Результатами ж будуть узагальнення, що самі по собі можуть бути визначені як гіпотези.

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

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

Методологія Scrum передбачає обмежений час на виконання кожного етапу проекту. Це дозволяє членам команди отримати оцінку своєї діяльності та скоригувати свої дії відповідним чином. Навіть для окремого завдання така оцінка є важливою, тому що вона спонукає розробника розуміти пріоритети роботи та концентруватися на кінцевому результаті [29, 1]. Наприклад, рекомендації, визначені методологією щодо часу виконання завдань: спринт (2-4 тижні), щоденний Scrum (15 хвилин), планування (4-8 годин), ретроспектива (2-3 години) [30, 12].

Час і пунктуальність оцінюються по-різному представниками різних країн. Представники Заходу схильні до планування, створення графіків і слідкування за діяльністю та часом. На відміну від них, мешканці Сходу (окрім Китаю, Японії) сприймають час, як гнучкий та регульований інструмент. В науковій літературі в контексті сприйняття часу Західна культура отримала назву монохронічна, а Східна – поліхронічна [31, 13].

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

Практика Scrum передбачає взаємодію багатофункціональних кваліфікованих розробників. Члени команди не повинні обмежувати свою роботу визначенням їх основної діяльності, такої як дизайнер чи тестувальник. Вони мають бути задіяні в будь-якому завданні, де можна використати їх знання, з метою досягнення цілей спринту. Наприклад, якщо проект вимагає тестування, будь-який член команди може виконати його роль. Для досягнення цієї мети, кожен розробник має бути кваліфікований у декількох сферах (проектування, розробка, документування, тестування, відлагодження тощо), а мати знання різних рівнів (інтерфейс, бізнес-рівень, база даних і т.д.). Для заощадження часу та балансування навантаження на кожного учасника, не рекомендується вибір завдань, оснований на професійній орієнтації. Кращим рішенням буде вибір завдань, що передбачає здобуття нових навиків. Це дозволить поширити сукупний об’єм інформації в робочому середовищі та підвищити крос-функціональні здібності команди [32, 4].

Як зазначалося вище, для підвищення продуктивності кожен член команди має виконувати й орієнтуватися в різних типах завдань. Така крос-функціональність забезпечує безперервну роботу навіть в ситуації, коли один з розробників відсутній під час спринту.

Представники поліхронізму, згідно з дослідженнями [31, 13], будуть схильні до вибору задач з певними елементами невизначеності та творчості. Такі люди легко пристосовуються до нових робочих місць та обов’язків, одночасно поєднуючи основні завдання з другорядними. Одночасно з цим, не очікується складностей зі змінами ролей (розробник, тестувальник) під час спринту. Крім того, вони більш зацікавлені в розробці різних модулів проекту одночасно.

Для підвищення продуктивності при роботі в Scrum рекомендується забезпечити максимальну відкритість діяльності для досягнення прозорості процесу. Кожен член команди повинен володіти необхідними і достатніми знаннями для роботи в спринті [33, 5]. Відкритість допомагає отримати об’єктивну оцінку задач під час ретроспектив, а також знижує комунікаційні бар’єри всередині команди. Крім того відкритість дозволяє членам команди зрозуміти один одного, підвищуючи ефективність групи в цілому [27, 28].

Міжкультурна взаємодія значним чином впливає на відкритість. Мешканці Сходу є більш стриманими у спілкуванні та в першу чергу використовують непрямі стилі спілкування для вирішення конфліктів. Проте європейці та американці поводять себе більш відкрито.

Крім того, східна тенденція поводитися сором’язливо може ускладнити роботу в команді, в той час як їх західні колеги більш активно обговорюють проблеми, що виникають під час роботи. Дослідницька робота Sutherland [27, 11] вказує на те, що голландські та індійські розробники використовують різні підходи в спілкуванні. Голландці виражають свої думки прямо, в той час, як їх індійські колеги більш обережні та уважні у своїх висловлюваннях [27, 28].

У зв’язку з культурними відмінностями, при спільній роботі у Scrum, між членами команди виникає непорозуміння: одні вважають своїх колег менш зацікавленими у роботі, тому до них знижується степінь довіри, в той час як інші звинувачують своїх опонентів у грубості, неповазі та знищенні командного духу. Якщо проблему не урегулювати на етапі її виникнення, то вона може призвести до розколу команди.

Як вже зазначалося раніше, відкритий стиль спілкування та співпраця є одними з головних критеріїв успіху команди Scrum. Як стверджують дослідники, неформальне спілкування має значно кращий вплив, ніж листування чи використання технічних засобів, таких, як комп’ютери та телефони [34, 5].

Формальні зустрічі, наприклад, під час щоденного Scrum, забезпечують багате невербальне спілкування всередині команди. Однак у випадку географічно-розподіленої розробки, важливу роль у співпраці відіграє вербальна комунікація. Інші засоби спілкування, такі як мова тіла, не завжди є загальнодоступними, тому вербальні сигнали, такі як паузи, отримують більшого значення під час комунікації.

Одна з причин виникнення непорозумінь всередині географічно-розподіленої команди – це різний обсяг вербальної інформації, необхідної для розуміння повідомлення представниками Заходу та Сходу. Наприклад, американці схильні до детального, чіткого та завершеного спілкування, в той час, як японські розробники звикли до лаконічності та мінімального використання вербальних засобів спілкування; вони більш залежні від контексту передачі повідомлень. Ці фактори можуть спричинити непорозуміння під час зустрічей команди: наприклад, представники Заходу схильні задавати надлишкові питання, якщо виникає неясність і двозначність, пов’язана з недостатньою поінформованістю. Крім того, Західна культура відрізняється зниженим рівнем толерантності в умовах щоденної командної роботи. Наприклад, нетипова поведінка співробітників під час щоденних зборів, може викликати обурення та дратування окремих членів команди.

Відповідальність у команді – це ключ до самоорганізації та досягнення успіху. Практики Scrum стверджують, що зменшення явних механізмів контролю підвищує продуктивність команди. Наприклад, вони пропонують використовувати непрямі методи взаємодії, такі як рекомендації колег в керівництві та мотивації членів команди. Подальше управління необхідно розглядати з особливою обережністю, щоб не обмежувати дії розробників. Надмірний контроль над командою в процесі вирішення задач перетворить її в засіб виконання наказів, а не в ініціативну групу людей, що вирішують проблеми самостійно. За таких умов є мала ймовірність виникнення самоорганізації, а подальші дії команди будуть залежати від вказівок лідера команди, замовника чи ScrumMaster [36, 8].

Дослідження географічно-розподілених команд розробників з Нової Зеландії та Індії виявили той факт, що, незважаючи на індивідуалізм новозеландців, самоорганізація команди залишалася на високому рівні. З іншого боку, індійська культура виявилася ієрархічною з низьким рівнем індивідуалізму, тому більшість командних рішень було прийнято за ініціативи розробників з Нової Зеландії [19, 10]. Представники ієрархічних культур, такі як азіати, мають кращі показники в роботі за умов підпорядкування. На відміну від них, представники індивідуалістичних культур негативно сприймають пропозиції приєднатися до ієрархії, запропонованої колегами. Утворення таких структур призводить до небажання співпрацювати. Водночас, такі дії можуть сприйматися, як порушення дисципліни представниками східних культур.

Інший аспект роботи розподілених команд, що може викликати труднощі у взаємодії, це зміна підходу до розробки – типове явище в методології Scrum. Хоча, як правило, у межах окремого спринту змін не відбувається, вони можливі за певних обставин. Гнучкі методи розробки приділяють велику увагу цьому процесу, тому він детально описаний в Маніфесті [15, 3].

Scrum передбачає зміну вимог до проекту навіть на завершальних стадіях розробки шляхом зміни пріоритетності виконання завдань та модифікації Product Backlog. Ця практика дозволяє реагувати на потреби ринку, збільшувати конкурентоспроможність замовника. Кодекс етики розробника Scrum стверджує: «ми визнаємо, що зміни неминучі, що зміни призводять до росту, а зростання – до покращення» [37, 1 ].

Глобальні зміни можуть призвести до значних проблем всередині команди. Ці зміни передбачають як реорганізацію роботи, так і модифікацію окремих частин коду (у випадку розробки програмного забезпечення). Ці обставини деколи викликають дисбаланс у роботі. Наприклад, результати, що були виконані в окремому спринті, втрачають свою актуальність у зв’язку зі зміною вимог до проекту. Інший приклад: команда вирішила змінити дизайн проекту з метою підвищення його зручності для користувачів. Такі зміни можуть сприйматися неоднозначно окремими членами команди.

Використання методології Agile Scrum є комплексним підходом для вирішення питання географічно-розподіленої розробки. Цей підхід потребує ґрунтовних знань, насамперед, самої методології, процесу керування та взаємодії команди. З одного боку, ця методологія є однією з найбільш складних для розуміння і парадоксальних процесів керування проектами. З іншої, Scrum дуже простий. Сам процес, його практики, артефакти і правила: їх мало і вони легкі для розуміння і застосування.

Основною метою цього дослідження було встановлення впливу індивідуальних якостей окремого члена команди на процес розробки проекту у географічно-розподіленому середовищі. В якості прикладів розглядалися команди зі Сполучених Штатів, Індії, Японії, Китаю та Нової Зеландії. Особлива увага приділялася обставинам, за яких виникають конфліктні ситуації. Як уже зазначалося, процес розробки в географічно-розподіленому середовищі залежить від взаєморозуміння команди та пристосованості до різких змін до умов розробки. У цьому процесі важливе значення має надаватися тісній співпраці, глибокому розумінню принципів гнучкої розробки. Окрема увага має приділятися вивченню міжкультурних відмінностей окремих членів команди.

У ході проведення цього дослідження виявлений тісний взаємозв’язок між культурними відмінностями розробників та процесом розробки проектів (Таблиця 3.3). Отримана інформація базується на аналізі літературних джерел та власному досвіді команд-розробників, що працюють в географічно-розподіленому середовищі. Результати цього дослідження вказують на необхідність внесення коректив як технічного, так і нетехнічного характеру до існуючої методології з метою усунення проблем, що виникають на шляху географічно-розподіленої розробки.

		Рекомендації до розробки в середовищі Scrum
		Фіксований час виконання завдань	Крос-функціональність		Прозорість	Забов’язання	Комунікація	Самоорганізація	Згуртованість	Ведення документації	Схильність до змін
Комунікативні особливості	Відкритість			a			a
	Стриманість			a			a
	Акцент на гармонії групи			a
	Паузи в мові						a
Робота в команді	Впевненість							a			a
	Схильність до колективної роботи								a	a
	Акцент на результаті роботи					a
	Пристосованість до командної роботи								a
	Акцент на власних інтересах					a
	Конкурентоспроможність								a
Використання часу	Планування часу	a
	Мультизадачність					a					a
	Пристосованість до змін у проекті	a	a				a				a
	Пунктуальність	a

Таблиця 3.3 - вплив індивідуальних якостей членів команди на процес розробки проектів у географічно-розподіленому середовищі.

Одна з поширених помилок серед команд-початківців – це небажання змінити стиль роботи та пристосуватися до нових умов. Наприклад, учасники, що не встигають вчасно завершити свої завдання під час спринту, вирішують збільшити час самого спринту, замість того, щоб знайти причини своїх невдач та усунути їх. Таким чином, без зміни методики, консультування з досвідченими спеціалістами та практики, така команда перетворюється на неефективний інструмент, що буде заважати як компанії-розробнику, так і замовнику.

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

Важлива річ, яку необхідно враховувати менеджерам при переході на Scrum, це час адаптації команди до технічних засобів реалізації проекту та самої методології. Scrum надає розробникам простір у діях та інструменти для самоорганізації, проте ці фактори не є запорукою успіху для початківців. Більш ефективним є поступове введення в методологію та навчання у професіоналів-практиків, менеджерів тощо.

У ході проведення дослідження виявлені 2 категорії проблем, що виникають за умов співпраці географічно-розподілених команд: ті, що пов’язані з використанням технічних засобів, та ті, що обумовлюються людським фактором. До другої категорії належать:

· Стратегічні – проблеми ефективного використання уже наявних ресурсів, рекомендовані в галузі підходи часто забирають багато часу на впровадження і підтримку;

· Керування проектами і процесами – складність синхронізації робіт між географічно розподіленими областями;

· Комунікаційні – відсутність ефективних механізмів спілкування;

· Культурні – конфліктуючі поведінка, процеси і технології.

Перша категорія містить такі проблеми, як:

· Технічні – несумісні формати даних, схеми, стандарти;

· Безпека – необхідність забезпечення конфіденційності електронних трансакцій.

Результати цього дослідження вказують на необхідність внесення коректив як технічного, так і нетехнічного характеру до існуючої методології з метою усунення проблем, що виникають на шляху географічно-розподіленої розробки.

РОЗДІЛ 4. ПРАКТИЧНА ЧАСТИНА

4.1 Підхід до вирішення проблем координації розподілених команд

Станом на 2012 рік існує не так багато теоретично-обґрунтованих методів для роботи в географічно-розподіленому середовищі, а ті, що створені, забезпечують лише часткову її підтримку. Кілька існуючих досліджень [38, 1] вказують на численні проблеми в розподілених проектах. Основні з проблем, такі як час, управління, інфраструктура і культурні відмінності, ускладнюють керування залежностями, управління і контроль над роботою. Традиційні механізми координації і контролю лише частково пристосовані до географічно-розподіленої роботи. Кармель та Ван Фенема стверджують, що ці механізми будуть ефективними для розподілених проектів тільки за умов їх вдосконалення та створення відповідних технічних інструментів.

Основною метою цієї роботи є вирішення існуючих проблем шляхом вдосконалення наявних методів розробки. Таке рішення має складатися з двох частин, перша з яких буде адаптацією існуючої методології Scrum до умов географічно-розподіленої розробки, а друга - реалізацією технічних засобів, необхідних для роботи в таких умовах. Що стосується першої частини, то рекомендації, в першу чергу будуть впливати на роботу ScrumMaster і менеджерів проекту, а потім уже безпосередньо на розробників і замовника продукту.

Керівник команди відіграє дуже важливу роль у роботі команди: по-перше, він є гарантом дотримання методології, по-друге, він відповідальний за взаємодію з кожним членом команди з метою уникнення непорозумінь і конфліктних ситуацій, і, по-третє, саме він контролює процес і якість розробки. В умовах географічної розподіленості в практиці Scrum автоматично виникають проблеми, які не є типовими для централізованої розробки. До них належать: стратегічні – неефективне використання наявних ресурсів або нестача ресурсів, складність синхронізації робіт, культурні та комунікаційні відмінності. Завдання ScrumMaster у цій ситуації полягає в структуризації процесу розробки таким чином, щоб уникати вищезазначених проблем.

За результатами дослідження попереднього розділу, запропоновані основні зміни в методології Scrum, що забезпечать підвищення якості виконання проектів в умовах географічно-розподіленої розробки:

- формування чітких та вичерпних вимог до продукту з боку замовника;

- забезпечення живого спілкування в умовах географічної розподіленості;

- створення якісного інформаційного каналу для кожного з розробників;

- виконання обов’язків та дотримання пріоритетів.

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

Наступна зміна, що підвищить продуктивність розробників, це налагодження комунікації один з одним. Географічно-розподілена розробка спричинила появу нових складнощів у процесі керування проектами. По-перше, відсутність зустрічей «віч-на-віч» знижує «прозорість» процесу розробки, тим самим спричиняючи проблеми «візуалізації», визначені Бруксом. Крім того, відстань призводить до втрати відчуття командного духу і викликає додаткові проблеми в області спілкування. З точки зору керування, ослаблення контролю призводить до труднощів, пов’язаних з інтеграцією організаційних структур, керуванням і налаштуванням систем керування [39,6]. Команда повинна розуміти, що не всі проблеми і питання можна вирішити за допомогою електронної пошти чи телефону. Для ефективної роботи потрібне живе спілкування, а коли це не є можливим, відео конференції, де мають бути присутні усі члени команди. Досвідчені менеджери радять організовувати такі зустрічі якнайчастіше: мінімум два рази на місяць. Під час щоденного Scrum, рекомендується використання відео’звязку.

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

Як уже було зазначено у теоретичній частині роботи, виконання своїх обов’язків та дотримання пріоритетів є ключовим фактором успішного завершення проекту. Найважливішу частину обов’язків бере на себе ScrumMaster. Він відповідає за дотримання принципів методології та усунення проблем, що виникають у ході розробки. З вище написаного випливає, що керівник повинен мати глибоку теоретичну базу, та мати практичні навички роботи. Під теоретичною базою мається на увазі володіння інформацією у сфері керування проектами, знання методології, адаптованої до географічно-розподіленої розробки.

Що стосується технічної сторони питання, то друга частина рішення проблеми передбачає виявлення та опис методів, що забезпечать стабільну роботу географічно-розподілених проектів. Під час аналізу проблем, з якими стикаються розробники у географічно-розподіленому середовищі, були з’ясовані критерії, яким мають відповідати інформаційно-технічні засоби, для забезпечення ефективної розробки. Ці критерії стали основою для розробки моделі середовища для розробки географічно-розподілених проектів.

Інформаційно-технічні засоби для керування географічно-розподіленими проектами можна розділити на чотири функціональні групи: інструменти для керування проектом, для розробки проекту, для керування процесами та інструменти, що забезпечують можливість групової розробки (Рисунок 4.1):

4 instruments

Рисунок 4.1 – Інформаційно-технічні засоби для керування географічно-розподіленими проектами

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

Дослідження у сфері розвитку програмного забезпечення свідчать про тенденцію інтеграції інструментів (систем) різної функціональності (як правило, кращих у своїй сфері), а не розробку єдиної системи, що «вміє все». Відповідно, у межах цієї роботи пропонується інтегрована архітектура для цих інструментів. Враховуючи вимогу функціонування цих інструментів у географічно-розподіленому середовищі, вони мають працювати на глобально-розподілених і глобально-доступних Інтернет платформах. Таким чином, інтегрована архітектура буде побудована з використанням компонентно-орієнтованих методів моделювання.

За результатами дослідження методології Scrum, встановлено п’ять відцентрових сил, що негативно впливають на розподілені команди розробників, і шість доцентрових сил, що сприяють успішному виконанню географічно-розподіленого проекту.

5 6

Рисунок 4.2 – Відцентрові сили, Рис 4.3 – Доцентрові сили, що мають

що мають негативний вплив позитивний вплив на проект

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

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

control ()

Рисунок 4.4 Модель середовища для географічно-розподіленої розробки

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

На другому рівні моделі, що має назву «координація та контроль» відбуваються основна активність під час розробки: здійснюється планування розробки, розподіл ролей, моніторинг процесів, керування ризиком та ін.

Третє коло, що є адаптованою методологією Scrum, відображає загальні вимоги до розробки, координації та контролю проекту.

4.2 Вдосконалення існуючої web-базованої системи керування проектами Redmine. Орієнтація на географічно-розподілену розробку

Як було зазначено у другому розділі роботи, найбільш функціональним Web-базованим застосуванням для роботи розподілених команд є Redmine. Однак, цей засіб керування проектами містить вагомий недолік: відсутність можливості «живого» спілкування між розробниками. В якості інструментів, що виконують комунікативні функції, присутні електронне листування та технологія RSS. Проте, цих засобів недостатньо для задоволення потреб географічно-розподіленої команди.

Ефективним рішенням, що усуває існуючу проблему, є розробка модуля для існуючої системи, основним завданням якого є забезпечення відеозв’язку між розробниками в реальному часі. Функціонал має передбачати можливість конференції з усіма учасниками проекту одночасно, а також планування зустрічей. Окрім цього, варто передбачити можливість надсилати запрошення до конференції тим учасникам проекту, хто не зареєстрований у системі Redmine, наприклад, менеджерам, які не приймають безпосередньої участі у розробці.

Першим кроком для виконання завдання є вибір серверної частини, що забезпечить необхідний функціонал для команди. Проаналізувавши існуючі сервіси відеозв’язку, вибір зупинився на BigBlueButton, що є програмним рішенням з відкритим кодом та ліцензією GPL. BigBlueButton підтримує аудіо- та відеозв’зок, проведення презентацій, обмін графічною інформацією в інтерактивному режимі. Передбачена модерація, що дозволяє керувати учасниками та їх діяльністю під час проведення зустрічі. Сервіс має досить функціональний API для розробки власних додатків.

Наступний крок – це визначення функціоналу, необхідного для повноцінної роботи команди. Модуль має забезпечувати:

- обмін аудіо- та відео повідомленнями між окремими учасниками;

- проведення конференції між усіма членами команди;

- обмін миттєвими текстовими повідомленнями;

- модерацію конференцій.

Реалізація функціоналу відбувалася шляхом використання API серверної частини та програмування мовою Ruby. У результаті написання коду отримано модуль наступної структури:

application – реалізація функцій аудіо- та відеозв’язку, обміну текстовими повідомленнями;

assets – каскадні таблиці стилів та javascript, необхідний для роботи;

config – мовна конфігурація;

db – зміна структури бази даних Redmine з метою збереження інформації про заплановані зустрічі;

lib – реалізація планувальника зустрічей;

init.rb – файл ініціалізації модулю.

Останнім кроком у розробці є інсталювання в систему керування проектами Redmine.

Робота модуля тестувался на операційній системі FreeBSD 8.2 з інстальованими Redmine v. 1.4 та останньою версією BigBlueButton (0.8). Для повноцінної роботи модуля необхідна бібліотека ri_cal, яка містить дані для роботи електронного планувальника: створення календарів, конвертування часу в різних часових зонах. Інсталюємо бібліотеку:

gem install ri_cal

Копіюємо файли створеного модуля у директорію vendor системи Redmine. Далі оновлюємо базу даних для збереження інформації про заплановані зустрічі:

rake db:migrate_plugins RAILS_ENV=production

Перезавантажуємо сервер, за допомогою якого працює Redmine та розпочинаємо його роботу з директорії, в якій інстальований Redmine:

ruby script/server webrick -e production

Тепер в панелі адміністратора в розділі Plugins можна побачити щойно інстальований модуль. Для його активування необхідно внести інформацію про сервер, який буде використовуватися в процесі роботи ( у нашому випадкуhttp://localhost) .Якщо планується використання API, заповнюємо поле Хешування (Salt). Вказуємо те значення, яке є результатом виконання команди:

bbb-conf –salt

Якщо усі налаштування вказано правильно, то в меню кожного проекту з’являється новий пункт під назвою «Конференції». Далі адміністратор встановлює привілегії планування та створення зустрічей для окремих груп користувачів. Як правило, відповідальний за зустрічі є керівник команди – ScrumMaster.

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

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

chat

Рисунок 4.5 – Загальний вигляд конференцій у системі Redmine

ВИСНОВКИ

Розробка проектів – це нетривіальне завдання, що потребує ґрунтовних знань в предметній області від кожного члена команди. Складність процесу обумовлена багатьма факторами, серед яких найбільший вплив мають механізмами координації та взаємодії між розробниками. В умовах географічно-розподіленої роботи складність розробки зростає. Додаткові проблеми пов’язані з територіальною віддаленістю, соціальною та культурною розшарованістю. Зокрема, нестача неформального спілкування між окремими розробниками призводить до інформаційної незабезпеченості і некомандних дій.

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

Під час роботи проведений аналіз функціональності та порівняння сучасних Web-базованих систем для керування проектами з урахуванням потреб розподілених команд розробників. Визначені основні компоненти, які мають бути присутні в таких застосуваннях для забезпечення ефективної роботи команди:

- інтегрована система контролю версій і зберігання кодів програм, в т.ч. перегляд списків змін; важливою є підтримка кількох різних систем контролю версій;

- система розподілу завдань серед членів команд та обліку їх поточного стану і виконання; додатковою зручністю є візуалізація цих даних;

- система для зберігання документації по проекту та різноманітних додаткових ресурсів, відмінна від системи зберігання кодів програм;

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

- зручні засоби для планування вирішення тих чи інших завдань (milestones, to-do lists тощо).

Під час порівняння Web-базованих систем для керування географічно-розподіленими проектами з'ясувалося, що більшість з них не має ефективних інструментів для спілкування, зокрема для проведення нарад та інтерактивних зустрічей. Як правило, засоби комунікації між членами команди обмежувались електронним листуванням та використанням технології RSS. В окремих випадках були присутні вбудовані сервіси обміну миттєвими повідомленнями.

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

У ході дослідження методології гнучкої розробки Agile Scrum, виявлені основні проблеми, з якими стикаються розробники у географічно-розпоіделному середовищі. Проаналізовані деякі аспекти контролю за процесом розробки програмного забезпечення, його особливості у розподілених проектах. За результатами дослідження методології, запропоновані наступні зміни, що забезпечать підвищення якості виконання проектів в умовах географічно-розподіленої розробки:

- створення якісного інформаційного каналу для кожного з розробників;

- формування чітких та вичерпних вимог до продукту з боку замовника;

- забезпечення живого спілкування в умовах географічної розподіленості;

- виконання обов’язків та дотримання пріоритетів.

Запропоновані зміни стали основою для створення нової моделі середовища, що поєднує в собі загальні вимоги до розробки проектів та вимоги, що усувають проблеми, характерні саме для географічно-розподілених проектів. Модель визначає функціональні вимоги до методів та інструментів, що використовуються у географічно-розподіленій розробці.

Говорячи про перспективи розвитку географічно-розподіленої розробки проектів, варто зазначити, що з кожним роком аутсорсинг користується все більшою популярністю. Однак, робота в умовах географічної розподіленості – це досить нова предметна область, і станом на 2012 рік існує не так багато праць, що стосуються даної теми. Зокрема, доцільні дослідження, що стосуються ризиків, пов’язаних з роботою віртуальних команд.

ПОСИЛАННЯ

1. Understanding and Predicting Effort in Software Projects / A. Mockus, D. Weiss, and P. Zhang // Avaya Labs Research Basking Ridge, NJ 07920 – 2003. – Посилання: http://mockus.org/papers/icse03presentation.pdf

2. Integrating Process Support and Knowledge Management for Virtual Software Development teams / Frank Maurer, Harald Holz // 2003. – Посилання: http://sern.cpsc.ucalgary.ca/~milos/papers/2002/MaurerHolz2002.pdf

3. The Geography of Coordination: Dealing with Distance in R&D Work / Rebecca E. Grinter, James D. Herbsleb, Dewayne E. Perry // Bell Labs, Lucent Technologies – 1999.

4. A Grounded Theofy Analysis of E-Collaboration Effects for Distributed Project Management / Sajda Qureshi, Min Liu and Doug Vogel // 2003.- ISBN: 0-7695-2268-8 – Посилання: http://www.computer.org/csdl/proceedings/hicss/2005/2268/08/22680264c-abs.html

5. Versionweb: a Tool for helping Web Pages Version Control Internet and Multimedia Systems and Applications / Marinalva Dias Soares, Renata P. Mattos Fortes, Dilvan de Abreu Moreira //University of San Paulo, Institute of Mathematics and Computing – 2000. – Посилання: http://wenku.baidu.com/view/cffdc20df12d2af90242e602.html?from=related

6. Analyzing and Relating Bug Report Data for Feature Tracking - Proceedings of the 10th Working Conference on Reverse Engineering (WCRE’03) / Michael Fischer, Martin Pinzger, Harald Gall // IEEE Computer Society Washington, DC, USA – 2003. - Посилання: http://seal.ifi.uzh.ch/fileadmin/User_Filemount/Publications/fischer-wcre03.pdf

7. Project management software, online collaboration: Basecamp / Посилання: http://basecamp.com

8. Server software designed to help you manage software development: Bugzilla / Посилання: http://bugzilla.org

9. Collabtive – Open Source Collaboration // Посилання: http://collabtive.o-dyn.de

10. GitHub Social Coding // Посилання: https://github.com

11. Launchpad: software collaboration platform // Посилання: https://launchpad.net

12. A flexible project management web application: Redmine // Посилання: http://redmine.org

13. Scrum Alliance - Transforming the World of Work // 2010. - Посилання: www.scrumalliance.org

14. SCRUM Development Process / Ken Schwaber//Advanced Development Methods – 2008.

15. The Agile Manifesto / Martin Fowler, Jim Highsmith // 2001. - Посилання: www.pmp-projects.org/Agile-Manifesto.pdf

16. The Scrum Primer – An Introduction to Agile Project Management with Scrum / Pete Deemer, Gabrielle Benefield / 2007. – Посилання: http://jeffsutherland.com/ScrumPapers.pdf

17. The 3 basic principles of Scrum in an Agile Mindset / Bossuyt M. //Stress-Free Productivity – 2010. - Посилання: http://sfp101.com/?p=3832

18. The Scrum Primer Version 1.2 / Deemer, P., Benefield, G., Larman, C., Vodde, B. // One Broadway, 14th Floor Cambridge, MA 02142 – 2010. - Посилання: www.rallydev.com/documents/scrumprimer.pdf

19. Organizing Self-Organizing Teams / Hoda R., Noble J., Marshall S. // 2010.

20. Introduction to Scrum - An Agile Process // Mountain Goat Software – 2011. - Посилання: http://www.mountaingoatsoftware.com/topics/scrum

21. Scrum as Classic Teamwork / Miller I, / 2008.

22. Interface Control and Incremental Development in the PC Environment / Alexander L. Wolf, Lori A. Clarke, Jack C. Wileden //University of Massachusetts – 1985.

23. Knowledge management in virtual projects: A research agenda / Katzy, B. Evaristo, J.R. Zigurs // Proceedings of the 33rd Hawaii International Conference on System Sciences, Maui, Hawaii.- 2000. - Посилання: http://portal.cetim.org/file/1/92/KatzyEvaristoZigurs.pdf

24. Toward a Knowledge-Based Theory of the Firm / Grant R.M. // School of Business, Georgetown University – 1996. - Посилання: http://fp.tm.tue.nl/ecis/EcisA12004/Grant.pdf

25. The state of the notion: Knowledge management in practice / Ruggles R. // California Management Review, 40 (3) - 1998. - Посилання: www.ischool.utexas.edu/~i385q/readings/Ruggles-1998-State_of_the_Notion.pdf

26. Knowledge management with artificial intelligence / Desouza K.C. // Westport, CT, London: Quorum Books – 2002.

27. Fully Distributed Scrum / Sutherland J., Schoonheim G., Kumar N., Pandey, V., Vishal, S. // 2009.

28. A Practical Guide to Distributed Scrum / Woodward E., Surdek S., Ganis, M. // IBM Press – 2010.

29. The 3 basic principles of Scrum in an Agile Mindset / Bossuyt G. // Stress-Free Productivity – 2010. - Посилання: http://sfp101.com/?p=3832

30. Scrum Ceremony In a Nutshell / Bar-Nahor R. / 2008.

31. Time Management and Polychronicity: Comparisons, Contrasts, and Insights for the Workplace / Kaufman-Scarborough, Lindquist J. // 1999.

32. The Scrum Primer v. 1.21 / Deemer, Benefield, Larman // Scrum Training Institute – 2010.

33. Scrum Values: Respect Commitment, Focus, Courage, and Openness / Mezick D. // New Technology Solutions Inc. – 2010. - Посилання: http://www.newtechusa.com/agileboston/notes/ScrumValues.htm

34. What is SCRUM/ Sheriff D. // 2010.

35. Understanding Different Cultural Patterns or Orientations Between East and West. Investigationes Linguisticae, vol. IX / Qingxue L. / 2003.

36. Succeeding with Agile / Cohn M. // Mountain Goat Software – 2010. - Посилання: http://blog.mountaingoatsoftware.com/the-role-of-leaders-on-a-self-organizing-team

1. 37. Scrum Alliance Code of Ethics // Scrum Alliance – 2011. - Посилання: http://www.scrumalliance.org/pages/code_of_ethics

38. Global Software Teams: Collaborating Across Borders and Time Zones / Carmel E. // Upper Saddle River, NJ, Prentice-Hall P T R. – 2000.

39. Global Software Development: Managing Virtual Teams and Environments / Karolak D. W. // Los Alamitos, California, IEEE Computer Society – 2000.

1. Вирощування гороху
2. Reserching fmily history is true pssion rther thn just hobby for mny people
3. 21 МГТУ им. Н. Э. Баумана Чернышёва А
4. Gret Britn
5. Лекция 1. Определение задачи и история развития нанотрибологии как науки Трибология и краткая история е.
6. Утверждаю Согласовано Проректор по УР и КОД Начальник учебного отдела Коновалова Г
7. Київський політехнічний інститут Теорія адміністративнодержавного управління є одним з найбільш важли
8. Консалтинг деятельность по консультированию производителей продавцов покупателей по широкому кр
9. Школы стратегического менеджмента Роль школы культуры в стратегическом менеджменте
10. МУП ЖЭУРуководитель практики на предприятии- Гл.html
11. Теневая экономика экономические сищииьные и правовые аспекты
12. КУРСОВИЙ ПРОЕКТ РОБОТА з руйнування гірських порід Студентаки 3 курсу групи УГ.html
13. на тему ldquo;Хвороби поведінкиrdquo; Коломия 2000 Венеричні хвороби ldquo
14. тебе туда твое время на земле прошло
15. тематические основы АП
16. Якість та контроль якості продукції
17. Анализ финансового сотояния предприятия и диагностика банкротства
18. Теоретические основы управления и планирования в торговой организации в условиях кризиса
19. Підбиття підсумків попередньої теми
20. КОСМОС Оглавление

Материалы собраны группой SamZan и находятся в свободном доступе