Безкоштовний онлайн-курс Scrum Master Fundamentals

У першій лекції ми поговоримо про те, чому у світі розробки програмного забезпечення з’явилося таке поняття як Agile.

Відповімо на питання:

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

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

Методологія Scrum приділяє дуже багато уваги команді й правильному процесу організації її роботи.

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

Короткий зміст:

• Які ролі передбачає Scrum команда?
• Які обов’язки передбачає кожна роль і як їх оптимально впровадити?
• Як перетворити нинішню команду в Scrum або створити її з нуля?
• Як зрозуміти, що ваша команда дійсно Scrum і яким характеристикам вона повинна відповідати?
• Як тримати командні ризики низькими за допомогою “числа вантажівки”?

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

На нашому вебінарі ми:

• Розповімо про те, хто відповідальний за вимоги в Scrum команді;
• Подивимося, з чого починається робота з вимогами в Scrum;
• Обговоримо, що таке User Story і навіщо використовувати саме такий формат;
• поговоримо про те, як правильно організувати вимоги і яка ієрархія використовується в гнучких підходах;
• розглянемо поняття Backlog (Беклогу), його пріоритезації та правильного управління.

Оцінка роботи – ключовий складник будь-якого процесу і методології розробки. Саме правильна оцінка дозволяє спланувати подальшу роботу над проектом або продуктом. Різноманітні методології використовують різні заходи для оцінки тривалості робіт: людино-годину, story points, розміри футболок або, навіть, фрукти. Як же правильно оцінювати? І чи є “правильно” взагалі?

На цьому вебінарі ви дізнаєтеся про те:

• чому в Agile і Scrum використовують відносну оцінку трудомісткості;
• як виглядає процес оцінки у відносних одиницях і що таке Planning poker;
• що означають поняття Velocity i Capacity;
• і яка оцінка застосовується на різних рівнях планування (реліз, спринт, день).

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

У цьому модулі ми більш детально розглянемо:

• планування в Scrum з погляду команди та Product Owner;
• використання Velocity і Capacity для планування;
• принципи планування на рівні релізу, використовуючи Minimal Marketable Product;
• різні підходи до планування релізу, основані на бюджеті, часу або обсязі робіт.

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

Ми розповімо про:

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

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

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

На цьому вебінарі ми докладно розглянемо процеси:

• Sprint review і Демо;
• ретроспективи;
• як їх проводити ефективно;
• і як переконатися, що домовленості й поліпшення, що виникають, втілюються і насправді призводять до вдосконалення.

Як і все велике, Scrum починався з чого меншого і на момент народження зазвичай використовувався в невеликих проектах для роботи над невеликими продуктами, відповідно, за допомогою невеликих команд. І, зазвичай, з часом, після того як фреймворк набув популярності, з’явилася необхідність масштабувати на великі проекти та на більшу кількість команд.
У базовому описі Scrum guide не описується, як можна ефективно використовувати Scrum на великих проектах. Тому наш вебінар покликаний розповісти, які саме елементи потрібно додати, щоб успішно працювати за наявності декількох команд.

Зокрема поговоримо про те:

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

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

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

На це складне питання ми будемо відповідати на нашому вебінарі.

А також розглянемо такі теми:

• Як змінити свій світогляд і чи потрібно це взагалі робити?
• Які плюси й мінуси “Agile mindset”?
• Як не перетворити Agile на священну корову?

У багатьох з вас, напевно, вже є досвід роботи за Scrum. Але зазвичай це не чистий “Vanilla scrum”, а “ScrumBut” – від уже класичного “ну у нас scrum, але (but) …” І далі буде перелік причин, а що ж у вас на проекті не так. Це в кращому випадку.
У гіршому – у ваших колег буде алергічна реакція на слова “Agile”, “Scrum”, “Kanban” і їхні похідні. У деяких особливо складних випадках їх вживання буде під ще більшим табу ніж ім’я “самі-знаєте-кого” з епопеї про Гаррі Поттера.
Чому ж так відбувається? Які помилки допускають і як їх уникати?
Спробуймо відповісти на ці важливі питання в рамках нашого вебінару.

Приурочивши вихід оновленої версії Scrum Guide до 25-річчя Scrum, 18 листопада 2020 року Кен Швабер і Джеф Сазерленд презентували оновлену версію Scrum Guide.

Що ж змінилося в новому документі?

По-перше, саме керівництво стало менше «нормативним». У новій версії автори спробували повернутися до редакції, де менше чітких вказівок, а сам Scrum зробити відповідним визначенням «minimally sufficient framework».

По-друге, спробували усунути конфлікт між «ми» як команда розробників і «вони», тобто РО. Зараз буде одна Scrum Team, сфокусована над єдиною метою. А до традиційних ролей SM і PO замість Development Teams додасться роль Developers (хто завгодно, хто працює над інкрементом спринту).

По-третє, вводиться концепт Product Goal. І кожен спринт тепер повинен наближати продукт до Product Goal. Так само вводяться поняття Sprint Goal і Definition of Done.

По-четверте, замість самоорганізованої команди розробників, тепер вводиться самокерована Scrum команда, яка сама вирішує хто, як і що буде робити.

По-п’яте, Sprint Planning тепер фокусується на 3-х питаннях: Що? Як? І навіщо?

Власне, ці та інші зміни в оновленій версії Scrum Guide ми з вами і обговоримо на нашому вебінарі.