Якщо в Scrum standup слід обговорювати те, що було зроблено вчора, обмеженням завдань на дошці або всієї виконаної роботи?

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

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

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

Відповідно до вмісту Посібника з Scrum щодо щоденних резервів, три питання для обговорення:

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

Усі питання зосереджуються на цілі спринту, а не на завданнях на дошці. Знову ж таки, згідно з посібником Scrum, ціль спринту створюється в плануванні спринту, і вона визначає "мету, яка буде досягнута в спринті за допомогою впровадження" Блокування продукту ", і вона дає керівництву розробникам питання, чому він будує Приріст ».

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

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

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

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

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

Ні, вам слід поговорити про те, що ви робили вчора.

Якщо його немає на дошці, вам потрібно зробити одне з наступних дій:

• покласти його на дошку,
• перестати це робити
• або змінити команди.

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

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

Ще одна дратівлива річ у спринтах - "Прем'єр-міністр говорить про зустрічі для інших проектів". На мою думку, прем'єр-міністр не є членом команди scrum, вони заповнюють роль Scrum «Власник продукту» і, таким чином, відповідають на запитання, а не повідомляють про хід.