Zum Inhalt springen

Softwareentwicklung

Zuletzt geändert von Timo Walter am 28.07.2026 13:21

Diese Seite stellt den Prozess der Unicorn Development Softwareentwicklung dar.

Softwareentwicklungsprozess (visuell)

Softwareprozess.jpg

Entwicklungsprozess (technisch)

In unserer Softwareentwicklung arbeiten wir in Sprints. Sobald ein Product Backlog Item (PBI) den Status „Definition of Ready“ (DoR) erreicht hat und im Azure DevOps einem Sprint zugewiesen sowie auf „Committed“ gesetzt wird, verpflichten wir uns, die Entwicklung dieses PBIs innerhalb des Sprints abzuschließen. Dies bedeutet jedoch nicht automatisch, dass die entwickelte Software im selben Zeitraum auf ein externes Test- oder Produktivsystem deployed wird. Externe Tests, Reviews und Abnahmen erfordern oft zusätzliche Terminabstimmungen mit anderen Beteiligten, die nicht immer innerhalb des Sprint-Zeitrahmens realisierbar sind. Wir übernehmen die Verantwortung für die vollständige Umsetzung der Software im Sprint, während das Deployment auf externe Systeme von Faktoren abhängt, die außerhalb unseres direkten Einflussbereichs liegen. Unser Ziel bleibt es jedoch, die entwickelte Software so zeitnah wie möglich in den Produktivbetrieb zu überführen.

Product Backlog Items (PBI)

  • Wer schreibt PBIs?

    • Jede/r kann grundsätzlich PBIs schreiben, um auftretende Aufgaben oder Ideen zu beschreiben. Das bedeutet nicht, dass dieses PBI zur Umsetzung kommt. Der Status ist dann "New". Bei zeitkritischen Aufgaben oder der Erwartung einer Priorisierung oder dem Erstellen eines Angebotes muss die entsprechende Person aktiv angesprochen werden.
      • Area Path muss ausgefüllt werden, wenn es nichts Passendes gibt, dann Development.
      • Iteration muss leer, also Development sein.
      • Status muss New sein.
      • Parent, wenn es keinen gibt, muss einer angelegt werden.
      • Die Beschreibung sollte im ersten Schritt so sein, dass die Aufgabe gut nachvollziehbar ist (siehe: "Warum schreiben wir Backloglog Items" & DoR)
      • PO bekommt bescheid

  • Warum schreiben wir Backlog Items?

    • Aus jedem PBI sollte hervorgehen, wer, was, (eventuell auch wie) umgesetzt haben möchte und zu welchem Zweck bzw. aus welchem Grund, mit welchem Nutzen.
    • Aus Transparenzgründen: z. B. wenn eine Person im Urlaub oder krank ist, muss eine andere Person die Arbeit nahtlos übernehmen können.
    • Die Beschreibung sollte so wenig wie möglich Interpretationsspielraum bieten, um Missverständnissen vorzubeugen.
    • Als Abgrenzung von Features und Bugs. Der Scope muss so klar sein, dass im Nachhinein keine neuen Funktionen hineininterpretiert werden können.
      • Es können auch Dinge genannt werden, die explizit nicht Bestandteil sind.
    • Manchmal schreiben wir PBIs um Zunkunftsaufgaben festzuhalten. Dabei wird beispielsweise der Stand der Planung festgehalten. Die meisten PBIs sind jedoch für Aufgaben die feststehen und auch bearbeitet werden sollen. Diese werden mit dem Status "Planung" betitelt. PBIs (und Bugs) mit diesem Status werden in der Sprintplanungsvorbereitungsvobereitung beachtet. 

  • Wer spricht mit Kundinnen?

    • Jede/r kann/darf mit Kundinnen sprechen. Die Ergebnisse aus Gesprächen sollten nachvollziehbar im PBI dokumentiert werden.

  • Definition of Ready (DoR)

    • siehe z. B.: https://www.it-agile.de/agiles-wissen/agile-arbeit/was-ist-definition-of-ready/
    • Die Aufgabe ist beauftragt oder PO priorisiert interne Aufgaben.
    • Alle verstehen den Inhalt und wie es umgesetzt werden soll aus dem PBI (verschriftlicht).
    • Die Aufgabe ist geschätzt, Ausnahme sind Bugs.
    • Die Aufgabe sollte innerhalb eines Sprints umgesetzt werden können (ohne manuelles Testen).
    • Akzeptanzkriterien sind definiert.
      • Hinweis: Nicht-Funktionale Anforderungen sind definiert, falls es sie gibt. (Geschwindigkeit, Reaktionszeit, Security, Benutzbarkeit, Backups, …)
      • Muss eine Dokumentation erstellt / erweitert / berichtigt werden?
    • Es ist geklärt, wie getestet wird (verschriftlicht) und es gibt ggf. einen Test-Task.
    • Externe Abhängigkeiten sind aufgelöst. Interne Abhängigkeiten werden sicher im selben Sprint aufgelöst.

  • Definition of Done (DoD)

    • siehe z. B.: https://www.it-agile.de/agiles-wissen/agile-arbeit/was-ist-eine-definition-of-done/
    • Status: Dev-completed (alle Aufgaben im Zusammenhang mit der Softwareentwicklung sind fertig)
      • Pull-Request ist abgeschlossen (siehe: Umsetzung -> Pull Requests (PR)).
      • Aufgabe ist im Dev-System deployed (oder auf einem Testsystem, wenn es kein Dev-System gibt) und von einer Entwickler:in getestet
        • wenn dies aus technischen oder organisatorischen Gründen nicht möglich ist, dann nicht
      • Anforderungen an die Dokumentation sind umgesetzt (siehe Akzeptanzkriterien)
      • Wenn es einen Test-Task gibt, hat eine Testübergabe stattgefunden
      • Idee: Bibliotheken sollten entsprechende Tests haben
      • Idee: Neue Features sollten automatisiert testbar sein
    • Status Done:
      • Die Info an das Triebwerk zur Abrechnung ist erfolgt.
      • Das Produktivrelease ist erfolgt.

