Меню

Події Scrum: бокс у часі, планування спринту, щоденна відмова та уточнення відставання

  • Головна
  • Інший
  • Події Scrum: бокс у часі, планування спринту, щоденна відмова та уточнення відставання

scrum events time boxing

Спробуйте Наш Інструмент Для Усунення Проблем

Вступ до Scrum Events:

У наших попередніх уроках ми обговорювали Scrum та його структуру.

І наш попередній підручник пояснив усе про Артефакти Scrum детально.

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

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

сутички

Що ви дізнаєтесь:

Огляд

Працюючи над проектом, заснованим на Scrum, команда Scrum проходить низку Церемоній Scrum.

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

Типи Scrum-подій

Типи подій Scrum

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

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

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

Що таке тайм-бокс?

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

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

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

Як ми визначаємо часову шкалу для кожної події Scrum?

Часовий інтервал для Scrum Events прямо пропорційний довжині Спринту. Однак єдиним винятком з цього правила є Daily Standup, який має фіксований часовий інтервал 15 хвилин незалежно від тривалості спринту.

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

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

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

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

Власник продукту може звернутися за допомогою до зацікавлених сторін, замовника, дизайнера та Scrum Master, щоб розробити відставання товару.

Обов’язковим є наявність критеріїв прийнятності в історії користувача. Команда уповноважена відхилити історію користувача без критеріїв прийнятності.

Призначення

Планування спринту - це початкова церемонія під час запуску спринту. Метою зустрічі з планування Sprint є створення цілі Sprint, вибір історій користувачів із Backlog Product до Backlog Backlog та детальне їх обговорення.

Команда збирається у залі засідань разом із Власником продукту та Scrum Master, де Власник продукту представляє історії користувачів, які слід вибрати для наступного спринту.

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

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

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

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

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

Багато команд використовують картки Planning Poker для оцінки історії. Найбільш поширеною методикою оцінки є вказівка ​​на історію за допомогою серії Фібоначчі. Ряд Фібоначчі - це ряд чисел, де кожне наступне число в ряді складається шляхом складання попередніх двох чисел.

Серія Фібоначчі - 1, 1, 2, 3, 5, 8, 13 тощо.

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

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

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

Зустріч із планування спринту

Окрім історій користувачів, можуть бути деякі інші типи предметів, які можуть стати частиною відставання Sprint.

  • Шипи
  • Технічні борги
  • Помилки

Шипи - це дослідницькі завдання для пошуку рішення, тобто потреба в яких викликається самою Історією користувача. Деякі історії можуть бути непростими або не відповідати технічним можливостям, а отже, потребуватимуть додаткового аналізу та досліджень навколо них. Тому створюється шип. Він також може включати POC, якщо виникає необхідність.

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

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

Присутні

Усі учасники Scrum Team є частиною наради з планування спринту. Ніхто інший, крім основної команди, не запрошений взяти участь у засіданні.

Зустріч із планування спринту організовує та сприяє Scrum Master, але власник продукту викрадає шоу.

Таймбокс

Зустріч із планування спринту може тривати півдня на два тижні спринту. Час для зустрічі з планування спринту безпосередньо залежить від тривалості спринту. Коротший для короткого спринту та довший для тривалого спринту.

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

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

Щоденний стендап

Призначення

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

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

Щоденний стендап

Під час щоденної зустрічі в режимі стенда кожен член команди за столом відповідає одне за одним на три ключові запитання:

'Що ви зробили з моменту останньої щоденної зустрічі зі стендапу?'

'Що ти плануєш робити сьогодні?'

як відкрити новий проект в eclipse - -

'Чи є якісь перешкоди для блокування вашої роботи?'

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

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

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

Присутні

Будь-який бажаючий може взяти участь у щоденній зустрічі Standup. Однак основна команда повинна бути присутнім на засіданні та представити статус своєї роботи.

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

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

Щоденне засідання Standup слід проводити, навіть якщо присутній один член команди.

Команда може проводити щоденну зустріч зі стендапом самостійно або може попросити Scrum Master допомогти їм.

Таймбокс

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

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

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

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

вхідні вихідні файли c ++

Огляд спринту

Призначення

Sprint Review Meeting - це все для демонстрації виконаної роботи та збору відгуків та бай-іну. Подекуди засідання Sprint Review також відоме як Sprint Demo. Зустріч із огляду спринту зазвичай проводиться в кінці спринту, але до ретроспективної зустрічі спринту.

