Mobil inkişafda sprint: mahiyyəti, müddəti və planlaşdırma

İnkişafda sprint nədir?

Sprint — sabit müddətli vaxt intervalıdır (timebox), onun sonunda komanda istifadəyə hazır məhsul artımı təqdim edir. Sprint konsepsiyası Scrum-ın əsasıdır, lakin digər Agile çərçivələrində də istifadə olunur. Mobil inkişafda artım — cihaza quraşdırıla bilən, sınaqdan keçirilə bilən və maraqlı tərəflərə göstərilə bilən tətbiq buildidir. Sprint uzadıla bilməz — tapşırıqlar yerinə yetirilməyibsə, növbəti sprintə keçirilir.

Sprintin əsas xüsusiyyəti sabit müddətdir. Komanda təsdiqdən sonra sprintin məqsədini dəyişmir. Bu proqnozlaşdırıla bilənlik verir: maraqlı tərəflər nə vaxt nəticə alacaqlarını bilirlər. Sprint daxilində komanda işi necə bölüşdürəcəyinə özü qərar verir. Scrum Master komandanı kənar müdaxilələrdən qoruyur — cari sprintə yeni tapşırıqlar əlavə edilmir. Scrum Guide 2025-ə görə, bu davamlı inkişaf tempini (sustainable pace) qorumağın yeganə yoludur.

Sprint dörd məcburi hadisədən ibarətdir: Sprint Planning (planlaşdırma), Daily Scrum (günlük sinxronizasiya), Sprint Review (nəticənin nümayişi), Sprint Retrospective (prosesin təhlili). Onların arasında əsas iş: tapşırıqların icrası, test etmə, kod baxışı. Hər hadisənin müddəti sprintin uzunluğu ilə mütənasibdir: 2 həftəlik sprint üçün Planning — 4 saat, Review — 2 saat, Retro — 1.5 saat, Daily — 15 dəqiqə. Ümumilikdə ritualar sprint başına təxminən 8 saat — komandanın iş vaxtının 10%-ni tutur.

Sprintin Scrum rituaları

Scrum rituaları (mərasimlər/hadisələr) — sprint çərçivəsində komandanın strukturlaşdırılmış görüşləri. Sprint Planning — başlanğıcda, Daily Scrum — hər gün, Sprint Review və Retrospective — sonda. Bütün hadisələrin timebox-ı (vaxt məhdudiyyəti) var. Scrum Master timebox və diqqətin qorunmasına nəzarət edir. Hər ritualda bütün Scrum komandası iştirak edir: Product Owner, Scrum Master, tərtibatçılar. İstisna — Daily Scrum (yalnız tərtibatçılar iştirak edir, PO və SM — isteğə bağlı).

Rituaların sprint mərhələləri ilə əlaqəsi: Planning istiqamət verir (nəyi və necə edirik), Daily sinxronlaşdırır (kim nə edir, hansı maneələr var), Review nəticəni göstərir (nə edilib, nə edilməyib), Retrospective prosesi təkmillşdirir (növbəti sprinti necə yaxşılaşdırmaq olar). Retrospektivin buraxılması — komandaların ən geniş yayılmış səhvi: müddətlər yananda məhz Retro qurban verilir. Bu, proseslərin durğunluğuna və eyni səhvlərin təkrarlanmasına gətirib çıxarır. Scrum.org (2025) tədqiqatı göstərir: hər 2 həftədən bir Retro keçirən komandalar velocity-ni 35% daha sürətli yaxşılaşdırır.

Sprint Planning: iterasiyanın planlaşdırılması

Sprint Planning — sprintin əvvəlində komandanın görüşüdür, burada nə ediləcəyi və necə ediləcəyi müəyyənləşdirilir. Product Owner Product Backlog-dan prioritet tapşırıqları təqdim edir. Komanda capacity-ni (məzuniyyətlər, görüşlər, texniki borc nəzərə alınmaqla mövcud vaxt) qiymətləndirir və sprintdə yerinə yetirə biləcəyi tapşırıqları seçir. Planning-in nəticəsi — Sprint Goal (sprintin məqsədi) və Sprint Backlog (tapşırıq siyahısı). Sprint Goal qısa bir cümle kimi formullaşdırılır: “Sifariş ekranını və ödəniş inteqrasiyasını həyata keçirmək”.

