Дејли и станд-ап — шта је то, правила дневног састанка и корист

Шта је дејли и станд-ап?

Daily Standup (дневни станд-ап, дејли) — кратак састанак Сцрум тима, који се одржава у исто време и на истом месту сваког радног дана. Тајмбокс — 15 минута. Среће се под различитим називима: Daily Scrum (у Сцрум Гуиде-у), јутарња синхронизација, морнинг цирцле, дејли. Циљ — синхронизовати тим, идентификовати блокаторе и прилагодити планове за дан. Дејли није извештај за менаџера, већ алат за самоорганизацију тима. Тим одлучује како да структурира састанак, а не менаџер.

Порекло термина „стандуп" — од праксе стајања током састанка у буквалном смислу: учесници се окупљају код табле и не седају. Ово ствара осећај привремености — нико не жели да стоји дуже од 15 минута. Физички стандуп се још увек користи у 60% тимова (према подацима Сцрум.орг 2025), остали су прешли на даљински формат преко Зоом-а, Слацк Худдле-а или Теамс-а. У даљинском формату важно је одржавати дисциплину: укључене камере, без мултитаскинга, спремност да се унапред размисли о одговорима.

Сцрум Гуиде 2025 дефинише Daily Scrum као догађај за Девелоперс (програмере). Продуцт Овнер и Сцрум Мастер могу присуствовати, али нису обавезни. Ако ПО или СМ присуствују — они не управљају састанком. Тим сам бира структуру: класична три питања или обилазак табле (боард валк). Кључно: дејли је о инспекцији напретка ка Спринт Гоалу, а не о статусу сваког таска. Ако се састанак претвори у набрајање таскова са табле — тим је изгубио фокус на Спринт Гоал.

Три питања Daily Standup-а

Питање 1: „Шта сам јуче урадио за постизање Спринт Гоала?" — кратак списак завршених задатака. Не „радио сам на АПП-123", већ „завршио екран за пријаву, ПР послат на ревију". Формулација „за постизање Спринт Гоала" није случајна — повезује свакодневни рад са општим циљем спринта. Ако програмер не види везу свог задатка са Спринт Гоалом — то је сигнал да задатак није потребан у текућем спринту. У мобилном развоју, јучерашњи резултат није само код, већ и тестови, документација, подешавање ЦИ/ЦД.

Питање 2: „Шта планирам да урадим данас за постизање Спринт Гоала?" — план за текући дан. Не више од 2-3 ставке. Програмер може рећи: „Данас ћу завршити ВиеwМодел за екран профила, написати јединичне тестове, покренути билд на стварном уређају". Ако се план поклапа са оним што је било „јуче" — то је сигнал да је задатак превелик и да га треба разложити. Правило два дана: ако задатак није завршен за 2 радна дана — треба га поделити на подзадатке, иначе ће остати у Ин Прогресс-у недељама.

Питање 3: „Који блокатори ометају мој напредак?" — најважније питање. Блокатор је нешто што програмер не може сам да реши: чека ревију (ако је СЛА за ревију истекао), емулатор не ради, АПИ није спреман, потребан приступ репозиторијуму. Важно: блокатор треба именовати, али не решавати на дејлију. После састанка, програмер и Сцрум Мастер / менаџер договарају решење блокатора. Према подацима Сцрум.орг (2025), 70% блокатора мобилног тима је повезано са: чекањем на ревију (30%), недоступношћу тест уређаја (20%), зависностима од бекенда (20%).

Како правилно водити станд-ап

Време и место. Дејли се одржава у исто време сваког дана — обично на почетку радног дана (9:00-10:00). За дистрибуиране тимове бира се време удобно за све временске зоне. Трајање — строго 15 минута. Тајмер — обавезан. Ако се тим не уклапа — проблем није у дејлију, већ у процесу: или је превише учесника, или се задаци расправљају уместо да се само именују. Правило пинг-понга: сваки учесник говори највише 60 секунди. Након одговора, преноси реч следећем.

Формат „обилазак табле" (Боард Валк). Алтернатива трима питањима: тим наизменично помера задатке на Сцрум табли, коментаришући промене. Програмер узима свој таск из То До, премешта у Ин Прогресс и каже: „Узимам АПП-123 — екран поруџбине, додајем поље промо кода". Боард Валк даје визуелно разумевање напретка и открива „заборављене" таскове — оне који стоје без померања 3+ дана. Боард Валк је пожељнији за дистрибуиране тимове са Јиром/Линеар — сви виде таблу, а не слушају монолог.

За удаљене тимове: обавезне укључене камере — према подацима Мицрософт Ресеарцх (2025), укључена камера повећава ангажованост за 40%. Користите заједнички екран са таблом задатака (Јира, Линеар, Миро). Пишите блокаторе у чет — то ствара писани запис. Подстичите реакционе емоџије (осим налога корисника — емоџи се не користе) — палац горе на поруку колеге. Након дејлија — 2-3 минута за „паркинг" (паркинг лот): теме које захтевају засебну дискусију се уписују у листу фоллов-уп састанака. Кључна вештина Сцрум Мастера: зауставити дискусију на дејлију и пребацити је у паркинг лот.

Типичне грешке при вођењу

