Scrum vadovas | 40. Produkto backlog’o puoselėjimas

Produkto backlog’o puoselėjimas yra viena iš pagrindinių Produkto savininko užduočių. Puoselėjimo procesas apima naujų vartotojo istorijų formulavimą, detalizavimą ir pridėjimą prie Produkto backlog’o. Tačiau svarbiausia iš puoselėjimo užduočių yra užtikrinti, kad įrašai, esantys backlog’e, būtų teisinga tvarka, t. y. būtų prioritetizuoti.

Produkto backlog’o puoselėjimas – turinys:

1. Įvadas
2. Produkto backlog’o puoselėjimo tikslas
3. Klaidos prižiūrint Produkto backlog’ą
4. Backlog’o priežiūra vs. Scrum’e naudojami metrikai
5. Santrauka

Įvadas

Produkto backlog’as yra vienas iš Scrum artefaktų. Jame yra prioritetizuotas darbų sąrašas, reikalingas Produktui sukurti. Kitaip tariant, tai yra vartotojo istorijų sąrašas, būtinas Produkto tikslo pasiekimui. Išsamesnį aprašymą, kas yra vartotojo istorijos, galite rasti šiuo straipsniu. O čia rasite detales apie Produkto backlog’o savybes ir kaip jį prižiūrėti.

Produkto backlog’o puoselėjimas taip pat vadinamas šiais pavadinimais:

• Backlog’o prioritetizavimas,
• Backlog’o tobulinimas,
• Backlog’o plėtra.

Produkto backlog’o puoselėjimo tikslas

Produkto savininkas valdo Produkto backlog’ą. Pagrindinės įgūdžių sritys apima užduočių prioritetizavimą, kai artėja jų atlikimo terminas. Tai yra todėl, kad Produkto backlog’o puoselėjimo tikslas yra užtikrinti, kad Produkto funkcionalumai turėtų didžiausią verslo vertę, t. y. tie, kurie yra patys svarbiausi Kliento požiūriu, būtų sąrašo viršuje. Ir jų aprašymas yra aiškus ir išsamus, kad jų įgyvendinimas galėtų prasidėti jau kitame Sprint’e.

Produkto backlog’as gali būti atnaujinamas kasdien, jei reikia. Produkto savininkas gali pridėti naujas vartotojo istorijas prie Produkto backlog’o po pokalbio su suinteresuotaisiais asmenimis ir plėtros komanda arba darydamas išvadas ir reformuluodamas jau parašytas vartotojo istorijas Produkto backlog’e.

Privalomas backlog’o atnaujinimas yra viena iš užduočių, atliekamų Sprint’o peržiūros metu. Mes išsamiai aprašėme šį procesą šiuo straipsniu. Paprastai šio susitikimo metu Scrum komanda aptaria ne tik užduotis, kurias reikia atlikti kitame Sprint’e. Ji taip pat preliminariai nurodo vartotojo istorijas ir jų įgyvendinimą per artimiausius du ar tris Sprint’us. Šis požiūris leidžia Scrum komandai ir jos veiklai plačiau pažvelgti į ilgalaikę kryptį. Tai leidžia galvoti apie šiuo metu atliekamas užduotis iš jų plėtros perspektyvos būsimuose Sprint’uose.

Klaidos prižiūrint Produkto backlog’ą

Viena iš dažniausiai pasitaikančių problemų, susijusių su Produkto backlog’o puoselėjimu, yra leisti jam plėstis nekontroliuojamai. Tai yra todėl, kad dirbant su Produktu, įvairios papildomos funkcijos ir užduotys, pasiūlytos tiek suinteresuotųjų asmenų, tiek Scrum komandos narių, spontaniškai atsiranda. Todėl riboti Produkto backlog’o apimties augimą (scope creep) yra viena iš svarbiausių užduočių, kurias atlieka Produkto savininkas. Dažniausios klaidos, kurias daro Produkto savininkai, susijusios su:

1. Nuokrypiu nuo Produkto tikslo – pridėti per daug idėjų prie Produkto backlog’o, viršijančių pagrindinį Produkto tikslą, nėra gera praktika, nes tai labai sumažina jo skaitomumą. Geriau rinkti idėjas papildomoms funkcijoms atskirame dokumente.
2. Turinio dubliavimu – įrašant pakartotines ar labai panašias idėjas iš skirtingų suinteresuotųjų asmenų į backlog’ą – prieš pridėdamas kitą įrašą į backlog’ą, Produkto savininkas turėtų įsitikinti, kad naujas įrašas nedubliuoja jokio iš esamų.
3. Platesnio požiūrio trūkumu – turėtumėte tvarkyti Produkto backlog’o įrašus pagal jų vertę, susijusią su Produkto tikslu. Vis dėlto turėtumėte atsižvelgti į artimiausius kelis Sprint’us, kad užduotys, atliekamos tam tikrame Sprint’e, būtų sklandžiai susijusios tiek su ankstesniu Sprint’u, tiek su iš karto po jo einančiu Sprint’u.

Negalite išvengti tokio pobūdžio klaidų. Tačiau žinojimas apie jų atsiradimą gali padaryti Produkto savininką atsargesnį pridėdamas naujas vartotojo istorijas prie Produkto backlog’o, kad būtų pasiektas tinkamas balansas. Tai yra todėl, kad taip pat yra klaida per daug sumažinti backlog’ą ir pašalinti įrašus, kurie apima panašias užduotis, kurios skiriasi. Pavyzdžiui, aprašant panašias Produkto funkcijas, kurios labai skiriasi taikymo požiūriu.

Backlog’o priežiūra vs. Scrum’e naudojami metrikai

Produkto backlog’as apima likusio darbo aprašymą viso projekto metu. Tačiau tik atnaujintas ir reguliariai puoselėjamas backlog’as gali tiksliai įvertinti atlikto darbo kiekio ir viso darbo santykį. Norint pavaizduoti atlikto darbo kiekį, turėtumėte taikyti Burndown diagramą, apie kurią rašėme šiuo straipsniu.

Dar viena populiari metrika, apibūdinanti Scrum komandos darbą, yra Greitis. Jį galite matuoti, palygindami Produkto backlog’o įrašų skaičių, paverstą Increment per vieną Sprint’ą. Mes išsamiau aprašėme Greitį šiuo straipsniu.

Santrauka

Produkto savininkas atlieka Produkto backlog’o puoselėjimą. Kai Produkto backlog’as yra gerai prižiūrimas, Scrum komanda turi aiškų vaizdą apie likusį darbą. Ji taip pat gali gauti platesnį, į ateitį orientuotą požiūrį į tai, kaip atrodo kelias į Produkto tikslą. Štai kodėl Produkto savininkas turi užtikrinti, kad vartotojo istorijos, įtrauktos į Produkto backlog’ą, būtų prioritetizuotos pagal užbaigimo tvarką. Ir taip pat, kad užduotys, kurias reikia atlikti artimiausiuose Sprint’uose, būtų aprašytos kuo išsamesnėmis detalėmis.

Jei jums patinka mūsų turinys, prisijunkite prie mūsų užimtų bičių bendruomenės Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.