W tym dokumencie znajdziesz opis „uniwersalnej” metody prowadzenia projektów IT.
Przewodnikiem po tym obszarze jest Grzegorz Szeffer Pliś, project manager w softwarehouse Inovatica. Grzegorz wraz ze swoim zespołem na co dzień mierzą się z wymagającymi uwagi i uporządkowania projektami.

Zarządzanie projektami IT

Na wstępie muszę Cię zmartwić, podejście które opisuję nie jest złotym Grallem zarządzania projektami, które można zastosować w każdym możliwym projekcie. Niestety takiego uniwersalnego podejścia nie da się stworzyć, gdyż każdy projekt jest po prostu inny – ma swoją indywidualną specyfikę, w której dane metody i techniki albo sprawdzą się idealnie, albo wprost przeciwnie.
Z uwagi na powyższe, przybliżę Ci podejście, które wymyśliłem na podstawie ponad 10 lat mojej pracy z projektami developerskimi i utrzymaniowymi w IT. Jest ono oparte o zwinne podejście do zarządzania projektami (SCRUM), jednakże w niektórych miejscach bardziej sformalizowane, niźli w samym frameworku SCRUMa. 

1. Wstęp o frameworku SCRUMa

Framework Scrum (nie mylić z metodyką prowadzenia projektów, którą Scrum nie jest), opiera się na trzech filarach:

1. Przejrzystość (Transaparency)
2. Inspekcja (Inspection)
3. Adaptacja (Adaptation)

O samych filarach Scruma, można napisać całą książkę, albo chociaż długi rozdział.
Po krótce można te elementy opisać jako:
Przejrzystość (transparentność) polega na nieustannej wymianie pełnych i rozumianych przez wszystkich informacji. Istotne jest, by stan prac był jasny nie tylko dla członków zespołu, ale również ich otoczenia (interesariusze). Nie chodzi tu o raportowanie stanu prac, ale o wspólnym budowaniu świadomości na jakim etapie się obecnie znajdujemy i co jest w tym momencie najistotniejsze. Dotyczy to również informacji na temat wszystkich pojawiających się problemach, które utrudniają realizację celów.

Inspekcja związana jest ze skupieniem uwagi na przebiegu procesu i identyfikowaniem zachodzących nieprawidłowości. By można było efektywnie śledzić wszystkie zmiany konieczna jest wspomniana wyżej przejrzystość procesu. Inspekcje należy wykonywać regularnie, jednakże nie nadmiernie często co mogłoby zaburzyć ustalony rytm pracy wszystkich członków zespołu. 

Ostatnim filarem Scruma jest adaptacja. To umiejętność szybkiej diagnozy i wprowadzenia zmian, które są podyktowane zmieniającymi się warunkami na rynku lub wynikają z przeprowadzonej inspekcji. Dostosowanie do nowych warunków i wprowadzenie ulepszeń do procesu następuje w tym samym momencie, co ich inspekcja.

 Opis filarów zapożyczony ze strony biegajewski.com/pl/co-to-jest-scrum-trzy-filary/

2. Zespół w SCRUMie 

Podstawą funkcjonowania SCRUMa jest niewielki zespół, składający się z 5-9 osób.
W jego obrębie nie występują podzespoły, jak również nie ma hierarchii.
W jego skład wchodzi jeden Scrum Master, jeden Product Owner oraz Developerzy.
Scrum Teamy są interdyscyplinarne, co oznacza, że ich członkowie mają wszystkie umiejętności potrzebne do wytwarzania wartości co Sprint. Są także zespołami samozarządzającymi, co oznacza, że samodzielnie podejmują decyzję o tym, kto będzie wykonywał określone zadania, kiedy i jak.

2.1.1. Role w zespole Scrumowym 

Role w zespole Scrumowym mają określone odpowiedzialności:

Scrum Master ponosi odpowiedzialność za to, by Scrum był stosowany zgodnie ze Scrum Guidem. Realizuje to zadanie, pomagając wszystkim w zrozumieniu teorii i praktyki Scruma, zarówno w samym Scrum Teamie, jak i w organizacji

