BYOP po raz drugi w Łodzi

Drugie spotkanie BYOP w Łodzi miało miejsce w czasie gdy z powodu mrozu samochody nie chcą otwierać drzwi a w kraju szaleje epidemia grypy. Pomimo tego na spotkaniu wszyscy wyglądali rześko co potwierdza starą góralską prawdę, że praca z metodykami zwinnymi zwiększa satysfakcje z życia i poprawia działanie układu immunologicznego.

Poruszane zagadnienia

Podział na user story mocno zależnych od siebie funkcjonalności

Problem : Jak podzielić na user story funkcjonalność, której nie jesteśmy w stanie skończyć w jednym sprincie, a która składa się z mocno zależnych od siebie części.
Na potrzeby dyskusji przyjęliśmy błahy przykład z następującymi założeniami.

• Mamy formularz z trzema polami
• Nie da się zrealizować całego formularz w jednym sprincie
• Dodanie każdego pola niesie ze sobą wartość biznesową

Podejście 1 : ukrywanie zależności technicznych w user story

• As a User chce mieć pole1 - 3 story pointy
• As a User chce mieć pole2 - 1 story point
• As a User chce mieć pole2 - 1 story point

W tym przypadku zakładamy, że z pierwszym polem robimy całą obsługę formularza i przy następnych polach ta część będzie gotowa. Istnieje ryzyko, że Product Owner zmieni priorytety user story i cała misterna intryga się posypie.

Podejście 2 : jasne wydzielenie technicznego user story

• Zaimplementować obsługę formularza - 2 story pointy
• As a User chce mieć pole1 - 1 story pointy
• As a User chce mieć pole2 - 1 story point
• As a User chce mieć pole2 - 1 story point

Tutaj z kolei były dyskusje czy powinniśmy tworzyć user story, które nie niesie ze sobą żadnej wartości biznesowej oraz jak zaprezentować na demie "obsługę formularza bez pól".

Podejście 3 : niezależna wycena każdego z pól

• As a User chce mieć pole1 - 3 story pointy
• As a User chce mieć pole2 - 3 story pointy
• As a User chce mieć pole2 - 3 story pointy

Ten przypadek ma w zasadzie jedyną zaletę, że Product Owner może sobie zmieniać priorytety jak chce ale poza tym ma same wady i zostało przez uczestników dyskusji określone mianem totalnie złego.

Podejście 4 : bez kombinowania

• As a User chce mieć nowy formularz z polem1 - 3 story pointy
• As a User chce dodać pole2 do formularza - 1 story point
• As a User chce dodać pole3 do formularza - 1 story point

Tutaj jest opisane jasno na białym, że z pierwszym user story tworzymy formularz a kolejne pola są dodawane. Jeśli Product Owner chce zmienić priorytety i mieć pole2 przed polem1 wtedy nie ma wyjścia i trzeba dokonać zmiany w backlogu co wydaje się być logiczne. Osobiście najbardziej podoba mi się właśnie to rozwiązanie.

Grywalizacja jako sposób na code review

Co to jest grywalizacja - http://pl.wikipedia.org/wiki/Grywalizacja

Problem : Ludzie nie chcą robić code review i jak wykorzystać grywalizację aby ich do tego skłonić.

Osobiście Trudno mi opisać obiektywnie ten temat gdyż moim zdaniem programiści domyślnie chcą pisać dobry kod. Jeśli tego nie robią to znaczy, że istnieje "coś jeszcze" co ich demotywuje.

Tak czy inaczej tło problemu zostało przedstawione i rozpoczęła się dyskusja jak wykorzystać przyznawanie punktów przy okazji code review. Z tego co pamiętam każda kolejna propozycja spotkała się z pomysłem jak dany system pohakować by mieć więcej punktów. Było tez trochę teoretyzowania co motywuje ludzi, ilu ewangelistów potrzeba do wkręcenia żarówki i takie tam. Pomysłodawca zagadnienia ma sprawdzić je w praktyce i przynieść wnioski na kolejny BYOP.

Scrum a odziedziczony kod

Problem : Z dalekiego uduchowionego kraju o bogatej tradycji przywędrował do nas projekt o wątpliwej jakości technicznej - jak go rozwijać/naprawiać przy pomocy metodyk zwinnych.

1. Słowo klucz - ScumBan
2. Uświadom interesariuszy (piękne słowo) o ogromnym długu technicznym projektu
3. Estymuj bugi jak user story
4. Ponieważ pole minowe jest niezbadane więc trudno "komitować" się na określoną ilość story pointów. Kontrakt - w sprincie zrobimy minimum tyle a tyle user stories a jak uda się szybciej to bierzemy kolejne z backlogu

Poprawny model obiektowy a metodyki zwinne

Problem : Jak uzyskać poprawny model obiektowy bez BDUF (big design up front) i towarzyszącego temu podejściu marnotrawstwa (waste)

Bardzo złożony i nawet kontrowersyjny problem. Niektórzy słysząc słowa analiza czy projektowanie wyciągają kołki, czosnek i wodę święconą. Z jednej strony każda sekunda poświęcona na projektowanie rozwiązania user story, które zostanie przez PO wyrzucone lub przesunięte gdzieś na dół backlogu jest stratą, której należy unikać. To jest raczej oczywiste. Ale..

• Po pierwsze primo: w trakcie code review łatwo poprawić jakieś zjebotwory w kodzie ale jak już ktoś źle stworzy model obiektowy to trzeba czasem poprawiać wszystko
• Po drugie primo : jeśli kod jest współwłasnością całego teamu to czy jedna osoba może według swojego mniemania tworzyć model obiektowy, który będzie uderzał w każdego członka zespołu przez następne lata?
• Po trzecie primo : czy mając przeanalizowane tylko user story na najbliższy sprint (bądź nawet trzy sprinty) jesteśmy w stanie stworzyć model, który będzie łatwo rozwijalny w kontekście kolejnych funkcjonalności?

Generalnie trzeba znaleźć sposób aby zacząć projektować i przestać kiedy to już nie niesie ze sobą wartości.

W trakcie dyskusji nie udało się znaleźć rozwiązania. Na chwilę obecna będziemy próbować wpleść etap analizy obiektowej do przedsprintowych spotkań planningowych. Czas pokaże co z tego wyjdzie...

Podsumowanie

Tym razem spotkanie było bardziej merytoryczne - mniej filozofowania a więcej porad. Dwie kwestie pozostały otwarte i będą dyskutowane ponownie gdy praktyka da odpowiedzi na część pytań i założeń. Kolejne spotkanie jest planowane na początku marca.