Розподіл ролей Scrum

Роль	Відповідальність
Власник продукту (Product Owner) Відповідає за формування списку вимог до функціональності продукту. Зазвичай власник продукту є представником або довіреною особою замовника.	Формує журнал продукту; визначає пріоритети функційності у відповідності з їх комерційною цінністю; визначає дату та зміст випусків продукту; відповідає за комерційну успішність продукту; уточнює функціональність і пріоритети після кожного спринту; приймає (або відхиляє) результати проекту.
Команда (Scrum Team) - група, що складається з п'яти-дев'яти (7 ± 2 людини) самостійних, ініціативних розробників, включаючи архітекторів, програмістів, тестерів та інше, спеціалістів, безпосередньо працюючих над реалізацією проекту.	Активно приймають участь у виборі мети наступної ітерації; має право приймати всі можливі (в рамках проекту) дії для досягнення мети спринту; забезпечує відповідний рівень якості продукту; самостійно організує себе і свою роботу; демонструє результати роботи власнику проекту.
Скрам-майстер (ScrumMaster) посередник між всіма учасниками проекту, основним обов'язком якого є організація процесу і дотримання технології Scrum.	Гарантує високу продуктивність роботи групи; відповідає за забезпечення продуктивної взаємодії між усіма учасниками проекту; захищає команду від всіх небажаних зовнішніх впливів; відповідає за дотримання в процесі всіх принципів технології Scrum.

Модель групи DSDM