Product Owner ponosi odpowiedzialność za maksymalizowanie wartości produktu będącego efektem pracy Scrum Teamu

Natomiast Developerzy to osoby w Scrum Teamie zobowiązane do wytwarzania każdego aspektu użytecznego Incrementu w każdym Sprincie

Więcej szczegółów na temat zesposłu Scrumowego można znaleźć w Scrum Guide:

scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Polish.pdf

2.2. Ceremonie (spotkania scrumowe)

Cały Scrum obraca się wokół iteracyjnego modelu pracy. Poniżej można zobaczyć cały model przepływu pracy od Idei po przygotowany do wdrożenia przyrost. 

2.2.1. Sprint

Sprint jest centralnym elementem całego procesu. Stanowi on pojedynczy okres czasu w którym pomysły są przekształcane w wartość. Trwa on od 1 do 4 tygodni, przy stałej długości (czyli nie następuje jego zmiana ze sprintu na sprint). Ponadto,  w trakcie jego trwania odbywają się wszystkie inne ceremonie(spotkania scrumowe).
Dodatkowo, w trakcie trwania sprintu:

• nie dokonuje się żadnych zmian, które zagrażałyby osiągnięciu Celu Sprintu; 
• jakość nie spada; 
• Product Backlog jest w razie potrzeby uszczegóławiany;
• zakres pracy może być doprecyzowywany lub renegocjowany z Product Ownerem wraz z rosnącym zrozumieniem.

2.2.2. Sprint Planning

Przed przystąpieniem do pracy w sprincie, trzeba zaplanować prace, które mają zostać wykonane w najbliższym/najbliższych sprintach.

Ta operacja jest wykonywana podczas spotkania zwanego Sprint Planningiem. Sprint Planning może trwać do 8h dla miesięcznego sprintu (ewentualnie można przyjąć, że timebox dla sprint planningu to 2h per każdy tydzień sprintu.)

W trakcie niniejszego spotkania są omawiane trzy główne tematy:
Temat pierwszy: Dlaczego ten Sprint ma wartość? 

Temat drugi: Co może zostać Ukończone w tym Sprincie? 

Temat trzeci: W jaki sposób zostanie wykonana praca? 

Pierwszy wątek wiąże się z określeniem celu sprintu, czyli nadrzędnego wątku, który ma przyświecać realizacji prac w sprincie, a jednocześnie podnieść wartość biznesową produktu.
Cel Sprintu powstaje w wyniku dyskusji pomiędzy zespołem a Product Ownerem i musi zostać określony w czasie Sprint Planningu.

Wątek ten wiąże się bezpośrednio z tematem drugim, czyli wyborem zagadnień, które mają zostać wykonane w trakcie sprintu. Tematy są wybierane z Backlogu produktu, który powinien(misi) być uszeregowany wg. największej wartości biznesowej wg Product Ownera. Zadania są wybierane z góry listy. Nie wszystkie zadania przewidziane na sprint muszą się wiązać z celem sprintu, niemniej jednak cel sprintu jest nadrzędnym zobowiązaniem dla zespołu.

Trzeci temat, wiąże się z uszczegóławianiem sposobu realizacji User Story, jak i podziałem na mniejsze części. Jeżeli oprócz czterech kanonicznych spotkań jest realizowany także Refinement, to ten wątek jest realizowany w trakcie niego. Z praktycznego punktu widzenia jest to podejście lepsze gdyż zostaje rozłożone obciążenie analityczne dla developerów.
 

2.2.3. Daily Scrum

Daily Scrum jest krótkim codziennym wydarzeniem, służącym do synchronizacji wiedzy o postępie prac wewnątrz zespołu, w zakresie realizacji celu sprintu. Trwa maksymalnie 15 minut i powinno się odbywać w tym samym miejscu o tej samej porze. 

2.2.4. Sprint rewiew

Celem Sprint Review jest inspekcja efektów pracy wykonanej w Sprincie oraz wskazanie przyszłych 