technische Machbarkeit

  • Wer sind die Teilnehmenden? Wer ist verantwortlich und kümmert sich (um was)?

    • Im Daily wird die Personengruppe geklärt.
      • Teilnehmer je nach Projekt aus DevOps Liste Verantwortliche
    • Product Owner.

  • Warum?

    • Aufwandsschätzung.
    • Prüfung Machbarkeit.
    • Der Umfang ist geklärt.

  • Wann?

    • wenn es Bedarf gibt.

  • Was schätzen wir?

    • Umsätzung
    • ToDo Testen noch zu klären? Puffer?
  • Doings die daraus fallen:
    • Priceing Tagessatz Pauschale Stundensatz

Angebotsprozess

  • Ablage von Dokumenten

    • z.B. Angebote, Kalkulation, Verträge.
      • Kunden Teams / SharePoint für Software Entwicklungskunden.
      • Angebote / Rechnungen im Odoo.
  • Projekt im Odoo anlegen damit im Kimai gebucht werden kann.

Approval

  • Wer sind die Teilnehmenden? Wer ist verantwortlich und kümmert sich (um was)?

    • Alle Unicorns, die in dem Termin anwesend sind, das bedeutet, es können auch Entscheidungen getroffen werden, wenn nicht alle Unicorns anwesend sind, insofern sich die Anwesenden in der Lage fühlen eine qualifizierte Entscheidung zu treffen.
    • Das Approval ist eine Pflichtveranstaltung, nach Absprache kann jedoch in Einzelfällen davon abgewichen werden.
    • PO ist verantwortlich, dass die Themen die im Approval geschätzt werden sollen, auch gepokert werden.

  • Warum?

    • Um ein gemeinsames Verständnis der PBIs zu bekommen.
    • Um die größe (Komplexität) der PBIs zu schätzen und so den Umfang der nächsten Sprints realistisch zu planen.

  • Wann?

    • Wenn das PBI im Status ToApprove ist.
    • Wenn das PBI ausreichend Beschrieben ist. (siehe DoR)
    • Spätestens bei der Sprintplanung.

  • Was?

    • Fehlende Dummy-(zum tracken der Kapazität) & Testtasks anlegen.
    • Schätzen von PBIs
    • Alle PBIs die am am Tag vor dem Approval in dem Approval-Chat bekannt gegeben werden.

  • Bugs

    • Es wird über Bugs gesprochen, auch wenn diese nicht geschätzt werden, so benötigen sie doch Kapazität und müssen verstanden werden und die DoR erfüllen.

  • Stuzubi Aufgaben

    • werden genauso wie alle anderen Aufgaben im Approval behandelt. Das bedeutet, dass Stuzubis Backlogitems für ihre Aufgaben pflegen.

