Яка мета рецензування та його тривалість у спритних методологіях? [зачинено]

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

Чи помиляюсь я так себе почуваю? Це, як зазвичай проводяться етапи?

Для Scrum Кен Швабер та Джефф Сазерленд пояснюють :

Щодня Scrum

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

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

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

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

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

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

Майстер Scrum застосовує правило, що в щоденній Scrum беруть участь лише члени Команди розвитку.

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

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

TL; DR

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

Мета stand-up

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

Важливо, щоб майстер Scrum та власник продукту були активними учасниками стенд-ап, але якщо команда звітує перед будь-яким із них, то ваш процес Scrum може бути справді зламаним. Відповідна відповідь на Project Management Stack Exchange містить 10-бальний список "проектних запахів" внизу, деякі з яких можуть застосовуватися у вашому випадку. Навіть якщо вони не застосовуються, ви обов'язково повинні переоцінити ефективність своїх протистоянь на наступній ретроспективі спринту.

Поважайте тайм-бокс

У той час як я не люблю «три питання» в якості формату конкретного саме тому , що вони , як правило, призводять до зустрічей , які нагадують тягнути стану, я б упущення , якби я не зробив пункт до канонічного опису Майка Кона з Daily Scrum . На сторінці написано частково:

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

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

Щодня проводити зустрічі з резервним станом суворо, до 15 хвилин. Це робить дискусію швидкою, але актуальною.

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

Те, що ви описуєте, - це один із способів, коли «протистояння» може провалитися для команди.

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

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

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

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

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

Як і у всіх процесах Agile, ця мета полягає в тому, щоб "ви отримуєте цінність".

Щоденне складання типово є механізмом забезпечення спілкування між членами команди слабким чином, коли кожен може зрозуміти, де знаходиться команда стосовно поточного набору завдань. Тож 5-хвилинний запуск, де всі кажуть: "Я робив х вчора і збираюся робити сьогодні", це добре, як і 15 хвилин, коли команда вирішує між собою, над чим працювати далі, і оновлює дошку завдань.

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

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

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