1. Що таке Agile і Scrum? Що таке Agile?
2. Що таке Scrum?
3. Артефакти в Scrum
4. Product backlog:
5. Sprint backlog:
6. Sprint Goal
7. Sprint Burndown Chart
8. Ролі в Scrum
9. Роль Product Owner
10. Роль Scrum Master
11. Team (команда проекту)
12. Ритуали (процеси в Scrum)
13. Sprint Planning Meeting (зустріч з планування спринту)
14. Daily Meeting (щоденна зустріч команди).
15. Sprint Review - здача спринту Product Owner
16. Retrospective
17. Чому з'явився Agile?

Що таке Agile і Scrum?

Що таке Agile?

У перекладі з англійської мови «agile» означає «живий, рухливий», але переводять його частіше як «гнучкий». В галузі розробки програмного забезпечення цей термін з'явився на початку 2000-х років, коли в штаті Юта був виданий « Маніфест гнучкої розробки ПО ». З тих пір під «agile» розуміють набір підходів по "гнучкою" розробці програмного забезпечення.

Agile Manifest

Суть agile-підходу викладена в "маніфесті", але для замовника її можна коротко сформулювати так:

• розробка ведеться короткими циклами (ітераціями), тривалістю 1-4 тижні;
• в кінці кожної ітерації замовник отримує цінне для нього додаток (або його частина), яке можна використовувати в бізнесі;
• команда розробки співпрацює з Замовником в ході всього проекту;
• зміни в проекті вітаються і швидко включаються в роботу.

В даний час agile-принципи використовуються в роботі десятки тисяч команд по всьому світу.

Основоположні принципи Agile .

Коротке відео про те, що таке Scrum (english).

Що таке Scrum?

Scrum - це одна з кількох методологій гнучкої розробки ПО:

• • Scrum
  • Lean
  • Feature Driving Development
  • Extreme Programming

Scrum процес на одному аркуші

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

Артефакти в Scrum

У скрам використовується всього чотири артефакту:

• Product Backlog
• Sprint Backlog
• Sprint Goal
• Sprint Burndown Chart.

Я рекомендую вам відвідати наш тренінг " Scrum для проектних команд ". Тренінг допомагає вивчити Scrum-процес від початку і до останніх нюансів.

Product backlog:

• Це список усіх вимог, які потрібно зробити за проектом. Коли в Backlog'e немає вимог, проект вважається завершеним.
• Всі вимоги описані за єдиним шаблоном, який називають User Story (призначена для користувача історія).
• Вимоги складені так, що очевидно і зрозуміло, яку цінність вони представляють для користувача
• Вимоги відсортовані за пріоритетами, які переглядаються кожен спринт.

На знімку нижче представлений Backlog проекту. Команда проекту вибрала 2 вимоги в Sprint # 3.

Project Backlog (JIRA)

Sprint backlog:

• Це список усіх вимог, які потрібно зробити в найближчий спринт.
• Протягом спринту, нові вимоги не можуть з'явиться в Sprint backlog.
• Всі вимоги повинні бути розділені на завдання і оцінені.

Sprint Backlog - це зобов'язання команди: що вони повинні виконати за найближчі 2 тижні. Кожна вимога розділене на завдання, які представлені на Kanban-дошці.

Kanban Дошка в спринті

Sprint Goal

• це короткий опис того, заради чого виконується даний спринт.
• мета на спринт допомагає команді приймати обґрунтовані рішення.

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

Sprint Burndown Chart

• дослівно "діаграма згоряння"
• в якості "згорають" елементів виступають людино-години або ідеальні одиниці (Story Points).
• діаграма оновлюється кожного разу, коли завершується якась завдання.

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

Burndown діаграма в Jira

Якщо є час, подивіться мою запис про книгах , Які можна скачати для вивчення Agile / Scrum.

Ролі в Scrum

У скрам використовується всього три ролі:

• Product Owner
• Scrum Master
• Team.