zmian. Trwa ono maksymalnie 4 godziny dla miesięcznego sprintu.

Podczas tego wydarzenia Scrum Team wraz z interesariuszami oceniają to, co zostało zrealizowane podczas Sprintu oraz zmiany, jakie zaszły w ich otoczeniu. Na podstawie tych informacji uczestnicy wspólnie ustalają, co należy robić w następnej kolejności. 

Sprint Review nie powinno się ograniczać jedynie do prezentacji przyrostu, lecz także skupiać się na optymalizacji kierunku rozwoju aplikacji, w bezpośredniej współpracy z interesariuszami.

2.2.5. Sprint retrospective

Celem Sprint Retrospective jest planowanie sposobów na podniesienie jakości i efektywności działania scruma w zespole. 

W trakcie spotkania, cały zespół przedyskutowuje jak przebiegł ostatni sprint, w odniesieniu do osób, interakcji, procesów, narzędzi oraz Definicji Ukończenia. Omawiane są elementy i ich przyczyny co się sprawdziło, a co dało negatywny wynik. Elementy pozytywne są wzmacniane i kontynuowane, natomiast w zakresie negatywnych, przewiduje się działania w celu ich poprawy lub eliminacji.
Najbardziej potrzebne zmiany mogą zostać wręcz włączone do backlogu produktu. 

Sprint Retrospective kończy Sprint. Czas trwania tego zdarzenia scrumowego to maksymalnie trzy godziny dla miesięcznego Sprintu. Niezwłocznie po zakończeniu Retrospektywy jest rozpoczynany kolejny sprint.

2.2.6. Refinement

Ostatnim, lecz nie kanonicznym wydarzeniem w scrumie jest Refinement.
Jest to spotkanie lub spotkania odbywające się w trakcie trwania sprintu, służące doskonaleniu przyszłych historyjek, które są planowane do realizacji w późniejszym okresie.

W spotkaniu biorą developerzy i product owner. Scrum Master, z uwagi na niekanoniczość nie jest niezbędny, jednakże wskazany, by dysponował wiedzą na temat planowanych prac.

W trakcie spotkania są omawiane zadania o najwyższym priorytecie. Następuje ich analiza pod kontem niezbędnych do wykonania prac (wypełnienie sekcji „To Do”), podział na zadania/pod-zadania i ich wycena.

Spotkania te najlepiej organizować 1-2 w ciągu tygodnia po maksymalnie 1 godzinie.
Elementem wejściowym do spotkania jest uprzednia analiza przewidywanych zadań pod kontem zmian w kodzie.

Przydatną praktyką jest wybór przez PO/PM tematów do analizy szczegółowej (konkretne US) i ich rozdysponowanie między członków zespołu, tak by jeszcze przed spotkaniem zweryfikowali kod/zastanowili się co trzeba wykonać/zmodyfikować. Podczas samego refinementu, developer który weryfikował dane zadanie referuje wynik swoich analiz pozostałym członkom zespołu, tak by przyspieszyć omawianie zagadnienia. Na tej podstawie, są spisywane „to do’sy” i dokonuje się estymacji.

2.3. Artefakty

2.3.1. Product backlog

Product Backlog to jest to ewoluująca, uporządkowana lista tego, co jest konieczne do ulepszenia produktu - realizację projektu. To jedyne źródło pracy podejmowanej przez Scrum Team.
User strory w Product Backlog jest są porządkowane wg najwyższej wartości biznesowej oraz innych kryteriów wybranych przez Product Ownera. Jednocześnie US będące wyżej w Backlogu są jak najbardziej  uszczegóławiane, podczas gdy te znajdujące się dalej w kolejce są definiowane tylko na wyższym poziomie ogólności.

2.3.2. Sprint Backlog