Sprintplanung

  • Vorplanung

    • Vor der Sprintplanung gibt es eine Vorplanung, bei der die PBIs vorpriorisiert werden.
    • Wer priorisiert?
      • Product Owner:in
      • Geschäftsführende

  • Wer sind die Teilnehmenden?

    • Alle Unicorns, die in dem Termin anwesend sind.
    • Die Sprintplanung ist eine Pflichtveranstaltung, nach Absprache kann jedoch in Einzelfällen davon abgewichen werden.

  • Warum machen wir eine Sprintplanung?

    • Um die Aufgaben und deren Priorisierung für den nächsten Sprint festzulegen.
    • Um den Sprint Scope entsprechend der Kapazität zu füllen.

  • Was machen wir in der Sprintplanung?

    • ​​​​​​Letztes Sprint Backlog aufräumen.
    • Kapazitätsplanung. 
    • Aufnehmen von Product Backlog Items aus dem Product Backlog in das Sprint Backlog.
    • Approval von PBIs.
    • Es werden nur PBIs in den Sprint genommen, die die DoR erfüllen.
    • PBIs und Bugs auf den Status "Committed" stellen.

Umsetzung

  • Tasks anlegen
  • Feature Branch 
  • Code schreiben
    • Zu jedem Backlog Item (auch Bugs) mit Änderungen am Code, wird mindestens ein PR-Task erstellt, bevor der letzte Umsetzungstask auf "Done" gesetzt wird.
  • Refactoring: Falls ein Refactoring-Task auffällt wird dieser entweder sofort gefixt (Änderungen, die weniger als 15 Minuten Zeit benötigen) oder ein Task unter der nächsten Wartung angelegt
  • Remaining Work pflegen
  • Pull Requests (PR)
    • Warum PR:
      • 4-Augen-Prinzip
      • Qualität
      • Vollständigkeit (alle Anforderungen aus dem Bug / PBI)
      • Konsistenz (passen die Namen und Kommentare noch)
    • Für jeden Pull Request (PR) wird ein Task ("PR: ###") im aktuellen Sprint erstellt. Im nächsten Daily wird eine Person gefunden, die den PR übernimmt und ein Review durchführt. Dieses kann per Kommentare am PR geschehen oder per Peer Review mit dem Ersteller. Dieses wird im Daily bei der Übergabe festgelegt.
    • Wer darf ein Review machen?
      • Nach Absprache können auch Stuzubis oder neue Mitarbeitende Reviews durchführen.
      • Code Ersteller:in und Reviewer:in müssen unterschiedliche Personen sein
    • Der PR-Task wird zwischen Ersteller und Reviewer hin und her geschoben, bis der Pull Request geschlossen ist. Den Pull Request darf in der Regel nur durch den Ersteller geschlossen werden. In diesem Zuge wird der PR-Task automatisch geschlossen.
    • Zu jeder Codeänderung wird ein PR mit PR-Task mit Parent im aktuellen Sprint erstellt. 
    • Bei "Feuerwehraktionen" (z.B. Nachts) muss trotzdem ein PR-Task angelegt werden und es muss nachträglich ein Review durchgeführt werden.
    • Für Codeänderungen in Richtung Master wird immer ein PR erstellt.
    • Mit diesem Prozess sollte es nicht vorkommen, dass ein PR offen ist, ohne dass es einen offenen oder geblockten Task auf dem Board im aktuellen Sprint gibt.
    • PRs dürfen erst gemerged werden, wenn der Build erfolgreich durchgelaufen ist.
    • Alle Kommentare an einem PR müssen aufgelöst, sein bevor dieser gemerged wird.
    • Bei Unstimmigkeiten wird eine dritte Person involviert.
  • Dev Release
  • Todo sollten wir nochmal drüber reden: Dokumentation
  • Todo sollten wir nochmal drüber reden: Test Release sollte im Sprint abgestimmt werden
  • Testreleases finden so schnell wie möglich statt, spätestens aber im Dienstagstermin für Releases
  • Backlog Items sollten immer soviel Informationen enthalten, dass sich der jeweilige Status gut erkennen lässt. Zum Beispiel sollte sich der Grund für einen geblockten Task aus einem Kommentar erschließen. Die Person, die den Status ändert ist auch für den erklärenden Kommentar zuständig.

