Sprint planlaşdırma: Agile ən yaxşı təcrübələr

Planlaşdırmanın əsasları

Yaxşı sprint planı üç şeyə söykənir: əvvəlki sprintlərin təhlili, komandanın real imkanlarının qiymətləndirilməsi və aydın qoyulmuş məqsədlər. Ətraflı məlumat: IT komandaları üçün IT layihə idarəetmə proqramı.

1. Planlaşdırmaya hazırlıq əvvəlcədən başlayır. Product Owner görüşdən ən azı bir gün qabaq backlog-u qaydaya salmalı və prioritetləri müəyyən etməlidir. Tərtibat komandasının da user story-lərə əvvəlcədən baxıb suallarını vermək imkanı olmalıdır.
2. Klassik bölgü qaydası belədir: sprintin hər həftəsinə iki saat planlaşdırma. İki həftəlik sprintdə bu, dörd saat edir. Amma təcrübədə bu vaxtı bir uzun görüşə yığmaqdansa bir neçə qısa sessiyaya bölmək çox vaxt daha yaxşı nəticə verir.

Hazırlıq mərhələsi

Hazırlıq zəifdirsə, sprint planlaşdırmasını yaxşılaşdırmaq mümkün olmur. Bu mərhələyə çox vaxt lazımi diqqət ayrılmır, halbuki bütün prosesin taleyi elə burada həll olunur.

• Definition of Ready (DoR) user story-nin sprintə götürülməsi üçün hansı şərtlərə cavab verməli olduğunu göstərir. Hər hekayədə aydın qəbul meyarları, mürəkkəblik qiymətləndirməsi və başqa tapşırıqlardan asılılıqlar yazılmalıdır. DoR-a əməl olunmayanda planlaşdırma xaosa dönür və komanda icranı planlamaq əvəzinə vaxtını aydınlaşdırmalara xərcləyir.
• Backlog refinement planlaşdırmadan bir az əvvəl yox, müntəzəm aparılmalıdır. Sprint vaxtının 10%-ni bu işə ayırmaq geniş yayılmış təcrübədir. Komanda həftədə bir neçə dəfə qısa sessiyalar keçirib gələcək sprintlərin hekayələrini tədricən hazırlaya bilər.
• Velocity təhlili komandanın əslində nə qədər iş çatdırdığını dəqiq göstərir. Burada son 3-5 sprintin orta Velocity-si ilə kifayətlənmək olmaz. Qarşıdakı sprintdə məhsuldarlığa təsir edəcək amilləri də nəzərə almaq lazımdır: planlaşdırılmış məzuniyyətlər, bayramlar, yığılıb qalmış texniki borc, xarici asılılıqlar.

Planlaşdırma sessiyaları

Sprint planlaşdırması iki hissədən ibarətdir. Birincidə sprintdə nəyin çatdırılacağı, ikincidə seçilmiş işin necə görüləcəyi müəyyən olunur. Hər hissənin öz girişləri və öz nəticələri var. Onları qarışdırmaq olmaz, yoxsa hər ikisindən alınan fayda azalır.

1. Komanda Product Owner ilə birlikdə seçilmiş bütün user story-ləri bir yerə toplayan sprint məqsədini müəyyən edir. Məqsəd konkret, ölçülə bilən və bütün iştirakçılar üçün mənalı olmalıdır. Zəif məqsəd: "İstifadəçi təcrübəsini yaxşılaşdırmaq." Yaxşı məqsəd: "İstifadəçilər bir kliklə sosial şəbəkə hesabı ilə qeydiyyatdan keçə biləcəklər."
2. Tərtibat komandası seçilmiş hekayələri tapşırıqlara bölür və hər birini saatla qiymətləndirir. Bu zaman hekayə səviyyəsində görünməyən gizli mürəkkəblik və asılılıqlar üzə çıxır. Bir tapşırıq 8 saatdan çox çəkməməlidir, bu həddi keçən tapşırığı daha xırda hissələrə bölmək lazımdır.

Rollar və məsuliyyətlər

Sprint planlaşdırmasının yaxşı keçməsi hər iştirakçının öz rolunu bilməsindən və onun çərçivəsində işləməsindən asılıdır.

• Scrum Master prosesi aparır, vaxt çərçivəsinə nəzarət edir və komandanın qərara gəlməsinə kömək edir. O, hazır həll diktə etmir, düzgün suallar verir və müzakirəni yayındırmır.
• Product Owner backlog-un prioritetlərinə və hansı funksiyanın birinci hazırlanacağına görə cavabdehdir. O, hər hekayənin biznes üçün dəyərini izah etməyə və komandanın suallarına qiymətləndirmə aparmaq üçün kifayət qədər konkret cavab verməyə hazır olmalıdır.
• Tərtibat komandası nəticəni çatdırmağı öhdəsinə götürür. Bu öhdəlik kənardan təyin olunmamalı, komandanın özündən gəlməlidir. Komandanın özü götürdüyü öhdəlik yuxarıdan qoyulan hədəfə nisbətən başqa cür motivasiya və məsuliyyət hissi yaradır.

Ümumi səhvlər

