Revize b6218b32

Updated document Interní směrnice

doc/internal/doc.tex

@@ -60 +60 @@
 
 \section{Verzovací systém Git}
 \paragraph{} Tato sekce se týká verzovacího systému Git (potažmo repozitáře Gitlab).
-Vzhledem k faktu, že je již od začátku aplikace vyvíjena pro české pacienty, terapeuty, \dots (a z důvodu zachování již zaběhlých konvencí) budou veškeré komentáře, názvy a komunikace popsány v \textbf{českém} jazyce.
+
 
 \subsection{Tvorba vývojových větví (\textit{branches})}
 \paragraph{} V rámci projektu existuje hlavní vývojová větev \textbf{master}.
 V této větvi budou dostupné veškeré \textbf{funkční a otestované} verze projektu ve formě otagovaných \textbf{releases}.
-Nadále bude existovat větev \textbf{development (dev)}, na které bude dostupná \textbf{poslední} upravená, fuknční a neotestovaná verze.
-Ve chvíli, kdy bude verze na development větvi otestována, může být vytvořen merge request do hlavní větve (za předpokladu, že jsou splněny všechny požadavky na novou verzi).
+Nadále bude existovat větev \textbf{development (dev)}, na které bude dostupná \textbf{poslední upravená, funkční a otestovaná}(na dev prostředí) verze, jež nebyla ještě otestována na produkčním prostředí.
+Ve chvíli, kdy bude verze na development větvi otestována i na produkčním prostředí, může být vytvořen merge request do hlavní větve (za předpokladu, že jsou splněny všechny požadavky na novou verzi).
 Pro nové \textit{features} nebo pro \textit{change requests} bude vždy vytvořena \textbf{nová} separátní větev z development větve.
 Workflow mezi jednotlivými větvemi je vyobrazen na obrázku \ref{fig:branches_workflow}.
 
@@ -78 +78 @@
 \end{figure}
 
 
-\subsection{Tvorba a správa úkolů (\textit{Tickets and Issues})}
-\paragraph{} Každý úkol bude mít svůj \textit{ticket} (v případě, že je tak obsáhlý, že se bude muset dále dělit na podúkoly).
-Pokud bude úkol ,,jednoduchý'' (tj. nebude vyžadovat žádnou, případně velice minimální dekompozici), bude k němu adresována daná \textit{issue}.
+\subsection{Tvorba a správa úkolů napříč používanými nástroji}
+
+\subsubsection{Issues}
+\paragraph{} Issue je základní plánovací jednotka v systému řízení projektu (zde konkrétně nástroj \textbf{Jira}).
+Tato jednotka bude vždy svázána s konkrétní \textit{issue} na repozitáři Gitlab, tzn. v rámci \textit{issue} bude \textbf{vždy} k dispozici odkaz na danou \textit{issue} v repozitáři. Jejich vazba by tedy vždy měla být 1:1.
+
+\subsubsection{Ticket}
+\paragraph{} Ticket je běžný základní úkol.
+V rámci každé issue bude k dispozici výčet všech podúkolů (\textit{task}) které je nutné v rámci daného ticketu splnit.
+V rámci \textit{issue} bude taktéž možné specifikovat, zda-li úkol čeká na dokončení jiného, či naopak.
+
+\subsubsection{Feature}
+\paragraph{} Feature je typ \textit{issue} využívaný k označení implementace nové funkcionality do aplikace.
+
+\subsubsection{Bug}
+\paragraph{} Bug je typ, kterým se označují úkoly spojené s odstraněním nových vzniklých chyb během vývoje.
+
+\subsubsection{Change request}
+\paragraph{} Tímto type se označují úkoly, které jsou spojené se změnou nějaké již implementované funkcionality (feature), nicméně během vývoje došlo ke změnám priorit zákazníka a je potřeba tuto funkčnost upravit/změnit.
 
