Спринт у мобилном развоју: суштина, трајање и планирање

Шта је спринт у развоју?

Спринт — временски интервал (timebox) фиксне дужине, на чијем крају тим доставља готов за употребу инкремент производа. Концепт спринта је основа Scrum-а, али се користи и у другим Agile оквирима. У мобилном развоју инкремент је билд апликације који се може инсталирати на уређај, тестирати и показати заинтересованим странама. Спринт се не може продужити — ако задаци нису завршени, преносе се у следећи спринт.

Кључна карактеристика спринта је фиксно трајање. Тим не мења циљ спринта након одобрења. То даје предвидљивост: заинтересоване стране знају када ће добити резултат. Унутар спринта тим сам одлучује како да распореди посао. Scrum Master штити тим од спољних мешања — нови задаци се не додају у текући спринт. Према подацима Scrum Guide 2025, то је једини начин да се одржи одржив темпо развоја (sustainable pace).

Спринт се састоји од четири обавезна догађаја: Sprint Planning (планирање), Daily Scrum (свакодневна синхронизација), Sprint Review (демонстрација резултата), Sprint Retrospective (анализа процеса). Између њих је главни посао: реализација задатака, тестирање, код ревизија. Трајање сваког догађаја је директно пропорционално дужини спринта: за двонедељни спринт Planning — 4 сата, Review — 2 сата, Retro — 1.5 сат, Daily — 15 минута. Укупно ритуали заузимају око 8 сати по спринту — 10% радног времена тима.

Scrum ритуали спринта

Scrum ритуали (церемоније/догађаји) — структурирани састанци тима у оквиру спринта. Sprint Planning — на почетку, Daily Scrum — сваки дан, Sprint Review и Retrospective — на крају. Сви догађаји имају timebox (ограничење по времену). Scrum Master пази на поштовање timebox-а и фокуса. На сваком ритуалу учествује цео Scrum тим: Product Owner, Scrum Master, програмери. Изузетак — Daily Scrum (учествују само програмери, PO и SM — опционо).

Веза ритуала са фазама спринта: Planning поставља смер (шта и како радимо), Daily синхронизује (ко шта ради, који блокери постоје), Review показује резултат (шта је урађено, шта није), Retrospective унапређује процес (како следећи спринт учинити бољим). Пропуштање ретроспективе — најчешћа грешка тимова: када рокови горе, жртвује се управо Retro. То води ка стагнацији процеса и понављању истих грешака. Истраживање Scrum.org (2025) показује: тимови који одржавају Retro сваке 2 недеље 35% брже побољшавају velocity.

Sprint Planning: планирање итерације

Sprint Planning — састанак тима на почетку спринта на којем се одређује шта ће бити урађено и како. Product Owner представља приоритетне задатке из Product Backlog-а. Тим процењује capacity (расположиво време узимајући у обзир годишње одморе, састанке, технолошки дуг) и бира задатке које може да заврши у спринту. Резултат Planning-а — Sprint Goal (циљ спринта) и Sprint Backlog (листа задатака). Sprint Goal се формулише као кратка реченица: „Реализовати екран поруџбине и интеграцију плаћања преко СБП-а“.

Velocity — брзина тима, мери се у стори поенима по спринту. Просечан за последњих 3-5 спринтова. Према подацима Scrum.org (2025), тим од 5 мобилних програмера (3 Android + 2 iOS) има velocity 25-40 SP за двонедељни спринт. Planning користи velocity као горњу границу — узима се 10-15% мање због непредвиђених задатака (code review, инциденти, помоћ другим тимовима). Capacity vs Velocity: capacity је „човек-сати“, velocity — „стори поени“. Capacity узима у обзир одморе, боловања, састанке. Типична loss rate — 25-30% радног времена одлази на не-код активности.

Планирање се дели на два дела: „шта“ (PO прича задатке, тим појашњава) — 2 сата, и „како“ (тим декомпонује и процењује) — 2 сата. За мобилне пројекте на „како“ се разговара о: компатибилности са верзијама Android/iOS, потреби за feature flag-ом, утицају на величину APK/IPA, новим permission-има. Техника Planning Poker се користи за процену: сваки програмер даје своју оцену у стори поенима (1, 2, 3, 5, 8, 13). Разлика > 2 јединице — разговарају се узроци. То открива скривене ризике у фази планирања, а не усред спринта.

Извршење спринта: Daily Standup и праћење

Daily Scrum (Standup) — свакодневни 15-минутни састанак за синхронизацију тима. Сваки учесник одговара на три питања: „Шта је урађено јуче?“, „Шта планирам данас?“, „Који блокери постоје?“. Daily — није статус извештај за менаџера, већ алат самоорганизације тима. Ако се на Daily-у испостави да два програмера раде на истом задатку — то је сигнал за реорганизацију. Важно: Daily не решава проблеме, већ их открива — за решавање се сазива засебан састанак након Daily-а.

