Month: Luty 2016

Czy warto suszyć i całować Backlog?

W jed­nym z moich poprzed­nich arty­ku­łów pisa­łam o tym, że:

W Scrumie za jakość odpowiada zespół deweloperski.

Pisa­łam też o tym że dobry Pro­dukt Bac­klog, deli­kat­nie mówiąc, uła­twia spra­wę. W inte­re­sie zespo­łu jest więc wspo­ma­gać PO jak tyl­ko może w utrzy­ma­niu porząd­ne­go Pro­duct Bac­klo­gu. Nie doty­czy to tyl­ko osób wyko­nu­ją­cych zada­nia zwią­za­ne z biz­ne­sem. Pro­gra­mi­stom też się przy­da dobre źró­dło infor­ma­cji o pro­duk­cie.

Do cze­go?

Będę to powta­rzać do znu­dze­nia.

Każda osoba w zespole deweloperskim podejmuje codziennie dziesiątki decyzji. Mogę one wspierać wizję Product Ownera i jego priorytety lub… coś całkiem innego.

Co? Na przy­kład chęć szyb­kie­go wyj­ścia z pra­cy, chęć zaim­po­no­wa­nia kole­gom bar­dziej skom­pli­ko­wa­nym roz­wią­za­niem, chęć powie­dze­nia następ­ne­go dnia że już jest zro­bio­ne. Każ­dy z nas chce być boha­te­rem. Nie ma w tym nic złe­go. Sztu­ka pole­ga na tym aby razem z Pro­duct Owne­rem dopro­wa­dzić do takiej moty­wa­cji, aby kon­cen­tra­cja na pro­duk­cie była czymś zupeł­nie oczy­wi­stym, a inne rze­czy nie zaprzą­ta­ły nam gło­wy.

Pro­duct Owner jest eks­per­tem od wizji. Dewe­lo­pe­rzy są eks­per­ta­mi od jako­ści. Jakość kodu jest ści­śle zwią­za­na z jego czy­tel­no­ścią. Zarów­no dobrzy pro­gra­mi­ści jak teste­rzy i ana­li­ty­cy biz­ne­so­wi są w kwe­stii czy­tel­no­ści abso­lut­ny­mi eks­per­ta­mi. Jak więc mogą pomóc Pro­duct Owne­ro­wi osią­gnąć przej­rzy­stość w Bac­klo­gu? Otóż oka­zu­je się, że zgrab­nie uję­te zasa­dy zwią­za­ne z czy­tel­no­ścią, któ­re uła­twia­ją utrzy­ma­nie czy­ste­go kodu pro­gra­mi­stom z powo­dze­niem moż­na zasto­so­wać do Bac­klo­gu. Mówię tu o trzech zasa­dach.

 dry

DRY czyli z angielskiego “Don’t reapet yourself”

a po polsku “Nie powtarzaj się”.

Cze­kaj, tam jest ten opis, sko­piu­je się…” — to jest ten moment w któ­rym nale­ży inge­ro­wać, bo ina­czej Dok­tor Copy-Paste zamie­ni Pro­duct Bac­klog w nie­koń­czą­cą się lita­nię powta­rza­ją­cych się frag­men­tów doku­men­ta­cji. Oczy­wi­ście nie dokład­nie takich samych, bo świat się zmie­nia. Klient zmie­nia zda­nie. Rynek się zmie­nia. Doku­men­ta­cja też się zmie­nia, ale prze­waż­nie tyl­ko jed­na kopia, cza­sem dwie, jeśli o nich pamię­ta­my. Rzad­ko wszyst­kie. Więc jeśli chcesz mieć dostęp do rze­tel­nych infor­ma­cji, trzy­maj­my każ­dą z nich dokład­nie raz. A kopio­wać moż­na jakiś odno­śnik do niej.

pablo (2)

KISS czyli “Keep it simple stupid”,

czyli “Niech będzie tak proste, że aż głupie”.

Czy war­to poświę­cać czas na wygła­dza­nie opi­sów w Pro­duct Bac­klo­gu. Na szli­fo­wa­niu ich tak, żeby każ­dy klient użyt­kow­nik i dewe­lo­per je zro­zu­miał. Na ślę­cze­niu przy nich tak dłu­go, że zro­zu­mie­my je nawet jak sią­dzie­my do nich za rok cza­su.

