piątek, sierpnia 23, 2019

DoR before DoD ;-)

W Agile często jest wielkie podniecenie DoD, czyli Definition of Done, czyli definicją tego co oznacza, że praca w ramach danego "taska" została zrobiona.
Są wielkie wojny czy coś jest Done jak zostało zamknięte przez developera, czy może (w razie jest oddzielna faza QA) gdy testerzy skończyli testy i nic nie znalazły, czy może jak PM/PO/stakeholder oznaczy coś jako Completed.

Ja zawsze jednak byłem orędownikiem tego, że zanim w ogóle zaczniemy rozmawiać o DoD, czyli tym kiedy robota jest gotowa, to najpierw powinniśmy określić DoR, czyli Definition of Ready, czyli coś co mówi kiedy kawałek pracy jest gotowy do tego by nad nim w ogóle zacząć pracować*.

Bo DoR powinno pilnować tego czy jak developer, czy developerka usiądą nad kawałkiem pracy to będą wiedzieć co i dlaczego ma być wynikiem tej pracy, że będą rozumieć problem i będą mogli stwierdzić, że zrobili to co mieli zrobić.

W DoD często są teksty w stylu:

  • kod jest w repo,
  • przechodzą testy,
  • są testy.


I jest tu takie domniemane założenie tego, że w ogóle wiadomo co trzeba zrobić ;-)
Ale jak widziałem już wiele razy (sam zresztą byłem kilka razy winny), że przez przez brak DoR i zły opis w historyjce developer rozwiąże inny problem niż miał rozwiązać.

Sam gdy kodowałem pierwszą rzecz w Motoroli te 15 lat temu to dodałem do naszej aplikacji akceleratory (czyli skróty klawiszowe) do opcji w menu, a nie skróty (czyli coś co pozwala się poruszać po menu (chcemy iść do menu File robimy ALT-F), bez jeszcze wybierania opcji (zresztą z tego co widzę w macOS już skrótów nie ma ;-)) bo cała historyjka była opisana jako "Add accelerators to menu options" ;-)
Z drugiej strony też byłem winien, zdarzyło mi się napisać historyjkę tak, że ja rozumiałem co trzeba zrobić, a ktoś kto ją wziął nie ;-)

Stąd jak już trzeba robić któreś Definition of .... to ja bym zaczął od Definition of Ready i jeszcze bym próbował męczyć zespół o to by się skarżyli na źle opisane historyki ;-)

[tak naprawdę nie miałem natchnienia o czym by napisać, stąd taki temat ;-)]

* - niby w Scrumie cały backlog refinement/grooming ma być od tego, ale bardzo często z tego co widziałem na spotkaniu jest "rozumiecie o co chodzi?" i jest "tak", "jasne" i rzadko pada pytanie "OK, to opiszcie co musi być wynikiem" ;-)


Podobne postybeta
Skróty klawiszowe
Todo - Efekt ciążenia ku dołowi listy ;-)
Jak walczyć z gigantycznym kodem w Java'ie, część 1.5 ;-) - czyli jak je się słonie ;-)
Świat The Three Body... też się nie domyka....
Macbook PRO Retina i OS X po 2* tygodniach

Brak komentarzy:

Prześlij komentarz