Zlecanie zadań w pracy

Hej

Mam takie pytanie odnośnie waszej pracy w firmach. Jak są Wam(programistom, devom, koderom) zadania wszelakiej maści( począwaszy od programowania). Jak to wygląda? Czy "na gębę" czyli "zrób system który obsłuży to i to tutaj masz trochę "niekompletnej dokumentacji np tabelki sql"? Czy jeszcze inaczej ? Jestem świeżo po studiach w pierwszej pracy w korpo i myślałem, szczerze mówiąc że inaczej wygląda zlecanie zadań programistycznych. Np. schematy diagramy z klasami, opis zadania, funkcjonalności wymagania itp. czyli w szczegółach. Jak to u Was wygląda ?

Pozdrawiam,
Krzysiek :)

U mnie to wygląda różnie w zależności od tego co dostaje.
Pare ostatnich projektów to było tak że otrzymałem dokumentacje obecnej aplikacji, a następnie dodatkowe rzeczy które mają się w niej znaleźć. Pisałem wszystko od zera, w 100% sam, jedynie jak czegoś nie wiedziałem no to trzeba było skonsultować.
Projekt nad którym teraz siedzę to jest gotowe rozwiązanie które już działa, jednak trzeba dodać tam różne nowe funkcje i ponieważ zostało to napisane przez jakiegoś idiotę, to zarówno mi jak i mojemu senior developerowi ciężko czasem jest dojść co jest gdzie (w głównym WIDOKU jest około 7000 linii kodu, więc jest to naprawdę kiepsko napisane). I w tym przypadku bardzo często się o coś pytam itd.

U nas zawsze dostajemy dokumentacje funkcjonalna tego co klient chce. Czasami dochodzi do tego tez dokumentacja techniczna, jednak jest to bardziej zbior sugestii jak dana rzecz moznaby zrobic. Taski zazwyczaj przydzielane sa na Jirce i kazdy do swojego przygotowuje jakas dok. techniczna jak dana rzecz zostala zrobiona. W razie jakby chcieli spojrzec, cos zmienic w przyszlosci.

Ze schematami, tablekami, uml, itp. sie nie spotkalem bo to w duzej mierze juz od nas zalezy jak dane zadanie wykonamy i to developer sobie konkretnie to ogarnia. Oczywiscie co jakis czas sa code review, mamy podpietego sonara pod kodzik. Ogolnie jest spoko. JUnity tam gdzie sie da tez sa dorzucane.

U nas agile (niestety tylko w ramach naszego zespołu). Od klienta dostajemy specyfikację, tworzymy user stories, test case'y itp. na rally. Potem to już od "samoorganizującego się" zespołu zależy, co kto sobie weźmie do roboty. Ściśle współpracujemy z osobami z biznesu, w tym z product ownerem - z analitykami i konsultantami, którzy decydują o ostatecznym wyglądzie i funkcjonalności programu. Myślenie, że dostaniesz od razu pełną, szczegółową dokumentację brzmi bardzo waterfallowo :)

My staramy się trzymać agile. My 2-tygodniowe "sprinty", które polegają na realizacji jakiegoś konkretnego celu. Np. obsługi jakiejś złożonej operacji w aplikacji. W pierwszym dniu sprintu robimy planowanie i dorzucamy notki z backloga do sprintu i w razie potrzeby tworzymy nowe notki. Notki są kategoryzowane na "feature'y" (np. feature: Logowanie i do tego notki: 1 - przygotowanie GUI, 2 - połączenie z serwerem, 3 - autoryzacja, etc.). Podczas sprintu developerzy przypisują do siebie notki, realizują je zgodnie z Git flow (osobny branch na feature, osobny branch na task/notkę). Po zrealizowaniu taska, przechodzi on Code Review (ostatnio używamy do tego Gitlaba). Po wprowadzeniu zmian po Code Review, mergujemy brancha z taskiem do feature brancha. Po skończeniu wszystkich tasków, mergujemy feature brancha do mastera i przekazujemy notkę do testów testerom. Testerzy mogą odbijać notkę, gdy coś jest nie tak, po poprawce, notka wraca do testów i tester podejmuje decyzję, czy ją zamknąć. Szczegóły dot. kwestii domenowych dogadujemy z Product Ownerem i testerami. Po zakończeniu sprintu, robimy jego review i retrospektywę. Do obsługi notek korzystamy z Jiry. Nie spotkałem się z lepszym issue trackerem. Jeśli chodzi o bardziej skomplikowane zadania, to czasami rozpisujemy diagramy klas UML i opisujemy proces działania aplikacji. Najczęściej dzieje się to, gdy projekt rusza od zera lub jest robiony jakiś konkretny refaktoring kodu. Później, gdy projekt już hula, ewentualne diagramy siedzą na wiki (na Jirze - confluence) i można do nich powrócić.