Testing

  • Info: Test-Tasks siehe DoR
  • Automatisiertes Testen
    • ist Teil der Implementation, wenn Tests im Prozess erstellt werden müssen.
    • Unit-Tests sollten im Build-Prozess laufen, Integrations-Tests nach dem Dev-Deployment.
  • Manuelles Testen
    • Test Übergabe
      • Die Entwickler:in zeigt der Tester:in wo / was entwickelt wurde und was ggfs. zu testen ist.
      • Der Test-Task wird der Tester:in übergeben
        • Wenn ein Kunde testen muss, dann gehört der Test-Task der Person aus dem Team, die Kontakt mit dem Kunden hat und die Rückmeldung erwartet.
    • Test im Team
      • kann im Sprint nach der Umsetzung passieren
  • Bugs und deren Behebung
    • Bevor ein Bug als Bug eingestuft wird, muss geprüft werden, ob der vermeintliche Bug nicht ein verstecktes Feature ist, welches nicht zum beauftragten Scope gehört.
    • Änderungen die weniger als 15 Minuten Zeit benötigen, dürfen von der Entwickler:in selbst entschieden werden. Größere Änderungen müssen mit der P.O. abgestimmt oder spätestens im nächsten Daily angesprochen werden.
    • Bugs werden im aktuellen Sprint angelegt.
    • Es wird ein Task mit dem Präfix "BUG: " angelegt und dem P.O. zugewiesen. Dieser klärt mit dem Ersteller die Priorität.
      • Repro Steps enthält eine nachvollziehbare Fehlerbeschreibung (was soll passieren, was passiert, warum ist das falsch)
      • System Info enthält Angaben zur Umgebung, dem Browser, Mobil/Desktop und falls vorhanden einen Link zu exceptionless
      • Akzeptanzkriterien können initial leer bleiben
      • Area Path muss ausgefüllt werden
      • Iteration ist der aktuelle Sprint
      • Status muss New sein.
      • Parent
      • Sofern vorhanden und bekannt, das Backlog Item als Related verknüpfen
    • vor der Lösung/Bearbeitung von Bugs müssen die Akzeptanzkriterien ausgefüllt werden und ein Test Task angelegt werden. Bugs die in die nähere Zukunft eingeplant werden sollen, werden mit dem Status "Planung" versehen
    • Bugs werden nicht geschätzt
  • Ist ein Bug oder PBI fertig entwickelt und intern fehlerfrei getestet, wird der Status auf Test Completed geändert.
    • Wird der Status Test Completed gesetzt
    • Am Dienstag im Daily sprechen wir über offene Prod-Releases und stimmen diese mit Kunden ab.
    • Zur Planung von Releases gibt es eine Spalte "Test Completed" auf dem Kanban-Board in der alle PBIs mit diesem Status aufgelistet werden.
  • Hinweis: DoD beachten

Sprint Review

  • Verantwortung
    • Planung des Termins durch P.O.
    • Gewählte Person aus dem Team präsentiert
    • P.O. protokolliert und legt ab
  • P.O. holt Abnahme vom Kunden ein
  • Teilnehmerkreis
    • P.O.
    • Kunde
    • Person aus dem Team
  • Übergabe an den Kunden

Produktivrelease

  • Planung des Termins durch P.O.
  • Wer kommuniziert?
    • Das Softwareentwicklungsteam.
  • Wann?
    • In der Regel versuchen wir Prod-Releases am Freitag, vor Feiertagen und am Wochenende zu vermeiden.
  • Wer führt das Release durch?
    • Zwei Unicorns (4-Augen-Prinzip)
  • Wie wird das Release durchgeführt?
    • Kurzer Funktionstest
    • Der Kunde wird über die Fertigstellung informiert
    • Releaselog wird von den Entwicklern gesendet.
    • PO wird informiert

