[maur]

Co kręci Was w pracy, z rzeczy pozafinansowych?
Jakieś możliwości rozwoju/benefity pozapłacowe?

#programista15k #pracait #it #praca

[maur]

@zibizz1: wydaje mi się, że na żadnym stanowisku nie będziesz mógł wszystkiego mniej atrakcyjnego zrzucić. A wręcz na wyższych jeszcze więcej możesz mieć takich rzeczy, także ten. Miej jaja i kończ waść co zacząłeś! :P

[Sefton]

@Sefton: Ja bardziej pracuje na 4 statusach w jirze ustalonych, jeśli 3 taski mają priorytet jiry low, to nie patrzymy na ich kolejność. Raczej ani devi ani PO nie narzekają. Ale zaciekawiłeś mnie i chce zrozumieć :)

- pair coding w tym przypadku (junior chce wziąć 1 ticket z góry, do którego brak mu wiedzy) to odrywanie np seniora już teraz bo junior chce wziąć taska, którego nie ogarnia do końca.

-

[maur]

W backlog masz konkretną kolejność priorytetów a nie liczbę przypisaną do Epic\Feature\US etc. To jest dosyć mylące niestety.

@Sefton: to jeszcze kwestia konfigu - w jirze np można zarówno mieć ustawione zarządzanie kolejnością ręcznie jak i tymi 3-5 priorytetami w polu US "priority"

To tyle zmiennych, że nie widzę w tym

[Sefton]

@Sefton: o, to zapytam inaczej. Jaki widzisz sens w tym by iść przez taski w sprincie w 100% kolejności zaplanowanej?

jeśli spojrzymy z punktu widzenia, że celem ma być zamknięty sprint, to jaka różnica, czy czasem ktoś weźmie 2 od góry task, a nie 1? (pod warunkiem, że mają podobne priorytety, może nazwijmy to wagi priorytetów - czyli nie ma sytuacji, że olewany jest task "high" bo devowi się podoba

[maur]

Najprostrzy powód to zależność (predecessor vs successor).

@Sefton: Jasne. Na jakim sofcie pracujesz? Jira ma coś takiego jak linked issues

Ale jeżeli tego nie ma to jak dla mnie powód jest prosty - nigdy nie wiesz czy zamkniesz sprint (chyba, że bierzesz tylko rzeczy na 10%...)

@Sefton: tak, dlatego u nas kolejność jest cel sprintu>taski high>taski medium>taski low i to jest ważne.
No nic, różne procesy i potrzeby,

[Sefton]

@maur: Kiedyś Jira, teraz DevOps

[Sefton]

@Sefton: tak, dlatego u nas kolejność jest cel sprintu>taski high>taski medium>taski low i to jest ważne.

No nic, różne procesy i potrzeby, co komu działa :)

@maur: u mnie chyba podobnie o ile dobrze Cię rozumiem. Ale zawsze pomiędzy np. "high" mamy priorytet który jest "bardziej high". Jak masz dwa PBI, z czego jeden zamyka całą funkcjonalność a drugi nie to ten pierwszy teoretycznie jest wyżej

[maur]

@Sefton: no tak, by być dokładnym to mamy: critical, high, medium, low, none
a wątek zależności mamy rozwiązany używając "linked issues". W przypadku taska zamykającego/spinającego całą nową funkcjonalność to jest zrobiony i ma dodane x linked issues typu "blocked by"
inna sytuacja - jeśli task wyniknął ze spike to ma przypiętego spike jako "is caused by" czy "relates"