Agile: PO, BA, SM, QA хто всі ці люди?

20 December 2020

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

Я б хотіла розпочати з Waterfall методології – традиційного способу управління та реалізації проектів, потім плавно перейти до Agile маніфесту та ролей у Agile.

Перший формальний опис Waterfall методології, після якої вона стала популярною, здійснив В. В. Ройс ще у 1970, але і зараз її активно використовують у виробництві та будівництві. Без виснажливого планування, детального тестування та аудиту неможливо створити продукт – чи це автомобіль, чи комп’ютерна програма.

Waterfall (Водоспад) –

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

Як правило, ініціатива проходить через такі етапи всередині організації:

  • Клієнт приходить з ідеєю та обговорює її з менеджером проєкту
  • BA (Business Analyst)описує специфікацію вимог
  • дизайнери створюють макети та ескізи
  • розробники програмують упродовж  69 місяців
  • тестувальники перевіряють готовий продукт

 

Які проблеми можуть виникнути при такому підході?

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

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

Який результат можемо очікувати? 

  • багато невдалих і складних проєктів
  • програмне забезпечення довго виходить на ринок
  • не всі вимоги виконані
  • висока вартість внесення змін після випуску продукту
  • необхідність “зробити все правильно” з першого разу
  • велика кількість дефектів
  • незадоволені клієнти
  • незадоволена та стресована команда

 

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

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

Agile безумовна альтернатива Waterfall, адже її особливістю є швидка адаптація до змін.

У лютому 2001 року група з сімнадцяти експертів з програмного забезпечення зібралася  у Snowbird, штаті Юта у Сполучених Штатах та написала маніфест для гнучкої розробки програмного забезпечення, виклавши цінності та принципи гнучких процесів у чотири ключові ідеї.

Що вони означають?

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

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

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

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

Існує понад 40 методів Agile, такі як Kanban, Scrum, Extreme програмування (XP), Lean Startup тощо.

Хоч методів багато, ролі в Agile не варіюються від цього. Розгляньмо деякі популярні ролі, котрі можуть бути не такими зрозумілими, як Developer (DEV), а саме – Product Owner (PO), Business Analyst (BA), Scrum Master (SM) та Quality Analyst/Assurance (QA).
Якщо тобі буде цікаво дізнатися більше чи почути про інші ролі – пиши в коментарях.

Product Owner (PO) – власниця/-к продукту: фізична особа, яка володіє продуктом від імені організації, несе повну відповідальність за його продуктивність і доставку цінності користувачам.
Продукт – це все, що може бути запропоновано ринку, що може задовольнити бажання або потребу.

Задачі PO:

  • Формулює проблему
  • Створює, володіє і передає бачення продукту
  • Визначає особливості продукту
  • Визначає рентабельність інвестицій (ROI) продукту
  • Пріоритизує функції відповідно до їхньої цінності
  • Веде список невиконаних робіт щодо продукту
  • Пише і розробляє вимоги до продукту за допомогою користувацьких історій
  • Корегує та змінює функції і пріоритети між ітераціями
  • Приймає або відхиляє результати роботи
  • Забезпечує зворотний зв’язок під час розробки продукту
  • Визначає дату випуску продукту
  • Бере участь в Agile-церемоніях
  • Ухвалює рішення щодо продукту
  • Працює за всіма функціями організації
  • Повідомляє про прогрес
  • Керує розробкою прототипів і тестуванням ідей
  • Збирає та аналізує показники використання продукту
  • Працює в тісному контакті з UX
  • Переглядає та закриває задачі після завершення роботи

 

Business Analyst (BA) – бізнес-аналітик: роль BA залежить від типу проєкту, його рівня складності та неоднозначності; BA є відповідальним за надання цінності, яку шукає бізнес.

  • Build the Thing Right
  • Build the Right Thing
 