Abschluss

  • Verantwortung bei PO
  • Info an das Triebwerk:
    • dass Abgerechnet werden kann oder selbst abrechnen
    • ggfs. Wartungsgebühren anpassen (lassen)
    • Abschluss im Odoo (archivieren), dann kann im Kimai nicht mehr gebucht werden.
  • Backlog Item kann geschlossen werden

Abrechnung

Die Abrechnung kann von zwei Seiten erfolgen: Entweder es ist ein Auftrag abgeschlossen und man rechnet von der Seite des Auftrags ab oder man nimmt die Tätigkeiten des Teams in Kimai und rechnet diese nach Projekten ab. Ich bin immer zuerst die Aufträge durchgegangen und habe zum Schluss geprüft, welche Tätigkeiten noch stattgefunden haben, damit nichts vergessen wird abzurechnen. Die Wartungsverträge werden automatisch vom Triebwerk zum Monatswechsel abgerechnet.

  • Abrechnung von Wartungen

    • Hier muss keine proaktive Meldung an das Triebwerk erfolgen. Es wird direkt zum Monatswechsel abgerechnet. Lediglich folgende Dinge sind zu beachten: 
      • Erhöhung der Wartungen im Vorfeld an das Triebwerk melden:  
        • HSHL (Liste der Anwendungen)
          • Für jedes neue Feature, welches (nach Rücksprache mit Bianco) wartungsrelevant ist, wird mit der Fakturierung des Vertrags die Summe der Rechnung für die Berechnung des Wartungsbetrag erhöht. Dazu wird an dem Backlog Item das Häkchen entsprechend gepflegt.  1733305493670-835.png
        • Stadtwerke Soest (Wartungsgebühr je Mandant)
      • Überprüfung der Tätigkeitseintragungen in Kimai, die unter Wartungen verbucht sind. Gelegentlich kommt es vor, dass Tätigkeiten dort eingetragen wurden, die auf einen Auftrag gehören.
      • Des Weiteren ist das monatliche Zeit-Budget im Blick zu behalten (Beispiel: HSHL. Erklärt in einem Stream. )
      • aktuell keine Erhöhung der Wartung bei:
        • BfW (Pauschale ohne Erhöhungsklausel)
        • ahd (Pauschale Support-Service Reaktionszeit my.ahd Verbrauchsdaten monatlich gleichbleibend €500)

  • Abrechnung von Aufträgen

    • Bei den meisten Aufträgen spielt der Monatsbezug in Kimai keine Rolle, da sich diese oft über zwei oder mehr Monate ziehen und zum Ende hin per Festpreis abgerechnet werden. Somit muss mit der Abrechnung nicht auf den Monatswechsel gewartet werden, sondern diese kann direkt nach Abnahme erfolgen.
    • Überprüfung der Tätigkeiten des Auftrags in Kimai, ob
      • Tätigkeiten aus Versehen unter Wartung gebucht wurden, die eigentlich zum Auftrag gehören.
      • Tätigkeiten den Schlagwort "Unklar" enthalten und dieses dann klären.
      • der Status "abrechenbar" passt.
    • Infomail an das Triebwerk, dass der Auftrag abgerechnet werden kann oder selbst abrechnen. 
      • Inkl. Info, ob der Auftrag geschlossen werden kann. Manchmal machen Teilabrechnungen Sinn. 
      • Inkl. Info, ob das Projekt in Odoo / Kimai geschlossen werden kann. Manchmal finden im Nachhinein noch Tätigkeiten statt, zum Beispiel das Produktivrelease, obwohl der Auftrag schon abgerechnet wurde. Somit sollte das Projekt in Kimai noch offen bleiben, damit die Tätigkeiten darauf gebucht werden können.
    • Tätigkeiten in Kimai sollten anschließend auf "exportiert" stehen bzw. der Auftrag ist im Kimai nicht mehr zu sehen, wenn er im Odoo archiviert wurde.

  • Abrechnung von weiteren Tätigkeiten

    • In Kimai unter "Alle Zeiten" lassen sich mit dem Team-Filter "Team Unicorn" weitere Tätigkeiten identifizieren, die abgerechnet werden können.
      • zunächst Überprüfung der Tätigkeiten, die das Schlagwort "Unklar" haben und ggf. klären
      • Überprüfung des Status abrechenbar
    • Oder über die Kundenübersicht (Daten für Export filtern) in Kimai ( > Filter Team Unicorn). Hiermit kann man sich je Kunde die gebuchte Dauer des Teams mit "Abrechenbar = ja" und "Exportiert = nein" anzeigen lassen. 
      • Betrachtung eines Kunden: Dazu Anzeige aller Tätigkeiten des Kunden für den letzten Monat. Überprüfung Schlagwort "Unklar" und Status abrechenbar. Bei Tätigkeiten, die als Nachweis dem Kunden zugeschickt werden, Prüfung des Beschreibungstext. Um Sicher zu gehen, dass keine Dinge übersehen werden, kann man je Kunde die Tätigkeiten der einzelnen Projekte in Kimai durchgehen. Hier eine Liste der Tätigkeiten bei der ahd mit der Abrechnung nach Aufwand mit den Referenzen. Vorsicht bei den Tätigkeiten "ahd Express Support": Diese haben einen höheren Stundensatz, laufen aber unter dem Kimai-Projekt "Verbrauchsdaten", unter dem auch nicht ahd Express Support Tätigkeiten gebucht werden. Diese müssen vorher extrahiert werden.