-\subsubsection{Issues (Tickets)}
-\paragraph{} Ticketem se rozumí takový úkol, který je nutné dekomponovat do menší, ideálně atomických podúkolů.
-Samotný ticket bude reprezentován v repozitáři jakožto \textit{issue}, nicméně v rámci jeho popisů (\textit{Tasks}) bude výčet všech úkolů (volně popsaných), které je nutné splnit.
-V rámci Ticketu bude využito i sekce \textit{Linked Items}, kde budou linknuté konkrétní podúkoly ve formě jednotlivých \textit{issues} (přesná korelace mezi sekcí \textit{Tasks a Linked Items} je tedy zřejmá).
-\par Z pragmatického hlediska bude tedy Ticket pouze speciální issue, která agreguje veškeré logicky související podúkoly.
+\subsubsection{Epic}
+\paragraph{} Epicy jsou velké logické celky agregující jednotlivé, logicky spjaté \textit{issues}.
+V rámci jedné iterace je možné mít naplánováno více Epiců a jeden Epic může být součástí více iterací.
 
-\subsubsection{Issues (Tasks)}
-\paragraph{} Jak bylo již řečeno výše, \textit{issue} bude buďto jednoduchý úkol, který je součástí daného \textit{tasku}.
-Pravidla pro vytváření těchto úkolů:
+\subsubsection{Obecná pravidla pro vytváření \textit{issues}}
 \begin{itemize}
     \item Každá \textit{issue} bude obsahovat krátký, nicméně dostatečně deskriptivní popis, čeho konkrétně se týká
     \item Každá \textit{issue} bude \textbf{jednoznačně identifikovatelná} za pomocí tzv. \textbf{labelů} (specifikováno dále)
     \item Každá \textit{issue}, která bude v jiné, než \textbf{Backlog} fázi (specifikováno dále) bude \textbf{jednoznačně přiřazena} danému vývojáři (případně testerovi či zákazníkovi, bude-li třeba)
-    \item Každá \textit{issue} bude označena jednou z možností \textbf{,,urgentnosti''} (viz dále)
-    \item U každé issue, které je ve fázi ,,In progress'', či dále, bude jednoznačně stanoveno datum, kdy by měl být úkol dokončen (neměl by přesáhnout koncové datum iterace, v rámci které je úkol řešen)
+    \item Každá \textit{issue} bude označena jednou z možností \textbf{,,priority''} (viz dále)
+    \item U každé issue, které je ve fázi ,,In progress'', či dále, by měl být stanoven časový odhad potřebné práce k dokončení.
 
 \end{itemize}
 
-\paragraph{Jednotlivé fáze úkolů}
+\subsubsection{Možné fáze \textit{issues}}
 \begin{itemize}
     \item Backlog - analogie s TODO
     \item In progress
-    \item To test (dev) - testování \textbf{vždy provádí jiný vývojář/tester!}
+    \item To test (dev) - testování \textbf{vždy provádí jiný vývojář(tester)!}
     \item Code review
     \item To deploy (dev) - funkcionalita implementována, nicméně je nutné funkční verzi \textit{deploynout} na testovací prostředí k umožnění testování
     \item To test (prod) - otestování na produkčním prostředí
@@ -125 +137 @@
     \item Change request - vyžádaná změna od zákazníka/uživatele, která byla již dříve implementována
 \end{itemize}
 
-\paragraph{Typy priority/urgentnosti}
+\paragraph{Typy priority}
 \begin{itemize}
+    \item \textbf{Lowest}
     \item \textbf{Low} - nevyžaduje velkou pozornost (příkladem mohou být nekritické části aplikace, ,,nice to have(s)''),
     \item \textbf{Medium} - vyžaduje vyšší míru pozornosti - již by neměly zůstávat nedokončeny v rámci přiřazené iterace (v krajních případech je možné posunout do další),
     \item \textbf{High} - vysoká priorita vyžadujicí privilegované řešení,
-    \item \textbf{Severe} - maximální důležitost - vyžaduje okamžité řešení (například v případech, kdy tyto problémy způsobují nestabilitu či přímo rozbíjí produkční prostředí)
+    \item \textbf{Highest (Severe)} - maximální důležitost - vyžaduje okamžité řešení (například v případech, kdy tyto problémy způsobují nestabilitu či přímo rozbíjí produkční prostředí)
 \end{itemize}
 
 \paragraph{} V rámci jakýchkoliv úkolů \textbf{není potřeba} vést časové údaje a odhady. Tato činnost bude probíhat v systému \textbf{Jira}.