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