Product Backlog management

Product Backlog Product Owner-in əsas alətidir. Vision, value və validation haqqında bütün düşüncələr sonda bir sualda cəmlənir: növbəti nə edirik? Backlog bu sualın cavabıdır və onun keyfiyyəti Product Owner-in keyfiyyətinin ən görünən göstəricisidir.

Bu fəsil backlog-un strukturunu, element-lərin necə yazıldığını, sıralama və refinement-i, böyük işi necə kiçik dilimlərə bölməyi və backlog-un sağlamlığını necə qorumağı izah edir.

Backlog nədir

Product Backlog məhsulu yaxşılaşdırmaq üçün lazım ola biləcək hər şeyin sıralanmış siyahısıdır: feature-lər, təkmilləşdirmələr, düzəlişlər, eksperimentlər, texniki iş, araşdırma. Bir neçə prinsip:

• Bir məhsul, bir backlog. Bir məhsul üzərində bir neçə komanda işləyirsə də, backlog birdir. Komanda başına backlog məhsulun parçalanmasıdır.
• Sıralanıb, prioritetləşdirilməyib. "Yüksək prioritet" etiketi otuz element-ə vurula bilər; sıra hər element-ə bir yer verir. Növbəti nə edilir, aydındır.
• Yaranmaqdadır. Backlog heç vaxt tam deyil; məhsul yaşadıqca dəyişir. Tam backlog sona çatmış məhsul deməkdir.
• Yeganə mənbədir. Komanda yalnız backlog-dakı işi görür. Yan kanallar, "kiçik xahişlər", birbaşa Developer-ə gələn tapşırıqlar backlog-u dəyərsizləşdirir.

DEEP

Roman Pichler-in sağlam backlog üçün dörd meyarı:

• Detailed appropriately. Yuxarı element-lər kiçik və aydın, aşağı element-lər böyük və qaba. Bütün backlog-u eyni detalla yazmaq vaxt itkisidir, çünki aşağıdakıların çoxu heç vaxt qurulmayacaq və ya başqa formada qurulacaq.
• Emergent. Öyrəndikcə dəyişir.
• Estimated. Ən azı yuxarı hissə ölçülüb ki, planlaşdırma və proqnoz mümkün olsun.
• Prioritized (sıralanmış). Yuxarıdakı ən dəyərlidir.

Backlog-un forması piramida kimidir: yuxarıda bir-iki Sprint-lik hazır, kiçik element; ortada bir neçə ay üçün orta ölçülü, qismən aydın element; aşağıda böyük, qaba, bəlkə də yalnız bir cümlə ilə ifadə olunmuş fikirlər.

Element-lərin yazılması

User story

Ən geniş yayılmış format:

[Rol] olaraq, [məqsəd] istəyirəm ki, [fayda].

Formatın gücü sonuncu hissəsindədir: fayda. "İstifadəçi olaraq, export düyməsi istəyirəm" niyə-ni demir. "Mühasib olaraq, aylıq hesabatı Excel-ə export etmək istəyirəm ki, auditorla əl ilə yenidən yazmadan paylaşa bilim" həm problemi, həm həllin dəyərini deyir və Developer-lərə başqa həll təklif etmək imkanı verir.

User story sənəd deyil, söhbət üçün vədir. Ron Jeffries-in üç C-si: Card (qısa yazı), Conversation (Developer-lərlə söhbət), Confirmation (qəbul meyarları). Story-nin dəyəri kartdakı mətnində deyil, onun ətrafında gedən söhbətdədir.

Qəbul meyarları

Hər story-nin nə vaxt "hazır" sayılacağını deyən konkret şərtlər. Given-When-Then formatı geniş istifadə olunur:

Given mühasib aylıq hesabat səhifəsindədir, when "Export" düyməsinə basır, then hesabat bütün sütunlarla .xlsx formatında yüklənir.

Qəbul meyarları Definition of Done-dan fərqlidir: Definition of Done hər element üçün eyni keyfiyyət standartıdır; qəbul meyarları hər element-in öz spesifik şərtləridir.

INVEST

Bill Wake-in yaxşı story üçün meyarları:

Story olmayan element-lər

