Please enable JavaScript.
Coggle requires JavaScript to display documents.
DEV podejmuje zadanie przypisane w RM do niego, zmienia status w RM z NOWY…
- DEV podejmuje zadanie przypisane w RM do niego, zmienia status w RM z NOWY na W TOKU
REDMINE:
STATUS: NOWY -> W TOKU
PRZYPISANY DO: DEV
NOTATKA: brak
LOKALIZACJA: brak
- Po zrealizowaniu zadania DEV przekazuję zadanie do Code Review, zmienia status w RM z W TOKU na CODE REVIEW, przypisuje zadanie w RM do DEV2 i umieszcza w notatce link do Merge Request przypisany w GITLabie do DEV2 wykonującego Code Review.
REDMINE:
STATUS: W TOKU -> CODE REVIEW
PRZYPISANY DO: DEV -> DEV2
NOTATKA: link do Merge Request
LOKALIZACJA: brak GITLAB:
DEV tworzy Merge Request i przypisuje go DEV2
- DEV2 wykonuje Code Review:
a) DEV2 nie akceptuje zmian, odrzuca Merge Request w GITLabie, zmienia status w RM z CODE REVIEW na ODRZUCONY i przypisuje zadanie do DEV - powrót do pkt 1
REDMINE:
STATUS: CODE REVIEW -> ODRZUCONY
PRZYPISANY DO: DEV2 -> DEV
NOTATKA: Informacja o odrzuceniu CR.
LOKALIZACJA: brak GITLAB:
DEV2 odrzuca Merge Request.
3.DEV2 wykonuje Code Review:
b) DEV2 akceptuje zmiany, akceptuje Merge Request w GITLabie, zmienia status w RM na z CODE REVIEW -> DO WERYFIKACJI, umieszcza w notatce potwierdzenie Code Review i przypisuje zadanie DEV. DEV weryfikuje swoje zmiany.
REDMINE:
STATUS: CODE REVIEW -> DO WERYFIKACJI
PRZYPISANY DO: DEV2 -> DEV
NOTATKA: Informacja o potwierdzeniu CR.
LOKALIZACJA: brak
GITLAB:
DEV2 akceptuje Merge Request.
- DEV robi deploy zmian (przenosi zmiany na brancha):
b) DEV potwierdza swoje zmiany na branchu, zmienia status w RM z DO WERYFIKACJI na DO TESTÓW, umieszcza w notatce informacje gdzie należy przetestować i przepisuje zadanie do osoby weryfikującej UX, ustawia lokalizację na BRANCH
REDMINE:
STATUS: DO WERYFIKACJI -> DO TESTÓW
PRZYPISANY DO: DEV -> QA
NOTATKA: Informacja o tym, gdzie można przetestować zmiany np. link do brancha.
LOKALIZACJA: BRANCH
- UX wykonuje test zmian na branchu:
a) UX nie potwierdza zmian, zmienia status w RM z DO TESTÓW na ODRZUCONY, umieszcza w notatce informacje dlaczego nie potwierdza zmian, przypisuje zadanie do DEV - powrót do pkt 1
REDMINE:
STATUS: DO TESTÓW -> ODRZUCONY
PRZYPISANY DO: UX -> DEV
NOTATKA: Informacja o tym, dlaczego UX nie potwierdza zmian.
LOKALIZACJA: BRANCH
- UX wykonuje test zmian na branchu:
b) UX potwierdza zmiany, zmienia status w RM z DO TESTÓW na DO AKCEPTACJI,, opcjonalnie w notatce umieszcza swoje spostrzeżenia, przypisuje zadanie do PM
REDMINE:
STATUS: DO TESTÓW -> DO AKCEPTACJI
PRZYPISANY DO: UX -> PM
NOTATKA: Opcjonalnie, spostrzeżenia UX, które mogą być istotne dla PM.
LOKALIZACJA: BRANCH
- PM weryfikuje jeszcze raz zmiany na branchu
a) PM nie potwierdza zmian, zmienia status w RM z DO AKCEPTACJI na ODRZUCONY,, umieszcza w notatce informacje dlaczego nie potwierdza zmian, przypisuje zadanie do UX
REDMINE:
STATUS: DO AKCEPTACJI -> ODRZUCONY
PRZYPISANY DO: PM -> UX
NOTATKA: Informacja o tym, dlaczego PM nie potwierdza zmian.
LOKALIZACJA: BRANCH
- PM weryfikuje jeszcze raz zmiany na branchu
b) PM potwierdza zmiany, zmienia status w RM z DO AKCEPTACJI na U KLIENTA, przekazuję zmiany do weryfikacji przez klienta w MANTIS.
REDMINE:
STATUS: DO AKCEPTACJI -> U KLIENTA
PRZYPISANY DO: PM
NOTATKA: brak
LOKALIZACJA: BRANCH
- Klient weryfikuje zmiany na branchu
a) Klient nie potwierdza zmian, PM zmienia status w RM z U KLIENTA na ODRZUCONY, przypisuje zadanie do UX, w notatce na podstawie przekazanych informacji w mantis informuje dlaczego klient nie potwierdza zmian
REDMINE:
STATUS: U KLIENTA -> ODRZUCONY
PRZYPISANY DO: PM -> UX
NOTATKA: Informacja o tym, dlaczego klient nie potwierdza zmian.
LOKALIZACJA: BRANCH
- Klient weryfikuje zmiany na branchu
b) Klient potwierdza zmiany, PM zmienia status w RM z U KLIENTA na W TOKU, przypisuje zadanie do DEV, w notatce umieszcza prośbę o przeniesienie zmian na BETA.
REDMINE:
STATUS: U KLIENTA -> W TOKU
PRZYPISANY DO: PM ->DEV
NOTATKA: Request o przeniesienie zmian na BETA
LOKALIZACJA: BRANCH
- DEV wykonuje aktualizację bety, sprawdza zmiany na beta, zmienia status w RM z W TOKU na DO TESTÓW, przypisuje zadanie do UX w notatce umieszcza informację o przeniesieniu zmian na BETA, ustawia LOKALIZACJĘ na BETA.
REDMINE:
STATUS: W TOKU -> DO TESTÓW
PRZYPISANY DO: DEV -> UX
NOTATKA: Informacja o przeniesieniu zmian na beta.
LOKALIZACJA: BRANCH -> BETA
- UX weryfikuje zmiany na beta.
a) UX nie potwierdza zmian, zmienia status w RM z DO TESTÓW na ODRZUCONY, umieszcza w notatce informacje dlaczego nie potwierdza zmian, przypisuje zadanie do DEV - powrót do pkt 1
REDMINE:
STATUS: DO TESTÓW -> ODRZUCONY
PRZYPISANY DO: UX -> DEV
NOTATKA: Informacja o tym, dlaczego UX nie potwierdza zmian.
LOKALIZACJA: BETA
- UX weryfikuje zmiany na beta.
b) UX potwierdza zmiany, zmienia status w RM z DO TESTÓW na DO AKCEPTACJI,, opcjonalnie w notatce umieszcza swoje spostrzeżenia, przypisuje zadanie do PM
REDMINE:
STATUS: DO TESTÓW -> DO AKCEPTACJI
PRZYPISANY DO: UX -> PM
NOTATKA: Opcjonalnie, spostrzeżenia UX, które mogą być istotne dla PM.
LOKALIZACJA: BETA
- PM weryfikuje jeszcze raz zmiany na beta.
a) PM nie potwierdza zmian, zmienia status w RM z DO AKCEPTACJI na ODRZUCONY,, umieszcza w notatce informacje dlaczego nie potwierdza zmian, przypisuje zadanie do UX
REDMINE:
STATUS: DO AKCEPTACJI -> ODRZUCONY
PRZYPISANY DO: PM -> UX
NOTATKA: Informacja o tym, dlaczego PM nie potwierdza zmian.
LOKALIZACJA: BETA
- PM weryfikuje jeszcze raz zmiany na beta.
b) PM potwierdza zmiany, zmienia status w RM z DO AKCEPTACJI na U KLIENTA, przekazuję zmiany do weryfikacji przez klienta w MANTIS.
REDMINE:
STATUS: DO AKCEPTACJI -> U KLIENTA
PRZYPISANY DO: PM
NOTATKA: brak
LOKALIZACJA: BETA- 2 more items...
- DEV robi deploy zmian (przenosi zmiany na brancha):
a) DEV nie potwierdza swoich zmian na branchu, zmienia status w RM z DO WERYFIKACJI na W TOKU, powrót do pkt1
STATUS: DO WERYFIKACJI -> W TOKU