1. Залучаючи більш кваліфіковану або дефіцитну робочу силу, знижуючи витрати, компанії-розробники неминуче...
2. концептуальне рішення
3. Вибір типу розробки

Залучаючи більш кваліфіковану або дефіцитну робочу силу, знижуючи витрати, компанії-розробники неминуче за це «розплачуються». Ускладнюється їх контроль над якістю продуктів, збільшуються терміни створення програмних продуктів, зростає кількість проблем, пов'язаних з координацією дій розрізнених робочих груп. Чи є можливість хоча б мінімізувати негативні наслідки децентралізації розробки? Є, але вона забезпечується не тільки певними інструментами підтримки групової роботи. Не існує «срібної кулі», яка разом вирішить всі проблеми, тому необхідно комплексне використання інструментів і нових методологій розробки та контролю над якістю.

Ключова відмінність розподіленої розробки

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

Хоча в суспільстві склалося уявлення про програміста як про класичний інтроверт (людину, яка повністю занурений в роботу і мало спілкується з колегами протягом робочого дня), дослідження дають зовсім іншу картину. Одне з них свідчить, що кожен розробник приділяє в середньому 75 хвилин в день неформального обговорення з колегами питань, пов'язаних з проектом. Згідно з дослідженням [ 1 ], Розробники телекомунікаційного програмного забезпечення витрачають на формальне і неформальне взаємодія з колегами 50% свого часу - аж до останнього місяця розробки, коли цей показник знижується до 10%. Звичайно, показники варіюються від проекту до проекту, але можна однозначно стверджувати, що спілкування має для розробника величезне значення.

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

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

Яке безпосередній вплив надає рівень взаємодії розробників на виконання проекту? Найбільш очевидним параметром є час завершення проекту. Якщо одним фахівцям регулярно доводиться чекати інших для вирішення будь-яких питань, то затримки неминучі. Вони виникають і при звичайній, нерозподіленого, розробці, але бувають значно меншими за часом. Опитування розробників декількох десятків компаній з Великобританії і Німеччини, проведене дослідницьким підрозділом Lucent Technologies, дав наступні результати. При роботі в межах одного будинку кожен реципієнт стикався в середньому з 2,1 затримки в місяць при тривалості кожної 0,9 робочого дня. При розподіленої розробки виникало 1,9 затримки в місяць, але їх середня тривалість становила вже 2,1 дня. Отже, різниця в кількості затримок при локальної й розподіленої розробки несуттєва, тоді як різниця в їх тривалості досить відчутна.

Приблизно ті ж результати отримані при аналізі запитів на зміну проекту в цілому. В середньому при локальної розробці на одна істотна зміна в проекті (виправлення помилок або додавання нових функцій) було потрібно 5 днів (з початку реальної роботи до внесення останніх змін в код - це називається «робочим інтервалом»). Якщо в створенні програмних продуктів брали участь кілька віддалених колективів, такий інтервал збільшувався до 12,7 дня (тобто більш ніж в два з половиною рази). Ситуація з повним інтервалом (часом з моменту надходження запиту на зміну до внесення останньої зміни в код; цей інтервал трохи більше робочого, оскільки включає в себе час, необхідний для аналізу запиту, призначення пріоритету і т.п.) аналогічна: 20,5 дня проти 12,7.

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

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

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

Для подальшого аналізу служить графічна модель Гаусса ( см. малюнок ). Вузли тут - досліджувані змінні фактори, а дуги - приватна кореляція між ними. Приватна кореляція між змінними X1 і X2 відрізняється від звичайної вибіркової кореляції тим, що показує величину взаємозв'язку між змінними при фіксованих значеннях інших змінних (Xi), що безпосередньо впливають на X1 і X2. Синій колір дуги означає позитивну приватну кореляцію, а червоний - негативну. Товщина лінії визначає значимість кореляції. Цифри поруч з дугою означають відхилення (чим воно більше, тим більше і значимість) і приватну кореляцію. На відміну від звичайної кореляції (взаємозалежності величин), приватна кореляція використовується, якщо не можна достовірно стверджувати, що величини пов'язані між собою безпосередньо, а не через деяку третю величину або групу величин. У таких випадках розглядається так звана «приватна кореляція двох величин при незмінних значеннях інших величин». Змінні, не пов'язані між собою безпосередньо, є незалежними при фіксованих значеннях змінних, з якими вони пов'язані.

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

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

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

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

концептуальне рішення

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

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

література

1. J. Herbsleb etс. Object-oriented analysis and design in software project teams. // Human-Computer Interaction, 1995, Vol. 10, № 2-3.

Олексій Абсалямов ( [email protected] ) - аспірант МГТУ ім. Н. Е. Баумана (Москва).

Вибір типу розробки

Розподілена розробка об'єктивно є більш складним методом, яким проте користуються все частіше і частіше. Керівник проекту повинен брати до уваги такі фактори.

• «Вік» проекту. Проект може бути як новим, так і продовженням попереднього. Більшість розробників дуже не люблять розбиратися в чужому коді, особливо якщо його автор не сидить за сусіднім столом. Дійсно, «старі» проекти набагато складніше адаптувати до нового стилю розробки: вони містять багато коду, який вже частково не підтримується, а архітектура проекту може бути незручна для поділу завдань. Треба відмовитися від переходу до розподіленої моделі при виконанні проектів, які раніше довгий час виконувалися суто на локальному рівні.
• Критичність проекту для виробника і споживача. Продукт, створений кількома віддаленими колективами, при інших рівних умовах зазвичай виявляється гіршим за якістю, ніж продукт, розроблений локальної командою, - при розподіленої розробки контроль над якістю і тестування ускладнені.
• Бюджет. Якщо грошове питання є одним з найбільш істотних у проекті, розподілена розробка може дати переваги. Економія коштів досягається не тільки при виконанні аутсорсингу програмних проектів в Індії, Росії або державах Південно-Східної Азії, але і при роботі з віддаленими колективами всередині країни.
• Модульність проекту. Абсолютно незалежних модулів в проекті не буває, але можна легко відрізнити умовно неподільні проекти від повністю модульних. Розробку основної системи можна доручити віддаленим колективам, а взаємодія з нею модулів регулювати чітко визначеними програмними інтерфейсами. Чим більшою модульностью відрізняється проект, тим легше його виконувати віддалено і тим більше причин вибрати розподілену розробку.
• Розмір проекту. Малі проекти порівняно легко передати розподіленим колективам, але економічно це буває невиправданим. Економія на заробітній платі виявляється незначною і перекривається витратами на пошук невеликих команд або індивідуальних розробників, оскільки великі сервісні компанії неохоче беруться за такі проекти. Крім того, за той час, який знадобиться віддаленим розробникам, щоб увійти в курс справи, місцевий фахівець часто встигне написати й налагодити код.

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

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

• Кадровий потенціал. Цей фактор є важко формалізованих, оскільки залежить від рівня зарплати, доступності кадрів на місцевому ринку, складності та унікальності поставлених завдань і т.п.