Agile церемонії, ролі в команді, артефакти

Print Friendly, PDF & Email

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

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

Розкажемо про всі етапи Agile, що таке  agile підходи і як грамотно налагодити взаємодію команди.

Що таке Agile та ролі Agile в ІТ?

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

В традиційних методах розробки зацікавлені сторони можуть не отримувати достатньо інформації про прогрес проєкту. Як результат — через відсутність регулярного зворотного зв’язку та тестування продукт може бути низької якості або не відповідати очікуванням.

Але Agile поділив ситуацію на «до» і «після». Філософія agile діє як каталізатор для змін у ІТ-сфері, реформуючи традиційні методи розробки:

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

Spotify, Google, Amazon, і Microsoft використовують Agile методики розробки для своїх продуктів і послуг.

Наприклад, Spotify використовує модель Spotify Engineering Culture, яка базується на Agile та Scrum, для розробки свого музичного сервісу. Google також відомий своєю Agile-орієнтованою культурою розробки програмного забезпечення, яка дозволяє їм швидко реагувати на зміни та інновації. Багато продуктів Microsoft, таких як Microsoft Office та Xbox, розроблені з використанням Agile. Онлайн-рітейлер Amazon використовує Agile для швидкої розробки та впровадження нових функцій на своєму вебсайті та в мобільних додатках.

В Agile над проєктом працює окрема команда. Ось деякі з найважливіших ролей Agile у ІТ:

  • Scrum Master: Це особа, відповідальна за забезпечення правильної роботи процесу розробки згідно з методологією Scrum. Scrum Master допомагає команді усунути перешкоди, забезпечує дотримання Scrum-процесів та сприяє постійному вдосконаленню команди.
  • Product Owner: Це представник клієнта або бізнесу в команді, який визначає пріоритети для розробки продукту. Product Owner визначає вимоги, створює Backlog (список завдань) та надає команді чітке розуміння того, що потрібно розробити.
  • Розробники (Developers): Це члени команди, які фактично пишуть код, тестують продукт та роблять усе необхідне для створення функціонального продукту.
  • Quality Assurance (QA): Це члени команди, які відповідають за забезпечення якості продукту. Вони тестують функціональність, виявляють помилки та забезпечують, щоб продукт відповідав стандартам якості.
  • Stakeholders (Зацікавлені сторони): Це всі, хто має інтерес до продукту, будь то клієнти, менеджери, маркетологи тощо. Вони можуть бути запрошені до участі в демо-презентаціях або надавати зворотний зв’язок під час розробки.
  • Team Lead (Керівник команди): Це особа, яка відповідає за організацію та керівництво роботою команди. Вони сприяють збереженню командної динаміки та вирішенню конфліктів.

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

Використання Agile підходу: головні терміни

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

  • User Story (Історія користувача): Це короткий опис функціональності, який виражається з точки зору користувача. Історії користувачів допомагають уникнути технічного жаргону та зосередитися на потребах та очікуваннях користувачів.
  • Sprint (Спринт) — короткий часовий проміжок, під час якого команда працює над конкретним набором завдань з метою створення готового до випуску продукту. Кожен спринт зазвичай триває від 1 до 4 тижнів і закінчується створенням готового до випуску продукту або його частини.
  • Backlog (Беклог) — список завдань або вимог, які потрібно виконати для розробки продукту. Беклог допомагає команді організувати та пріоритизувати свою роботу.
  • Burnout Chart (Діаграма випалювання) — графік, який відображає кількість роботи, яка залишилася відзначеною у Backlog та час, що залишився до завершення проєкту. Діаграма випалювання допомагає команді візуалізувати свій прогрес та відстежувати виконання завдань.

Артефакти в Agile — це всі видимі результати роботи команди під час розробки продукту. Вони допомагають команді тримати під контролем свою роботу, розуміти, що вони мають зробити, і відстежувати прогрес. Це може бути що завгодно: від списків завдань до готових функціональних частин продукту.

Agile церемонії (події чи зустрічі)

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

Філософія Agile передбачає 4 основні церемонії:

  • Планування спринту (Sprint Planning): Ця церемонія відбувається на початку кожного спринту і має на меті обговорити та визначити завдання, які команда буде виконувати протягом спринту. Під час планування спринту команда обговорює, які завдання потрібно виконати, оцінює час, необхідний для їх виконання, та визначає, хто з членів команди візьметься за кожне завдання.
  • Щоденний стендап (Daily Standup): Обов’язкова частина церемонії. Це коротка щоденна зустріч команди, яка зазвичай триває до 15 хвилин. Кожен учасник команди ділиться тим, над чим він працював вчора, над чим планує працювати сьогодні та чи є в нього які-небудь перешкоди. Це сприяє вирішенню проблем швидше, визначенню прогресу та підтримує командний дух.
  • Огляд спринту (Sprint Review): Це зустріч, яка відбувається в кінці кожного спринту, під час якої команда демонструє виконану роботу за спринт. Зазвичай на огляді спринту присутні клієнти та інші зацікавлені сторони, які можуть дати зворотний зв’язок та вказати на необхідні зміни.
  • Ретроспектива спринту (Sprint Retrospective): Ця церемонія також відбувається в кінці кожного спринту і має на меті оцінити ефективність команди та визначити, які кроки можна підняти на наступному спринті. Команда обговорює, що працювало добре, що можна покращити та які кроки можна підняти для подальшого успіху.

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

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