Velocity — komandanın sürəti, sprint üçün story point-lərlə ölçülür. Son 3-5 sprintin ortalaması. Scrum.org (2025)-ə görə, 5 mobil tərtibatçıdan ibarət komanda (3 Android + 2 iOS) 2 həftəlik sprintdə 25-40 SP velocity-yə malikdir. Planning velocity-ni yuxarı hədd kimi istifadə edir — gözlənməyən tapşırıqlar (kod baxışı, insidentlər, digər komandalara kömək) üçün 10-15% az götürürlər. Capacity vs Velocity: capacity — “insan-saat”, velocity — “story point”. Capacity məzuniyyət, xəstəlik, görüşləri nəzərə alır. Tipik loss rate — iş vaxtının 25-30%-i qeyri-kod fəaliyyətinə sərf olunur.

Planlaşdırma iki hissəyə bölünür: “nə” (PO tapşırıqları danışır, komanda dəqiqləşdirir) — 2 saat, və “necə” (komanda parçalayır və qiymətləndirir) — 2 saat. Mobil layihələr üçün “necə” hissəsində müzakirə edilir: Android/iOS versiyaları ilə uyğunluq, feature flag ehtiyacı, APK/IPA ölçüsünə təsir, yeni icazələr. Planning Poker texnikası qiymətləndirmə üçün istifadə olunur: hər tərtibatçı story point-lərdə öz qiymətləndirməsini verir (1, 2, 3, 5, 8, 13). 2 vahiddən çox fərq — səbəbləri müzakirə edirlər. Bu, sprintin ortasında yox, planlaşdırma mərhələsində gizli riskləri üzə çıxarır.

Sprintin icrası: Daily Standup və izləmə

Daily Scrum (Standup) — komandanın sinxronizasiyası üçün günlük 15 dəqiqəlik görüş. Hər iştirakçı üç suala cavab verir: “Dünən nə etdim?”, “Bu gün nə planlaşdırıram?”, “Hansı maneələr var?”. Daily menecer üçün status hesabatı deyil, komandanın özünütəşkil alətidir. Daily zamanı iki tərtibatçının eyni tapşırıq üzərində işlədiyi məlum olarsa — bu yenidən təşkilatlanma üçün siqnaldır. Vacib: Daily problemləri həll etmir, onları müəyyənləşdirir — həll üçün Daily-dən sonra ayrı görüş keçirilir.

Scrum Board (sprint lövhəsi) — Sprint Backlog-un vizuallaşdırılması. Sütunlar: To Do / In Progress / In Review / Done. Hər tapşırıq lövhə üzrə hərəkət edir. Burndown Chart — sprintin günləri üzrə qalan işin qrafiki. İdeal burndown — total SP-dən 0-a düz xətt. Real burndown — tapşırıqların bağlanmasını nəzərə alan pilləli qrafik. Düşən burndown (ideal xəttdən aşağı) — gecikirik. Problem siqnalı: sprintin ortasında tapşırıqların 30%-dən azı yerinə yetirilibsə — düzəliş lazımdır. Ola bilsin ki, risklər nəzərə alınmayıb və ya tapşırıqlar həddən artıq qiymətləndirilib.

Mobil inkişafda sprintin izlənməsinə spesifik amillər təsir edir: qurma vaxtı (Android layihəsinin CI-da qurulması 30+ dəqiqə çəkə bilər), App Store / Google Play moderasiyasının gözlənilməsi (testçilərə TestFlight vasitəsilə build vermək lazımdırsa), müxtəlif cihazlarla uyğunluq (10+ modeldə sınaq vaxt aparır). Məsləhət: sprintin sonunda yekun test və release build qurulması üçün 1 günlük bufer planlaşdırın. Bu, Mind the Product (2025)-ə görə, yarımçıq sprint riskini 40% azaldır.

Sprint Review və Retrospective

Sprint Review — maraqlı tərəflərə artımın nümayişi. Komanda işləyən build-i göstərir, slaydları yox. Müddət — 2 həftəlik sprint üçün 2 saat. Product Owner Acceptance Criteria-ya uyğunluğu yoxlayır. Maraqlı tərəflər Product Backlog-a təsir edə biləcək əks əlaqə verirlər. Review hesabat deyil, dialoqdur: maraqlı tərəflər suallar verə və dəyişikliklər təklif edə bilər. Əsas qayda: Sprint Review məhsulla bağlıdır, proseslə yox. Nəyə nail olduğumuzu göstəririk, necə etdiyimizi yox.

Sprint Retrospective — keçmiş sprintin təhlili üçün komandanın daxili görüşü. Format: Start Doing (nəyə başlamaq), Stop Doing (nəyi dayandırmaq), Continue Doing (nəyi davam etdirmək). Müddət — 2 həftəlik sprint üçün 1.5 saat. Retrospective problemlərin müzakirəsi üçün təhlükəsiz məkandır. Qayda: Retro-da texniki detallar müzakirə edilmir (bunun üçün texniki görüşlər var). Yalnızca proses, ünsiyyət, alətlər, mədəniyyət. Scrum Master görüşü idarə edir və hər iştirakçının fikrini bildirməsinə şərait yaradır.