Backlog-da hər şey user story olmalı deyil. Bug, texniki borc ödəməsi, araşdırma (spike), compliance tələbi, eksperiment: bunlar backlog element-idir və Product Owner tərəfindən dəyərə görə sıralanır. Texniki işi süni user story-yə ("Developer olaraq, refactoring istəyirəm ki...") çevirmək lazım deyil; amma onun dəyərini izah etmək lazımdır, məsələn A2I və ya time-to-market baxımından.

Böyük işi dilimləmək

Backlog-un ən vacib bacarığı böyük fikri kiçik, müstəqil dəyər verən dilimlərə bölməkdir. Pis dilimləmə üfüqidir: əvvəl database, sonra API, sonra UI. Hər dilim texniki cəhətdən məntiqlidir, amma heç biri istifadəçiyə dəyər vermir və üçüncü dilim bitənə qədər heç nə yoxlanıla bilmir. Yaxşı dilimləmə şaqulidir: hər dilim database-dən UI-a qədər nazik, amma tam bir axındır.

Şaquli dilimləmə strategiyaları:

• Workflow addımları: tam axının əvvəlcə ən sadə yolu, sonra alternativ yollar.
• Biznes qaydaları: əvvəlcə bir qayda, sonra istisnalar.
• Məlumat variantları: əvvəlcə bir valyuta, bir dil, bir fayl formatı.
• İnterfeys: əvvəlcə sadə form, sonra gözəl dizayn.
• Platforma: əvvəlcə web, sonra mobil.
• Performans: əvvəlcə işləyən, sonra sürətli.
• İstifadəçi seqmenti: əvvəlcə daxili istifadəçilər, sonra müştərilər.

Hər dilimin yoxlanıla bilən olması məqsəddir: dilim release olunur, nəticə ölçülür, növbəti dilim bu nəticəyə görə seçilir və ya silinir.

User story mapping

Jeff Patton-un alətidir. Üfüqi ox istifadəçinin fəaliyyətlərini zaman ardıcıllığı ilə göstərir (qeydiyyat, axtarış, seçim, ödəniş, izləmə); hər fəaliyyətin altında şaquli olaraq bu fəaliyyəti dəstəkləyən story-lər prioritetlə düzülür. Sonra üfüqi xətt çəkilir: xəttin üstündəki hər fəaliyyətdən ən azı bir story release-in minimum scope-udur.

Story map düz siyahının görə bilmədiyi şeyi göstərir: istifadəçinin tam yolunu. Düz backlog-da "ödəniş" story-lərinin hamısının 15-ci Sprint-ə qaldığı görünmür; map-də bu, dərhal görünür.

Impact mapping

Gojko Adzic-in alətidir, dörd səviyyəli ağac: Why (biznes məqsədi, ölçülə bilən), Who (bu məqsədə təsir edə biləcək aktorlar), How (aktorların davranışında istənilən dəyişiklik), What (bu dəyişikliyi yarada biləcək feature-lər). Impact map hər feature-i məqsədə bağlayır; məqsədə bağlanmayan feature map-də yer tapmır. Product Owner üçün bu, "niyə bunu qururuq?" sualının vizual cavabıdır.

Sıralama

Sıra bir neçə faktorun birgə nəticəsidir: dəyər, xərc, risk, asılılıq, öyrənmə dəyəri, bazar pəncərəsi. Fəsil 3-dəki cost of delay və Kano burada tətbiq olunur. Bir neçə praktiki qayda:

• Yüksək dəyər, yüksək qeyri-müəyyənlik əvvəl. Haqqında ən az bildiyimiz, ən çox vəd edən iş əvvəl gəlməlidir ki, tez öyrənək.
• Asılılıqları açıq görün. B A-dan asılıdırsa, A əvvəl gəlir, A-nın dəyəri az olsa da. Amma asılılığı qırmaq, B-ni A-sız dilimləmək daha yaxşıdır.
• Sıra qərardır, hesablama deyil. Bal modelləri kömək edir, amma son söz Product Owner-indir. Modelin nəticəsini şübhəsiz qəbul etmək qərar verməkdən qaçmaqdır.
• Sıranı izah edin. Hər kəs niyə bu element-in o birindən yuxarı olduğunu başa düşməlidir. İzah edə bilmirsinizsə, sıra ya səhvdir, ya da təsadüfidir.

Estimation