Роль Product Owner

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

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

• мати особисту залученість в проект і його результати;
• добре володіти навичками написання вимог.

У деяких випадках допустимо призначити більше однієї людини на роль Product Owner. Але в цьому випадку необхідно призначити серед них "головного", який буде авторизувати вимоги в Bcaklog'e і особисто розставляти пріоритети.

Роль Scrum Master

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

Дуже складна роль. У класичному project management є Керівник проекту. У Scrum така роль не передбачена. Кращим синонімом ролі Scrum Master буде "адміністратор". Скрам Майстер організовує роботу команди проекту, але не втручається в її роботу.

• Скрам майстер не призначає людей на завдання - це робить сама команда;
• Майстер не змушує людей робити роботу - це відповідальність команди;
• Майстер не вказує Product Owner які вимоги він повинен написати - це робота власника продукту.

Проте, якщо скрам-процес проходить з порушеннями (хто-небудь з команди спізнюється на daily-meeting), то майстер повинен втрутитися і виправити ситуацію.

Функції Scrum Master'a істотно ширше, але щоб пояснити їх все потрібна окрема стаття. Пишіть в коментарях, якщо така потрібна.

Team (команда проекту)

• крос-функціональна
• взаємозамінна
• самоорганізована
• з фіксованим складом (в ході спринту)
• 4-10 чоловік.

Команда відповідає за розробку продукту ітераціями (спринт). Команда визначає самостійно:

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

Команда НЕ приймає рішень:

• які вимоги є пріоритетними - це робить Product Owner.

На знімку нижче команда проекту проводить обов'язковий "ритуал" - Daily Meeting (див. Нижче).

Команда проводить "ритуал" Daily Meeting

Для компаній, які вирішили системно перейти на методологію Scrum, я рекомендую ознайомитися зі структурою проекту впровадження і рекомендаціями замовнику.

Ритуали (процеси в Scrum)

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

Ритуали в скрам це:

• Sprint Planning Meeting
• Daily Meeting
• Sprint Review
• Retrospective

Sprint Planning Meeting (зустріч з планування спринту)

• виконується всією командою перед початком спринту
• команда вибирає вимоги з Product Backlog і формує Sprint Backlog
• якщо потрібно врахувати взаємозв'язки між операціями, то це робиться тут
• команда декомпозіруется вимоги на завдання (tasks)
• кожна задача проходить оцінку в трудовитратах або універсальних одиницях
• під час зустрічі Product Owner відповідає на питання команди.

Зустріч, яка проводиться перед початком кожного спринту. Структура зустрічі:

• уявлення і пояснення Product Owner'ом списку вимог
• питання з боку команди
• / Рекомендується перерву /
• декомпозиція вимог на завдання (tasks)
• оцінка задач за методом Planning Poker.

Зустріч проста по суті, але вкрай складна за змістом. На початку проекту може займати 5-6 годин. І тільки після 3-4 спринту зустріч стає більш оперативною та триває 2-3 години. Тримайтеся.

Daily Meeting (щоденна зустріч команди).

З назви зрозуміло, що зустріч проводиться щодня. Основні принципи:

• проходить щодня і тільки в один і той же час;
• зустріч проходить тільки стоячи;
• тому тривалість зустрічі не більше 15 хвилин;
• щоб встигнути кожен повинен відповісти за все на 3 питання: що я робив вчора, чим я займаюся сьогодні, які є проблеми?

Scrum Master стежить за ходом зустрічі, спонукає учасників висловлюватися повністю і слухати мовця.

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

Зустріч команди ефективно проводити навпаки Kanban дошки, на якій відображені всі завдання спринту.

Kanban Board під час спринту

Sprint Review - здача спринту Product Owner

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

Цінність Scrum для звичайного замовника багато в чому полягає в тому, що результат робіт (поганий або хороший, не важливо) буде продемонстрований в будь-якому випадку. Це знає і команда і Product Owner і інші зацікавлені особи. Якщо команда не проводить демонстрацію (інша назва Sprint Review), то це дискредитує всі переваги гнучких процесів.