Scrum Board (табла спринта) — визуализација Sprint Backlog-а. Колоне: To Do / In Progress / In Review / Done. Сваки задатак се помера по табли. Burndown Chart — график преосталог посла по данима спринта. Идеални burndown — права линија од total SP до 0. Реални burndown — степенасти график узимајући у обзир затварање задатака. Падајући burndown (испод идеалне линије) — каснимо. Проблемни сигнал: ако је до средине спринта завршено мање од 30% задатака — потребна је корекција. Могуће да нису узети у обзир ризици или су задаци прецењени.

За мобилни развој на праћење спринта утичу специфични фактори: време изградње (билд Android пројекта у CI-ју може трајати 30+ минута), чекање модерације App Store / Google Play (ако је потребно издати билд тестерима преко TestFlight-а), компатибилност са различитим уређајима (тестирање на 10+ модела траје). Савет: планирајте 1 дан бафера на крају спринта за финално тестирање и изградњу релизног билда. То смањује ризик незавршеног спринта за 40% према подацима Mind the Product (2025).

Sprint Review и Retrospective

Sprint Review — демонстрација инкремента заинтересованим странама. Тим показује радни билд апликације, а не слајдове. Трајање — 2 сата за двонедељни спринт. Product Owner проверава усклађеност са Acceptance Criteria. Заинтересоване стране дају повратне информације које могу утицати на Product Backlog. Review — није извештај, већ дијалог: заинтересоване стране могу постављати питања и предлагати измене. Кључно правило: Sprint Review је о производу, а не о процесу. Показујемо шта је постигнуто, а не како смо радили.

Sprint Retrospective — интерни састанак тима за анализу протеклог спринта. Формат: Start Doing (шта почети радити), Stop Doing (шта престати), Continue Doing (шта наставити). Трајање — 1.5 сат за двонедељни спринт. Retrospective — безбедан простор за дискусију проблема. Правило: на Retro-у се не разговара о техничким детаљима (за то постоје технички састанци). Само процес, комуникација, алати, култура. Scrum Master фасилитира састанак и пази да се сваки учесник изјасни.

Резултат Retrospective-а — 1-3 побољшања за следећи спринт. Ако је тим идентификовао проблем „Сувише дугачак code review“ — action item: „Поставити SLA на ревизију — 4 сата. Ако ревизија није урађена на време — програмер подсећа у Slack-у“. Action Items морају бити конкретни, мерљиви и додељени одређеној особи. Према подацима Atlassian (2025), тимови који извршавају своје Retro action item-е побољшавају velocity за 15-25% током 3-4 спринта. Они који не извршавају — марширају у месту.

Како изабрати трајање спринта

2 недеље — стандард за мобилни развој. Оптималан баланс између предвидљивости и флексибилности. Успева се: испланирати, реализовати 3-5 средњих функционалности, тестирати, показати резултат. 1 недеља — за тимове са високом зрелошћу процеса и CI/CD. Захтева брзе одлуке, минималну бирократију. Погодна за стартапове у раној фази, када је потребно брзо експериментисати. Недостатак: висок overhead на ритуале (сваке недеље Planning + Review + Retro = 7.5 сати).

3-4 недеље — за сложене пројекте где је интеграција са хардвером (wearables, IoT, BLE уређаји), дуга модерација сторова или велике миграције (на пример, прелазак са RxJava на Coroutines). Дуги спринтови дају више времена за тестирање, али повећавају ризик „ефекта водопада“ — тим губи agile флексибилност. Препорука Scrum Guide-а: не прекорачите 1 месец. Ако је спринт дужи — на Review-у ће бити превише контекста, заинтересоване стране неће моћи дати квалитетне повратне информације.

Типични проблеми спринтова

Проблем 1: Scope Creep. Усред спринта Product Owner додаје нови задатак „хитан и важан“. Тим пристаје — и спринт пропада. Решење: Sprint Goal — уговор. Свака измена захтева преиспитивање Sprint Goal-а, а то је могуће само у ванредним случајевима. Нови задатак иде у Product Backlog и у следећи спринт. Ако је задатак заиста критичан — стари Sprint Goal се отказује, спринт се препланира, али то је изузетак, а не пракса. Учесталост scope creep-а већа од 1 пута у 3 спринта — знак слабог Product Owner-а.

Проблем 2: Незавршени задаци. На крају спринта 50% задатака у In Progress, 20% у Review, само 30% Done. Разлози: прецењен capacity, потцењена сложеност, непланирани багови. Решење: анализирајте узрок на Retro-у. Ако систематски не стижете — не повећавајте број задатака на Planning-у, већ га смањите. Тимови који узимају 20% мање задатака показују већи проценат завршетка (80%+ насупрот 50-60%). Контролна листа за Planning: за сваки задатак проверити Acceptance Criteria, Definition of Ready и зависност од других задатака.

Проблем 3: Формални Retro. Тим одржава Retro ради форме — 15 минута, општих фраза, без action item-а. Решење: мењајте формат сваког Retro-а. Методе: Sailboat (шта успорава, шта убрзава), Start / Stop / Continue, Happy / Sad / Mad, 4Ls (Liked, Learned, Lacked, Longed For). Назначите action item-е са роком и одговорном особом. На почетку следећег Retro-а проверите извршење претходних action item-а. Према подацима Atlassian (2025), тимови који користе различите формате Retro-а генеришу 50% више корисних увида.