Шаблон за дневен стендъп (който инженерите наистина използват)

Проблемът с повечето шаблони за стендъп

Повечето шаблони за стендъп са създадени за екипи, които всъщност не правят стендъп. Три въпроса на човек, петима души, 15 минути — това се превръща в планова среща, ако екипът я остави да се разрасне. Шаблонът по-долу е оптимизиран за едно нещо: да задържи стендъпа под 10 минути, като същевременно гарантира, че правилната информация излиза наяве и се записва. Въпросите са умишлено стеснени. Секциите след кръга поемат всичко останало.

Агендата (копирайте и поставете)

Продължителност: максимум 10 минути
Формат: Синхронно, всеки говори по веднъж

За всеки член на екипа (90 секунди на човек):

Свършено от последния стендъп — доставено или мерджнато, а не в процес
Планирано за днес — какво възнамерявате да приключите, а не аспирационна спринт работа
Блокиращи проблеми — назовете отговорника; „чакам ревю на дизайна“ се брои само ако някой отговаря за отблокирането

След кръга (оставащото време):

Нужни решения — всичко, което изисква решение точно сега; ако отнема повече от 2 минути, насрочете отделна среща
Съобщения — по едно изречение на точка, без обсъждане по време на стендъпа

Теми за отделно обсъждане: когато по средата на кръга изникне тема, която не засяга цялата група, запишете я и се заемете с нея после или асинхронно. Обсъждането на тези теми — обикновено между 2-3 души, а не целия екип — често е по-полезно от самия стендъп.

Какво повечето шаблони за стендъп грешат

Най-високо класираните шаблони за стендъп изпадат в два режима на провал.

Минималният скелет („Какво направи? Какво ще правиш? Блокиращи проблеми?“) работи, докато екипът не започне да третира блокиращите проблеми като нещо по избор. Никой не записва „чакам ревю на сигурността“, защото нищо не се случва, когато го направят. Зависимостите се губят и се отблокират от когото случайно се сети да попита следващата седмица.

Претрупаната версия добавя 8-12 въпроса и проверка на здравословното състояние на екипа. Това превръща стендъпа в служебно съвещание. Инженерите спират да внимават след първите двама, които говорят.

И двете версии споделят един и същ коренен проблем: те рамкират стендъпа като упражнение по отчитане. Стендъпът е упражнение по подравняване. Отчитането произвежда информация; подравняването произвежда действие. Това разграничение е важно за начина, по който ограничавате времето за въпросите, и за това какво се случва след края на кръга.

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

Защо обобщенията от стендъп се разпадат

Подходът с редуващ се протоколчик се проваля в рамките на няколко седмици. Този, чийто ред е, е претрупан, пропуска детайлите и публикува нещо мъгляво, което никой не чете. Екипът спира да се доверява на записките, после спира да ги чете, а после записките спират да служат за каквото и да било.

Асинхронните стендъпи — публикуване на актуализацията в Slack преди разговора — решават проблема с присъствието, но губят отговорността, която идва от разговора на живо. Хората все пак питат „какво решихме за X?“ по-късно през деня.

Скритата цена се натрупва бързо. За поглед върху това какво струва загубеният контекст от стендъп на екипа за едно тримесечие, вижте Данъкът на срещите.

Как Pavleur се справя с обобщението

Проведете стендъпа с тази агенда и Pavleur отворен. Когато разговорът приключи, отчетът се генерира автоматично — без протоколчик, без 5 минути разчистване след стендъпа. Обобщението улавя точките свършено/планирано/блокиращи проблеми на всеки човек, извлича взетите решения и изброява задачите с отговорниците, така както са назовани по време на срещата.

Частта, която само аудио инструментите пропускат: ако някой покаже табло с PR, дъска в Jira или графика на деплоймънт по средата на стендъпа, Pavleur го улавя и го включва в отчета с контекст. Инструменти като Otter или Fireflies ви дават думите; визуалният запис на това, което е било на екрана, не съществува. Всеки, който е пропуснал стендъпа, може да прочете пълния отчет, без да пита какво се е случило. Ако сравнявате инструменти по това измерение, страницата за сравнение покрива разликите.

Налагане на времевата рамка

Дисциплината от 90 секунди на човек се разпада най-често, когато EM започне да отговаря на въпроси по средата на кръга. Тренирайте рефлекса да казвате „ще се заемем с това после“ и го запишете в темите за отделно обсъждане.

Ако стендъпът постоянно надхвърля 10 минути, причината обикновено е една от следните: твърде много хора (разделете стендъпа), точки от агендата, които се промъкват от планирането на спринта, или повтаряща се тема за обсъждане, която се нуждае от собствена периодична среща. Отстранете структурната причина, а не просто симптома.