Обраний представник (и) з команди демонструє поточні завдання у спринті. Зазвичай розробник, який працює над історією користувача, демонструє роботу та відповідає на запитання, задані будь-ким із аудиторії.

Історії користувачів, які зроблені на основі Визначення Готового, є єдиними кандидатами для демонстрації на оглядовій зустрічі Спринту.

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

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

Ключовим результатом засідання Sprint Review є загальна картина дати завершення проекту. Власник продукту приймає / відхиляє історію, а прийняті історії потім інтегруються з Інкрементом (створеним під час попередніх спринтів) в цілому, щоб отримати кращу картину щодо того, де ми стоїмо у виконанні всього продукту.

Ще одним ключовим результатом наради Sprint Review є те, що члени команди дізнаються щось про оцінку. Кількість прийнятих історій користувачів визначає кількість очок історії, досягнутих у спринті.

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

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

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

Зустріч з огляду спринту

Присутні

На засіданні Sprint Review беруть участь члени команди, включаючи Scrum Master та Власника продукту. Іншими учасниками зустрічі Sprint Review є зацікавлені сторони, менеджери з доставки, клієнти / кінцеві користувачі або всі, хто зацікавлений у тому, щоб бути учасником Sprint Review.

Таймбокс

За ідеального сценарію для двотижневого спринту ми проводимо приблизно 2 години на зустрічі Sprint Review. Це може відрізнятися залежно від довжини Спринту. Для коротшого спринту коротший Sprint Review та для більш тривалого спринту - довший Sprint Review.

Як і інші зустрічі, Scrum Master відповідає за збереження темпу зустрічі та переконання, що діяльність (демонстрація історій, відповідь на запити, прийняття історій, відмітки тощо) відповідає встановленому часу.

Ретроспектива Спринту

Призначення

Ретроспектива Sprint полягає у втіленні того, що каже Agile - ' Регулярні роздуми про те, як стати ефективнішими '. Ретроспектива спринту дає можливість всій команді поміркувати і подумати про те, як пройшов спринт і що потрібно зробити, щоб імпровізувати процеси? Ретроспектива спринту проводиться в кінці кожного спринту.

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

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

Всім в команда очікує відповіді на чотири основних питання:

Ретроспектива Спринту

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

Що пройшло добре?

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

Що ви дізналися?

Scrum розглядається як можливість навчитися чомусь новому в кожному спринті. Ця область квадранта має обговорити ключові висновки та висновки з останнього Спринту.

Що не вдалося?

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

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

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

Що можна зробити краще?

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

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

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

Присутні

Вся команда Scrum, включаючи майстра Scrum та власника продукту. Але на відміну від щоденної стендап-зустрічі, Scrum Master і Продукт також беруть участь у наданні своїх матеріалів та ретроспективних моментів.

Як і щоденні стендап-зустрічі, ретроспективним засіданням Sprint також сприяє Scrum Master. Scrum Master подбає про те, щоб кожен у команді, включаючи його самого, мав можливість відкритися та висловити як позитивні, так і негативні моменти.

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

Таймбокс

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

Однак, якщо ми розглядаємо Sprint Retrospective як можливість спілкування, ретроспекції та прихильності вдосконаленням, дуже виправдано приділити достатньо часу для зустрічі, щоб не втратити важливі точки зору та розуміння.

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

Уточнення відставання

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

Загальна ідея полягає в тому, щоб підготувати відставання товару до майбутнього Sprint та переконатися, що історії користувачів готові до вибору. Зустріч з питань відставання організовується під час спринту «n-1», щоб підготуватися до вибору предметів у спринті «n».

Висновок

Цим ми підійшли до кінця цього підручника з „Події Scrum”, який потрібно прочитати. Події Scrum - безумовно найважливіша і найважливіша тема серії Scrum.

У цьому посібнику ми обговорили всі п’ять подій Scrum, тобто Спринт, Планування спринту, Щоденний стенд, огляд спринту та ретроспектива спринту . Кожна подія, крім щоденного стенду, має регулярний цикл на спринт, тобто виконується один раз у кожному спринті.

Події дають уявлення про те, як завдання виконуються в середовищі Scrum. Усі події Scrum - це можливості для вдосконалення, адаптації та перевірки.

Далі йде навчальний посібник з “Випробування дефектів”, який є офіційною зустріччю, де обговорюються та аналізуються всі дефекти поточного Спринту, тобто пріоритети.

НАЗАД Підручник | НАСТУПНИЙ підручник

Рекомендована література

^