Wartung

Ein vorhandener Wartungsvertrag sollte im Projektsteckbrief erwähnt sein und z. B. auf dem Sharepoint im Kundenverzeichnis zu finden sein.

  • Warum machen wir eine Wartung?
    • Um Sicherheitsrisiken zu minimieren.
    • Den Code wartbar zu halten.
    • Um 3rd party libraries aktuell zu halten. (Updates von frameworks werden gesondert berechnet)
    • Um jederzeit Änderungen am Code und entsprechende Releases machen zu können.
  • Was ist der Inhalt der Wartung? (wenn der Kunde einen Wartungsvertrag hat)
    • Abhängigkeiten Updates (NPM, Nuget, ...)
    • Code Überarbeitung
    • Nicht inhalt der Wartung sind mehrere Entwicklungsstände. (Nur Main ist Bestandteil der Wartung)
    • Eigene Nuget Pakete
    • Unit Test
    • Dinge die in der Entwicklung aufgefallen sind (die als Task unter der Wartung angelegt worden sind)
  • Wann wird die Wartung durchgeführt?
    • Wenn diese im Sprint eingeplant ist.
    • Üblicherweise wird eine monatliche Wartung mit einem Umfang von einem Personentag verkauft.
  • Wer führt die Wartung durch?
    • Jede/r Entwickler:in kann die Wartung durchführen.
    • Wenn zu wartende Dinge auffallen, dann sollen dafür neue Tasks angelegt und an das PBI der nächsten Wartung gehängt werden.
  • Testen der Wartung?
    • Das ergibt sich aus dem Wartungsvertrag.
      • z. B. Funktionstests für die wichtigsten Funktionen
    • Checklisten mit den wichtigsten Funktionen.
    • Unser Ziel ist es, die wichtigsten Funktionen automatisiert zu testen.

