Agile dəyişiklik qarşısında öyrənməyi və dəyər yaratmağı önə çəkən düşüncə tərzidir. Scrum isə mürəkkəb iş üçün konkret çərçivədir. Bu iki sözü eyni mənada işlətmək anlaşılmazlıq yaradır: hər çevik komanda Scrum istifadə etmir, Scrum tədbirlərini keçirmək də özlüyündə çevik düşüncə yaratmır. Layihə idarəetməsində əsas sual metod adını seçmək deyil, qeyri-müəyyən işi necə kiçik hissələrdə yoxlayacağınızı müəyyənləşdirməkdir.
Agile nəyi dəyişir?
Agile Manifesto prinsipləri müştəriyə erkən dəyər çatdırmağı və dəyişən tələblərə uyğunlaşmağı vurğulayır. Bu prinsiplər metod seçimi üçün kontekst verir, bütün təşkilatlara eyni icra resepti deyil.
Ənənəvi planlama bəzi işlərdə yaxşı işləyir: tələblər sabit, nəticə və icra yolu əvvəlcədən məlumdursa, detallı ardıcıllıq səmərəli ola bilər. Mürəkkəb məhsul və xidmət işində isə istifadəçi ehtiyacı, texnologiya və bazar haqqında məlumat iş gedərkən açılır. Agile yanaşması bu öyrənməni planın uğursuzluğu kimi deyil, qərar prosesinin hissəsi kimi qəbul edir. Komanda kiçik nəticə yaradır, istifadəçidən və iş nəticəsindən məlumat alır, sonra növbəti addımı düzəldir.
Bu, “plan yoxdur” demək deyil. Məqsəd, prioritet və keyfiyyət standartı yenə lazımdır. Fərq ondadır ki, plan dəyişməz fərziyyə kimi qorunmur. Məsələn, yeni müştəri portalında bütün funksiyaları bir il ərzində hazırlamaq əvəzinə, ən kritik müraciət axını pilotda yoxlanıla bilər. İstifadəçi orada ilişirsə, qalan funksiyaları çoxaltmadan əvvəl problemi həll etmək daha mənalıdır.
Scrum-un üç məsuliyyəti
Rəsmi Scrum Guide Scrum Team daxilində Product Owner, Scrum Master və Developers məsuliyyətlərini təsvir edir. Product Owner məhsul dəyəri və Product Backlog-un idarəsinə cavabdehdir. Scrum Master çərçivənin düzgün başa düşülməsinə və maneələrin aradan qaldırılmasına xidmət edir. Developers isə hər Sprint-də istifadə edilə bilən Increment yaradır. Bu adlar şirkət iyerarxiyası haqqında hökm deyil; çərçivə daxilində qərar məsuliyyətlərini aydınlaşdırır.
Bir şəxsin birdən çox təşkilati vəzifəsi ola bilər, lakin Scrum məsuliyyətləri qarışdıqda qərar bulanıqlaşır. Məsələn, hər maraqlı tərəf backlog prioritetini ayrıca dəyişirsə, Product Owner qərar verə bilmir. Rəhbərlik komandanın məqsəd və məhdudiyyətini aydın saxlamalı, gündəlik işin bütün detalları üzərində mikro nəzarət qurmamalıdır.
Sprint və hadisələr nə üçündür?
Sprint müəyyən müddətli iş dövrüdür; nəticədə dəyərli Increment yaratmağa xidmət edir. Sprint Planning-də niyə və nə üzərində işlənəcəyi, necə başlanacağı müzakirə edilir. Daily Scrum Developers üçün qısa koordinasiyadır, rəhbərə fərdi hesabat səhnəsi deyil. Sprint Review maraqlı tərəflərlə nəticəyə baxış və gələcək istiqamətin müzakirəsidir. Retrospective isə komandanın iş üsulunu yaxşılaşdırmaq üçündür. Hər tədbirin məqsədi yoxdursa, təqvim yükünə çevrilir.
Sprint “iki həftəlik tapşırıq siyahısı” kimi başa düşülməməlidir. Sprint Goal seçilən işləri bir nəticə ətrafında birləşdirir. Gündəlik dəyişiklik ortaya çıxanda komanda onun məqsədə təsirini dəyərləndirə bilir. Hər yeni istəyi dərhal əlavə etmək Sprint-in fokusunu pozur. Eyni zamanda yeni faktı görməməzliyə vurmaq da çeviklik deyil; Product Owner və komanda prioriteti məlumatla yeniləyir.
Backlog və keyfiyyət meyarı
Product Backlog məhsulu yaxşılaşdırmaq üçün lazım olduğu bilinən işlərin nizamlanmış siyahısıdır. Siyahının hər bəndi eyni detallı olmamalıdır; yaxın iş daha aydın, uzaq ehtimallar daha qısa ola bilər. Prioritet yalnız kimin yüksək səslə tələb etməsi ilə seçilməməlidir. Dəyər, risk, asılılıq və öyrənmə ehtiyacı birlikdə baxılır. Bəndi kiçik və yoxlanıla bilən nəticəyə çevirmək planlamanı asanlaşdırır.
Definition of Done işin həqiqətən tamam sayılması üçün ortaq keyfiyyət meyarıdır. Test, sənədləşmə, təhlükəsizlik və istifadəçi təcrübəsi tələbləri mövzuya uyğun burada yer ala bilər. “Kod yazıldı, amma yoxlanmadı” işi bitmiş kimi təqdim etmək şəffaflığı azaldır. Keyfiyyət meyarı olmadan sürət göstəricisi aldadıcıdır: çox tapşırıq bağlanır, sonra təkrar düzəliş artır.
Agile hər təşkilata eyni qaydada uyğundurmu?
Yox. Tənzimlənən mühitdə təsdiq, audit izi və müqavilə öhdəlikləri saxlanmalıdır. Scrum komandanın öyrənmə və koordinasiya formasını verə bilər, amma qanuni və təhlükəsizlik tələblərini ləğv etmir. Fiziki istehsalda material tədarükü və avadanlıq qrafiki daha uzun plan tələb edə bilər. Metodu məqsədə uyğunlaşdırarkən əsas prinsipləri də gizlicə pozmayın; rəsmi Scrum adından istifadə edirsinizsə, onun məsuliyyət və hadisələrini düzgün izah edin.
Komanda ilə müştəri arasında əlaqə yoxdursa, qısa Sprint-lər özlüyündə dəyər yaratmayacaq. Müştəri geribildiriminə çıxış, qərar vermə səlahiyyəti və keyfiyyət üzrə razılaşma lazımdır. Rəhbər komandanın qarşısına yalnız “daha sürətli olun” tələbi qoyursa, nəticə əlavə görüş ola bilər. İşlək başlanğıc real bir məhsul problemini seçmək və onun üzərində kiçik nəticəni yoxlamaqdır.
Praktiki məşq: kiçik pilot
Bir komanda ilə iki həftəlik pilot qurun. Məhsul və ya proses üçün bir aydın məqsəd seçin; məsələn, müraciət formasındakı anlaşılmaz addımı azaltmaq. Product Backlog-da ən vacib üç işi yazın. Hər birinə “tamamlandı” meyarı qoyun. Sprint əvvəlində məqsədi və tutumu razılaşdırın, gündəlik qısa koordinasiya edin. Sonda nəticəni real istifadəçi və ya maraqlı tərəflə yoxlayın. Retrospektivdə bir proses dəyişiklik seçin.
Pilotun nəticəsini “neçə xal tamamlandı?” ilə məhdudlaşdırmayın. İstifadəçi problemi həll oldumu, hansı fərziyyə yanlış çıxdı, keyfiyyət meyarı qorundumu? Bu suallar çevik işin əsasını göstərir. Göstəricilər komandaları bir-birinə qarşı sıralamaq üçün yox, öz iş proseslərini yaxşılaşdırmaq üçün istifadə olunmalıdır.
İş nümunəsi: sprint var, nəticə görünmür
Bir məhsul komandası hər iki həftədə Sprint Planning və Daily Scrum keçirir, amma istifadəçiyə görünən dəyişiklik azdır. İşlərin çoxu “demək olar hazır” statusunda qalır. Komanda əvvəl tədbirlərin sayını artırmaq əvəzinə Definition of Done-u yoxlayır. Məlum olur ki, test və məzmun yoxlaması Sprint-in sonunda başqa şöbəyə ötürülür. Buna görə iş siyahıda bağlansa da istifadə oluna bilən Increment yaranmır. Komanda növbəti Sprint-də daha az iş götürür və test asılılığını əvvəlcədən planlayır.
Sprint Review-da slayd hesabatı əvəzinə işləyən axın göstərilir. Maraqlı tərəf bir istifadəçi sualının hələ anlaşılmadığını bildirir. Product Owner bunu backlog-da yeni iş kimi nizamlayır. Retrospektivdə komanda gecikmənin səbəbini şəxslərin “yavaşlığı” ilə yox, keyfiyyət addımının prosesdən kənarda qalması ilə əlaqələndirir. Növbəti sınaq üçün test mütəxəssisini planlamaya daha erkən daxil edir.
Bir Sprint sonra bütün nəticənin yaxşılaşması zəmanət deyil. Lakin daha az yarımçıq iş və daha aydın istifadəçi geribildirimi komandanın nə öyrəndiyini göstərir. Scrum tədbirlərinin dəyəri təqvimin dolmasında yox, şəffaflıq, yoxlama və uyğunlaşma imkanında görünür. Çərçivəni “gündəlik hesabat” mexanizminə endirmək həmin imkanı zəiflədir.
Scrum tətbiqindən əvvəl yoxlama siyahısı
Məhsul və ya xidmət üçün qərar sahibi aydındırmı? Komanda işin müəyyən hissəsini müstəqil tamamlayacaq səlahiyyətə malikdirmi? Hər qısa dövrdə istifadə edilə bilən nəticəni yoxlamaq mümkündürmü? Maraqlı tərəflər geribildirim verməyə hazırdırmı? Keyfiyyət meyarı və təhlükəsizlik tələbləri əvvəlcədən məlumdurmu? Bu suallardan birinə cavab yoxdursa, yalnız tədbir adlarını təqvimə əlavə etmək problemin kökünü həll etməyəcək.
Başlanğıcda istifadə olunan terminləri komanda ilə eyni cür izah edin. “Done”, “hazır”, “təklif” sözləri fərqli mənada işlənirsə, lövhə görünən olsa da anlaşma zəifdir. İlk retrospektivlərdə bir düzəliş seçin və sonrakı dövrdə onun təsirini yoxlayın. Çox sayda paralel proses dəyişiklik səbəb-nəticəni görməyi çətinləşdirir.
İlk pilotun uğur meyarı
Pilotun sonunda “Scrum tətbiq olundu” ifadəsi əvəzinə üç sualı cavablandırın. İstifadəçi və ya maraqlı tərəf üçün işlək nəticə yarandımı? Komanda əvvəl bilmədiyi hansı məlumatı öyrəndi? Növbəti dövrdə hansı bir iş qaydasını dəyişəcək? Əgər cavab yalnız görüş sayı və lövhədə bağlanan kartdırsa, dəyər barədə məlumat hələ zəifdir. Keyfiyyət meyarı qorunmadan bağlanan kartlar irəliləyiş sayılmamalıdır.
Rəhbərlik bu nəticələri komandanı fərdi reytinqə salmaq üçün istifadə etməsin. Məqsəd mürəkkəb işdə qeyri-müəyyənliyi azaltmaqdır. Müştəri rəyinin gec gəlməsi və ya asılılıq səbəbindən nəticə zəifdirsə, komandanın səlahiyyətini və əlaqə yolunu düzəldin. Sonra eyni meyarla növbəti dövrə baxın. Bu öyrənmə intizamı çevik yanaşmanın gündəlik mənasıdır.
Tez-tez verilən suallar
Agile və Scrum eynidirmi?
Xeyr. Agile ümumi yanaşmadır; Scrum isə müəyyən məsuliyyət, hadisə və artefaktları olan konkret çərçivədir.
Scrum Master layihə rəhbəridirmi?
Rəsmi çərçivədə Scrum Master komandanın Scrum-u effektiv tətbiq etməsinə cavabdehdir. O, bütün tapşırıqları fərdi qaydada paylayan klassik rəhbər rolu deyil.
Sprint bitəndə bütün backlog bitməlidirmi?
Xeyr. Sprint məqsədi və seçilmiş işlər üçün tamamlanmış Increment vacibdir; Product Backlog davamlı inkişaf edir.
Scrum yalnız proqram təminatı üçündürmü?
Scrum Guide mürəkkəb problemlər üçün geniş tətbiqi təsvir edir. Uyğunluq işin təbiətindən, komanda səlahiyyətindən və nəticənin yoxlanma imkanından asılıdır.
Növbəti addım
Layihə qərarlarının biznes tərəfini dərinləşdirmək üçün AİTM-in layihələrdə biznes düşüncəsi təliminə baxın. Bu proqram xüsusi Scrum sertifikasiya kursu kimi təqdim edilmir. Bizə yazın; əlaqəli oxu: vaxtın idarə edilməsi və peşəkar idarəetmə.