Scrum estimation üsulu tələb etmir; empirik planlaşdırma üçün ölçü tələb edir. Variantlar:

• Story point-lər və planning poker: nisbi ölçü, komanda daxilində müqayisə üçün.
• T-shirt ölçüləri (S, M, L, XL): backlog-un aşağı hissəsi üçün qaba, sürətli.
• Saymaq: element-lər kiçik və oxşar ölçüdədirsə, sadəcə sayları ilə proqnoz vermək (throughput). Getdikcə daha çox komanda bunu seçir.

Product Owner üçün estimation-ın dəyəri rəqəmdə deyil, söhbətdədir: Developer-lər bir element-i böyük hesab edirsə, bu, element-in qeyri-müəyyən olduğunu, dilimlənməli olduğunu və ya həllin başqa cür düşünüləcəyini göstərir. Estimation-ın ən pis istifadəsi onu öhdəlik və ya performans ölçüsünə çevirməkdir: story point-lər şişir və bütün ölçü mənasını itirir.

Refinement

Refinement backlog element-lərinə detal, sıra və ölçü əlavə etmək fəaliyyətidir. Scrum-da ayrıca event deyil; Sprint boyu davamlı gedir. Praktiki tövsiyə Sprint-in 10%-ə qədərini buna ayırmaqdır.

Yaxşı refinement:

• Növbəti bir-iki Sprint-ə fokuslanır. Bütün backlog-u refine etmək vaxt itkisidir.
• Birlikdə edilir. Product Owner, Developer-lər, lazım gəldikdə stakeholder və ya istifadəçi. Product Owner-in tək başına yazdığı story-lər söhbətin yoxluğunun əlamətidir.
• Suallarla bitir, cavablarla yox. Element-in "hazır" olub-olmadığına Developer-lər qərar verir: başa düşürük, ölçə bilirik, bir Sprint-ə sığır.
• Silir. Refinement yalnız əlavə etmək deyil; köhnəlmiş, artıq uyğun olmayan element-ləri silmək də refinement-dir.

Bəzi komandalar Definition of Ready istifadə edir: element-in Sprint-ə girməsi üçün minimum şərtlər. Faydalı ola bilər, amma təhlükəsi var: divara çevrilir, "hazır olmayan" element-lər haqqında söhbət dayanır. Checklist-dən çox söhbət vacibdir.

Backlog-un sağlamlığı

Backlog zamanla xəstələnir və Product Owner bunun əlamətlərini tanımalıdır:

• Həddindən artıq böyükdür. Yüzlərlə element, çoxu bir ildən köhnə. Heç kim hamısını oxumur. Dərman: aşağı hissəni amansız silmək. Vacib olan yenidən gələcək.
• Yuxarısı hazır deyil. Sprint Planning uzanır, element-lər Sprint içində aydınlaşdırılır. Dərman: refinement-ə vaxt ayırmaq.
• Hamısı eyni detalda. Ya hamısı qaba (planlaşdırmaq mümkün deyil), ya hamısı detallı (vaxt itkisi). Dərman: piramida forması.
• Stakeholder sifariş siyahısına çevrilib. Hər istək backlog-a düşür, heç nə silinmir. Dərman: vision-a bağlanmayan element-i qəbul etməmək.
• Texniki iş görünmür. Developer-lər texniki borcu gizli, "feature içində" ödəyir. Dərman: texniki işi backlog-a açıq çıxarmaq və A2I ilə əsaslandırmaq.

Fəslin xülasəsi

• Backlog bir məhsul üçün bir dənədir, sıralanıb, yaranmaqdadır və komandanın işinin yeganə mənbəyidir.
• DEEP: yuxarı detallı, aşağı qaba; piramida forması.
• User story söhbət üçün vəddir; dəyəri "niyə" hissəsində və qəbul meyarlarındadır. INVEST sağlam story-nin meyarlarıdır.
• Böyük işi şaquli dilimləyin: hər dilim tam, nazik, yoxlanıla bilən axındır. Story mapping və impact mapping bunun alətləridir.
• Sıra dəyər, xərc, risk və asılılığın birgə nəticəsidir, amma hesablama deyil, qərardır və izah oluna bilməlidir.
• Refinement davamlı, birgə və növbəti bir-iki Sprint-ə fokuslanmış fəaliyyətdir; silmək də refinement-dir.