Odpo­wiedź brzmi TAK.

Z dwóch powo­dów. Słu­ży to użyt­kow­ni­kom i auto­ro­wi:

  1. Użyt­kow­ni­kom bo Pro­duct Bac­klog sta­no­wi plan — do pla­nu zaglą­da się czę­sto. Aby go doszli­fo­wy­wać, wery­fi­ko­wać i wresz­cie reali­zo­wać. Zaglą­da tam spo­ro osób. Użyt­kow­ni­cy, klien­ci, dewe­lo­pe­rzy, zarząd a przede wszyst­kim autor. Powi­nien być więc tak pro­sty i przej­rzy­sty jak tyl­ko się da. Aby nie mar­no­wać cza­su odbior­ców i zachę­cać do korzy­sta­nia. Jeśli będzie się koja­rzył z kodek­sem, to nikt tam nie zaj­rzy i będzie mnó­stwo nie­spo­dzia­nek. Pro­duct Owner będzie miał nie­spo­dzian­kę jeśli nie dosta­nie tego co chciał, bo dewe­lo­per nie zaj­rzał. Klient będzie miał nie­spo­dzian­kę jak nie dosta­nie tego co chciał, bo nie zaj­rzał i nie zauwa­żył, że go nie zro­zu­mia­no i tak dalej. Jeże­li do pla­nu nie zaglą­da się czę­sto i nie jest potrzeb­ny wie­lu oso­bom, to coś jest nie tak. Pla­nu­je­my na zbyt dłu­gie okre­sy cza­su? A może nie mamy kon­tak­tu z odbior­ca­mi? Nie zbie­ra­my od nich infor­ma­cji zwrot­nej? Moż­li­wo­ści jest wie­le. Opty­mal­ny Pro­duct Bac­klog jest krót­ki, zwię­zły, aktu­al­ny, zmie­nia się czę­sto i jest uży­wa­ny.
  2. Przy­da­je się też auto­ro­wi bo pro­ces kla­ry­fi­ka­cji opi­su kla­ry­fi­ku­je wizję auto­ra. Czy zda­rzy­ło wam się ska­so­wać przy­pad­kiem wyni­ki swo­jej pra­cy, przez co byli­ście zmu­sze­ni do wyko­na­nia jej jesz­cze raz? Mi się zda­rza­ło. Bar­dzo czę­sto efekt pra­cy był dużo lep­szy niż pier­wot­na wer­sja. Co wię­cej moje zro­zu­mie­nie tema­tu sta­je się o nie­bo lep­sze. Tak samo jest z kodem i tak samo jest z Pro­duck Bac­klo­giem. Pra­ca nad nim spra­wia że, wizja sta­je się coraz wyraź­niej­sza i dokład­niej­sza. Cza­sem spra­wia też, że wizja zmie­nia się bo autor odkry­wa coś cze­go wcze­śniej nie wie­dział, lub wpa­da na lep­szy pomysł. Koniecz­ność wyra­że­nia cze­goś w pro­sty spo­sób, dopro­wa­dza do zro­zu­mie­nia tego lepiej. War­to poświę­cić na to czas. Jeże­li wasz Pro­duct Owner nie spę­dza mnó­stwa cza­su wpa­tru­jąc się w Pro­duct Bac­klog, to wiedz­cie, że coś nie­do­bre­go się dzie­je z pro­duk­tem.

4315444

YAGNI czyli “You aren’t gonna need it”,

po polsku “Nie, nie będziesz tego potrzebował”.

