Embedded Files
План уроку:
Product Backlog
Planning
Estimation
Сторі Поінт (Story Point)
Покер планування (Poker planning)
Командна практика
Scrum схема на рівні команди
Робота з вимогами у SCRUM
Приклад вимог
Product Owner:
володіє розумінням доменної області та діяльності бізнесу;
орієнтує розробку продукту відповідно до бізнес цілей і потреб кінцевих користувачів;
пріоритезує вимоги залежно від розвитку ринку та бізнесу;
приймає рішення щодо змін у вимогах.
Business Analyst:
Proxy Product Owner;
говорить не лише «мовою бізнесу», а й «мовою команди»;
деталізує та декомпозує функціональні вимоги;
формує User Stories;
презентує скоуп вимог для команди на Grooming зустрічах.
Структура вимог
User Story
User Story – це опис маленького шматочка функціональності, який несе цінність для кінцевого користувача продукту.
User Story
Як «Користувацька Роль»: ...
Я хочу «Активність»: ...
Щоб «Бізнес цінність»: ...
User Story - INVEST
User Stories (приклад)
Планування у SCRUM
Планування Релізу в SCRUM
Планування дня в SCRUM
Agile Estimation
Agile Estimation
Оцінює група
Відносні одиниці
Може зайняти більше часу, ніж водоспадна, оскільки вимагає досягнення консенсусу
Фокус планування на найближчі активності (Rolling wave planning)
Як складати оцінку задачі
1. Врахувати всю роботу, яка знадобиться dev, test, DevOps.
2. Час на код рев'ю та мердж.
3. Час на деплой.
4. Час на оновлення документації та бази знань (knowledge base).
5. Комплексність задачі.
6. Наскільки команда знайома з технологією, чи будуть питання із цим.
7. Чи є залежності на інші команди, чи є сторонні інтеграції.
8. Основні ризики, які можуть виникнути.
Agile Estimation – Planning pocker
Типові помилки оцінювання story points:
1. Сторі поінти не треба зводити тільки до складності, невизначеності чи обсягу роботи.
2. Сторіни поінти не треба переводити в години.
3. Варто уникати усереднених значень (наприклад, коли половина команди оцінює елемент на 3 сторі
поінти, а інша половина - на 5). Якщо виникає дискусія, краще прийняти більший показник.
4. Ніколи не змінюйте оцінку під час спринту, навіть якщо вона виявилася некоректною.
5. Не забувайте оцінювати баги.
6. Не підлаштовуйте оцінку в сторі поінтах під окремого розробника.
7. Якщо змінюється склад команди, потрібно налаштувати оцінки заново.
8. Не підлаштовуйтесь під оцінку найдосвідченішого спеціаліста на нараді.
Q&A
Дякую всім за заняття!🙌🏻
❗️🎓Тема уроку: 4. Scrum планування та естимації
Нагадую, що дедлайн здачі домашніх робіт – до наступного уроку.
Якщо виникають складнощі, пишіть, допоможу із задоволенням 😌
Запис лекції тренер опублікує трохи пізніше 🖥
Не забудьте повторити матеріал та підготуватися до наступного уроку📚
Успіху і до зустрічі!🤩
Практика
Практика
Page updated
Google Sites
Report abuse