Press "Enter" to skip to content

Sestavení backlogu

Začínáme první sprint, takže musíme sestavit backlog. Nebude to těžké, na rozjezd budeme dělat jen jednu „user story“.

Zadavatel nám sdělil, že zákazníci nerozumí informacím na „děkovací obrazovce“ v eShopu. Z toho sestavujeme „epic“ v tomto znění: „Jako zákazník chci srozumitelné a přesné informace po odeslání objednávky, abych rozuměl v jakém je stavu a nevolal na podporu.“

Nemám vážnějších námitek – story je trochu pochybná, obchodní hodnota vágní, ale sám jsem si vyzkoušel, že ten problém opravdu existuje, tak proč ho nevyřešit. Něčím začít musíme.

Problém nastal ve chvíli, kdy jsme to začali porcovat na „deliverables“, které si mezi sebe rozdělíme. Jsme v korporaci, takže každý je specialista. Máme tu:

  • business analytika který umí jen přepsat zadané požadavky do podoby, které rozumí vývojáři
  • grafika, který dělá jen počítačovou grafiku
  • SW designéra, který umí jen „detailní design“ (něco jako programování, ale ve Wordu)
  • UX designéra, který umí jen vyrábět wireframy
  • copywritera, který umí jen psát texty
  • testera, který umí dělat jen UAT testy
  • druhého testera, co umí jen určitou formu integračních testů
  • kodéra, který umí jen HTML, CSS a Javascript
  • programátora, který umí jen programovat obrazovky nad naším CRM systémem

Většinový názor je, že každý má odbavit jeden úkol, takže vznikají tyto úkoly:

  • sestavit „business zadání“ (business analytik)
  • vyrobit wireframe (UX designér)
  • připravit texty (copywriter)
  • vyrobit HTML šablonu (kodér)
  • vyrobit seznam požadavků (business analytik)
  • připravit „detailní design“ (SW designér)
  • vyvinout to (programátor)

Připadám si jak v Jiříkově vidění. Oni si tu demenci ze školení zapamatovali a fakt ji chtějí použít. Je mi jasné, že při tomhle rozdělení si každý bude „hrabat na vlastním písečku“, bude se prokrastinovat a stejně to nakonec nedodáme ve funkčním stavu.

Snažím se vysvětlit, že tým není totéž co skupina jednotlivců. Že bychom to měli rozdělit na jednoduché user stories a pracovat na každé společně. Ale jsem tu jediný kverulant, takže dostávám nálepku toho, kdo akorát zdržuje, a pokračujeme beze změn.

Následně máme odhadnout pracnost jednotlivých „deliverables“. Kodér svoji položku „vyrobit HTML šablonu“ odhaduje na hodinu, protože ví, že jde o jednu obrazovku.

Teď přichází moje komická vložka, ve které svoji práci „vyrobit wireframe“ odhaduju na 60h. Lidi se smějou, ale odhaduju že některé brzy smích přejde – zatím nevím, v kolika user stories se ta obrazovka objevuje, ale už jsem jich napočítal dvacet a zdaleka nejsem u konce.

Na někoho, kdo dělal opravdový agilní vývoj, může působit otázka „Co bude položkou backlogu“ trochu hloupě, možná absurdně, ale není radno ji podcenit. V drtivé většině případů se sice nespletete, pokud do backlogu dáváte klasické user stories – lidé jim rozumí, dobře nesou „business value“, dobře se prioritizují a odhady se na ně také dělají celkem v pohodě. Pěkně to popsala Zuzana Šochová: https://soch.cz/blog/management/agile/proc-piseme-user-story/

Zažil jsem ale taky týmy, které měly backlog organizovaný jinak, a fungovalo to:

  • tým, co dělá API, si zvolil jako položku backlogu metodu API
  • tým, který kóduje obrazovky podle dodaných wireframů, má jako položku backlogu vždy jednu konkrétní obrazovku
  • tým, který dělal zákaznický support, měl jako položku backlogu požadavek zákazníka

Tohle je ale třeba dělat na míru konkrétního týmu, nedá se to nějak stanovit direktivně. Dělení backlogu, které funguje pro jeden tým a jeden typ problému, totálně selže pro jiný tým a jiný typ problému.

Co je ale podstatné, a co se strašně těžko vysvětluje: backlog vždy musí být sestavený tak, aby šel prioritizovat. A prioritizovat neznamená říci si, co uděláme teď a co potom. Prioritizovat znamená říci si, na čem nebudeme dělat. A to klidně i během sprintu, když nestíháme.

Náš backlog je tedy nefunkční – vyškrtnutí kterékoli položky způsobí, že i všechny ostatní zcela ztratí hodnotu. Taky už tušíte, co se bude dít na demu?