Pro­duct Bac­klog jest cen­tral­nym punk­tem infor­ma­cji o pro­duk­cie. Wyda­je się więc, że powi­nien być duży. To nie praw­da. Powin­no być tam wszyst­ko co waż­ne, krót­ko i zwięź­le, a nie wszyst­ko co kie­dy­kol­wiek ktoś wymy­ślił. Nad­miar infor­ma­cji jest świet­nym spo­so­bem na ukry­cie tego co jest waż­ne, tyle, że w przy­pad­ku Pro­duct Bac­klo­gu inten­cja jest odwrot­na. Chce­my to przej­rzy­ście poka­zać. Tak jak dobry dewe­lo­per uczy się w pew­nym momen­cie kaso­wać kod, któ­ry napi­sał bo oka­zu­je się, że nie jest uży­wa­ny, tak i Pro­duct Owner uczy się kaso­wać rze­czy, któ­rych jed­nak nie będzie reali­zo­wał. Nie­za­leż­nie od tego jak dużo cza­su poświę­cił na ich zapla­no­wa­nie. Wiem to trud­ne, ale war­to. Przy oka­zji uczy­my się, że nie war­to pla­no­wać szcze­gó­łów tego, co będzie­my robić za pół roku i nie war­to trzy­mać tego pla­nu jeże­li już go mamy, bo i tak za pół roku zro­bi­my to ina­czej. Za pół roku będzie­my inny­mi ludź­mi dosłow­nie lub w prze­no­śni.

Oczy­wi­ście nie tyl­ko te zasa­dy czy­ste­go kodu z powo­dze­niem moż­na sto­so­wać do Pro­duct Bac­klo­gu. Czy­tel­ność w obu przy­pad­kach jest klu­czo­wa, pro­gra­mi­ści wyko­rzy­staj­cie więc swo­jej doświad­cze­nie w utrzy­ma­niu czy­ste­go i czy­tel­ne­go kodu i pokaż­cie jak to robić waszym Pro­duct Owne­rom. Nie z altru­izmy. Zrób­cie to bo jest to w waszym inte­re­sie.

Agent do zadań spe­cjal­nych. Pierw­szy w Pol­sce Tre­ner Pro­fes­sio­nal Scrum Deve­lo­per oraz pierw­sza kobie­ta na świe­cie z taki­mi kom­pe­ten­cja­mi!

Definition of Done dla Product Ownerów — Poradnik Użytkownika

 

Co to jest DoD?

Umowa ma dwie strony – tych, którzy mówią co, i tych którzy mówią jak.

Pew­nie sły­sze­li­ście już nie raz o  Defi­ni­tion of Done. DoD jest waż­ne i potrzeb­ne. Tyl­ko  do cze­go słu­ży Pro­duct Owne­ro­wi?

Konia z rzę­dem pierw­sze­mu Pro­duct Owne­ro­wi, któ­ry nie zdę­biał na dźwięk jakichś „Con­ti­nu­ous Inte­gra­tion”, „TDD”, „BDD”, „featu­re tog­gle” i innych magicz­nych haseł, rzu­ca­nych przez zespół. Nie widać tego, poma­cać się nie da, a żeby zro­zu­mieć trze­ba się wczy­tać w jakieś podej­rza­ne szlacz­ki.

Zacznij­my od tego, co to jest za wyna­la­zek, to całe Defi­ni­tion of Done.

DoD to umo­wa – umo­wa o poziom jako­ści. Odpo­wia­da na pyta­nie:  jak bar­dzo bez­a­wa­ryj­ny i prze­my­śla­ny ma być nasz sys­tem? Ile pie­nię­dzy chce­my poświę­cić na zacho­wa­nie jako­ści?

W przy­pad­ku pro­duk­cji butów jest to dość pro­ste – usta­wia­my maszy­ny testu­ją­ce na wybra­ne egzem­pla­rze z par­tii i je roz­cią­ga­my, naci­ska­my, imi­tu­je­my zuży­cie. Wszyst­ko widać. Kosz­ty jako­ści i ryzy­ka jej nie­za­cho­wa­nia bar­dzo łatwo poli­czyć. Buł­ka z masłem.

Tu są smoki

W przypadku softu sprawa jest nieco bardziej interesująca.

DoD to jed­no miej­sce, w któ­rym znaj­dzie­my warun­ki okre­śla­ją­ce, co to zna­czy, że coś jest zro­bio­ne, czy­li wyko­na­ne i goto­we do wyda­nia (w nie­któ­rych przy­pad­kach już wyda­ne) oraz jakich prak­tyk jako­ścio­wych dotrzy­ma­li­śmy, żeby do tego dotrzeć. Brzmi bar­dzo pro­sto. DoD przy­kła­da­ne jest do każ­de­go ele­men­tu Pro­duct Bac­klo­gu (PBI), jaki bie­rze­my do pra­cy, czy­li musi być jako­ścio­wą czę­ścią wspól­ną.

