Agile: backlog-u iş siyahısından nəticə xəritəsinə çevir

Komanda çox işləyir, sprint tamamlanır, task-lar bağlanır. Amma məhsulun istifadəçisi üçün nə dəyişib? Agile komandalarla işləyərkən bu sualı tez-tez verirəm. Çünki backlog dolu olanda işləmək asandır; nəyin əvvəl gəlməli olduğunu seçmək isə məhsul düşüncəsi tələb edir.

İş sayı ilə nəticəni ayır

Tamamlanan task-lar komandanın gördüyü işi göstərir. İstifadəçinin işini daha rahat tamamlaması isə nəticədir. Hər ikisini bilmək faydalıdır, amma onları eyni qəbul etmək düzgün deyil. Sürətli işləyən komanda yanlış problemi də sürətlə həll edə bilər.

Məhsul məqsədini davranış və ya biznes nəticəsi ilə ifadə etmək qərarları aydınlaşdırır. “Yeni dashboard hazırlamaq” əvəzinə, “biznes sahibinin günün rezervasiyalarını daha rahat izləməsi” kimi məqsəd yazmaq olar. Dashboard həll variantıdır; nəticə isə səbəbdir.

Backlog elementinin səbəbi görünməlidir

Hər böyük backlog elementi üçün üç şey yazmağı faydalı hesab edirəm: kim üçün işləyirik, hansı problemi dəyişirik və necə yoxlayacağıq? Bu çərçivə stakeholder-lərlə söhbəti də asanlaşdırır. “Bu funksiya vacibdir” yerinə, konkret istifadəçi vəziyyətini müzakirə edirik.

User story yazmaq bu işin bir hissəsidir, amma tək başına kifayət etmir. Story-nin içində istifadəçinin ehtiyacı, acceptance criteria-da isə həllin sərhədi görünməlidir. “Sistem sürətli olsun” test edilə bilən ifadə deyil. Hansı proses, hansı şərait və hansı gözlənti nəzərdə tutulduğunu dəqiqləşdirmək lazımdır.

Prioritet razılaşma deyil, qərardır

Hər stakeholder-in istəyi eyni anda prioritet ola bilməz. Məhsul liderinin işi sadəcə tələbləri toplamaq yox, bir-biri ilə rəqabət aparan istəklər arasında qərar verməkdir. Bu qərar istifadəçi təsiri, biznes əhəmiyyəti, risk və iş həcmi nəzərə alınaraq verilməlidir.

• İndiki məhsul məqsədinə uyğunluq.
• Problemin istifadəçi üçün əhəmiyyəti.
• Əlimizdəki sübutun gücü.
• Asılılıqlar və texniki risklər.
• Öyrənməyə və nəticəyə qədər məsafə.

RICE və ya başqa çərçivə düşüncəni nizamlaya bilər, amma rəqəmlərə saxta dəqiqlik vermək lazım deyil. Məlumat zəifdirsə, score da zəifdir. Belə vəziyyətdə qısa discovery işi böyük development qərarından daha yaxşı başlanğıc ola bilər.

Sprint məqsədi komandanı birləşdirir

Sprint yalnız müəyyən sayda işin seçildiyi vaxt bölməsi kimi qalanda komanda parçalanır. Hər kəs öz task-ını edir, amma ümumi dəyişiklik görünmür. Aydın sprint məqsədi işlər arasında əlaqə yaradır və planın içində seçim etmək üçün istiqamət verir.

Planlama zamanı komandanın məqsədə necə çatacağını birlikdə müzakirə etmək vacibdir. Product Owner nəyin dəyərli olduğunu aydınlaşdırır; komanda isə həyata keçirmə yanaşmasını və real imkanları gətirir. Bu əməkdaşlıq tələblərin sadəcə ötürülməsindən daha sağlamdır.

Review yalnız təqdimat deyil

Sprint Review-də ekranları nümayiş etdirmək olar, amma əsas sual “nə hazırladıq?” ilə bitməməlidir. Göstərilən həll məqsədə yaxınlaşdırırmı? İstifadəçi prosesində hansı yeni məlumat yaranıb? Əvvəlki fərziyyələr dəyişibmi? Sonrakı prioritetə bunun təsiri nədir?

Stakeholder rəyi konkret istifadə ssenarisi ilə bağlananda daha faydalı olur. Hər yeni istəyi dərhal backlog-un yuxarısına əlavə etmək əvəzinə, məqsədlə əlaqəsini yoxlamaq lazımdır. Review öyrənmə və uyğunlaşma üçün fürsətdir.

Sadə bir komanda məşqi

Növbəti refinement-də backlog-dan beş element seç. Hər element üçün “bunu etməsək istifadəçi və ya biznes üçün hansı problem qalacaq?” sualını ver. Cavab aydın deyilsə, həmin işin səbəbini yenidən araşdır. Sonra elementləri məhsul məqsədinə görə qruplaşdır və minimum işlək dəyişiklik üçün hansı hissələrin birlikdə lazım olduğunu qeyd et.

Daha yaxşı backlog daha uzun siyahı deyil. Daha aydın seçimlərdir.

Bu yanaşmaları real tapşırıqlarla işləmək üçün Product Ownership və Agile təlimlərimə qoşula bilərsən. Təlim keçidi aşağıdadır.