• İmkanları şişirtmək sprint planlaşdırmasında ən çox rast gəlinən səhvdir. Komandalar mütəmadi olaraq bitirə biləcəklərindən çox iş götürür, xüsusən layihənin əvvəlində və ya uğurlu bir sprintdən sonra. Qayda sadədir: az söz verib çox etmək, çox söz verib az etməkdən yaxşıdır. Yerinə yetirilməyən öhdəliklər maraqlı tərəflərin etibarını sarsıdır və sonrakı sprintlərdə komandanın ruhunu düşürür.
• Vaxt ehtiyatının olmaması ciddi struktur səhvidir. Sprint planında gözlənilməz tapşırıqlar, xətalar və texniki dəstək sorğuları üçün 10-20% ehtiyat vaxt qalmalıdır. Bu ehtiyatı əvvəlcədən əlavə hekayələrlə doldurmaq olmaz. Onun işi hər sprintdə mütləq çıxan plandankənar işi qəbul etməkdir.
• Asılılıqları nəzərə almamaq sprintin ortasında tıxac yaradır. Bütün xarici asılılıqlar planlaşdırma zamanı üzə çıxarılmalı və həll edilməlidir. Tapşırıq başqa komandadan və ya kənar təchizatçıdan asılıdırsa, son tarixlər qabaqcadan razılaşdırılmalı, təsdiqlər sprint başlamazdan əvvəl alınmalıdır.

Proses monitorinqi

Yetkin Agile komandası planlaşdırmanın özünü də təkmilləşdirir. Retrospektivdə təkcə sprintin necə icra olunduğuna baxılmır, planlaşdırmanın keyfiyyəti də ayrıca amil kimi təhlil edilir.

Təhlil üçün metriklər:

• Qiymətləndirmə dəqiqliyi: hər hekayə və tapşırıq üzrə planlaşdırılan və faktiki sərf olunan vaxtın müqayisəsi
• Tamamlanmış hekayələrin faizi: sprintə götürülən hekayələrdən neçəsinin sprint bitənədək çatdırıldığı
• Planlaşdırmadan sonra sprintdə edilən dəyişikliklərin sayı: planın nə qədər sabit və tələblərin nə qədər aydın olduğunu göstərir
• Planlaşdırmaya sərf olunan vaxt: həmişə çox və ya həmişə az vaxt ayrıldığını görmək üçün adi göstəricilərlə müqayisə edilir

Burndown qrafiki sprint boyu irəliləyişi izləyir və problemləri vaxtında düzəliş etmək mümkün olan mərhələdə göstərir. Qrafik komandanın planlanan işi çatdırmayacağını göstərirsə, gözləmək olmaz. Qalan tapşırıqların prioritetini yenidən müəyyən edin və ya ən aşağı prioritetli user story-ləri sprintdən çıxarın.

Planlaşdırmanın uyğunlaşdırılması

• Uzaqdan işləyən komandalar üçün sprint planlaşdırması xüsusi uyğunlaşma istəyir. Əməkdaşlıq üçün lazımi alətlər hazır olmalı, uzaqdakı bütün iştirakçıların bərabər söz haqqı olmasına fəal nəzarət edilməlidir. Paylanmış komandalarda planlaşdırmanı bir uzun görüş əvəzinə bir neçə qısa sessiyada keçirəndə iştirak da, nəticənin keyfiyyəti də adətən yüksəlir.
• Bir neçə komandanın işlədiyi böyük proqramlarda proqram səviyyəsində koordinasiya lazımdır. Scrum of Scrums və ya SAFe (Scaled Agile Framework) ortaq asılılıqları olan komandaların sprint planlaşdırmasını uzlaşdırmaq üçün hazır mexanizmlər verir.
• Texniki xidmət layihələrində sprint vaxtının xeyli hissəsi dəstəyə və xətaların düzəldilməsinə gedir, ona görə də plandankənar iş üçün açıq ehtiyat saxlamaq lazımdır. Adətən sprint tutumunun 30-50%-i dəstək işinə ayrılır, qalanı yeni funksiyaların hazırlanmasına qalır. Bu bölgü dəstək işini planın bir hissəsi kimi görməyə imkan verir. Onu sonradan üstə gələn əlavə yük sayanda isə çatdırılma pozulur.

Əlaqəli məqalələr:

Layihə idarəetmə çərçivələri və məhdudiyyətlər arasında tarazlıq barədə oxuyun: Layihə idarəetmə üçbucağı: əhatə dairəsi, vaxt və xərclərin tarazlanması.

Kanban lövhələri və iş axınının vizual idarə olunması barədə praktik icmal üçün oxuyun: Kanban lövhəsi nədir? Vizual iş axını idarəetməsinə bələdçi.

Agile komandalarının istifadəçinin real ehtiyaclarından uzaqlaşmamaq üçün personajlardan necə yararlandığını öyrənmək üçün oxuyun: Agile personajlar: Agile layihələrində istifadəçi mərkəzli inkişafın gücləndirilməsi. Daha çox oxuyun: Kanban lövhəsi.

Nəticə

Yaxşı sprint planlaşdırması layihədən sonra xatırlanan formallıq olmamalıdır. Bu, sistemli yanaşma tələb edən şüurlu işdir. Onu daim təkmilləşdirmək lazımdır. Retrospektivlər sprintin nəticələri ilə yanaşı, o nəticələri formalaşdıran planlaşdırma qərarlarını da təhlil etməyə imkan verir. Beləliklə, Agile məhsulun hazırlanmasında tətbiq etdiyi addım-addım təkmilləşdirməni planlaşdırma prosesinin özünə də tətbiq edir.