Технологія розробки ПЗ Dynamic Systems Development Method (DSDM) сфокусована на організації процесу виробництва програмного забезпечення. Технологія DSDM визначає набір стандартних ролей і відповідальностей, які перелічені нижче. На рисунку 3.2 приведена типова структура команди розробників (учасники проекту, які мають повну зайнятість, зображені в зафарбованих овалах.

Менеджер проекту (Project Manager) забезпечу загальне керівництво проектом.

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

Рис. 3.2. Модель групи DSDM

Чемпіон проекту (Project Champion або Executive Sponsor) володіє можливостями і обов’язками по розпорядженню ресурсами і фондами, які необхідні даному проекту. Він несе відповідальність за прийняття будь – яких рішень, пов’язаних з проектом. Ця роль передбачає можливість часткової зайнятості.

Лідер команди (Team Leader) керує командою розробників і забезпечує ефективність її роботи.

Технічний координатор (Technical Coordinator) відповідає за роботу архітектури проекту. Технічний координатор, також, відповідає за загальний технічний стан проекту.

Розробник (Developer) приймає участь в аналізі вимог, моделюванні, проектуванні, основним обов’язком розробника є програмування.

Тестувальник (Tester) відповідає за технічне тестування продукту.

Представницький користувач (Ambassador User) представляє користувачів продукту. Представницький користувач відповідає за те, щоби розробники вчасно отримували зворотній зв'язок зі сторони користувачів.

Користувач – консультант (Advisor User) може бути будь – який користувач, представляючий значну точку зору за продукт. Користувач – консультант вносить в проект знання з певного аспекту використання розроблювального продукту. Ця роль передбачає можливість часткової зайнятості.

Секретар (Scribe) відповідає за протоколювання всіх угод та рішень, прийнятих за час семінарів.

Посередник (Facilitator) відповідає за проведення семінарів. Посередник, також відповідає за ефективність комунікації між всіма членами команди.

Модель проектної групи MSF.

Microsoft Solutions Framework (MSF) Team Model описує підхід Microsoft до організації працюючого над проектом персоналу і його діяльності з ціллю максимізації успішності проекту. Дана модель визначає рольові кластери, їх галузі компетенції і зони відповідальності, а також рекомендації членам проектної групи, які дозволяють їм успішно здійснювати діяльність по втіленню проекту в життя.

Ефективність використання моделі групи MSF базується на наступних принципах організації команди соратників:

• спрямованість на кінцевий результат;

• установлення на відсутність дефектів;

• прагнення до самовдосконалення;

• зацікавленість в результаті.

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

Рис.3.3 Модель групи MSF

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

Таблиця 2. Відповідальності рольових кластерів

Роль	Відповідальність
Управління програмою (program manager)	За розробку архітектури, рішення, адміністративні служби
Розробка (developer)	За розробку додатків і інфраструктуру, технологічні консультації
Тестування (QAE	За планування, розробку тестів і звітність по тестах
Управління випуском (release manager)	За інфраструктуру, супровід бізнес – процеси, випуск готового продукту
Задоволення замовника (user experіence)	За навчання, ергономіку, графічний дизайн, технічну підтримку
Управління продуктом (product manager)	За бізнес – пріоритети, маркетинг, представництво інтересів замовника

Переваги моделі групи MSF:

• висока продуктивність;

• відносно легка масштабність;

• висока мотивація праці і зацікавленість всіх членів групи кінцевим успіхом.

Недоліки моделі MSF:

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

• важливе значення має комунікабельність і вміння працювати в колективі;

• демократична модель команди MSF погано поєднується з жорсткою ієрархічною структурою підприємства [19].

Модель групи FDD

Функціонально – орієнтована розробка ПЗ FDD передбачає наявність шести основних ролей, але кожен учасник проекту може виконати одну або декілька ролей.

Менеджер проекту (Project Manager) є адміністративним лідером проекту і відповідає за управління бюджетом проекту і розподіл ресурсів. На плечах менеджера проекту також лежить подання звітів про стан проекту керівництву організації.

Головний архітектор (Chief Architect) відповідає за загальний дизайн системи. Під час колективних сесій присвячених проектуванню системи, головний архітектор виступає в ролі експерта і посередника. Також головному архітектору належить виключне право прийняття рішень в суперечливих ситуаціях.

Менеджер розробки (Development Manager) відповідає за управління процесом розробки. Обов’язком менеджера розробки є забезпечення ефективного використання всіх ресурсів проекту. Частково, менеджер розробки виступає в ролі арбітра в організаційних суперечках між головними програмістами (наприклад, суперечки про розподіл ресурсів проекту між функціональними командами).

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

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

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

Переваги використання моделі групи FDD:

• дозволяє управляти проектами до 500 осіб;

• залучати до роботи менш кваліфікованих розробників;

• ефективно контролювати процес розробки.

Модель групи OpenUp

Технологія розробки ПЗ OpenUp позиціонується авторами як легкий гнучкий варіант RUP, в основі якого лежать наступні принципи:

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

• постійне спілкування з метою збереження спільності інтересів і розуміння;

• постійний розвиток в процесі отримання зворотного зв’язку і проведення покращень;

• концентрація на чітко сформульованій архітектурі [18].

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

• колективно планувати і розподіляти обов’язки;

• самостійно висувати свої кандидатури на виконання ролі;

• давати бачення своєї участі в проекті, як в якості ролі, так і в якості члена колективу.

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

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

Учасники групи виконують нижче перелічені ролі.

Користувачі представляють інтереси груп, зацікавлених в розробці програмного забезпечення. Цю роль може виконувати будь – яка зацікавлена в проекті людина (клієнт, замовник, інвестор, користувачі ПЗ та інші).

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

Аналітик взаємодіє зі всіма зацікавленими особами (замовником, користувачами, розробниками та інш.) в реалізації проекту, збирає дані від них, розставляє пріоритети для вимог користувачів.

Архітектор відповідає за проектування архітектури програмного забезпечення, приймає ключові технічні рішення.

Розробник відповідає за проектування, реалізацію і тестування компонент, об’єднання компонент системи.

Тестер планує і здійснює тестування системи, реєструє і аналізує результати тестування.

Будь – яка Роль виконується будь – якою особою в групі, яка може виконувати загальні завдання проекту.

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

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

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

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

Вся робота назначається, записується і відстежується за допомогою Списку робіт (Work Item List). Учасники команди використовують його в якості єдиного репозитарія для всіх завдань, які необхідно записати і відстежувати, включаючи всі запити на зміни, дефекти і вимоги користувачів.

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

Переваги моделі групи OpenUp: прозорість процесу розробки ПЗ; розуміння членами колективу роботи інших.