DoD jest też czę­sto mylo­ne z kry­te­ria­mi akcep­ta­cji – czy­li spe­cy­ficz­ny­mi warun­ka­mi, któ­re doty­czą kon­kret­ne­go zada­nia.

Budujemy nowy dom…

Definition of Done w działaniu

Budu­je­my sobie dom. W domu ma być piw­ni­ca, par­ter i pod­da­sze. Na par­te­rze ma być kuch­nia, salon, łazien­ka, gabi­net i wia­tro­łap. Mamy z tego bac­klog wyglą­da­ją­cy tak:

- Kuch­nia (Par­ter)

- Łazien­ka (Par­ter)

- Salon (Par­ter)

- Wia­tro­łap (Par­ter)

- Gabi­net (Par­ter)

- Piw­ni­ca

- Pod­da­sze

Jakie może być tu DoD? Na przy­kład:

- Pod­ło­gi pane­le Kro­no Sound

- Ścia­ny far­ba bez­la­tek­so­wa (Dzie­ci mają uczu­le­nie)

- Ścia­ny z poro­ther­mu

- Okna drew­nia­ne, trzy­szy­bo­we

- Osprzęt elek­trycz­ny bia­ły, Simon54

Zauważ­cie, że powyż­sze warun­ki doty­czą wszyst­kich pomiesz­czeń. W kry­te­riach akcep­ta­cji znaj­dzie­my wytycz­ne dla dane­go pomiesz­cze­nia– na przy­kład wan­na w łazien­ce, albo biur­ko w gabi­ne­cie.

Mogą też być wyjąt­ki – w łazien­ce nie będzie pod­ło­gi z pane­la­mi, tyl­ko kafle. Ale to już trze­ba dokład­nie zazna­czyć w opi­sie.

W przy­pad­ku softu DoD peł­ni taką samą funk­cję.

Przy­kład:

Kod w repo­zy­to­rium, opi­sa­ny i zgod­ny z usta­le­nia­mi czy­tel­no­ści

Algo­ryt­my stwo­rzo­ne w Pair Pro­gram­min­gu i TDD

Meto­dy nie dłuż­sze niż 40 linii

Regre­sja prze­cho­dzi

Pokry­cie min. 78%

Kto to ma rozumieć?

Warto rozmawiać.

Zespo­ły są zobo­wią­za­ne wytłu­ma­czyć PO, na czym pole­ga­ją róż­ne ele­men­ty DoD. Cho­ciaż PO tak­że musi mieć ele­men­tar­ną wie­dzę z tego zakre­su. Tak jak budu­jąc dom, jego wła­ści­ciel uczy się o aspek­tach budow­nic­twa.

A co się sta­nie jeśli DoD nie zosta­nie zacho­wa­ne? Wła­śnie w taki spo­sób two­rzy się dług tech­no­lo­gicz­ny. Jak z baj­ki o Wiel­kim-Złym-Pro­ject-Mana­ge­rze.

For­mat

Naj­le­piej na począt­ku spi­sać sobie DoD w for­mie umo­wy. Z pod­pi­sa­mi. Dla­cze­go tak? Bo umów z wła­snym pod­pi­sem raczej się pil­nu­je i prze­strze­ga, a każ­de od nich odstęp­stwo musi być zgła­sza­ne. Pamię­taj­cie tyl­ko, że co praw­da cię­żar DoD spo­czy­wa na zespo­le, jed­nak jest to umo­wa, a umo­wa ma dwie stro­ny. Może się zda­rzyć że PO jakaś prak­ty­ka wyda­je się nie­po­trzeb­na. Wte­dy trze­ba to prze­dys­ku­to­wać na retro. Podob­nie jeśli jakieś nie­ści­sło­ści widzi Zespół.

Nie­któ­re zespo­ły wbu­do­wu­ją DoD w swo­je Sprint Bac­klo­gi tak, żeby przy doda­wa­niu ele­men­tu ten auto­ma­tycz­nie roz­wi­jał się we wszyst­kie ele­men­ty DoD.

A inne uży­wa­ją do tego po pro­stu kart­ki na ścia­nie.

Zgod­ność

A co w takim razie ze spraw­dza­niem zgod­no­ści DoD? Skąd mamy wie­dzieć, że odda­ny ele­ment ją speł­nia?