Agile команда: ролі і артефакти

Є цікавий анекдот:

На фермі зібралися курки та свині, щоб обговорити спільну вечерю. Одна з курок запропонувала зробити яєчню з беконом. Вона сказала: “Ми, кури, зможемо дати яйця, тоді як ви, свині, можете надати бекон”. Свині подумали і відповіли: “Чекайте-но, ви тільки учасники у цьому обіді, але для нас, свиней, це ціле життя”.

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

Хоч зараз така аналогія здається дивною, але ця метафора ідеально пояснює ролі agile в іт.

Кури:

  • Розробники: Вони є основними виконавцями agile команди,  які створюють програмне забезпечення.
  • Тестувальники: Вони відповідають за перевірку та тестування програмного забезпечення на відповідність вимогам та якості.
  • Інженери з DevOps: Вони забезпечують автоматизацію та управління інфраструктурою.

Свині:

  • Продакт Овнер: Він визначає стратегію розробки продукту, встановлює пріоритети та співпрацює з командою для досягнення бізнес-цілей.
  • Scrum Master: Він координує роботу команди, вирішує перешкоди та допомагає виконати завдання.

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

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

Як впровадити церемонії Agile: покрокова інструкція

  1. Планування спринту

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

Структура:

  • Присутні: Вся команда Scrum (команда розробників, Scrum Master і Product Owner).
  • Час: На початку кожного спринту.
  • Тривалість: Одна-дві години на тиждень ітерації.

Кроки:

  1. Беклог продукту: Продакт овнер (він же власник продукту і Product Owner=PM але не плутайте з Project Manager)  приносить беклог продукту для обговорення з командою розробників. Це важливий момент, оскільки визначаються завдання, які слід виконати протягом спринту.
  2. Оцінка зусиль: Команда Scrum разом проводить оцінку зусиль або очок історії. Це допомагає розуміти, яку роботу можна виконати протягом спринту.
  3. Уточнення беклогу продукту:  Продакт овне роз’яснює будь-які сумніви щодо відставання продукту та вносить необхідні зміни до беклогу продукту.
  4. Формування беклогу спринту: Створюється беклог стринту, який містить завдання, що будуть виконуватися протягом спринту.

Результати:

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

Найкращі поради:

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

2. Щоденний Стендап

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

Структура:

  • Присутні: Команда розробки, Scrum Master, Product Owner (необов’язково).
  • Час: Щодня, зазвичай вранці.
  • Тривалість: Коротко і різко, не довше 15 хвилин.

Процес:

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

Результати:

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

Найкращі поради:

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

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

3. Огляд Спринту

Огляд спринту – це час для команди продемонструвати виконану роботу та зібрати відгуки від зацікавлених сторін. Ця церемонія важлива для зміцнення довіри між командою та зацікавленими сторонами і сприяє вдосконаленню продукту.

Структура:

  • Присутні: Команда розробки, Scrum Master, Product Owner. За бажанням, керівництво, клієнти, розробники та інші зацікавлені сторони.
  • Час: Наприкінці спринту.
  • Тривалість: Одна година на тиждень спринту.

Процес:

  1. Демонстрація роботи: Команда продемонструє виконані завдання та функціональності продукту.
  2. Збір відгуків: Зацікавлені сторони надають відгуки та рекомендації щодо виконаної роботи.
  3. Обговорення планів на майбутнє: Продакт овнер ставить запитання зацікавленим сторонам та відповідає на їх запитання.

Результати:

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

Найкращі поради:

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

4. Ретроспективний Огляд Спринту

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

Структура:

  • Присутні: Команда розробки, Scrum Master, Product Owner (необов’язково).
  • Час: Наприкінці спринту.
  • Тривалість: 45 хвилин на тиждень спринту.

Процес:

  1. Аналіз роботи: Команда обговорює, що було добре та що пішло не так протягом спринту.
  2. Визначення проблем: Спільно визначаються проблеми та недоліки, які виникли під час спринту.
  3. Розробка плану дій: Команда обговорює можливі рішення та розробляє план дій для запобігання проблем у майбутніх спринтах.

Результати:

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

Найкращі поради:

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

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

На сьогодні це все. Якщо вам цікава тема IT-cфери, ви кайфуєте від її системності і масштабу, біжіть в календар і шукайте список наших найближчих курсів.