Tətbiq inkişafında backlog: nədir, strukturu və tapşırıqların idarə edilməsi
Backlog — bu, layihədə həyata keçirilməli olan bütün tapşırıqların, tələblərin və təkmilləşdirmələrin sıralanmış siyahısıdır. O, çevik metodologiyaların mərkəzi artefaktıdır: Scrum-da backlogu Product Owner idarə edir, Kanban-da isə bütün komanda. Scrum Guide, 2020-yə görə, backlog heç vaxt tamamlanmış sayılmır: o, məhsul və bazar tələbləri ilə birlikdə daim təkamül edir.
Əsas
- Backlog — prioritet və icra hazırlığına görə sıralanmış bütün layihə tapşırıqlarının siyahısı.
- Əsas elementlər — user story, səhvlər, texniki borc, tədqiqat və təkmilləşdirmə tapşırıqları.
- Prioritetləşdirmə — əsas proses: backlogun yuxarısındakı tapşırıqlar ən vacib və sprinta hazırdır.
- Product Owner — backlogun sahibi, onun məzmunu və prioritetlərinə görə cavabdehdir.
- Grooming (refinement) — backlog elementlərinin dəqiqləşdirilməsi, qiymətləndirilməsi və yenidən prioritetləşdirilməsi üzrə müntəzəm fəaliyyət.
İnkişafda backlog nədir?
Backlog (ing. backlog) — məhsuldakı bütün dəyişikliklər üçün vahid tələb mənbəyidir. Product Owner onun məzmununa, əldətanlığına və şəffaflığına görə cavabdehdir: komandanın hər bir üzvü backlogda hansı tapşırıqların olduğunu və onların hansı ardıcıllıqla həyata keçiriləcəyini başa düşməlidir.
Product Backlog və Sprint Backlog arasındakı fərq
Product Backlog növbəti rüb üçün funksiyalardan tutmuş bir illik ideyalara qədər bütün layihə tapşırıqlarını perspektivdə ehtiva edir. Sprint Backlog — komandanın cari sprinta götürdüyü Product Backlog-dan tapşırıqların alt çoxluğudur. Sprint Backlog sprint müddətində dondurulur, Product Backlog isə daim dəyişir.
Scrum və Kanban-da backlog
Scrum-da backlog ciddi şəkildə strukturlaşdırılıb: Product Backlog və Sprint Backlog var, tapşırıqlar story point-lərlə qiymətləndirilir, sprintlər sabit uzunluğa malikdir. Kanban-da backlog daha çevikdir: tapşırıqlar proqramçılar boşaldıqca çəkilir, prioritetlər hər gün dəyişə bilər, WIP (work in progress) limitləri isə tapşırıq axınını tənzimləyir.
Backlog elementləri: nədən ibarətdir
Keyfiyyətli backlog müxtəlif tapşırıq növlərini ehtiva edir, təkcə yeni funksionallığı deyil. Balanslaşdırılmış backlog məhsulun inkişafının bütün aspektlərini nəzərə alır.
| Element növü | Təsvir | Nümunə |
|---|---|---|
| User Story | İstifadəçi baxışından yeni funksionallıq | “İstifadəçi olaraq şifrəmi bərpa etmək istəyirəm” |
| Bug | Mövcud funksionallıqda qüsur və ya səhv | “Qeydiyyat düyməsi iOS 16-da işləmir” |
| Tech Debt | İstifadəçiyə görünməz effektli kod bazasının təkmilləşdirilməsi | “Asılılıqları son versiyalara yeniləmək” |
| Spike / Research | Qeyri-müəyyənliyi azaltmaq üçün tədqiqat və ya prototip | “Jetpack Compose-a miqrasiya imkanını araşdırmaq” |
| Improvement | Proseslərin və ya infrastrukturun təkmilləşdirilməsi | “Avtomatik qurma üçün CI/CD konfiqurasiyası” |
Əsas element kimi User Story
Backlogun əsas tikinti bloku User Story-dir (istifadəçi hekayəsi). Keyfiyyətli User Story istifadəçinin hansı dəyəri əldə edəcəyini təsvir edir, hansı texniki hərəkətlərin yerinə yetirilməli olduğunu deyil. INVEST formatı: Independent, Negotiable, Valuable, Estimable, Small, Testable. Hekayə bir sprinta sığmalıdır, əks halda onu parçalamaq lazımdır.
Qəbul meyarları
Qəbul meyarları (acceptance criteria) tapşırığın nə vaxt yerinə yetirilmiş sayılacağını müəyyən edir. Onlar Given-When-Then formatında və ya sadə şərtlər siyahısı şəklində yazılır. Məsələn: “İstifadəçi e-poçt vasitəsilə şifrəni bərpa edə bilər, məktub 30 saniyəyə gəlir, keçid 24 saat aktivdir”. Aydın qəbul meyarları demo mərhələsində mübahisələri aradan qaldırır.
Backlogun prioritetləşdirilməsi: metod və yanaşmalar
Prioritetləşdirmə — backlogun idarə edilməsinin ən vacib və çətin prosesidir. Product Owner biznes dəyərini, əmək sərfiyyatını, riskləri və tapşırıqlar arasındakı asılılıqları nəzərə almalıdır.
MoSCoW: Must-Should-Could-Won’t
MoSCoW — klassik prioritetləşdirmə metodu. Must have — tapşırıq olmadan məhsul işləmir. Should have — vacib tapşırıq, ancaq təxirə salına bilər. Could have — etmək istədiyimiz təkmilləşdirmə. Won’t have — gələcəyə təxirə salınmış tapşırıqlar. Bölgü: 60% Must, 20% Should, 20% Could. Metod kritik funksionallığa diqqət yetirməyə kömək edir.
Value vs Effort matrisi
Matris “dəyər / əmək sərfiyyatı” tapşırıqları dörd kvadranta bölür: Quick Wins (yüksək dəyər, aşağı əmək) — əvvəlcə edirik, Big Bets (yüksək dəyər, yüksək əmək) — əvvəlcədən planlaşdırırıq, Fill-ins (aşağı dəyər, aşağı əmək) — aralıq vaxtlarda edirik, və Avoid (aşağı dəyər, yüksək əmək) — etmirik. Bu yanaşma məhdud resurslarla dəyəri maksimuma çatdırmağa imkan verir.
Weighted Shortest Job First (WSJF)
WSJF — SAFe-dən prioritetləşdirmə metodu, düstura əsaslanır: dəyər / tapşırıq ölçüsü. Dəyərin ölçüyə nisbəti nə qədər böyükdürsə, prioritet bir o qədər yüksəkdir. WSJF biznes dəyərini, vaxt kritikliyini və riskləri nəzərə alır. Metod böyük həcmi olan yetkin məhsul komandaları üçün uyğundur.
Backlogu necə idarə etməli: ən yaxşı təcrübələr
Effektiv backlog idarəçiliyi müntəzəm fəaliyyətlər, düzgün alətlər və bütün komandanın intizamı tələb edir.
Backlog Refinement (Grooming)
Refinement — komandanın backlog elementlərini dəqiqləşdirdiyi, qiymətləndirdiyi və yenidən prioritetləşdirdiyi müntəzəm görüşdür (adətən həftədə bir dəfə). Scrum Guide refinement-ə komanda vaxtının 10%-dən çoxunu sərf etməməyi tövsiyə edir. Nəticə: backlogun yuxarı 20-30%-i sprint planlamasına hazırdır — qiymətləndirmə, qəbul meyarları və akseptı var.
Backlog üçün DEEP qaydaları
- Detailed appropriately — yaxın tapşırıqlar ətraflıdır, uzaq olanlar isə ancaq ideya şəklində.
- Estimated — yuxarı səviyyəli bütün tapşırıqlar story point və ya saatlarla qiymətləndirilib.
- Emergent — backlog daim dəyişir: tapşırıqlar əlavə olunur, silinir, yenidən prioritetləşdirilir.
- Prioritized — hər tapşırığın öz sırası var, eyni prioritetli tapşırıqlar yoxdur.
Backlog aparılması üçün alətlər
Ən populyar alətlər backlog idarəçiliyi üçün: Jira (sənaye standartı, çevik workflow konfiqurasiyası ilə), Linear (sürətli və müasir tracker), Trello (kiçik komandalar və Kanban üçün), Notion (çevik məkan, verilənlər bazası ilə) və Youtrack. Alətin seçimi komanda ölçüsündən, metodologiyadan və büdcədən asılıdır.
Backlogun aparılmasında tipik səhvlər
Hətta təcrübəli Product Owner-lər backlog idarəçiliyində səhvlər edir ki, bunlar komandanın effektivliyini və məhsulun keyfiyyətini aşağı salır.
Backlog ideya zibili kimi
Ən tez-tez rast gəlinən səhv — bütün ideyaları süzgəcdən keçirmədən və prioritetləşdirmədən backloga atmaqdır. Backlog yüzlərlə tapşırığa qədər böyüyür və oriyentasiya qeyri-mümkün olur. Həll yolu: backlogu müntəzəm təmizləmək — köhnəlmiş tapşırıqları silmək, oxşarları birləşdirmək, təxirəsalınmaz olanları təxirə salmaq. Sağlam backlog 50-100 elementdən ibarətdir, minlərlə deyil.
Texniki tapşırıqların olmaması
Backlog yalnız User Story-lərdən ibarət olduqda, texniki borc artır, infrastruktur təkmilləşdirmələri təxirə salınır. Gec-tez komanda köhnəlmiş asılılıqlar, testlərin çatışmazlığı və ya memarlıq problemləri səbəbindən məhsuldarlıq tavanına çarpır. Qayda: sprintdə tapşırıqların 20%-i texniki olmalıdır — refaktorinq, testlər, yeniləmələr.
Gələcək üçün həddən artıq təfərrüatlı backlog
3-6 ay qabaq tapşırıqları təfərrüatlı təsvir etmək vaxt itkisidir. Tələblər dəyişir, bazar təkamül edir, ətraflı yazılmış tapşırıqları yenidən yazmaq lazım gəlir. Yalnız 1-2 qarşıdakı sprinta düşəcək tapşırıqları təfərrüatlaşdırın. Uzaq tapşırıqlar üçün başlıq və qısa təsvir kifayətdir.
Səhvlərin görməməzdən gəlinməsi
Kiçik səhvlər backloga düşmür, çünki “vaxt yoxdur” və ya “sonra düzəldərik”. Zaman keçdikcə səhvlər çoxalır, keyfiyyət düşür, məhsul istifadəçilərin etimadını itirir. Qayda: hər səhv backlogda qeyd olunur, hətta aşağı prioritetli olsa belə. Çox səhv yığılıbsa — onları düzəltmək üçün sprint ayırın.
Tez-tez verilən suallar
Product Backlog Sprint Backlog-dan nə ilə fərqlənir?
Product Backlog — Product Owner tərəfindən idarə olunan bütün layihə tapşırıqlarının uzunmüddətli tam siyahısıdır. Sprint Backlog — komandanın cari sprinta götürdüyü Product Backlog-dan tapşırıqların alt çoxluğudur. Sprint Backlog sprint müddətində dondurulur, Product Backlog isə daim dəyişir.
Scrum-da backloga kim cavabdehdir?
Backloga Product Owner cavabdehdir. O, prioritetləri müəyyən edir, tapşırıqları formalaşdırır və elementlərin sprinta hazırlığı barədə qərar qəbul edir. Proqramçılar dəyişikliklər təklif edə, texniki tapşırıqlar əlavə edə və mürəkkəbliyi qiymətləndirə bilər, lakin prioritetlərlə bağlı son qərar Product Owner-ə məxsusdur.
Backlogun grooming-i nə qədər tez-tez aparılmalıdır?
Grooming həftədə bir dəfə və ya ən azından hər sprintdə bir dəfə aparılması tövsiyə olunur. Scrum Guide refinement-ə proqramçı vaxtının 10%-dən çoxunu sərf etməməyi tövsiyə edir. İki həftəlik sprint üçün bu, həftədə təxminən 1-2 saatdır. Müntəzəm grooming backlogda “zibil” yığılmasının qarşısını alır.
Backlogda nə qədər tapşırıq olmalıdır?
Sağlam Product Backlog 50-100 element ehtiva edir. Az olması komandanın gələcək barədə düşünmədiyini göstərir, çox olması isə backlogu zibilə çevirir. Vacib olan tapşırıqların sayı deyil, keyfiyyətidir: yuxarı 20-30% sprinta hazır olmalı, qalanları müxtəlif dərəcədə işlənmiş olmalıdır.
Sprint zamanı backlog dəyişdirilə bilərmi?
Product Backlog istənilən vaxt dəyişdirilə bilər — bu onun normal vəziyyətidir. Lakin Sprint Backlog komandanın məqsədə diqqət yetirməsi üçün sprint müddətində dondurulur. Yeganə istisna: Product Owner tapşırığı aktuallığını itirdiyi üçün sprintdən çıxardıqda.
Nəticə
- Backlog — Product Owner tərəfindən idarə olunan layihədəki bütün dəyişikliklər üçün vahid tələb mənbəyi.
- Əsas elementlər — User Story, səhvlər, texniki borc, tədqiqat, proses təkmilləşdirmələri.
- Prioritetləşdirmə — PO-nun əsas bacarığı: MoSCoW, Value vs Effort, WSJF metodları prioritetləri müəyyənləşdirməyə kömək edir.
- DEEP qaydaları — backlog münasib şəkildə təfərrüatlı, qiymətləndirilmiş, dəyişən və prioritetləşdirilmiş olmalıdır.
- Grooming — yuxarı səviyyəli tapşırıqların dəqiqləşdirilməsi və qiymətləndirilməsi üçün həftəlik fəaliyyət.
- Tipik səhvlər — ideya zibili, texniki tapşırıqların olmaması, həddən artıq təfərrüat və səhvlərin görməməzdən gəlinməsi.
- Sağlam ölçü — 50-100 element, yuxarı 30% sprinta hazır.
Açar təslim mobil tətbiq hazırlayacağıq
IT Sectr 2017-ci ildən startaplar və bizneslər üçün iOS və Android tətbiqləri yaradır. Sizə məsləhət verəcəyik və ən yaxşı həlli təklif edəcəyik.
Həm də oxuyun