Po pierw­sze trze­ba sobie uświa­do­mić, że PO nie ma zwy­kle wystar­cza­ją­cej wie­dzy, żeby taką zgod­ność spraw­dzać. Kto zatem pil­nu­je żeby wszyst­ko się z DoD zga­dza­ło? Pew­nie już się domy­ślasz — Scrum Master, DoD to w koń­cu część pro­ce­su. W tym aku­rat przy­pad­ku bar­dzo rzad­ko SM oso­bi­ście  spraw­dza, czy wszyst­ko jest zgod­ne. DoD jest wery­fi­ko­wa­na pod­czas sprin­tu, na bie­żą­co. Kie­dy tyl­ko PBI  jest ukoń­czo­ne. DoD jest zwy­kle uży­wa­na przy pla­no­wa­niu sprin­tu, więc nic nie umy­ka. Zda­rza się, że kie­dy zespół jesz­cze się uczy pra­cy w Scru­mie, SM spraw­dza od cza­su do cza­su, czy coś nie umknę­ło, ale na pew­no nie kon­tro­lu­je zgod­no­ści dla każ­de­go PBI.

Idealna DoD

Byle z umiarem

War­to też nad­mie­nić, że pro­ble­my z DoD czę­sto są powo­do­wa­ne tym, że jest ona albo za pro­sta albo zbyt skom­pli­ko­wa­na. W pierw­szym przy­pad­ku wszyst­ko ją speł­nia, więc nie ma sen­su się wysi­lać, a w dru­gim zespół po pro­stu nie pamię­ta wszyst­kich jej usta­leń. War­to więc trzy­mać DoD w sen­sow­nej wiel­ko­ści.

Men­tor­ka o nie­zwy­kłej cha­ry­zmie. Jeden z naj­bar­dziej doświad­czo­nych eks­per­tów Scru­ma i pierw­szy tre­ner Sca­led Pro­fes­sio­nal Scrum w Pol­sce.

Bajka o Wielkim Złym Project Managerze

Usiądź­cie wygod­nie dziat­ki. Opo­wiem wam baj­kę. Będzie strasz­nie. Dobre­go zakoń­cze­nia też nie ma, ale Baj­ki Bra­ci Grimm też do naj­we­sel­szych nie nale­żą. Jak to w baj­kach z mora­łem.

Za sied­mio­ma góra­mi, za sied­mio­ma lasa­mi w Softwa­re „Spier­ni­qa” pra­co­wał sobie Deve­lop­ment Team o wdzięcz­nej nazwie „Misie”. Misie pro­du­ko­wa­ły sobie świet­ny soft. Klien­ci byli zado­wo­le­ni, Misie speł­nia­ły się jako eks­per­ci.

99

Pew­ne­go dnia, Misie zapla­no­wa­ły sobie rele­ase. Zapla­no­wa­ły jak zawsze, z uwzględ­nie­niem pręd­ko­ści któ­rą mia­ły w poprzed­nich sprin­tach. Z pla­no­wa­nia wyszło im coś takie­go:

8

Jed­nak komuś się to nie spodo­ba­ło. Chciał żeby to, co zosta­ło zapla­no­wa­ne dostar­czo­no szyb­ciej. Co więc zro­bił? To co pod­po­wia­da­ło mu doświad­cze­nie i wykrzyk­nął grom­ko „Pra­cuj­cie szyb­ciej!”

7

No więc Misie pra­co­wa­ły szyb­ciej. Na wykre­sie wyglą­da­ło to tak. Jak myśli­cie, czym jest to coś zazna­czo­ne kla­mer­ką? To jest NIEZROBIONE, zna­ne też pod nazwą dłu­gu tech­no­lo­gicz­ne­go albo śmier­dzą­ce­go kodu.

Jaki efekt ma takie “nie­zro­bio­ne”? Naj­czę­ściej taki, że kod jest nie­czy­tel­ny, są tam roz­wią­za­nia „na sło­wo hono­ru”, przez co poja­wia się wię­cej błę­dów, więc i częst­sze awa­rie, i wie­le innych rze­czy.

Czy Wiel­ki-Zły-Pro­ject-Mana­ger osią­gnął zle­co­ne mu cele? Oczy­wi­ście! Zespół dostar­czył szyb­ciej. Więc Wiel­ki-Zły-Pro­ject-Mana­ger dostał swój worek pie­nię­dzy i poszedł dalej, do kolej­ne­go pro­jek­tu.

