Opisy zadań w Jira

Jak w waszych miejscach pracy definiuje się zadania, które trzeba będzie wykonać? Na jakim poziomie szczegółowości? Przy ustalaniu podziału zadań dogadujecie się na przykład na poziomie interfejsów? Po ostatnich opisach moich zadań, które wykonywałem lub wykonuję, zacząłem się zastanawiać czy praktyka w moim miejscu pracy jest zła czy coś ze mną jest nie tak. Opisy historyjek (story) z narzuconą estymatą są niedodefiniowane, a czasem jedyną wskazówką jak pewne komponenty mają działać jest mockup, dokumenty HLD lub wiedza plemienna: "idź zapytaj A, on będzie wiedział". Opisy technicznych zadań (technical task) i ich granulację zostawia się programistom i testerom. Zgoła inaczej wyglądają zadania reaserchowe - tu jest wolna amerykanka.

Zazwyczaj coś dużego to taki Epic w Jirze (tworzy Product Owner lub Architekt), w nim są Storiesy napisane najczęściej przez Product Ownera, a potem każde Story jest dzielone na sub-taski już przeważnie przez developerów i testerów. Jeśli chodzi o wiedzę plemienną no to cóż... tak było, jest i będzie ;)

U nas zazwyczaj opisuje się, jaka funkcja z poziomu widzenia użytkownika ma być zrealizowana i jakie są kryteria akceptacji tego zadania. Potem zespół programistów tworzy podzadania, które już mogą być bardziej lub mniej techniczne. Staramy się, żeby podzadania były opisane na tyle, żeby każdy, kto siada do tego zadania, wiedział, co ma zrobić w połączniu z głównym zadaniem, ale nie zawsze to nam wychodzi.

@Pinek, @Michał Sikora, jak szczegółowo u was są opisane wymagania funkcjonalne? Rozbijając zadania techniczne modelujecie przy okazji API?

Brickcloak napisał(a):

@Pinek, @Michał Sikora, jak szczegółowo u was są opisane wymagania funkcjonalne? Rozbijając zadania techniczne modelujecie przy okazji API?

Często tak, ale nie zawsze się to udaje (lub np zadanie polega na czymś takim, że ciężko nazwać coś API)

System Analyst tworzy Story i Epiki w Jirze z dokładnym opisem jak ma cos działać a ja implementuję i potem z nim konsultuję. Nie muszę znać biznesowego kontekstu i zastanawiać się czy Pani Zosia miała na myśli zaokrąglenie w górę czy w dół w obliczeniach. Od takich ustaleń jest system analyst.

Zależy od zadania. Przykładowo.

As a user I want to have an ability to move items from the cart to the "remind me" section directly. If the "remind me" section has this item already, the item is just removed from the cart.

Acceptance criteria:

• An item can be moved at any point before the transaction is finalized.
• If I want to remove an item from the cart I'm asked if I want to add it to the "remind me" section first with a popup.
• Items moved from the cart to the "remind me" section stay reserved for me for a long period than usual.
• An item is moved to the "remind me" section with a swipe left action.

Open questions:

• Should the "remind me" popup have a "never ask again" checkbox?
• Yes.
• What is the length of the extended period?
• 1 week for items over $500, 1 month for others.

Sekcja "open questions" to pytania jakie mamy do strony biznesowej, ale nie przeszkadzają szczególnie w implmentacji, więc możemy zacząć z zadaniem i wyjaśnić w trakcie sprintu. Do takiego zadania dodajemy, jeśli trzeba, podzadania techniczne jak np. Design REST API, [Backend] Prepare DB migrations, [Backend] Create move to "remind me" endpoint, i bardziej opisowe biznesowo jeżeli to wystarczy do zrozumienia zadania. Na przykład [Android] Create popup, [iOS] Create popup. Są też zadania typowo dokumentacyjne - Prepare translations, Update business flow diagrams, Clarify open questions, itd.

Jeśli trzeba te podzadania bardziej opisać, to mają krótkie opisy, ale tego trochę się nie trzymamy. Jeżeli zadania wymagają zaprojektowania UI, to dodajemy pliki w załącznikach do głównego zadania, jeśli UI nie jest oczywiste.

Ja i tak czytam tylko summary, bo description to zazwyczaj jakieś biznesowe głupoty bez pojęcia i sensu (np. w każdym tasku powtórzone ta sama tabelka, co ma się stać, gdy dane autoryzacyjne będą błędne).

• Jak to jest być skrybą, dobrze?
  -** Moim zdaniem to nie ma tak, że dobrze albo że nie dobrze.** Gdybym miał powiedzieć, co cenię w życiu najbardziej, powiedziałbym, że ludzi. Ekhm... Ludzi, którzy podali mi pomocną dłoń, kiedy sobie nie radziłem, kiedy byłem sam. I co ciekawe, to właśnie przypadkowe spotkania wpływają na nasze życie. Chodzi o to, że kiedy wyznaje się pewne wartości, nawet pozornie uniwersalne, bywa, że nie znajduje się zrozumienia, które by tak rzec, które pomaga się nam rozwijać. Ja miałem szczęście, by tak rzec, ponieważ je znalazłem. I dziękuję życiu. Dziękuję mu, życie to śpiew, życie to taniec, życie to miłość. Wielu ludzi pyta mnie o to samo, ale jak ty to robisz?, skąd czerpiesz tę radość? A ja odpowiadam, że to proste, to umiłowanie życia, to właśnie ono sprawia, że dzisiaj na przykład buduję maszyny, a jutro... kto wie, dlaczego by nie, oddam się pracy społecznej i będę ot, choćby sadzić... znaczy... marchew.>

Chyba nie ma dobrej receptury. Pracowałem z ludźmi, którym wystarczyły same tytuły. Mnie nie (as n00b) i kilku innym osobom też niekoniecznie. Poprosiliśmy/wymogliśmy, żeby były opisy, żeby było z czym zacząć zanim, jak będzie trzeba, po wiedzę plemienną się wybierzemy, coś co przypomni o co w zasadzie chodziło jak omawiane były zadania podczas planowania.
Szczegółowo nie opisywaliśmy, ale pisaliśmy szczegóły, które wydawały się ważne, żeby ich nie pominąć, Czasem dopisywało się treść, żeby kolejna osoba np. tester mógł się zorientować co w zasadzie się zmieniło.

Nie ma, że taka forma jest dobra a taka to nieprofesjonalna. Jak sobie piszecie tak piszcie, jak chcecie zmienić to zmieńcie (trochę też trzeba chodzić na kompromis, a nie jak somekind pisze, że to a to to bzdury - chyba, że rzeczywiście nikomu te nadmiarowe rzeczy nie pomagają).