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

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

Давайте почнемо з того, що таке «Agile» 

Цей термін з’явився на початку 2000-х років в IT-індустрії, коли в штаті Юта було видано «Маніфест гнучкої розробки програмного забезпечення». Маніфест був розроблений групою програмістів-ентузіастів, які хотіли зрозуміти, що саме лежить в основі розробки затребуваного і корисного IT-продукту. Він включає в себе чотири основних ідеї і дванадцять принципів ефективного управління проектами, мова про які піде нижче. Також слід додати, що в даний час існує безліч Agile-підходів: Kanban, SCRUM, Extreme programming, Lean і інші, але всіх їх об’єднує відповідність 4-м базових ідей, описаним в тому самому Agile-маніфесті.

Ідеї ​​Agile: 

· Люди і взаємодія важливіше процесів та інструментів 

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

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

· Працюючий продукт важливіше вичерпної документації 

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

· Співпраця з замовником важливіше узгодження умов контракту

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

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

· Готовність до змін важливіша слідуванню початковому плану

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

12 основних принципів Agile маніфесту:

1. Найвищим пріоритетом для нас є задоволення потреб замовника, завдяки регулярній і своєчасній поставці цінного програмного забезпечення.
   
    
2. Зміна вимог вітається, навіть на пізніх стадіях розробки. Agile-процеси дозволяють використовувати зміни для забезпечення замовнику конкурентної переваги.
   
    
3. Працюючий продукт слід випускати якомога частіше, з періодичністю від кількох тижнів до кількох місяців.
   
    
4. Протягом всього проекту розробники і представники бізнесу повинні щодня працювати разом.
   
    
5. Над проектом повинні працювати мотивовані професіонали. Щоб робота була зроблена, створіть умови, забезпечте підтримку і повністю довіртеся їм.
   
    
6. Безпосереднє спілкування є найбільш практичним і ефективним способом обміну інформацією як з самою командою, так і всередині команди.
   
    
7. Працюючий продукт – основний показник прогресу.
   
    
8. Інвестори, розробники і користувачі повинні мати можливість підтримувати один і той же ритм постійно. Agile допомагає налагодити такий стійкий процес розробки.
   
    
9. Постійна увага до технічної досконалості і якості проектування підвищує гнучкість проекту.
   
    
10. Простота – мистецтво мінімізації зайвого клопоту – вкрай необхідна.
    
     
11. Найкращі вимоги, архітектурні та технічні рішення народжуються у самоорганізованих команд.
    
     
12. Команда повинна систематично аналізувати можливі способи поліпшення ефективності і відповідно коригувати стиль своєї роботи.

SCRUM . Agile метод управління проектами

 Однією з поширених Agile методології є – Scrum, в якому, як раз і існують вищезгадані Agile Ролі. 

 Scrum – це методологія (фреймворк) управління проектами з певним і обов’язковим до виконання зводом правил.

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

 Scrum Artifacts – це інструменти для вирішення проектних завдань. У Scrum існує чотири артефакти: беклог продукту, беклог спринту, діаграма згоряння і інкремент (ваша мета) з вашими критеріями готовності. 

 Scrum Rituals – це затверджені процеси, які команда виконує на регулярній основі протягом усього проекту. До scrum-ритуалів відносять: планування спринту, щоденна синхронізація, спринт рев’ю і ретроспективи. Кожен з цих ритуалів виконується в суворій відповідності і всією командою.    

Основні ролі всередині Agile Scrum-команди :

Product Owner (PO) – є власником продукту. Він формує і визначає вимоги продукту і його функціонал, визначає пріоритет завдання команди на спринт і допомагає команді планувати. Також він несе відповідальність за цінність продукту для користувачів і приймає роботу команди на рев’ю, але не несе відповідальності за терміни запуску продукту або здачі функціоналу. У ролі Product Owner також може виступати Product Manager.  

Product Manager (PM) – може виконувати роль Product Owner-a. Ця людина займається дослідженням ринку, доносить бажання клієнта, відповідає за вартість продукту, відповідає за всі комунікації з ринком, які ваш продукт буде виконувати. Питання якості та делівері (поставки продукта) не входять до його компетенції. Може виконувати ролі Product Owner і Scrum Master, але ніколи обидві відразу.  

Scrum Master (SM) – несе відповідальність за терміни здачі запланованих принтів. У цій ролі також може виступати Project Manager, так як основні завдання скрам-майстра це: оптимізація та покращення робочих процесів, створення комфортних умов роботи команди, виявлення проблем та знаходження шляхів для їх вирішення, що функціонально перегукується з роллю Project Manager.

Project Manager (PM) – відповідає і за якість, і за делівері продукту, тому його роль може поєднуватися з роллю скрам-майстра. Це людина, яка стежить і слідкує за проектом, відповідає за процеси комунікації на проекті. Стежить за тим, як відчуває себе команда і як інформація циркулює по організації. Допомагає команді прибирати перешкоди на шляху до успіху. 

Scrum Team (ST) – включає в себе всіх крос-функціональних членів команди для досягнення поставлених цілей продукту. Команда не вирішує які вимоги є пріоритетними для продукту, це завдання ролі Product Owner, але визначає який набір завдань візьме в спринт. Команда повинна бути взаємозамінною з фіксованим складом, щоб відчувати себе одним цілим. 

Корисна література: 

Дж. Сазерленд «Scrum. Революційний метод управління проектами »

Д. Андерсон «Канбан. Альтернативний шлях в Agile »

K. Schwaber, J. Sutherland “The Scrum Guide”