Sprint Backlog stanowi wycinek Product Backlogu, który jednocześnie jest planem developerów na dostarczenie wartościowego Incrementu na najbliższy sprint. Jest to zakres pracy, który developerzy obligują się wykonać w czasie najbliższej iteracji. Składa się on z trzech elementów:
- Celu Sprintu (po co?),
- Elementów Product Backlogu wybrane do realizacji w Sprincie (co), oraz
- wykonalny plan dostarczenia Incrementu (jak).

2.3.3. Increment 

Increment to konkretny krok w kierunku osiągnięcia Celu Produktu. Każdy kolejny Increment rozbudowuje wszystkie wcześniejsze, jest też skrupulatnie weryfikowany po to, aby zapewnić, że wszystkie Incrementy są do siebie dopasowane. Aby dostarczyć wartość, Increment musi być użyteczny. W trakcie sprintu może zostać wytworzonych i dostarczonych wiele incrementów.
Żeby uznać, że wykonana praca jest Incrementem musi on spełnić definicję ukończenia, czyli wymagania jakościowe wymagane dla produktu. 

3. Poziomy i typy zadań

Zadania umieszczane w Backlogu Produktu mieć różny poziom ogólności i definiują różny zakres prac. Stopień ogólności można zwizualizować poprzez poniższą grafikę:

Analizując od najwyższego poziomu ogólności do najniższego można wyróżnić następujące poziomy:

• Temat
• Epik
• Story
• Task 
• Sub-Task

3.1. Temat

Poziom „Tematu” jest to poziom ogólności zbierający kilka-kilkanaście epików powiązanych z danym zagadnieniem projektowym. W przypadku projektów realizowanych w Inovatica mówimy o zakresie dotyczącym obszaru:  „Aplikacja Mobilna” czy „CMS dla aplikacji XYZ”. 

3.2. Epic

Poziom „Epic’u” to inaczej bardzo duża historyjka, która jest zbyt duża, aby dostarczyć ją w jednym sprincie i musi zostać rozbita na mniejsze części (historie). Epiki są w odpowiednim czasie stopniowo dzielone na zestaw mniejszych historyjek użytkownika.

Jako przykład można przedstawić “Jako administrator systemu, chce mieć panel administracyjny wyświetlający wszystkie zdefiniowane powiadomienia, tak aby móc łatwo aktualizować ich treści”.

3.3. User Story 

Story (historyjka) to pojedyncza funkcja lub wymaganie biznesowe, które można dostarczyć w ciągu jednego sprintu. Jednocześnie takie wymaganie przynosi wartość biznesową dla klienta.
Historyjka zanim może zostać przyjęta do realizacji przez zespół musi spełnić „Definition of Ready” (DoR). Inaczej mówiąc zdefiniowane kryteria które musi spełnić historyjka by mogła zostać przyjęta przez zespół do realizacji w trakcie sprintu. Najczęściej przyjmuje się jako DoR akronim INVEST, którym można rozwinąć jako:

