Project Card Management - Karta Projektu
Introduction
Poniższy przewodnik przeprowadzi Cię przez proces Project Card Management.
Rozwiązanie to łączy się z agile epics, requirements engineering oraz niektórymi elementami metodologii Scrum jak * *Definition of Done ** (Increment commitment) czy Sprints (events).
Proces zaczyna się od stworzenia epiku w Jira, następnie stworzeniu karty projektu w Confluance, która ma m.in. za zadanie być łącznikiem pomiędzy interesariuszami. Status wymagań i postępy realizacji bedą widoczne w Jira i na karcie projektu , dzięki połączeniu tych dwóch obszarów. Znaczące wydarzenia dla projektu znajdą odzwierciedlenie w dzienniku decyzji/zdarzeń.
Ten przewodnik jest podzielony na główne sekcje, które zawierają praktyczne wskazówki, konkretne działania i kroki.
Pod następującym linkiem: Integracja z narzędziem Trusted Twin - MVP znajdziesz kartę projektu, która jest dobrym realnym przykładem tego, co możesz stworzyć po zapoznaniu się z tym dokumentem.
Anatomy of Project Card solution
instrukcją: How to configure Jira project according to PMF?
Getting started
Na początku musimy stworzyć EPIC w naszym projekcie na JIRA:
Wybieramy projekt (może to być dowolny projekt, który przeszedł następującą konfigurację: How to configure Jira project according to PMF?; konfiguracja została zlecona dla wszystkich projektów zgłoszonych na wizytówkach w Struktura)
Wybieramy typ zadania EPIC
Łączymy zadanie z programem przy użyciu pola Parent link
Ustawiamy wartości w polach Team i Project category
Pole Sponsor ustawi się samoczynnie na podstawie połączenia z Programem z kolejki PRODUKT
Przechodzimy do Confluence i tworzymy pustą Kartę Projektu za pomocą szablonu o nazwie Project Card.
Properties
Ustawiamy połączenie między Inicjatywą i Epiką, a Karta Projektu.
Wchodzimy w edycję dokumentu
Znajdujemy (u góry strony) sekcję Properties.
Klikamy ołówek oznaczający funkcję edycji makra “Jira”
Podajemy odpowiednie klucze zadań
Dane do tabeli pobierane są automatycznie z Jira :JIRA:. Dodanie nowych atrybutów wymaga zlecenia takiej potrzeby do Delivery Managerów lub, lokalnie - w ramach jednego projektu, uzupełnienia ręcznego 
.
Nazwa pola | Źródło | Pole źródłowe | Opis |
|---|---|---|---|
Initiative | :epic: |
| Link do programu z kolejki PRODUKT |
Epic | :epic: |
| Link do epiki projektu |
Status | :epic: |
| Informacja o aktualnym stanie postępu projektu. Status jest zgodny ze statusami z workflow jaki jest skonfigurowany w ramach danego projektu, na którym założono epic. |
Sponsor | :program: |
| Pion w organizacji finansujący projekt, mający wpływ na jego planowanie, realizacje i wynik |
Product | :program: |
| Produkt, którego dotyczy rozwój/zmiana |
Team | :epic: |
| Zespół projektowy, w ramach którego realizujemy inicjatywę. |
Start date | :epic: |
| Planowany dzień rozpoczęcia prac. |
Due date | :epic: |
| Planowany dzień zakończenia prac. |
Actual Start Date | :program: |
| Rzeczywisty dzień rozpoczęcia prac. |
Product Owner | :program: |
| Product Owner prowadzący projekt |
T-Shirt estimate | :program: |
| Wycena koszulkowa inicjatywy. |
Time spent | :epic: |
| Aktualny czas poświęcony na realizację. |
Project category | :program: |
| Typ projektu |
Stakeholders | :program: |
| Zespoły, których udział w projekcie jest wymagany lub które powinny być o nim informowane. |
Description | :program: |
| Opis inicjatywy |
Estimated Full WH Cost | :program: |
| Szacowany czas roboczogodzin |
Actual WH Cost | :program: |
| Rzeczywista łączna liczba roboczogodzin IT przepracowanych w projekcie (tylko liczba) |
Left WH Cost | :program: |
| Pozostała liczba roboczogodzin względem estymowanej. |
Analysis
Na Karcie projektu, znajduje się sekcja Analiza. Jest przeznaczona do przeprowadzenia analizy biznesowej i systemowej, w ramach których rozpisujemy wymagania, use case’y, procesy itp.
Jest to miejsce, w którym po zakończeniu Analizy wstępnych wymagań powinna znaleźć się dokumentacja techniczna i procesowa (a także wstępna analiza prawna/compliance i inna). Na podstawie danych umieszczonych w tej sekcji powstaje zakres projektu oraz poniższe wymagania funkcjonalne i niefunkcjonalne.
Do notowania spotkań, postępów w analizie projektu rekomendujemy używać Meeting notes i grupowanie ich pod kartą projektu.
Scope and limitations
W tej sekcji powinien zostać zdefiniowany obszar prac, których wykonanie jest niezbędne do osiągnięcia celów projektu oraz wskazane ograniczenia projektu / ryzyk, które mogą wpłynąć na osiągnięcie celu projektu. To miejsce w którym możesz umieścić informacje dot. kamieni milowych / etapów projektu.
np. nie realizujemy SDK albo realizujemy tylko wybrane scenariusze
W tej sekcji powinien znaleźć się również harmonogram.
Required resources
W miejscu tym definiujemy zespoły, które będą zaangażowane w projekt.
Lista zespołów powstaje w rezultacie analizy T-Shirt, następnie przeprowadzonej przez Product Ownera i Analityka. Lista zespołów importowana jest z Jiry automatycznie, po skonfigurowaniu marka:
Po uzupełnieniu pola, wskazanym jest poinformować zaangażowane zespołu i interesariuszy o gotowej karcie. Można to zrobić na przykład poprzez narzędzie do udostępniania strony:
Requirements management
Konsekwencją zebranych wymagań i analizy jest rozpoczęcie procesu identyfikowania i dokumentowania podstawowych wymagań funkcjonalnych i niefunkcjonalnych projektu.
Tworzenie zadań i dokumentów dla wymagań demonstruje film:
TIPS & TRICKS
Pola w Jira
Opis elementów zadania typu Requirement:
DESCIPTION/USER STOR - opisanie wymagań z perspektywy użytkownika / systemu. https://agileforce.pl/blog/co-to-jest-user-story/
ACCEPTANCE CRITERIA- wylistowanie zbioru warunków, które muszą zostać spełnione, aby User Story została uznana za zakończoną i spełniającą wymagania.
IMPEDIMENTS - zdefiniowane przeszkody, utrudnienia lub problemy, które utrudniają lub uniemożliwiają realizację zadań lub celów związanych z projektem.
PARTICIPANTS - zdefiniowane zespoły, działy, osoby, zewnętrzni partnerzy konieczni do realizacji wymagania.
Automat tworzący dokumenty
Po utworzeniu zadania typu Requirement, uruchamia się automat, który tworzy kartę w Confluence dokument z opisem wymagań, powiązany z nowo utworzonym zadaniem na Jira.
zakładce: Den of new Requirements from Jira
Dokument wymagań należy przenieść pod kartę projektu oraz wypełnić znajdujące się w niej makra.
Opis makr
W Confluence sekcja Requirements management podzielona jest na trzy części:
Wymagania Funkcjonalne - opis funkcji, jakie system lub aplikacja powinna spełniać w celu zrealizowania określonych celów biznesowych lub użytkowych.
Wymagania Niefunkcjonalne - to wymagania dotyczące cech systemu, które nie są związane z jego bezpośrednią funkcjonalnością, ale wpływają na jakość i wydajność systemu oraz doświadczenie użytkownika.
Listy zadań reprezentujących wymagania z podziałem według statusu przygotowań i realizacji wymagań.
Graf i opis stanów zadania typu Requirement
Statusy w fazie analizy wymagań
Status | Description |
|---|---|
Open | A newly created requirement with user story that defines user expectations (or software) without specific details or description. |
Analysis | The process by which the details of a requirement, needs or it conditions are determined. During this process the analysis team should consider the possibly conflicting conditions (impediments) of the various stakeholders or the other requirements that needs to be done before those analyzed. |
Ready | Fully analyzed and refined requirement (with all the issues belonging to it). |
Rejected | Requirement rejected. |
Statusy w fazie realizacji wymagań
Status | Description |
|---|---|
In Progress | Requirement in progress (with issues). |
Rejected | Requirement rejected. |
On Hold | Implementation of the requirement has been put on hold due to obstacles and impediments. |
Done | A requirement with completed definition of done (or acceptance criteria) |
Definition of Done
Sekcja do uzupełnienia w Karcie projektu w Confluence. Standardowe DoD może, ale nie musi zostać dostosowane do danego projektu. Staramy się unikać DoD pełnych “nie dotyczy”. https://www.leadingagile.com/2017/02/definition-of-done/
Rejestr wydarzeń
Zapisywane są wszystkie zdarzenia, które mają miejsce podczas realizacji projektu. Może to być lista problemów, nieoczekiwanych sytuacji, zmian w planach projektowych oraz inne ważne informacje związane z postępem projektu.
Docelowym formatem jest data i opis, np:
- 29 Mar 2023 Zgłoszono przez Partnera potrzebę zmiany wymagania X. Zmiana wpływa na zakres projektu w sposób Y. Przekazano informację do Product Managera celem podjęcia decyzji.
Decisions
Sekcja decyzja w karcie projektu powinna zawierać informacje dotyczące decyzji podjętych w ramach projektu. Podjęta decyzja powinna zostać zapisana w formacie: data, tytuł decyzji, opis decyzji, osoba odpowiedzialna za podjętą decyzję.
np:
29 Mar 2023 Zmieniono zakres projektu. Rezygnacja z implementacji funkcjonalności X. Przedyskutowano w gronie X,Y,Z zgodnie z Meeting notes . Decyzja podjęta przez A i B.
Lifecycle
Current Project Card lifecycle
Current Project Card (and also Project) lifecycle is based on 10 statuses that are connected with different situations and decisions. Jira epic statuses are not the same as project statuses. Included description is available on Project Management Framework.