Моделі груп розроблювачів програмного забезпечення.

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

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

Традиційні моделі організації колективів розробників ПЗ.

Модель бригада.

В кінці 60-хх початку 70-хх років у зв'язку із зростанням складності програмних систем з'явилася необхідність організації окремих програмістів у бригади або групи бригад. Оптимальна структура бригади визначилася чисельністю людей, їх підготовкою, індивідуальними особливостями, самим проектом і організаційними умовами.

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

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

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

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

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

Втрата кваліфікації програміста при висуненні на керівні посади і уся зростаюча ізольованість програмістів призвели до ідеї створення моделі «Бригади головного програміста».

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

В «Бригаді головного програміста» виділяють нижче перелічені ролі.

o Головний хірург - є головним конструктором і пише найбільш важливі шматки програми. Він повинен бути компетентним у даній галузі, мати стаж роботи понад 10 років, володіти суттєвими знаннями в системних і прикладних галузях.

o Другий пілот виконує особливо важливі дії і може при необхідності замінити хірурга, знає добре код програми, досліджує можливості альтернативних стратегій проектування, може займатися написанням коду, але не несе відповідальності за нього. Хірург випробовує на ньому свої ідеї, але не зв'язаний його пропозиціями.

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

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

Ієрархічна модель групи

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

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

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

Рис 3.1. Модель ієрархічної групи

До основних переваг ієрархічної моделі організації групи можна віднести:

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

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

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

- висока масштабованість дозволяє застосовувати модель в масштабах від десятків до сотень тисяч виконавців.

До недоліків ієрархічної моделі можна віднести:

- нарощування функціональності забезпечується збільшенням кількості співпрацівників;

- орієнтація на виконання суворо визначених функцій. Зміна функцій вимагає зміни усієї структури ієрархії;

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

- погана адаптація до швидкої зміни технологій і парадигм;

- вплив негативних якостей керівника на ефективність роботи групи.

Гнучкі моделі організації колективів розробників ПЗ.

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

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

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

Модель групи ХР.

Автор підходу екстремальне програмування (eXtreme Programming) К. Бек позиціонує його як спрощений, ефективний, гнучкий, передбачуваний, науково обгрунтованих і цілком приємний спосіб розробки програмного забезпечення, який передбачає низький рівень ризику.

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

Чотири цінності знаходяться в основі ХР:

- комунікація (communication);

- простота (simplicity);

- зворотній зв'язок (feedback);

- хоробрість (courage).

Технологія розробки ХР призначена для роботи над проектами, у яких працює від двох до десяти програмістів, не затиснутих у жорсткі рамки існуючого комп'ютерного оточення і в яких вся необхідна робота, пов'язана з тестуванням, може бути виконаною протягом одного дня.

В технології ХР виділені дві узагальнені ролі: менеджер і розробник.

Одним з основних правил стратегії ХР є те, що технарі концентруються на вирішенні технічних проблем, а бізнесмени - на вирішенні бізнес-проблем. В ХР менеджмент виконує дві ролі: Інструктор (coach) і Ревізор (tracker). Обидві ці ролі можуть виконуватися одним і тим самим членом команди, однак, це можуть бути, також різні люди.

Інструктор відповідає за весь процес розробки і концентрує свою увагу на загальній продуктивності команди. До його основних обов'язків належать:

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

- бачити довгострокові цілі переробки коду й стимулювати дрібномасштабну переробку;

- допомагати програмістам індивідуальними технічними навичками;

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

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

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

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

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

Модель групи Scrum.

В 1968 p. X. Такеучі та І. Нонака описали модель виробництва, яка використовувалася в галузі машинобудування та електроніки. У відповідності до цієї моделі успішність і гнучкість роботи проектів забезпечували невеликі згуртовані команди без жорсткої спеціалізації.

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

Чіткий розподіл ролей та обов'язків у групі Scrum, подається в таблиці 1, дозволяє ефективно приймати рішення відносно досягнення цілей проекту. Всі приймаючі участь в проекті спеціалісти поділяються на дві великі символічні групи: «поросята» (pigs) і «курчата» (chickens). Такий поділ прав та обов'язків між розробниками («поросятами») і менеджментом («курчата») дозволяє з одного боку, групі розробників (Scrum Team) отримати можливість самостійно приймати частину рішень, а з іншого боку, групі менеджменту (Product Owner, Scrum Master, представники менеджменту організації) контролювати хід проекту.

Таблиця 1