30 lines
3.5 KiB
TeX
30 lines
3.5 KiB
TeX
\section{Backlog und Entwicklungsprozess}
|
|
\label{sec:backlog}
|
|
|
|
\subsection{Entwicklungsprozess}
|
|
|
|
Die Unicorn Development arbeitet agil mit zweiwöchigen Sprints in Azure DevOps. Der dabei verbindliche Softwareprozess ist im internen XWiki dokumentiert und in Abbildung~\ref{fig:unicorn-process} wiedergegeben. Er beschreibt den vollständigen Weg von der Kundenidee bis zur Abrechnung und ordnet jedem Schritt den Zustand zu, den das zugehörige Work Item in Azure DevOps annimmt.
|
|
|
|
\begin{figure}[H]
|
|
\centering
|
|
\includegraphics[width=\textwidth]{figures/worksimple/softwareprozess-unicorns.jpg}
|
|
\caption{Softwareprozess der Unicorn Development mit den zugehörigen Work-Item-Zuständen}
|
|
\label{fig:unicorn-process}
|
|
\end{figure}
|
|
|
|
Am Anfang steht eine Idee, die festgehalten und als Product Backlog Item ausformuliert wird; das Item steht dabei auf \texttt{New}. Nach der Prüfung der technischen Machbarkeit und der kaufmännischen Abwicklung — Angebot, Annahme, Auftragsbestätigung — geht es in die Freigabe (\texttt{To Approve}). Im Approval-Termin prüft das Team die \emph{Definition of Ready}, stellt Rückfragen und schätzt den Aufwand; danach gilt das Item als \texttt{Approved}. Mit der Sprintplanung wechselt es auf \texttt{Committed} und wird umgesetzt. Ist die Umsetzung abgeschlossen und in den Hauptbranch übernommen, steht es auf \texttt{Dev Completed}. Es folgen das Release ins Testsystem, das Review mit dem Kunden sowie die Tests durch Unicorn Development und Kunde; mit deren Abschluss erreicht das Item \texttt{Test Completed}. Erst danach erfolgt das Release ins Produktivsystem mit anschließender Abnahme; die abschließenden kaufmännischen Schritte — Rechnungsstellung, Abschluss in Kimai, Anpassung der Wartungsgebühr — überführen es nach \texttt{Done}.
|
|
|
|
Das Dokumentenfeature wurde ohne Abweichung nach diesem Prozess bearbeitet. Da es sich um eine Erweiterung des eigenen Produkts Houston und nicht um einen Einzelauftrag handelt, entfielen lediglich die auftragsbezogenen Schritte; alle Freigabe-, Test- und Abnahmestufen wurden regulär durchlaufen.
|
|
|
|
Die Freigabestufe erwies sich dabei als wirksam: Rückfragen im Approval-Termin — insbesondere durch \emph{Timo Walter} — deckten mehrfach Lücken in den Akzeptanzkriterien auf, etwa zur Häufigkeit der Ordnerstrukturprüfung oder zu Namensbeschränkungen.
|
|
|
|
\subsection{Schnitt der Product Backlog Items}
|
|
|
|
Der Backlog-Schnitt erfolgte in zwei Phasen. Am 18.~Juni 2026 wurden acht Kern-Items angelegt, orientiert an der Feature-Beschreibung: Document Explorer als Basis, die \emph{Feature-Creep}-Punkte (Suche, Einzeldownload, ZIP-Download, PDF-Modal, URL-Dateien) als eigene Items. Am 7.~Juli kam die Typisierung über Icons hinzu, am 8.~Juli die automatische Ordneranlage.
|
|
|
|
Eine zweite Gruppe entstand während der Umsetzung: Am 22.~Juli ergänzte die UI-Zuarbeit Paginierung und Typfilter. Am 28.~Juli wurde die Recherche zur Optimierung der S3-Abfrage angelegt, deren Ergebnis am 12.~August in das Kundenordner-Lookup-Item mündete. Am 17.~August kam das Item zu Race Conditions hinzu (siehe Abschnitt~\ref{sec:race-conditions}).
|
|
|
|
Insgesamt hängen 14 Product Backlog Items und ein Bug am Feature (Tabelle~\ref{tab:backlog} im Anhang). Die geschätzten Aufwände summieren sich auf 46 Story Points: 35 in Sprint~15.2026, 11 in Sprint~16.2026.
|
|
|
|
Die vorgeschnittenen Items betreffen ausschließlich fachliche Funktionen; alle nachgeschobenen entstanden aus technischen Problemen bei der Implementierung — ein Muster, das in Abschnitt~\ref{sec:reflection} aufgegriffen wird.
|