0qln
e6d4fb04a4
- Newtype/parse-dont-validate auf Projektspezifik gekuerzt - Nebenlaeufigkeitsszenarien und Gegenmassnahmen als Tabellen statt Fliesstext - Testcode-Reviewbefunde (Timo Walter) zusammengefasst - Unicorn-Entwicklungsprozess-Beschreibung gekuerzt (Diagramm traegt Details) - S3-Infrastrukturbeschaffung: Bewertung entfernt, Text gestrafft - Normalisierungs-Review (Robin Noack) gekuerzt
32 lines
3.3 KiB
TeX
32 lines
3.3 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 als Product Backlog Item ausformuliert wird (\texttt{New}). Nach Prüfung von Machbarkeit und kaufmännischer Abwicklung geht es in die Freigabe (\texttt{To Approve}); im Approval-Termin prüft das Team die \emph{Definition of Ready} und schätzt den Aufwand (\texttt{Approved}). Mit der Sprintplanung wechselt es auf \texttt{Committed} und wird umgesetzt; nach Übernahme in den Hauptbranch steht es auf \texttt{Dev Completed}. Es folgen Release ins Testsystem, Review und Tests (\texttt{Test Completed}), danach Release ins Produktivsystem, Abnahme und die abschließenden kaufmännischen Schritte bis \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}
|
|
|
|
Alle Arbeiten hängen als Product Backlog Items am Feature~484. Tabelle~\ref{tab:backlog} im Anhang listet sie mit Kennung, Titel, geschätztem Aufwand, Sprint und Zustand auf; Tabelle~\ref{tab:requirements} ordnet ihnen die Anforderungen aus Abschnitt~\ref{sec:requirements} zu.
|
|
|
|
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 sind es 14 Product Backlog Items und ein Bug. 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.
|