Es beginnt – wir erstellen für einen Kunden eine neue WebAnwendung.
Das Ziel – in unter 3 Arbeitstagen (max. gerechneter Aufwand) eine erste stabile Version (0.0.1.0) zu erstellen, die der Kunde bereits dann testen kann.
Vorgehen
- Business Analyse
- Requirements Engineering
- System Architektur
- UI-Design
- Software Architektur
- Umsetzung
- Test
- GoLive
Alle Schritte beinhalten sowohl ein agiles Vorgehen (Fail-Fast Ansatz), als auch die Dokumentation.
Klammer um alle Tätigkeiten ist das Backlog des ProductOwners, der für diese Umsetzung „den Hut auf hat“. Die Rolle des SCRUM-Masters entfällt, da wir (fast immer, wenn wir dürfen) nach den Prinzipien von Lean – und im Modus KanBan – arbeiten.
Unsere Art des Projektmanagements könnte man also als eine Art „Lean-KanBan“ bezeichnen (auch wenn sicher diverse Verfechter der einen oder anderen Arbeitsweise hier Schwachstellen erkennen werden). Für uns passt diese Art der Arbeit perfekt, und so muss es schlussendlich auch sein.
Die gelebten Rollen
Wir lieben es verschiedene Dinge tun zu dürfen – und nicht immer nur eine sogenannte Rolle zu erfüllen.
Daher werden die 4 Personen des umsetzenden Teams auch verschiedene Rollen einnehmen, um zum Ziel zu gelangen.
| Product Owner | Business Analyst | Requirements Engineer | Architekt | UI Design | Entwicklung | Test | |
|---|---|---|---|---|---|---|---|
| Person 1 | X | X | X | X | X | ||
| Person 2 | X | X | |||||
| Person 3 | X | X | X | ||||
| Person 4 | X | X | X |
Alle Rollen sind dabei, aus dem T-Shape Ansatz heraus, mehrfach besetzt. Mehr darüber in dem dazu passenden Artikel Rollen und gelebte Funktionen.
Das Vorgehen etwas detaillierter dargestellt
Die Business Analyse
Klare Vorgabe für die Business Analyse in diesem Mini-Projekt ist 1 h Aufwand maximal.
Inhalt dieser Phase ist ein Meeting bzw. Workshop mit dem Kunden, in dem wir die Motivation des Kunden, dessen Vision und seine Wünsche so konkret wie irgend möglich erfassen.
Das Requirements Eingineering
Im Requirements Eingineering werden dann die Anforderungen des Kunden „herunter gebrochen“, so dass umsetzbare Einheiten entstehen. Der maximale Aufwand hierfür sollte 1 h nicht überschreiten.
Die System-Architektur
Mit unserer Erfahrung und den vorgefertigten Modulen, die wir seit über 20 Jahren neu und weiter entwickeln, sollte der Aufwand nicht über 0,5 h hinaus gehen. Zudem nutzen wir bereits bestehende Komponenten immer wieder, so dass der Aufwand für deren Planung und Entwicklung bereits an anderer Stelle angefallen ist.
Das UI-Design
Da die UI bzw. das Aussehen – von egal welchem Medium oder Produkt – immer stark subjektiv ist, wird ein vorgefertigtes, sehr funktionales Design verwendet. Es fallen hier also kaum Aufwände in der Planung an, so dass wir mit insgesamt 0,5 h Aufwand auskommen sollten.
Die Software Architektur
Die Software Architektur ist mit MVC (Model-View-Controller) der verwendeten Umgebung bereits mehr oder minder vorgegeben. Letzte Details dürfen daher mit 0,5 h Aufwand angepasst werden.
Die Umsetzung
Für die Umsetzung sollte nicht mehr als 10 h Aufwand verwendet werden.
Zielplattform – Ubuntu 22.04 LTS (Linux)
Der Prozess in unserer Entwicklung (siehe Vorgehen, weiter oben) ist in 3 Phasen unterteilt. So werden in der Planungs-Phase (Phase 1) die Schritte 1 bis 5 ausgeführt, in der Umsetzungs-Phase (Phase 2) dann Testing und Umsetzung und in der GoLive-Phase (Phase 3) dann alle restlichen Arbeiten bis zu einem für den Kunden nutzbaren Produkt.
Dabei verwenden wir – wie immer – die 3 Stages Development (DEV), Testing und Integration (TNT) und Produktion (PRD). Diese Stages werden über eine (fast) vollautomatische CI/CD Pipeline mit Ansible, Terraform und GitLab umgesetzt (Ansible und Terraform sind hierbei kein Widerspruch).
Der Test
Da wir prinzipiell TDD (Test-Driven-Development) als Art der Umsetzung gewählt haben, werden die Tests bereits vor der Umsetzung erstellt. Diese sind immer Automatisiert (soweit möglich). In der Phase Umsetzung wird gegen die Tests entwickelt. Wenn die Entwicklung dann fehlerfrei alle Tests durchläuft, kann von mind. 80% Zielerreichung in der Qualitätssicherung ausgegangen werden. Der kalukulierte Aufwand hierfür liegt bei 1 h maximal.
Der GoLive
Alles, was dann letztlich noch bleibt, sind die Abschluss-Dokumentation, die Freigabe nach allen Tests und die Abnahme des Produktes durch den Kunden. Diese Arbeiten verorten wir allesamt in der GoLive Phase – und ist mit max. 3 h Aufwand angesetzt.
Da wir die Produktentstehung mit dem Kunden ebenfalls in Phasen unterteilen, können wir obiges Vorgehen in jeder Phase der Produktentwicklung komplett und (fast) von einander losgelöst ausführen. Lediglich der Zusammenhang von Vorraussetzungen zu den für die aktuelle Phase der Produktentwicklung umzusetzenden Inhalte muss eingehalten werden. Wenn eine Vorraussetzung nicht erfüllt ist, kann die nächste Phase nicht begonnen werden – und die aktuelle bzw. vorherige Phase ist dadurch auch nicht abschließbar.
Mit der agilen Vorgehensweise, die wir nutzen, können wir mit der passenden Aufteilung der Arbeitspakete allerdings so gut wie Alles so steuern, dass wir selten in diese Verlegenheit kommen.
Die komplette Umsetzung wird natürlich länger dauern
… wir wissen das.
Dieser Beitrag verdeutlicht Phase 1 der Produktentwicklung von insgesamt 7 Phasen. Alle Phasen laufen dabei in etwa gleich ab, unterscheiden sich nur im Umfang bzw. Aufwand, der dafür notwendig ist.
Die Planung für das gesamte Produkt (alle 7 Phasen) liegt nach Abstimmung mit dem Kunden aktuell bei ca. 23 PT.
Wie oben bereits deutlich gemacht, verwendet Phase 1 davon ca. 3 PT. Da unser Arbeitstag i.d.R. 6 h umfasst, liegen wir mit 18 h ziemlich genau bei dieser Zahl.
Comments are closed