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

Рис 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

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

Читайте також:

<== попередня сторінка	\|	наступна сторінка ==>
Моделі груп розроблювачів програмного забезпечення.	\|	Модель групи DSDM

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.019 сек.