3.4.1: Unicorn-Softwareprozess statt eigenem Zustandsdiagramm
This commit is contained in:
@@ -16,7 +16,7 @@ screenshots habe ich in figures/screenshots gelegt.
|
|||||||
- houston architektur
|
- houston architektur
|
||||||
- unicorn prozess
|
- unicorn prozess
|
||||||
- etc.
|
- etc.
|
||||||
- [ ] "Figure 3.1: Zustände eines Work Items in Azure DevOps" sollte mit dem eigentlichem unicorn prozess bild ersaetzt werden. ich arbeite naehmlich nach dem ganz normalen prozess
|
- [x] "Figure 3.1: Zustände eines Work Items in Azure DevOps" sollte mit dem eigentlichem unicorn prozess bild ersaetzt werden. ich arbeite naehmlich nach dem ganz normalen prozess
|
||||||
- "3.4.1 Entwicklungsprozess" sollte dahingehend auch aktualisiert werden, und nicht *Linus-speziefisch* sein.
|
- "3.4.1 Entwicklungsprozess" sollte dahingehend auch aktualisiert werden, und nicht *Linus-speziefisch* sein.
|
||||||
- [ ] "3.4.2 Schnitt der Product Backlog Items": ein abbild aus dem devops oder eine tabelle mit den PBIs ergaenzen verweisen
|
- [ ] "3.4.2 Schnitt der Product Backlog Items": ein abbild aus dem devops oder eine tabelle mit den PBIs ergaenzen verweisen
|
||||||
- [ ] "Figure 3.3: Chronologie der Infrastrukturbeschaffung" sieht komisch aus, die pfeile gehen nach unten Chronologie geht aber nach rechts. sollte gefixed werden.
|
- [ ] "Figure 3.3: Chronologie der Infrastrukturbeschaffung" sieht komisch aus, die pfeile gehen nach unten Chronologie geht aber nach rechts. sollte gefixed werden.
|
||||||
|
|||||||
@@ -3,18 +3,20 @@
|
|||||||
|
|
||||||
\subsection{Entwicklungsprozess}
|
\subsection{Entwicklungsprozess}
|
||||||
|
|
||||||
Die Unicorn Development arbeitet agil mit zweiwöchigen Sprints in Azure DevOps. Jedes Work Item durchläuft den in Abbildung~\ref{fig:ado-workflow} dargestellten Zustandsautomaten.
|
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]
|
\begin{figure}[H]
|
||||||
\centering
|
\centering
|
||||||
\includegraphics[width=0.55\textwidth]{figures/diagrams/ado-workflow.pdf}
|
\includegraphics[width=\textwidth]{figures/worksimple/softwareprozess-unicorns.jpg}
|
||||||
\caption{Zustände eines Work Items in Azure DevOps}
|
\caption{Softwareprozess der Unicorn Development mit den zugehörigen Work-Item-Zuständen}
|
||||||
\label{fig:ado-workflow}
|
\label{fig:unicorn-process}
|
||||||
\end{figure}
|
\end{figure}
|
||||||
|
|
||||||
Ein neues Item steht auf \texttt{New} und wird nach vollständiger Beschreibung zur Freigabe eingereicht (\texttt{To Approve}). Im Approval-Termin prüft das Team die \emph{Definition of Ready}, stellt Rückfragen und schätzt Story Points; danach gilt es als \texttt{Approved} und kann in einen Sprint gezogen werden (\texttt{Committed}). Nach dem Merge wechselt es zu \texttt{Dev Completed}; die Abnahme überführt es nach \texttt{Test Completed}.
|
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}.
|
||||||
|
|
||||||
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.
|
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}
|
\subsection{Schnitt der Product Backlog Items}
|
||||||
|
|
||||||
|
|||||||
@@ -1,10 +0,0 @@
|
|||||||
stateDiagram-v2
|
|
||||||
[*] --> New
|
|
||||||
New --> ToApprove : Linus reicht PBI ein
|
|
||||||
ToApprove --> Approved : Approval-Team
|
|
||||||
Approved --> Committed : Sprint-Planung
|
|
||||||
Committed --> DevCompleted : PR gemerged
|
|
||||||
DevCompleted --> TestCompleted : Abnahme bestanden
|
|
||||||
TestCompleted --> [*]
|
|
||||||
ToApprove --> Removed : Verworfen
|
|
||||||
Removed --> New : Wiederhergestellt
|
|
||||||
Binary file not shown.
Reference in New Issue
Block a user