Retrospective-in nəticəsi — növbəti sprint üçün 1-3 təkmilləşmə. Komanda “Kod baxışı çox uzundur” problemini müəyyənləşdiribsə — action item: “Baxış üçün SLA müəyyənləşdirin — 4 saat. Baxış vaxtında edilməyibsə — tərtibatçı Slack-də xatırladır”. Action Items konkret, ölçülə bilən və müəyyən bir şəxsə təyin edilmiş olmalıdır. Atlassian (2025)-ə görə, Retro action items-lərini yerinə yetirən komandalar 3-4 sprint ərzində velocity-ni 15-25% yaxşılaşdırır. Yerinə yetirməyənlər yerində sayır.

Sprint müddətini necə seçmək

2 həftə — mobil inkişaf üçün standart. Proqnozlaşdırıla bilənlik və çeviklik arasında optimal balans. Yetər: planlaşdırmaq, 3-5 orta ölçülü funksiyanı həyata keçirmək, test etmək, nəticəni göstərmək. 1 həftə — yüksək proses yetkinliyi və CI/CD olan komandalar üçün. Sürətli qərarlar, minimal bürokratiya tələb edir. Erkən mərhələdə sürətli eksperimentlər etmək lazım olan startaplar üçün uyğundur. Çatışmazlıq: ritualara yüksək yük (hər həftə Planning + Review + Retro = 7.5 saat).

3-4 həftə — avadanlıqla inteqrasiya (wearables, IoT, BLE cihazları), mağaza moderasiyası və ya böyük miqrasiyalar (məs. RxJava-dan Coroutines-ə keçid) olan mürəkkəb layihələr üçün. Uzun sprintlər test üçün daha çox vaxt verir, lakin "şalalə effekti" riskini artırır — komanda Agile çevikliyini itirir. Scrum Guide tövsiyəsi: 1 aydan çox olmayın. Sprint daha uzundursa — Review-də çox kontekst olacaq, maraqlı tərəflər keyfiyyətli əks əlaqə verə bilməyəcək.

Sprintlərin tipik problemləri

Problem 1: Scope Creep. Sprintin ortasında Product Owner yeni "əcili və vacib" tapşırıq əlavə edir. Komanda razılaşır — və sprint uğursuz olur. Həll: Sprint Goal — müqavilə. İstənilən dəyişiklik Sprint Goal-in yenidən baxılmasını tələb edir və bu yalnız təcili hallarda mümkündür. Yeni tapşırıq Product Backlog-a və növbəti sprintə gedir. Tapşırıq həqiqətən kritikdirsə — köhnə Sprint Goal ləğv edilir, sprint yenidən planlaşdırılır, lakin bu istisnadır, təcrübə deyil. Scope creep tezliyi 3 sprintdə 1 dəfədən çox olarsa — zəif Product Owner əlamətidir.

Problem 2: Yarımçıq tapşırıqlar. Sprintin sonunda tapşırıqların 50% i In Progress, 20% i Review, yalnız 30% i Done. Səbəblər: capacity-nin həddən artıq qiymətləndirilməsi, mürəkkəbliyin az qiymətləndirilməsi, planlaşdırılmayan xətalar. Həll: Retro-da səbəbi təhlil edin. Sistemli şəkildə çatdıra bilmirsinizsə — Planning-də tapşırıqların sayını artırmayın, azaldın. 20% az tapşırıq götürən komandalar daha yüksək tamamlama faizi göstərir (50-60% əvəzinə 80%+). Planning üçün yoxlama siyahısı: hər tapşırıq üçün Acceptance Criteria, Definition of Ready və digər tapşırıqlardan asılılıqları yoxlayın.

Problem 3: Formal Retro. Komanda Retro-nu göstəriş üçün keçirir — 15 dəqiqə, ümumi ifadələr, action items yox. Həll: hər Retro-nun formatını dəyişin. Metodlar: Sailboat (nə mane olur, nə sürətləndirir), Start / Stop / Continue, Happy / Sad / Mad, 4Ls (Liked, Learned, Lacked, Longed For). Action items-ləri müddət və məsul şəxslə təyin edin. Növbəti Retro-nun əvvəlində əvvəlki action items-lərin yerinə yetirilməsini yoxlayın. Atlassian (2025)-ə görə, müxtəlif Retro formatlarından istifadə edən komandalar 50% daha çox faydalı fikir əldə edir.