Задачі BA:

  • Пише історії користувачів з позитивними критеріями прийняття (acceptance criteria) – виступає в якості розповідача та письменника задач та розповідача
    • Слідує принципам INVEST*
    • Розділяє користувацькі історії вертикально і горизонтально
    • Виявляє залежності, кидає виклик припущенням
  • Планує та проводить церемонії проєкту
    • Iteration Planning Meeting
    • Story Grooming
    • Story Kick-Offs
    • Desk Checks
    • Демонтрація проєкту Showcase
  • Планує поточну та майбутню роботу
    • Відповідає за беклог продукту (Product Backlog) та розставляє пріоритети
    • Фільтрує інформацію з досліджень користувачів, щоб створити чітку картину того, що має бути побудовано
    • Досліджує функції та поведінку інших систем
    • Створює карту історій/задач https://www.agilealliance.org/glossary/storymap/
    • Будує “дорожню карту” команди або проєкту https://roadmunk.com/guides/roadmap-templates/
    • Планує релізи
  • Співпрацює з власником продукту (PO)
    • Разом визначають, що таке успіх проєкту
    • Забезпечують конвеєр цінної роботи для команди
    • Узгоджують обсяг (scope) користувацьких історій
    • Визначають пріоритети користувацьких історій
  • Поширює інформацію про те, що робить команда
  • Створює видимість прогресу команди
  • Виступає як сполучна ланка і “будівельник” взаємної довіри
  • Активізує команду, підтримуючи “бойовий” дух
  • Інтенсивно керує очікуваннями зацікавлених сторін проєкту та спонсорів
  • Часто бере на себе роль власника продукту (PO)

*INVEST – мнемоніка; описує, якою повинна бути хороша історія користувача:
“I” independent – незалежний (від усіх інших задач)
“N” negotiable- договірний
“V” valuable – цінний
“Е” estimable – оцінений в story points
“S” small – невеликий, може вписатися в ітерацію
“T” testable – можливо перевірити

Поряд з основними навичками, бізнес-аналітик також повинен володіти деякими додатковими навичками, зокрема, це:

Технічний BA – обізнаний у інфраструктурі або пише код,
Data BA – аналітик даних, https://www.northeastern.edu/graduate/blog/data-analyst-vs-business-analyst/
BA/Agile Coach
BA/Scrum Master

Scrum Master – Скрам Майстер: відповідальний за просування і підтримку Scrum. Майстри Scrum допомагають кожному зрозуміти теорію, практику, правила та цінності Scrum.

Скрам Майстер є і лідером, і ”слугою” для скрам команди. Scrum Master допомагає тим, хто не входить в Scrum-команду, зрозуміти, які з їхніх взаємодій з Scrum-командою корисні, а які – ні. Scrum Master сприяє кожному змінити ці взаємодії, щоб максимізувати цінність, яка створена командою Scrum.

Задачі Scrum Master:

  • Виконує нетехнічну роль
  • Гарантує, що команда функціональна та продуктивна
  • Сприяє та полегшує співпрацю, допомагає розв’язувати конфлікти та знаходиться на боці команди
  • Усуває перешкоди на шляху розвитку команди розробників
  • Виступає за постійне вдосконалення
  • Відстежує та встановлює метрики

Керівники проєкту або BA потенційно можуть взяти на себе цю роль.

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

Quality Assurance/ Quality Analyst (QA) – Аналітик з якості: 
Людина, яка бере на себе відповідальність та гарантує, що програмне забезпечення, яке ми передаємо замовнику, є саме тим, що він очікує. Якість сама собою не має сенсу. Найголовніше – це задоволення потреб користувачів і бізнесу. QA виступає за процеси, що забезпечують відповідність розробленого продукту потребам користувачів та організації.
QA ставить під сумнів всі частини процесу, щоб переконатися, що команда дає бажаний результат, формулюючи постійне питання: : “Чи ми створюємо правильний продукт і, якщо так, чи правильно його будуємо?”

Задачі QA:

  • Підвищує та пропагандує якість та best practices (найкращі практики)
  • Запобігає створенню дефектів замість того, щоб виявляти їх
    • Аналізує вимоги, робить pairing з PO, BA, XD
    • Пише автоматизовані тести, тест-кейси, тест-стратегію
    • Робить pairing з девелоперами – пише unit-тести, дивиться в pull request, слухає, що програміст робить та обговорює edge case
  • Вивчає та знає продукт, який розробляється, та надає інформацію іншим членам команди
  • Є “клеєм”, який поєднує усіх членів команди і всі ролі
  • Навчає команду, що кожен має нести відповідальність за якість
  • Ініціює дискусії стосовно якості

Про яку роль було цікаво прочитати? Про шо було б ще цікаво дізнатися

Leave a Reply

Your email address will not be published. Required fields are marked *