Структура зустрічі:

• команда зачитує вимоги з Sprint Backlog
• за кожним критерієм приймання відбувається демонстрація отриманих результатів
• кожне питання з боку Product Owner'а записується, щоб мати можливість відповісти на них пізніше
• кожне нове вимога Product Owner'a виписується, щоб пізніше включити його в Product Backlog.

На зустрічі можуть бути присутніми будь-які співробітники організації або просто зацікавлені особи. Важливо, щоб право голосу мали тільки учасники Scrum процесу (Produt Owner, Team, Scrum Master).

Ніяких презентацій в PowerPoint на зустрічі, якщо ви правильно мене зрозуміли!

Retrospective

Ритуал, який спрямований на обмін досвідом всередині команди. Зустріч проводиться після Sprint Review. На зустрічі присутній вся команда і Scrum Master. На зустрічі може бути присутнім Produt Owner, якщо вважає за потрібне.

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

• які рішення повинна прийняти команда, щоб зробити процес більш передбачуваним?
• які проблеми заважають команді виконувати взяті на себе зобов'язання?
• як поліпшити взаємодію з Product Owner'ом?
• які помилки робить команда і чому.

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

Чому з'явився Agile?

Тепер трохи слів про те, як і навіщо з'явився цей підхід? Історія виникнення цього підходу стала відповіддю на запити галузі:

1. Замовник не може сформувати чіткі вимоги до ПЗ;
2. Нові технології посилили конкуренцію і зажадали оперативного застосування в бізнесі;
3. Замовники і розробники ПЗ не задоволені процесом взаємодії.

# 1 Замовник не може сформувати чіткі вимоги до ПО

У початковій фазі проекту замовник не може сформулювати вичерпні вимоги до продукту. Цьому є кілька причин:

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

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

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

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

# 2 Нові технології посилили конкуренцію і зажадали оперативного застосування в бізнесі

До середини 90-х розробляється ПЗ було в основному десктопних і його потрібно встановлювати на кожен окремий комп'ютер (наприклад, MS Word). З появою веб-додатків впровадження нової функціональності стало відбуватися швидше: потрібно розгорнути додаток тільки на сервері і всі користувачі отримували доступ до нього. Ця інновація серйозно посилила конкуренцію між компаніями: той, хто застосував нову технологію раніше інших - виграє ринок і клієнтів.

Підхід Agile надав бізнесу головна перевага - швидкі поставки нової функціональності. Це дозволило щомісяця випускати продукт і оперативно отримувати зворотний зв'язок від користувачів.

# 3 Замовники і розробники не задоволені процесом взаємодії

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

Основна ідея agile - співпраця з замовником важливіше, ніж контрактні зобов'язання. І тому agile-методи прагнуть до зменшення обсягу документації. Це дозволяє Замовнику платити тільки за результат, який має цінність для бізнесу.

При цьому agile не відмовляється від формулювання вимог. Замовник (в agile - власник продукту, product owner) висуває вимоги в спрощеному вигляді і на сценаріях роботи користувачів.

резюме

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

Велике спасибі, що знайшли час написати відгук!

• Зміст статті

• актуальність інформації

• Зміст статті

• актуальність інформації

Дуже пізнавально

• Зміст статті

• актуальність інформації

Зрозуміло, є, ємко, спасибі.

• Зміст статті

• актуальність інформації

Спасибі! Все викладено в доступній формі!

• Зміст статті

• актуальність інформації

Дуже змістовно і послідовно!

• Зміст статті

• актуальність інформації

Thanks a lot for your article! It was very helpful to me.

• Зміст статті

• актуальність інформації

• Зміст статті

• актуальність інформації

• Зміст статті

• актуальність інформації

• Зміст статті

• актуальність інформації

Дуже інформативно і структуровано!

• Зміст статті

• актуальність інформації