Czy są szczegółowo opisywane? Spotkałem się z taskami typu: "Jako użytkownik mogę dodać nowe produkty", ale taki opis zadania jest dla mnie niewystarczający. Czy to normalne? IMO powinien być dokładny opis, a nawet mockup z całym flow żeby po prostu usiąść i zrobić, a nie zastanawiać się pół dnia o co chodzi.
1
0
W firmach czasami jest tak, że nawet osoba zgłaszająca zadanie nie jest do końca pewna o co chodzi i właśnie rolą programisty jest dowiedzenie się kilku rzeczy tj. rozwiązanie problemu a nie samo kodowanie. Zakodować potrafi każdy jak wskażę jej palcem miejsce i dokładne kryteria ale czy wtedy taka osoba byłaby potrzebna w firmie?
A jak uda Ci się rozwiązać problem bez napisania linijki kodu to +1 dla Ciebie.
0
Zależy. Czasem są bardziej specyficzne (zmień szyfrowanie czegośtam z AES-128/CBC/PKCS#5 na AES-256/GCM) a czasami mniej (ogarni od zera co trzeba zrobić żeby zintegrować jakiśtam system płatności z backendem).
0
Świetny Kot napisał(a):
(ogarni od zera co trzeba zrobić żeby zintegrować jakiśtam system płatności z backendem).
Ile czasu na coś takiego? (estymacja)
0
WeiXiao napisał(a):
Świetny Kot napisał(a):
(ogarni od zera co trzeba zrobić żeby zintegrować jakiśtam system płatności z backendem).
Ile czasu na coś takiego? (estymacja)
Z odpowiednio zmotywowanym zespołem sądzę, że w jakieś 10 lat powimnno dać radę.
0
Zależy od tego jakie mają poryte api. Tak przeciętnie z 5 punktów, co się przekłada na gdzieś w okolicach niecałych 2 moich dni? Wynikiem jest epic/story i jakiś podstawowy flow dla naszych zastosowań plus wymagania jeśli chodzi o logowanie transakcji i ich rozliczanie, kawałek wewnętrznej dokumentacji technicznej (dane kontaktowe na ich support, ich cykl releasowy, gdzie jest dokumentacja).
1
Markuz napisał(a):
W firmach czasami jest tak, że nawet osoba zgłaszająca zadanie nie jest do końca pewna o co chodzi i właśnie rolą programisty jest dowiedzenie się kilku rzeczy tj. rozwiązanie problemu a nie samo kodowanie.
Programista ma dowiedzieć się gdzie i jak coś zrobić najlepiej. Ale tego co ma być zrobione i w jakim celu powinien dowiedzieć się analityk biznesowy.
0
Wszystko zależy od projektu.
Opis typu: Jako użytkowi X, chcę dodawać produkty Y, do koszyka. Krytearia akceptacji: … … ….
W większości wypadków wystarczą, bo większość projektów jest po prostu durna.
Jeśli jednak produkt jest bardziej skomplikowany (np system finansowy dowolnej maści), to lepiej dokładniej skonkretyzować co i jak to lepiej korzystać z takich cudów jak np:
fitnesse https://github.com/unclebob/fitnesse
0
A jak sie naprawia bledy w dzialajacym, produkcyjnym kodzie, to jak to sie nazywa?
Pracuje juz 2 miesiace i zajmuje sie tylko takimi przypadkami, czyli np. cos nie zadzialalo w konkretnym przypadku na produkcji i trzeba ustalic przyczyne.
Mam kilku doswiadczonych kolegow, ktorzy wola naprawiac bledy, niz wytwarzac nowe funkcjonalnosci.
0
U mnie w firmie zazwyczaj pisze się po prostu historyjki typu "jako zalogowany użytkownik chcę mieć możliwość zmiany swojego adresu e-mail", jakiś podstawowy flow typu "userowi wyświetlany jest taki i taki widok (tu makieta od grafika), input waliduje takie i takie dane z takimi i takimi warunkami, submit wysyła ajaxem taki json, oczekuje zwrotki takiego jsona" itp. Ale takie wymagania, przepływy i use case'y przygotowuje zazwyczaj analityk (których u nas nie ma, bo to malutka firma, sami się tym zajmujemy).
W prywatnych side-projectach sam sobie jestem analitykiem, projektantem, grafikiem, back-endowcem i front-endowcem, i jest o wiele łatwiej zapanować nad projektem, taskami i implementacją :)
0
Wielki Ogrodnik napisał(a):
A jak sie naprawia bledy w dzialajacym, produkcyjnym kodzie, to jak to sie nazywa?
Pracuje juz 2 miesiace i zajmuje sie tylko takimi przypadkami, czyli np. cos nie zadzialalo w konkretnym przypadku na produkcji i trzeba ustalic przyczyne.
Mam kilku doswiadczonych kolegow, ktorzy wola naprawiac bledy, niz wytwarzac nowe funkcjonalnosci.
Maintenance/Bugfixing. O tego typu pracy można przeczytać nawet kilka ciekawych artykułów, a czasem i kilka sporej długości lamentów. ;)
2
Kraków Samiec napisał(a):
Czy są szczegółowo opisywane? Spotkałem się z taskami typu: "Jako użytkownik mogę dodać nowe produkty",
To nie jest **task ** tylko user story.
0
Na gębę. Rób "to", a jak będziesz miał czas to sprawdź na drugim projekcie co jest bo chyba baza danych coś nie działa. A po wszystkim wpisuje się w systemie "zrobienie x - 16 godzin", "zrobienie y - 72 godziny" ( sensie że 9 dni).
3
Na przykład u mnie w firmie Managerzy piszą taski na karteczkach, a następnie rzucają je na podłogę. Jakiego taska złapesz ten jest Twój.
0
Roznie, zalezy od klienta. Np. teraz klient tworzy taski, robi AC, wrzuca docsy, mockupy, user stories i robisz.
0
Miałem nieprzyjemnosc pracować w firmie, gdzie były same tytuły i był dramat przy prawie każdej historyjce, bo były one tworzone kilka miesięcy do przodu więc autor prawie nigdy nie pamiętał co chciał. To był najkrótszy epizod w mojej karierze, między innymi z tego powodu.
3
Zawsze staram się tworzyc taski tak, żeby junior, który przyszedł wczoraj chociaż wiedział z grubsza o co chodzi. Jasno określam miejsce w aplikacji. Podpowiadam z czego można ewentualnie skorzystać. Zbieram do kupy wszystkie przydatne informacje, załączniki z maili etc. Opisuje taska tak, jak sam bym chciał go widzieć po miesięcznym urlopie, po którym nic nie pamiętam.
W jednej z firm mieliśmy plugin do Jiry który dodawał Taba do taska na historie użytkownika opisane gherkinem.
W innej firmie był dramat - same ogólniki dla wtajemniczonych, prosiłem wielokrotnie by trochę zmienić podejście, ale jak grochem o ścianę. W firmie nie pracuję już ja i wielu innych:).