Urlaubs- und Krankheitsvertretung

  • Idealfall:
    • Es sollte eine Skillmatrix geben, aus der ein Faktor hervorgeht wie viele Personen eine Aufgabe eigenständig lösen können.
      • Idee: Welche Fähigkeiten brauen wir, um die meisten unserer Referenzstorys zu bearbeiten?
    • Für jede Aufgabe sollte es min. 3 Personen geben, die diese eigenständig lösen können. 
    • Wenn eine Person in den Urlaub geht, muss vorher geprüft werden, ob zwei andere Personen diese Aufgaben übernehmen können.
  • Minimalfall:
    • Wir versuchen Abwesenheiten so zu Planen, das alle Skills vorhanden sind.
  • Urlaub:
    • Der Wikiartikel: Urlaub & Freizeitausgleich ist zu beachten.
    • Kurzfristige Urlaube, innerhalb der nächsten 14 Tage, müssen im Daily abgesprochen werden.
    • Längerfristige Urlaube, 14 Tage in der Zukunft und mehr, können unter den oben genannten Regeln (alle Skills vorhanden) eingetragen werden.
      • Für Stuzubis gilt dieselbe Regelung.
    • Serviceverträge:
      • für die Weihnachtszeit müssen wir beachten, dass die Hotline qualifiziert besetzt ist.
      • ggfs. müssen wir im Vorfeld die aktuellen Verträge prüfen.
      • ggf. prüfen, ob die richtigen Personen in der Telefonqueue sind.
  • Aufgaben, Aufgabenübergabe:
    • Grundsätzlich sollte eine Person keine offenen Aufgaben liegen lassen, wenn sie (mehr als zwei Tage) in den Urlaub geht.
    • Wenn Aufgaben offen sind / offen bleiben / weiter bearbeitet werden müssen, muss eine Übergabe stattfinden. Insbesondere sollte keine Person in den Urlaub gehen und der Name noch als Assignee an einem Task stehen.

Wissenstransfer

  • Wer?
    • Pflichtveranstaltung für Unicorns
    • Je nach Thema auch Worksimple
  • Warum?
    • Alle aus dem Team bilden sich an dem vorgestellten Thema weiter.
    • Damit sich die Qualität der Entwicklung der einzelnen Entwickler steigert durch Erfahrungen des Teams.
  • Was?
    • Wissen wird von jemanden an das Team weitergegeben.
  • Wann? Wie oft?
    • Bei Bedarf
  • Wo? 
    • Der Termin wird aus dem Unicorn Postfach erstellt.
  • Jeder Wissenstransfer muss aufgezeichnet werden. Aufzeichnungen werden im Unicorns Teams unter Allgemein/Dateien/Wissenstransfer abgelegt.

internes Sprint Review

  • Warum?
    • Um alle Unicorns auf den aktuellen Stand der einzelnen Projekte zu bringen.
    • Besonderheiten bei Projekten ins Team zu bringen.
    • Kann zur Vorbereitung eines externen Sprint Reviews dienen.
  • Wer?
    • Pflichtveranstaltung für Unicorns
  • Wann?
    • Alle 4 Wochen
  • Wo? 
    • Der Termin wird aus dem Unicorn Postfach erstellt.
  • Was?
    • Besonderheiten bei Projekten
    • Themen aus den letzten zwei Sprints

Retro

  • Warum?
    • Kontinuierliche Verbesserungen
  • Wer?
    • Pflichtveranstaltung für Unicorns
  • Wann?
    • Nach jedem Sprint
  • Wo? 
    • Der Termin wird aus dem Unicorn Postfach erstellt.
  • Was?

Daily

  • Findet täglich statt.
  • Ist eine Pflichtveranstaltung.
  • Eine Person moderiert.
  • Modus: was habe ich gestern gemacht, was mache ich heute, was behindert mich (eventuell)
    • Ergänzung aus der Retro vom 24.07.2025
      • Jede/r kommt vorbereitet zum Daily.
      • Wir prüfen immer am Ende, ob wir den Sprint noch schaffen.
        • Wenn nicht überlegen wir Gegenmaßnahmen oder planen aus.
      • Wir schauen, wie lange Tasks liegen bleiben.
      • Wer möchte, kann Aufgaben kleiner schneiden.
  • Am Ende können allgemeine Themen besprochen werden.
  • Literaturtipp: Daily oder der Gefängnisausbruch

Aufgaben Product Owner (P.O.) / Projektmanager:in

