Плутати з приводу зміни відставання спринту під час спринту

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

Однак я читаю Scrum і XP з траншей, і там описано розділ для незапланованих елементів на панелі завдань. Тоді я подивився на Керівництво по Scrum, в якому сказано, що під час спринту "Не вноситься жодних змін, які впливали б на ціль спринту" та в обговоренні цілі спринту "Якщо робота виявиться іншою, ніж очікувала команда розвитку, то вони співпрацюють із Власником продукту для того, щоб домовитись про сферу Блоку спринту в рамках спринту ". Продовжує говорити в обговоренні Блоку спринту:

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

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

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

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

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

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

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

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

1. Додайте новий елемент до спринту.
   АЛЕ видаліть із спринту еквівалентний розмір предмет.
2. Викиньте предмет, який був погано запланований, з цього спринту (так що ви зможете належним чином спланувати його в наступному спринті).
   • Додавання альтернативи (відповідного розміру) у верхній частині бродіння продукту (що повинно бути в черговому порядку з вашої зустрічі з планування спринту).
   • Або коли всі елементи спринту закінчені, дозволяють розробникам збирати слабкі з-за відставання продукту.

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

Тоді на наступній плановій нараді нове завдання буде відповідним чином проаналізовано та додано до спринту (у відповідних випадках).

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

Плутанина пояснюється неоднозначною мовою.

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

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

Отже, це ОБЕРЕГО перелік предметів, що відносяться до продукту, і план (завдання) для їх доставки.

Зараз багато команд люблять додавати всі запропоновані завдання (план) на початку Спринту, щоб вони могли відслідковувати діаграму витримки на основі годин, що залишилися до цього. Інші команди дозволяють виконувати завдання, як потрібно. ЦЕ коли це нормально додати до «Блоку спринту», оскільки команда повинна це зробити для того, щоб перевірити та адаптуватись для доставки Елементів та досягнення цілі спринту.

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

Отже, там у нас є; ТАК ... команди додають завдання до плану сприйняття "Спринту" за потребою. НІ, вони зазвичай не додають до списку предметів відставання, що визначають сферу спринту.

Я сподіваюся, що це прояснює ситуацію.

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

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

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

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

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

Ідея: надайте керівництву 3 перемикачі-кредити, щоб витратити кожен квартал як компроміс.