Що відбувається між спринтами?

Я працюю над проектом вільно за моделлю scrum. Ми робимо два тижні спринти. Щось мені не зрозуміло (і у мене немає книги для консультацій) - це саме те, що повинно відбуватися між спринтами: має бути якийсь процес "обгортання", коли продукт буде створений і поставлений, але:

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

Є три розробники, які складають близько 1 FTE. Тож спринти справді дуже короткі.

Я працюю над проектом вільно за моделлю scrum.

Щоб було зрозуміло: ваші менеджери, ймовірно, розповідали вам про Scrum, але те, що ви виконуєте, - це не Scrum.

Скільки часу це займає?

Спринт-огляд зустрічі + спринтерська ретроспективна зустріч завершує поточний спринт. У коротких спринтах вони повинні займати щось від 30 хвилин до 1 години разом. Наступного робочого дня розпочинається новий спринт, виконуючи зустрічі планування спринтів 1 і 2. Виходячи з розміру команди та тривалості спринту, ця зустріч може зайняти 2 - 4 години.

Чи повинна брати участь вся команда?

Вся команда повинна брати участь у зустрічах, зазначених у попередній відповіді.

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

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

Це коли відбувається перегляд та тестування коду?

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

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

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

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

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

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

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

... а коли оцінка? планування?

Історії повинні бути дійсно легкими, щоб не було часу між спринтами.

І я не знаю, про який тест ви говорите, але розробники зроблять тест на одиниці та інтеграцію, не більше того.

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