Jest taka stra­te­gia w pro­jek­to­wa­niu algo­ryt­mów “Dziel i zwy­cię­żaj”. Pole­ga na tym, że pro­ble­my dzie­li­my na mniej­sze, któ­re roz­wią­zać łatwo i łączy­my ich roz­wią­za­nia — tak aby roz­wią­zać więk­szy pro­blem.

Z jej pomo­cą zapro­jek­to­wa­ne są wszyst­kie szyb­kie algo­ryt­my sor­to­wa­nia — chy­ba naj­pow­szech­niej­sze­go pro­ble­mu, o dużej zło­żo­no­ści obli­cze­nio­wej. Stra­te­gia ta jest sku­tecz­na w przy­pad­ku kom­pu­te­rów. Czy nie będzie jesz­cze sku­tecz­niej­sza w przy­pad­ku ludzi, któ­rzy mają dużo mniej pamię­ci ope­ra­cyj­nej, a część z niej i tak jest wyko­rzy­sta­na na waż­kie pro­ble­my: “co robi moja dziew­czy­na” i “co będzie na obiad”?

Opo­wiem dzi­siaj histo­rię, któ­ra może rzu­cić nie­co wię­cej świa­tła na pewien pro­blem.

Byłam mło­dym Scrum Maste­rem. Mój zespół łączył pra­cę wyko­ny­wa­ną w dwóch tech­no­lo­giach, z któ­rych jed­na była dla mnie cał­ko­wi­cie obca. Cięż­ko mi było z nimi pole­mi­zo­wać kie­dy mówi­li:

  • Nie da się tego podzie­lić.
  • W tym narzę­dziu zaczy­nasz zawsze od począt­ku.

Ukoń­cze­nie jed­nej funk­cjo­nal­no­ści, któ­rą moż­na było zapre­zen­to­wać na Prze­glą­dzie Sprin­tu zaj­mo­wa­ło im 2 do 3 Sprin­tów.

Pró­bo­wa­łam robić z nimi Ele­phant Car­pa­cio — świet­ne ćwi­cze­nie, któ­re czę­sto robię na szko­le­niach — poka­zu­ją­ce o co cho­dzi w dzie­le­niu zadań. Wysy­ła­łam im arty­ku­ły, któ­re poka­zu­ją tech­ni­ki podzia­łu. Jest ich mnó­stwo. Piszą o tym pol­skiezagra­niczne mądre gło­wy. Moż­na zna­leźć nawet goto­we pla­ka­ty do powie­sze­nia, któ­re poka­zu­ją jak dzie­lić zada­nia. Nic nie dzia­ła­ło… dopó­ki nie usły­sza­łam o sta­ty­sty­ce, któ­rą moż­na w pro­sty spo­sób wycią­gnąć z Jiry. Z histo­rii zespo­łu (pole­cam wziąć ostat­nie pół roku) wycią­ga­my jakiej wiel­ko­ści zada­nia zespół dostar­czał oraz z jaką sku­tecz­no­ścią. W zespo­le, o któ­rym opo­wia­dam, uży­wa­no jed­nost­ki Sto­ry Point oraz cią­gu Fibo­nac­cie­go. Wyszło coś takie­go:

Wspo­ma­ga­ją­co, zro­bi­łam jesz­cze dwa wykre­sy.  Pierw­szy poka­zy­wał ile zadań okre­ślo­nej wiel­ko­ści zespół prze­wi­dział że dostar­czy.

Dru­gi ile punk­tów reali­zo­wa­ne było w ramach zadań okre­ślo­nej wiel­ko­ści, czy­li ile zadań okre­ślo­nej wiel­ko­ści razy ich wiel­kość.

Widać wyraź­nie, że naj­wię­cej punk­tów było reali­zo­wa­ne w ramach wiel­ko­ści zadań, któ­re wią­żą się z naj­mniej­szą sku­tecz­no­ścią.

Roz­da­łam zespo­ło­wi te dane na począt­ku Pla­no­wa­nia Sprin­tu, mówiąc:

  • Przy­go­to­wa­łam Wam małą sta­ty­sty­kę.

Zespół z uwa­gą przy­glą­dał się kart­kom, przez dobrych kil­ka minut. Padło kil­ka pytań:

  • A skąd te dane wzię­łaś?
  • Z jakie­go okre­su?

Pla­no­wa­nie Sprin­tu prze­biegł typo­wo, ale już na następ­nym spo­tka­niu w ramach pro­ce­su refi­ne­men­tu sami, bez żad­nej mojej suge­stii zaczę­li szu­kać spo­so­bów na podzie­le­nie zadań. Nigdy wię­cej nie wzię­li zada­nia wiel­ko­ści 21 (ani więk­sze­go). Sku­tecz­ność poszy­bo­wa­ła wyso­ko.

