Чи коли-небудь прийнятним проводити дискусії, що не стосуються чеків, на засіданнях Scrum Daily Standup?

Я сподіваюся, що люди будуть балувати мене потенційно очевидним питанням. Я працював у низці організацій, які проводять щоденні зустрічі з обговореннями. Деякі організації насправді суворо використовують лише scrum для реєстрації ("три питання" - що ви робили вчора, що ви робите сьогодні, чи є у вас блокатори?), Але деякі інші організації, які мають інші загальні умови оголошення або детальні технічні дискусії.

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

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

Цілком зрозуміло, що дискусії, не пов'язані з усією групою і не входять до "трьох питань", не повинні бути частиною stand-up. Однак, якщо є інші повідомлення, які стосуються всієї групи, і їх все одно потрібно обговорити, чи шкідливо обговорювати їх у той момент (а не на окремій зустрічі чи електронному листі)?

Завдання Щоденного скраду - команда розвитку переглянути останні 24 години та оновити свій план на наступні 24 години.

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

Щоденний Scrum не призначений - це вирішення проблем. Зроби це після ...

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

Як майстер Scrum я переконуюсь, що команда якось відповідає на три ключові питання.

Daily Scrum - це 15-хвилинна подія, яка розроблена для команди команди розробників, щоб синхронізувати діяльність та створити план на наступні 24 години.

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

Команда розвитку або члени команди часто зустрічаються відразу після Щоденного Scrum для детальних обговорень або для адаптації або перепланування решти робіт спринту.

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

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

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

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

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

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

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

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

Люди почнуть з’являтися пізно, бо вони займаються чимось «більш продуктивним». Вони навіть не з’являться взагалі кілька днів. Інші люди з’являться пізно або не всі, тому що "всі" з’являються пізно або зовсім не з'являються. Проблеми складаються один з одним, і складання перестають бути настільки ж корисними для їх первісного призначення. Це звучить крайно, але я бачив, як це відбувається. Якщо ви це зробите, будьте дуже обережні, куди це веде.

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

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

ОНОВЛЕННЯ: Я мушу уточнити: 15 хвилин - це НАЙВАЛЬНИЙ час, який ви повинні враховувати з будь-яким режимом роботи - ефективний запуск за наведеним нижче правилом зазвичай ніколи не перевищує 5 хв. Знову-таки, більшість дискусій, які ви вважаєте за потрібні, легко обговорюються між членами команди поза простою процедурою щоденної реєстрації, яка передбачається, що штаб-квартира має бути в найбільш чистому вигляді.

Правило великого пальця, яке я дотримувався і розбудовував під час проектів з друзями і відточував у професійній обстановці:

• Вчора

Що ви робили вчора індивідуально для просування проекту і, якщо це доречно, це вплинуло на когось іншого.

• Сьогодні

Як вище, але сьогодні

• Блокатори

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

Все інше - це відволікання. Це може означати тему, що "може" здатися, що вони стосуються прогресу проекту насправді немає. Він досить суворий, але ДУЖЕ ефективний для цілей XP.

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

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

Уникайте наступного:

1. Занадто довгі зустрічі.
2. Занадто багато людей воліють отримувати оголошення в іншому місці. Робити це під час запланованої зустрічі спокусливо, але не зловживайте цим. Більшість людей ненавидять зустрічі із забороною.
3. Інформація не стосується всіх. Декілька винятків - це добре.
4. Кожна зустріч має анонси за звичкою замість потреби. Будь професією.

Приймайте освічені та обґрунтовані рішення та не ховайтесь за надмірним застосуванням чи прийняттям правил занадто буквально.

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