An der Überschrift Product Owner / Projektmanager:in ist zu erkennen, dass die Aufgaben von der Rolle der Person abhängen. Die Rolle hängt wiederum vom Vorgehensmodell ab. Wir haben Projekte die nach Aufwand (Time & materials) abgerechnet werden. In solchen Fällen werden iterative Vorgehensmodelle (Annäherung an das Ergebnis in Feedback-Schleifen) wie zum Beispiel Scrum eingesetzt. Product Owner ist eine Rolle aus Scrum. Wir haben aber auch Projekte, die nach einem vorher definierten Projektumfang abgerechnet werden. In solchen Fällen werden lineare nicht iterative Vorgehensmodelle verwendet. Diese werden auch Wasserfallmodelle genannt. Projektmanager:in ist eine Rolle aus einem Wasserfallmodell. Wir müssen bei den Aufgaben anerkennen, dass es keine klare Rollentrennung gibt, da es sowohl iterative, nicht iterative als auch Mischformen (Agiler Festpreis) bei den Projekten gibt.

  • Statuscalls (wöchentlich / zweiwöchentlich / auf Zuruf) mit Kunden (intern / extern) - Vorbereiten, Durchführen, Nachbereiten
  • Approval (Schätzen von fertigen User Stories im Backlog) - einmal pro Woche
  • Planung & Durchführung von Anforderungsgesprächen
  • Erstellen, pflegen von Backlog Items
  • Angebotskalkulationen durchführen, Angebote erstellen und an den Kunden senden
  • Projekte und Tätigkeiten in Odoo anlegen
  • Sprintplanung
  • Priorisieren von Projekten
  • Protokolle von Meetings mit Kunden versenden
  • Tätigkeitsbewertung und Freigabe für die Abrechnung
  • Postfach im Auge behalten
  • Efecte im Auge behalten

Entwicklungsprozess (organisatorisch)

  • Kunde, Vertrieb oder anderer Eingangskanal bittet um ein Angebot oder eine Anforderung wird geäußert. (PO)
  • Kundenkontakt / Kundengespräch(e) mit konkreter Aufnahme der Anforderungen (Erstellen der User Stories / Backlog Items) (Alle)
  • Interne Bewertung der Machbarkeit und Aufwandsschätzung (Entwickler)
    • Entscheidung ob Entwicklung nach Pflichtenheft oder Stunden & Aufwände (PO)
  • Angebot an den Kunden senden (PO)
  • Auftragsbestätigung versenden / Kunde & Auftrag wird angelegt (PO)
  • Approval (Alle)
  • Sprintplanung
  • Softwareentwicklung in Sprints: In unserer Softwareentwicklung arbeiten wir in Sprints. Sobald ein Product Backlog Item (PBI) den Status „Definition of Ready“ (DoR) erreicht hat und im Azure DevOps einem Sprint zugewiesen sowie auf „Committed“ gesetzt wird, verpflichten wir uns, die Entwicklung dieses PBIs innerhalb des Sprints abzuschließen. Dies bedeutet jedoch nicht automatisch, dass die entwickelte Software im selben Zeitraum auf ein externes Test- oder Produktivsystem deployed wird. Externe Tests, Reviews und Abnahmen erfordern oft zusätzliche Terminabstimmungen mit anderen Beteiligten, die nicht immer innerhalb des Sprint-Zeitrahmens realisierbar sind. Wir übernehmen die Verantwortung für die vollständige Umsetzung der Software im Sprint, während das Deployment auf externe Systeme von Faktoren abhängt, die außerhalb unseres direkten Einflussbereichs liegen. Unser Ziel bleibt es jedoch, die entwickelte Software so zeitnah wie möglich in den Produktivbetrieb zu überführen.
  • Testrelease + Testen
  • Review mit dem Kunden & Kunde testet
  • Abnahme
  • Überprüfen der Angaben in Odoo / Kimai
  • Fakturierung: WorkSimple Buchhaltung (Triebwerk) oder wir selbst versenden die Rechnung
  • Geld geht auf Konto ein

Checkliste (Lifecycle Backlog Item)

[  ] technische Machbarkeit hat stattgefunden
[  ] Angebot ist verschickt
[  ] Angebot ist angenonmmen
[  ] Auftragsbestätigung ist verschickt
[  ] Thema ist approved
[  ] Thema ist im Sprint aufgenommen
[  ] Umsetzung ist abgeschlossen
[  ] Release ins Testsystem hat stattgefunden
[  ] Sprint Review hat stattgefunden
[  ] Kunde hat getestet
[  ] Unicorn Test ist abgeschlossen
[  ] Abnahme vom Kunden erhalten
[  ] Release ins Prodsystem hat stattgefunden
[  ] Rechnung ist geschrieben
[  ] Abschluss in Odoo / Kimai
[  ] Wartungsgebühr wurde ggfs. erhöht und Kunde informiert