Home

Słownik

• User Story (US) = wymaganie
• Karteczka = zadanie
• Story Points (SP) = abstrakcyjna miara złożoności zadania. Nie ma żadnego przełożenia na czas potrzebny na zrealizowanie zadania, służy tylko i wyłącznie do porównywania zadań ze sobą (które jest trudniejsze, bardziej złożone).
• Velocity = liczba punktów (SP), które zespół zrealizował w czasie sprintu
• Sprint = okres czasu, w który zobowiązujemy się dostarczyć nowe funkcjonalności, u nas 1 tydzień

Projekty

User Stories

• To Do - User Stories, które są do zrobienia
• In progress - User Stories, dla których zostały utworzone zadania, które będą robione w aktualnym sprincie
• Done - User Stories, które zostały w całości zaimplementowane, a praca została zatwierdzona przez @LordLukin.

Sprint X

Tablica dla kolejnych sprintów z zaznaczeniem czasu ich trwania.

• To Do - tu są zadania, które są zaplanowane na ten sprint.
• In progress - zadania, nad którymi aktualnie pracujemy. Dla każdego takiego zadania raz dziennie musi pojawić się update na karteczce z informacją ile SP pozostało albo czy coś nas blokuje.
• Needs review - po utworzeniu merge requestu zadania trafiają tutaj
• Reviewer approved - po zatwierdzeniu zmian ja przesuwam karteczkę do tej kolumny. Zmiany mogę zmergować ja lub ktokolwiek inny.
• Done - zrobione zadania.

Numeracja zadań

Każde zadanie powinno być poprzedzone numerem wymagania do którego się ono odnosi. Wyjątkiem są Issues. Przykłady: [US1] Project skeleton, [US1] Add README.md

Organizacja pracy

1. Pracujemy poprzez pull requesty
2. Biorąc zadanie konwertujemy je na Issue i przypisujemy do siebie.
3. Po planningu robimy screenshot tablicy, aby wiedzieć co zobowiązujemy się dostarczyć w ciągu tego sprintu.
4. Po tygodniu rozliczamy się ze zobowiązania, zapisujemy ile zadań zrobiliśmy i na ile one były szacowane. Robimy statystyki naszej pracy - liczymy velocity. Rozbijamy kolejne wymagania na zadania i planujemy co weźmiemy na kolejny sprint. Historia się powtarza :)
5. Jeśli gdzieś zauważysz błąd to wystaw Issue. Jest specjalna formatka odnośnie tego co wypadałoby napisać, ale nie będziemy bardzo mocno się tego trzymać, bo na pewno większość błędów będzie łatwa do zreprodukowania.
6. Priorytety:
   1. Komentowanie pull requestów
   2. Issues
   3. Codacy issues
   4. Refaktoring
   5. Nowe zadania
7. Po zrobieniu karteczki zanim weźmiesz jakąkolwiek inną to musisz obowiązkowo zobaczyć czy są jakieś pull requesty czekające na skomentowanie. Musisz napisać swoje uwagi, a jeśli ich nie masz to komentujesz, że wszystko jest ok. Jeśli nie masz już pull requestów do skomentowania to sprawdzasz, czy nie można poprawić jakości kodu. Gdy zauważysz gdzieś błąd albo że czegoś brakuje to zgłaszasz Issue. Następnie możesz przypisać sobie jakieś Issue (z Codacy również). Jeśli uważasz, że któryś kawałek kodu można zrefaktorować to zajmujesz się takim refaktorem uprzednio tworząc na niego zadanie wyestymowane na 0 SP. Jeśli stwierdzisz, że cały projekt jest zrozumiały i czytelny to dopiero wtedy możesz wziąć następną karteczkę z oficjalnych wymagań. Nie dopuszczamy możliwości, że od jednej osoby będzie kilka pull requestów związanych z zadaniami z karteczek czekających na zatwierdzenie.
8. UWAGA: Pull requesty wymagają sprawdzenia najpierw przez kogoś z zespołu, a potem przez @LordLukin :) Przypisujcie proszę @LordLukin do zrobienia review, jak już ktoś z zespołu zatwierdzi pull requesta.