Guide to GitKraken - marcinogo/robot GitHub Wiki

1. Kolejka zdarzeń - rzeczy do zrobienia. Dodane tam zadania muszą być odpowiednio oznaczone i opisane. Nikt nie może być przypisany do żadnego zadania w kolejce.

2. W trakcie - każde zadanie w tej kolumnie musi być przypisane do conajmniej 1 osoby. Podczas wykonywania zadania szczegółowo dokumentować jego przebieg w komentarzach. Czyli przydatne linki, wystepujące problemy, linki do commitów składających się na zadanie. Koniecznie rozpisać je sobie na zadania i wykreślać je regularnie jeśli nie było rozpisane wcześniej.

3. Recenzja - każde zadanie po wykonaniu ląduje w tej sekcji. Aby to miało sens zadanie musi mieć linki do commitów oraz link do "pull requesta" w komentarzu. Należy wtedy wypisać wszelkie osoby robiące to zadanie. Gdy ktoś podejmuje się recenzji przypisujemy się do zadania.

4. Do poprawy/nie przeszło recenzji - info, że dane zadanko nie przeszło recenzji i konieczna jest poprawa - autorzy poprawiają.

5. Do scalenia do mastera - codziennie dowiezione funkcjonalności sprawdzone i gotowe do scalenia z masterem lądują w tej sekcji. Wiemy wtedy ile i jakie konkretne rzeczy znajdą się na masterze. Zadnia niefunkcjonalne, na które nie można wystawić PR należy po udokumentowaniu po prostu zamknąć.

Robiąc nowe zadanie dodajemy je do kolejki zdarzeń. Należy je dobrze opisać i udokumentować, przypisać odpowiednie epiki. Fajnie też jakby od razu dodać w nim zadania - wtedy możemy powiedzieć, że tablica nas napędza.

Zarówno w kolejce zadań jak i w innych sekcjach jest hierarchia i waga zadań. Przypisując się do zadania kierujemy się priorytetami, nie ilością pracy czy "fajnością zadania"

Idąc od najważniejszych:

1. FOR REVIEW - najmniejsza ilość pracy, aby dane zadania uznać za zamknięte co najszybciej przybliżna nas do celu

2. PRIORITY - najważniejsze zadanie w danym momencie do wykonania

3. PROBLEMATIC - trzeba szybko określić dlaczego dane zadanie jest problematyczne i jaki ma wpływ na resztę zadań. Czy potrzebna jest pomoc przy rozwiązaniu albo czy nie trzeba oznaczyć zadania "BLOCKED". Jeśli oznaczamy zadanie jako PROBLEMATIC to w komentarzach muszą być informacje o tym co sprawia problem, jak go zreprodukować, podać listę prób rozwiązania i inne przydane informacje.

4. MUST - wymaganie, które musi znaleźć się w produkcie końcowym

5. SHOULD - wymaganie, które powinno znaleźć się w produkcie końcowym

6. COULD - wymaganie, które może musi znaleźć się w produkcie końcowym

Oczywiście kombinacja epików daje większy priorytet zadania

Pozostałe ważne epiki

BLOCKED - zadanie jest zablokowane z jakiegoś powodu i nie jest popychane do przodu. Oznaczając zadanie w ten sposób w komentarzach muszą znaleźć się: 1. informacje dlaczego zadanie jest zablokowane 2. odnośnik do zadania/zadań blokujących

SPRINT#…​ - każde zadanie jest przypisane do danego sprintu. Jeśli nie wszystkie z danego zostaną zamknięte to w kolejnym są PRIORITY

EPIKI FUNKCJONALNE - jak np MVP, CQRS, itd. odpowiadają konkretnym grupom funkcjonalności, które powinny być dowiezione w danym sprincie. Ich lista oraz szczegółowe wytłumaczenie znajduje się na slacku