6

A Misie? Misie zosta­ły z tym coraz brzyd­szym kodem.

5

Więc zapla­no­wa­ły sobie kolej­ny rele­ase. Tym razem już pra­ca szła im wol­niej, bo musia­ły prze­bi­jać się przez poprzed­nio stwo­rzo­ny dług tech­no­lo­gicz­ny.

4

To już zde­cy­do­wa­nie się komuś nie podo­ba­ło. Ponie­waż poprzed­ni Wiel­ki-Zły-Pro­ject-Mana­ger już daw­no pra­co­wał nad innym pro­jek­tem, zatrud­nił do pogod­nie­nia Misiów Ogrom­ne­go-Jesz­cze-Gor­sze­go-Pro­ject-Mana­ge­ra, z jesz­cze więk­szym batem, któ­ry strze­lił z nie­go i głę­bo­kim gło­sem naka­zał Misiom: „Pra­cuj­cie szyb­ciej!”

3

Co się sta­ło zapy­ta­cie? Ano pra­co­wa­li szyb­ciej two­rząc kolej­ne pokła­dy dłu­gu i nie mogąc go spła­cać. Ale dostar­czy­li szyb­ciej. Więc Ogrom­ny-Jesz­cze-Gor­szy-Pro­ject-Mana­ger osią­gnąw­szy swój cel dostał swój worek pie­nię­dzy i poszedł dalej.

2

Kil­ka rele­asów póź­niej, gdy pro­dukt był już w sta­nie nie nada­ją­cym się do roz­wo­ju, bo każ­da dopi­sa­na linij­ka gene­ro­wa­ła błę­dy i kon­flik­ty, nad­szedł czas na prze­pi­sa­nie tego roz­wią­za­nia. Któ­re kosz­tu­je wię­cej niż roz­wój obec­ne­go do tej pory.

1

Baj­ka ta nie­ste­ty nie ma dobre­go zakoń­cze­nia. Misie poszu­ka­ły sobie pra­cy gdzie indziej, a do prze­pi­sa­nia pro­duk­tu wzię­ło się kil­ko­ro prak­ty­kan­tów.

Czy war­to więc zatrud­niać zmie­nia­ją­cych się Wiel­kich-Złych-Pro­ject-Mana­ge­rów? To pozo­sta­wiam Waszej oce­nie.

A co by się sta­ło, gdy­by ten pro­dukt miał pra­cu­ją­ce­go z zespo­łem Pro­duct Owne­ra? Kie­dy zaczął­by naci­skać na zespół pod­czas pierw­sze­go rele­asu, spo­wol­nie­nie ugry­zło­by go w zad bar­dzo szyb­ko i oka­za­ło­by się, że takie ruchy są nie­opła­cal­ne. Ale zmie­nia­ją­cy się PM-owie nie mają szan­sy tego zauwa­żyć.

Jak­by tego było mało, wyobraź­cie sobie mora­le tego zespo­łu, któ­ry pod batem oglą­da, jak powo­li sami nisz­czą coś, co wspól­ny­mi siła­mi budo­wa­li.

Uwa­ga dla hej­te­rów: ta baj­ka nie ma za zada­nie zdys­kre­dy­to­wa­nia dzia­łań PM-ów i nie ozna­cza , że wszy­scy PM-owie są źli. Jest tu poka­za­ny pewien spe­cy­ficz­ny, ale i czę­sty przy­pa­dek, któ­re­go ofia­ra­mi sa tak­że PM-owie, bo w tym przy­pad­ku po pro­stu wyko­nu­ją dobrze swo­ją pra­cę — osią­ga­ją zle­co­ne im cele. Ale o wyzna­cza­niu i osią­ga­niu celów w kolej­nej baj­ce. Śpij­cie dobrze.

Men­tor­ka o nie­zwy­kłej cha­ry­zmie. Jeden z naj­bar­dziej doświad­czo­nych eks­per­tów Scru­ma i pierw­szy tre­ner Sca­led Pro­fes­sio­nal Scrum w Pol­sce.

© 2018 Brass Willow Blog

Theme by Anders NorenUp ↑