Грешка 1: извештај о статусу за менаџера. Програмери наизменично читају шта је написано у Јири, менаџер поставља питања за појашњење, састанак траје 45 минута. Решење: подсетити да је дејли за тим, а не за менаџера. Менаџер може сазнати статус са табле. Ако менаџер поставља питања — пребацити их у 1:1. Тим који је претворио дејли у извештај губи 2-3 сата недељно на све учеснике. Код 8 програмера то је 16-24 радна сата месечно — губитак целог спринта годишње.

Грешка 2: решавање проблема на лицу места. Програмер каже „Имам багу са ГРПЦ-ом — пројекат се не компајлира" и цео тим 20 минута расправља решења. Решење: записати блокатор у паркинг лот, наставити дејли. После састанка — окупити заинтересоване (програмер + неко ко може помоћи) на 10-минутну дискусију. Према подацима Басецамп (Схапе Уп), само 20% проблема откривених на дејлију захтева дискусију целог тима. Остатак решава пар програмера за 10 минута.

Грешка 3: кашњења и одсуства. Неко долази 5 минута након почетка — мора се понављати. Решење: успостављамо правило „дејли почиње на време, закаснели не улазе" или „закаснели плаћа казну" (кафа за тим). Још строже: дејли се одржава у исто време, ако неко систематски касни — то је питање његове дисциплине, решава се у 1:1. Дејли је синхронизација дана. Ако је програмер пропустио — није синхронизован и ризикује да ради посао који тиму није потребан.

Грешка 4: превише учесника. Тим 15+ особа, свако говори по минут — укупно 20+ минута. Решење: поделите тим у подгрупе по функцијама/модулима. Свака подгрупа води свој дејли (5-7 особа). Један представник подгрупе може доћи на заједнички цросс-тимски станд-ап (ако је потребна синхронизација између тимова). Алтернатива: асинхрони станд-ап преко Слацк-а/ГеекБот-а, где свако пише шта је урадио/планира/блокаторе.

Асинхрони станд-ап: алтернативе

Асинхрони станд-ап — формат у којем учесници пишу своје одговоре у чет (Слацк, Телеграм, Теамс) или специјализованог бота (ГеекБот, Стандуплы, Статус Херо) уместо усменог састанка. Погодан за дистрибуиране тимове са разликом у временским зонама 3+ сата. Сваки учесник одговара на иста три питања до одређеног времена (нпр. до 11:00). Бот прикупља одговоре и објављује сажетак на заједничком каналу. Предности: флексибилност, писани запис, без проблема кашњења.

Недостаци асинхроног формата: нема живе комуникације — губе се невербални сигнали, теже је идентификовати блокаторе (програмер можда неће написати о проблему). Блокатор написан у чету може остати непримећен до краја дана. Према подацима ГитЛаб (2025), 40% тимова који су прешли на асинх станд-ап вратило се на усмени у року од 3 месеца. Препорука: користите хибрид — 3 дана усмени станд-ап (пон, сре, пет), 2 дана асинхрони (уто, чет). Или: усмени станд-ап 1-2 пута недељно, осталим данима — асинхрони.

Алати за асинхрони станд-ап: ГеекБот (Слацк) — поставља три питања, објављује сажетак; Стандуплы — са интеграцијом са Јиром, аутоматским праћењем; Статус Херо — прикупља статусе и формира недељни извештај за менаџмент. Избор алата зависи од културе тима: у стартапима је довољан бот у Слацк-у, у ентерприсе-у може бити потребан Стандуплы са интеграцијом у корпоративне процесе. Важно правило: без обзира на формат, одговори треба да буду видљиви целом тиму, а не само менаџеру. Транспарентност — кључна вредност Агиле-а.

Посебности дејлија за мобилни тим

Мобилни тим на дејлију се суочава са специфичним блокаторима. Главни: изградња пројекта у ЦИ (Градле билд може трајати 20+ минута — ако се поквари, програмер губи сат на откривање), чекање на ТестФлигхт / Фиребасе Апп Дистрибутион (објављивање билда тестерима траје 30-60 минута), проблеми са емулаторима и симулаторима (Андроид Емулатор захтева КВМ/ХАКСМ, иОС Симулатор само на Мац-у). Дејли мобилног тима треба да укључи брзу проверу статуса билда: „Билд се склапа? Сви тестови су зелени?"

За цросс-платформ пројекте (Флуттер, Реацт Нативе) дејли може укључивати питање о стању заједничког кода. Ако два програмера истовремено мењају исти Дарт фајл и један од њих обједињује промене — други ће имати конфликте. Савјет: користите Боард Валк на табли са поделом по платформама (Андроид / иОС / Схаред). Ово помаже да се види ко где ради и да ли се промене преклапају. За пројекте са Флуттер-ом — табла са колонама Платформ Цханнел, БЛоЦ/Цубит, УИ, Тестс.

Спремност за релеасе — још једна специфична за мобилни развој тачка у дејлију. 3-5 дана пре релеаса додајте питање: „Да ли је билд спреман за релеасе? Сви метаподаци (иконе, снимци екрана, опис) су ажурирани?" Ово спречава ситуацију у којој програмери завршавају код на дан релеаса, а изградња и објављивање трају још 3-4 сата. Релеасе трацкер — засебна табла са чеклистом: ажурирање версионЦоде/версионНаме, провера ПроГуард-а, потписивање ААБ, отпремање у конзолу програмера, релеасе нотес.