Na pod­sta­wie tej krót­kiej histo­rii śmiem twier­dzić, że pro­ble­my z podzia­łem czę­sto nie są zwią­za­ne z tym, że zespół nie wie jak podzie­lić zadań na mniej­sze. Pro­blem pole­ga na tym że zespół nie czu­je po co mie­li­by się tak męczyć (tak, to jest trud­niej­sze), więc nawet nie szu­ka tych spo­so­bów.

Dalsza część dla tych, którzy są ciekawi jak to wygląda od strony technicznej.

Dla­cze­go dzie­le­nie zadań jest tak waż­ne z tech­nicz­ne­go punk­tu widze­nia? Otóż dla­te­go, że  naj­wię­cej nie­spo­dzia­nek jest na łącze­niu warstw. Np. oka­zu­je się, że baza danych nie ma funk­cji, któ­rej się spo­dzie­wa­li­śmy albo, że jed­nak inna funk­cja była­by tu wygod­niej­sza. Zakła­da­li­śmy że jed­na war­stwa zwró­ci nam dane okre­ślo­ne­go for­ma­tu, a ten for­mat jest odro­bi­nę inny — na tyle inny, że ta następ­na war­stwa nie ma goto­wej meto­dy obsłu­gi tego for­ma­tu.

Jak widać może się poja­wić mnó­stwo drob­nych pro­ble­mów, któ­re razem spra­wia­ją, że koniec Sprin­tu zaska­ku­je nas jak zima dro­go­wców, z poło­wą zadań nie­skoń­czo­nych. Dla­te­go war­to połą­czyć wszyst­kie war­stwy jak naj­szyb­ciej się da, zapre­zen­to­wać wynik połą­cze­nia inte­re­sa­riu­szom i spraw­dzić, czy aby i ich coś nie zasko­czy w tym co zoba­czą.

Zasa­da jest pro­sta. Jeże­li da się zro­bić mniej, aby połą­czyć war­stwy, zrób mniej i sprawdź czy war­stwy do sie­bie pasu­ją. Czas, któ­ry oszczę­dza­my robiąc wię­cej w ramach jed­nej war­stwy, czy­li:

A jak już tu jestem, to jesz­cze to zaim­ple­men­tu­je, prze­cież i tak będzie potrzeb­ne”.

W ogrom­nej ilo­ści przy­pad­ków taki czas, jest cza­sem stra­co­nym lub wręcz szko­dli­wym. Bo:

No jak już zro­bi­łem to zosta­wię, mimo że teraz widzę jak moż­na to zro­bić lepiej”.

Zobacz­my to na przy­kła­dzie. Kaziu chce zro­bić narzę­dzie do wyświe­tla­nia naszej małej sta­ty­sty­ki opi­sa­nej w powyż­szym przy­kła­dzie. Eks­por­tu­je dane z JIRY. Spę­dza 5 godzin na roz­gry­za­niu Jiro­we­go Exce­la i wyświe­tle­niu odpo­wied­nich danych na kon­so­li. Potem szu­ka cze­goś co wyświe­tli wykre­sy. W koń­cu  zna­lazł. Wykre­sy wyglą­da­ją okrop­nie, a już minę­ła godzi­na. Następ­ne dwie godzi­ny szu­ka inne­go narzę­dzia do ryso­wa­nia wykre­sów. W koń­cu zna­lazł narzę­dzie, któ­re ma spe­cjal­ny moduł do czy­ta­nia eks­por­tu z Jira. Super! Teraz poszło szyb­ciej. I wykre­sy wyglą­da­ją obłęd­nie. Zro­bił narzę­dzie w 1,5 dnia pra­cy. Poka­zu­je Wła­ści­cie­lo­wi Pro­duk­tu, a on na to:

  • I za każ­dym razem trze­ba mu dać dane z Jiry? Nie da się tego wyświe­tlić bez­po­śred­nio w Jira? Wolał­bym tak.

Spraw­dza. Pew­nie że się da! 1.5 dnia pra­cy do kosza. A co jak­by na kon­so­lę wyrzu­cił sobie dane tyl­ko do pierw­sze­go wykre­su, zro­bił wykres, od razu poka­zał ten pierw­szy nie­szczę­śli­wy wykres Wła­ści­cie­lo­wi Pro­duk­tu? Po dwóch godzi­nach pra­cy wie­dział­by, że idzie w złą stro­nę i oszczę­dził ponad dzień pra­cy.

Jeże­li masz pro­blem z dzie­le­niem zadań pomyśl o tym tak: jeże­li możesz napi­sać dwa osob­ne testy funk­cjo­nal­ne do dane­go zada­nia, możesz podzie­lić zada­nie. Nie musisz, ale  możesz. Zrób dla swo­je­go zespo­łu sta­ty­sty­kę opi­sa­ną powy­żej, a dowiesz się, że napraw­dę wie­lu przy­pad­kach war­to.

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!