• Independent – Niezależna od innych historyjek
• Negotiable – Negocjowalna – możliwa do doszczegółowienia, a jej zakres może zostać ustalony w trakcie negocjacji pomiędzy PO a Developerami
• Valuable – wartościowa – przynosząca wartość biznesową dla ostatecznego użytkownika
• Estimatable – estymowalna – możliwa do wycenienia w jednostkach czasu lub innych wymiernych jednostkach
• Small – mała – historyjka musi być na tyle mała, by można było ją zaplanować, oszacować i wykonać w trakcie jednego sprintu,.
• Testable – testowalna – praca wykonana na rzecz historyjki musi być możliwa do przetestowania i potwierdzenia wykonania prac i osiągnięcia zamierzonego efektu (przejścia testów akceptacyjnych

Historia nie musi od razu zawierać wszystkich informacji potrzebnych zespołowi do wykonania zadania.
Historie są często pisane w określonym formacie:
Jako... [użytkownik końcowy/określona rola]
Chcę... [co użytkownik chce zrobić po dostarczeniu funkcji]
Aby... [dlaczego chce funkcji/korzyści, jaką ona przynosi]
Czasami zespoły zaczynają od odwrotnej kolejności i umieszczają na początku „Aby…”.
Przykładowa historyjka użytkownika: „Jako administrator aplikacji, chcę widzieć listę wszystkich zdefiniowanych przerw serwisowych, aby móc łatwo zaplanować prace releasowe dla aplikacji”.³
[uwaga: powyższy opis User Story jest treścią do umieszczenia w treści zadania. Tytuł zadania powinien być znacznie krótszy, np.:[Admin] Pokazywanie listy przerw serwisowych.]

3.4. Task

Taski są elementami, które tworzą historyjkę. Zadania często są zgodne z akronimem SMART: 

• Specific(konkretne), 
• Measurable(mierzalne), 
• Achievable(osiągalne), 
• Relevant(istotne),
• Time-boxed (ograniczone czasowo) 

Podział na zadania nie jest niezbędny. Taski zachęcają do podziału Historyjki na elementy „poziomie” , zamiast podziału „pionowego”

3.5. Sub-task

Sub-taski – są elementami, na które można podzielić Taska, jeżeli wymaga on ścisłej współpracy np. na linii frontend-backend, czy frontend-UX/UI.

W przypadku podziału User Story na Taski/Sub-taski, wskazane jest by przy podziale określić w tytule US nadrzędne. Ponadto, deweloperzy powinni zwrócić uwagę na określenie kolejności realizacji zadań. Można to zrealizować chociażby poprzez odpowiednie nazewnictwo taska, np.:
[US- Admin] [kolejność zadania – 2/3] [[Tytuł – Endpoint listy powiadomień]

3.6. BUG

BUG’i – stanowią zgłoszenie błędów wykrytych w działaniu programu, czy to w procesie developmentu czy na etapie utrzymaniowym. Zgłoszenia mogą być albo wewnętrzne (zgłaszane przez testera, w trakcie różnych wersji testów aplikacji, lub też mogą być zgłaszane przez użytkowników końcowych).

W obrębie zgłoszenia powinny znaleźć się istotne informacje na temat samego błędu, czyli:
- w jakiej sytuacji wystąpił,
- na jakim użytkowniku (najlepiej ze screenem)
- w jaki sposób można powtórzyć błąd (lub czy było to zdarzenie jednostkowe)

Poniżej przykład rozbudowanego opisu bug’a:

# Aplikacja przestaje działać przy logowaniu z nieprawidłowym hasłem

**Description/Importance/User example**

Kluczowy problem przy odbiorze – do aplikacji będą logować się pracownicy, a na pewno ktoś źle kliknie.

**Places of occurence**

Tylko logowanie danymi pracownika ❌ (konta studenckie działają ✔️):

• Przez plan zajęć: [link_to_screen]
• Na ekranie początkowym [link_to_screen]

**Reproduction**

• Otwórz ekran z błędem, np. Menu > Plan zajęć.
• Podaj login pracownika (np. `adam.nowak@mail.com`).
• Wpisz nieprawidłowe hasło, np. `abc`.

**Incorrect behaviour**

Na ekranie pojawia się animacja ładowania, po chwili zamraża się i aplikacja przestaje działać (crash).

**Expected behaviour**

W przypadku podania nieprawidłowych danych nastąpi zaakcentowanie pola z podpisem o napotkanym błędzie, zgodnie z: [link_to_task], tak jak jest w Ustawienia > Moje konto✔️.

3.7. Time ticket

W procesie prac nad projektem, występują sytuacje gdy realizowane są działania, które nie są bezpośrednio powiązane z konkretnym zadaniem tworzenia oprogramowania, jednakże potrzebne w procesie realizacji projektu. Przykładowo można wymienić takie grupy tematyczne:
- Spotkania projektowe/ analityczne architektoniczne
- Spotkania scrum’owe
- Tworzenie dokumentacji
- Zarządzanie projektem
-Koncepcja UX/UI
- Zdarzenia losowe –/wyłączenia prądu, czy niedostępność sieci internetowej/.
Dlatego proponuję osobny typ zadań projektowych, w których możliwe jest zgłaszanie ww. działań.

Proponowane domyślne Taski:
- Spotkania
- Dokumentacja
- Zarządzanie projektem
- Konsultacje UX/UI
- Zdarzenia losowe

4. Proponowana struktura pojedynczego UserStory

W punkcie 2.4 omawiałem ogólny opis UserStory, natomiast w punkcie 2.5 Zadania.
W tym miejscu chciałbym zaproponować rozszerzony układ wewnętrzny Story

[Historyjka Użytkownika] – kontekst biznesowy – wypełnia PM/PO

[Key Notes] – istotne informacje od strony biznesowej, jak również wynikające z analizy. Ponadto można zawrzeć w tej sekcji wymagania niefunkcjonalne, czy szerszy opis funkcjonalności – wypełnia PM/PO/Analityk

[ACC] – Acceptance Criteria – warunki pod którymi praca nad US zostanie uznana za wykonaną poprawnie. Liczba ACC nie powinna przekraczać 4-5 dla większej czytelności  – wypełnia PM/PO/Analityk

[To Do’s-y] –sekcja zawierająca listę konkretnych zmian w systemie wymaganych do wykonania na poziomie technicznym – wypełniana przez developerów podczas Refinementu.

[HTT/HTS] – How To Test / How To Show - sekcja wypełniana przez konkretnego developera po wykonaniu prac developerskich. Zbiór informacji dla testera w jaki sposób może sprawdzić poprawność działania oraz jak może zaprezentować to zadanie podczas review. 

Niemniej jednak najlepiej poruszać się po przykładzie:

5. Workflows

5.1. EPIC Workflow

Poniżej przedstawiony został proponowany, ogólny schemat workflow dla kategorii Epic wraz z opisem.

1. Nowe zadanie zostaje wprowadzone do Redmine. 
2. Twórca wybiera typ EPIC.
3. Twórca wpisuje opis czego dotyczy EPIC. W tym celu może wykorzystać sposób definiowania UserStory z punktu 3.3.
4. Następnie EPIC jest dzielony na stosowne User Stories lub uprzednio stworzone User Stories są pod niego podpinane. Po wykonaniu podziału, status jest zmieniany na „In progres”
5. Po zrealizowaniu podpiętych User Stories, status EPIC’a jest zmieniany Development Done. 
6. PM/PO przeprowadza przegląd EPIC’a, pod kontem realizacji wymagań przed nim postawionych. Jeżeli potwierdzi brak rozbieżności ze stanem zakładanym zamyka EPIC.
   Jeżeli wykryje nieprawidłowości lub nie są spełnione określone wymagania, PO/PM zmienia z powrotem statusu na „In progress”.

5.2. User Story Workflow 

Poniżej przedstawiony został proponowany, ogólny schemat workflow dla kategorii User Story wraz z opisem.

 Nowe zadanie jest wprowadzane do Redmine. 

1. Twórca wybiera typ User Story 
2. Wypełnia opis zadania w oparciu o przedstawiony, w pkt 3.3,  schemat 
3. Zadania które są w statusie „Refinement” muszą zostać uzupełnione o „To Do’sy”
   i zweryfikowane pod kontem zgodności z DoR - INVEST oraz wycenione.
4. Gdy Zadanie jest gotowe do wzięcia do realizacji, otrzymuje status „Ready to do” i może zostać zaplanowane do realizacji w najbliższym czasie (ustawione w odpowiednim priorytecie w backlogu projektowym/tablicy kanban-owej).
5. Gdy rozpoczynają się prace nad zadaniem, otrzymuje status „In progress”. Jednocześnie zostaje przypisany konkretny developer, realizujący prace. 
6. Z chwilą zakończenia prac, developer wypełnia HTT/HTS i przekazuje swój kod do przeglądu kodu wewnątrz zespołu (w obrębie specjalności Frontend/Backend). 
7. Po pozytywnej weryfikacji, zostaje wprowadzony status „Development Done” i jest przekazywany do wykonania testów przez testera
8. Tester bazując na HTT/HTS i własnej wiedzy (w tym testach manualnych, regresyjnych, integracyjnych) przeprowadza weryfikację funkcjonalności.
   W przypadku wykrycia nieprawidłowości wpisuje je w komentarzu
   i ustawia status „Bug Fixing” i zwraca do developera.
   Jeżeli nie ma błędów i kod może być zintegrowany z istniejącym, zostaje ustawiony status „Ready to Release”. 
9. Na podstawie dostępnego modelu releasowania, zadania zakończone są kompletowane
   w paczki wdrożeniowe i wdrażane w ustalonych, w obrębie projektu, terminach.
10. Następuje weryfikacja przez testera, czy wprowadzone na produkcję zmiany działają prawidłowo. Jeżeli tak, to zostaje ustawiony status „Released”, a następnie zadanie zostaje zamknięte. 
11. Jeżeli zadanie jest na początkowym etapie, lecz zostanie uznane za zbędne, to można zmienić jego status na „Cancel” i w dalszym kroku zakończyć. Anulowania może dokonać albo klient/PO/PM po stronie klienta lub PO/PM po stronie Inovatica w porozumieniu lub na żądanie klienta. W innym przypadku, zadanie powinno być realizowane zgodnie z priorytetem. 
12. Jeżeli zadanie, na późniejszym etapie realizacyjnym, zostanie uznane za niewymagające kontynuacji (na żądanie klienta), PO/PM może przenieść je do statusu „Hold”. 

(Z uwagi na fakt, że w przypadku zadania na późniejszym etapie realizacji została wykonana już większa praca, nierzadko warto zadanie jedynie wstrzymać i zakończyć w późniejszym czasie. )
Zadanie ze statusem „Hold” może zostać przywrócone do realizacji – do statusu „In progress”. Powrót do tego etapu wynika, iż należy zweryfikować wykonane prace, jak również rozwiązać wszelkie konflikty, które mogły powstać na etapie wstrzymania.
W przeciwnym przypadku, zadanie może zostać całkowicie zamknięte, a kod usunięty. Zamknięcia zadania dokonuje PO/PM, ustawiając status „Done”.

5.3. BUG Workflow 

Poniżej przedstawiony został proponowany, ogólny schemat workflow dla kategorii BUG wraz z opisem. 

1. Nowe zadanie jest wprowadzane do Redmine. 
2. Twórca wybiera typ zadania „BUG” 
3. Wypełnia opis zadania w oparciu o przedstawiony, w pkt 3.6,  schemat.
4. Zgłoszony przypadek trafia do analizy po stronie Helpdesk Support, gdzie następuje weryfikacja zdarzenia oraz są definiowane konieczne poprawki.
5. W następnej kolejności BUG zostaje przekazany do realizacji po stronie administratorów i/lub developerów i następuje zmiana jego statusu na „In progress”,  
6. Po wykonaniu prac naprawczych i weryfikacji wewnętrznej przez developera następuje zmiana statusu na „Done”, z przekazaniem do HD Supportu.
7. HD Support przekazuje zagadnienie do weryfikacji po stronie klienta , ustalając status „Client verification”
8. Klient weryfikuje poprawność rozwiązania błędu.
   Jeżeli zostaje potwierdzone poprawne wykonanie naprawy, klient zmienia status na „Solved”. Natomiast jeżeli, klient zgłosi uwagi do wykonanej poprawki , status zostaje zmieniony na „Unsolved” i zagadnienie zostaje zwrócone do developerów. 
9. Zadanie po uzyskaniu statusu „Solved” zostaje zamknięte.

5.4. Task/Sub-task Workflow 

Poniżej przedstawiony został proponowany, ogólny schemat workflow dla kategorii TASK/Sub-task wraz z opisem.

Nowe zadanie jest wprowadzane do

1. Redmine. 
2. Twórca wybiera typ Task.
3. Wypełnia opis zadania w oparciu o przedstawiony, w pkt 3.3,  schemat 
4. Po wprowadzeniu opisu i przekazaniu do realizacji, przez konkretnego developera, zostaje zmieniony status zadania na „In progress”.
5.  Niezwłocznie po zakończeniu prac, temat jest przekazywany do testów – ustawiany jest status „Testing” i jest przypisywany tester.
6. Tester weryfikuje poprawność wykonania task/sub-tasku.
   Jeżeli wszystko jest poprawne, ustawia status „Development done” i zamyka task/sub-task
   Jeżeli wykryje błędy zmienia status na „Bug FIxing”, opisuje wykryte błędy i zwraca do developera.

1. =ścieżka szybka=
   W przypadku kiedy zadanie jest na tyle małe lub nietestowalne, że nie ma sensu przekazywać go do testów przez testera, developer, w porozumieniu z PO/PM, może od razu zamknąć zadanie ze statusem „Development done”. 

6. Organizacja pracy w czasie

W zależności od specyfiki projektu, konieczności realizacji nagłych wrzutek, zmiany priorytetów proponowane są dwa podejścia, albo „klasyczny” podział na sprinty albo wykorzystanie tylko tablicy kanban-owej, dla pracy w trybie ciągłym(utrzymaniowym).

6.1. Sprinty

W przypadku pracy w podejściu Sprintowym, zakres sprintu jest definiowany podczas sprint planningu. W trakcie niniejszego spotkania tworzony jest backlog sprintu, wraz z celem sprintu.
Podczas spotkania zespół zobowiązuje się do wykonania określonego zakresu pracy w czasie sprintu. 

Zakres prac który może zostać podjęty podczas pojedynczego sprintu jest powiązany z tzw. szybkością zespołu. Jest to teoretyczna wartość szacowana na podstawie uprzednich sprintów
i wartości punkowej zadań, które udało się zrealizować w uprzednich sprintach. By można było przystąpić do szacowania prędkości zespołu, muszą upłynąć co najmniej trzy sprinty - w krótszym okresie oszacowanie będzie całkowicie niewiarygodne.

Wartość punktowa zadań jest powiązana z techniką tzw. planning pokera, służącą do estymowania stopnia skomplikowania zadań.
Skupia się ona na porównywaniu stopnia skomplikowania  pomiędzy nimi.
Najczęściej stosuje się skalę ciągu Fibonnaciego: 1,2,3,5,8,13,21, ?, break.

Ponadto, do pracy w trakcie samego sprintu warto wykorzystać tablicę Kanbanową, do prezentacji wizualnej postępu prac. W takim wykorzystaniu pierwsza kolumna -„To do” zawiera listę wszystkich US /taksów wybranych do sprintu. Zadania są sukcesywnie przesuwane są przez kolumny „In progress”, „testing”, aż po „Done”. – dalszy opis kolumn w sekcji 8.2

6.2. Tablica Kanban

W przypadku, gdy częstość zmiany priorytetów lub pojawiania się pilnych zagadnień jest znaczna, można pozostać tylko przy wykorzystaniu tablicy kanbanowej, bez podziału na Sprinty.

Jest to proste narzędzie złożone z kilku kolumn opisujących postęp danego zadania. Jednocześnie pozwala ono na jeszcze większą zmienność zakresu aktualnej pracy, co niestety przekłada się na zmniejszenie przewidywalności dostarczenia zadań. 

Tablicę można bardzo elastycznie modyfikować, jednakże proponowany jest następujący układ kolumn:

1. „Backlog” kolumna zawierająca wszystkie User Story przewidywane do realizacji. Lista jest porządkowana przez PM/PO, tak by odzwierciedlała aktualne priorytety rozwoju aplikacji.
2. „To Do” w tej kolumnie znajdują się zadania ze statusem „Refinement” oraz „Ready to do”. 
3. „In progress” w tej kolumnie znajdują się zadania ze statusem „In progress” i „Bug Fixing”
4. „Testing” w tej kolumnie znajdują się zadania ze statusem”Code Review”, „development done” „Testing”
5. „Done” w tej kolumnie znajdują się zadania ze statusem „Ready to Implement”.