Empirisches Prozesskontrolle vs. Definiertes Prozesskontrolle
Empirisches Prozesskontrolle erwartet das Unerwartete, während definiertes Prozesskontrolle davon ausgeht, dass jede Aufgabe im Voraus vollständig verstanden werden kann.

Prozesskontrolle
Was ist definiertes Prozesskontrolle?
Definiertes Prozesskontrolle ist ein Prozess mit klar definierten Schritten. Wenn wir in einer relativ stabilen und vorhersehbaren Umgebung arbeiten, sollte ein definierter Prozess bei gleichem Eingang immer das gleiche Ergebnis liefern, basierend auf seiner Wiederholbarkeit und Vorhersehbarkeit. Ein definierter Prozess weist folgende Eigenschaften auf:
- Gemeinsam und kontrolliert
- Plane, was du erwarten wirst
- Führe den Plan unabhängig von sich ändernden Bedingungen aus
- Verwende Änderungskontrolle, weil Änderungen kostspielig sind
Was ist empirisches Prozesskontrolle?
Bei empirischem Prozesskontrolle erwartet man das Unerwartete. Bei definiertem Prozesskontrolle ist jede Aufgabe im Voraus vollständig verstanden. In Scrum, wird ein empirischer Prozess umgesetzt, bei dem Fortschritte auf Beobachtung und Experimentation basieren, anstatt auf detaillierte Vorplanung und vorgegebene Prozesse. Empirisches Prozesskontrolle basiert auf Fakten, Erfahrung und Beweisen – umgesetzt durch Inspektion und Anpassung.
Empirisches Prozesskontrolle weist folgende Eigenschaften auf:
- Lern aus dem Fortschritt
- Erwartet und begrüßt Veränderung
- Nutzt kurze Entwicklungszyklen zur Inspektion und Anpassung
- Schätzungen dienen nur als Referenz und können ungenau sein

Scrum empirisches Prozesskontrolle
Empirisches Prozesskontrolle in Scrum
In Scrum wird empirisches Prozesskontrolle durch drei zentrale Prinzipien umgesetzt: Transparenz, Inspektion und Anpassung.
Transparenz stellt sicher, dass alle Aspekte des Prozesses, die das Ergebnis beeinflussen, für diejenigen sichtbar sind, die für die Steuerung des Ergebnisses verantwortlich sind. Diese Aspekte müssen nicht nur transparent sein, sondern auch von den Beobachtern verstanden werden. Mit anderen Worten, wenn jemand eine Aufgabe als abgeschlossen betrachtet, muss dies mit ihrer definierten Definition des Fertiggestelltseins.
Aspekte des Prozesses müssen häufig inspiziert werden, um unzulässige Abweichungen zu erkennen. Die Häufigkeit der Inspektion muss berücksichtigen, dass die Inspektion selbst den Prozess verändern kann. Wenn die erforderliche Inspektionshäufigkeit die Prozess-Toleranz überschreitet, entstehen Komplikationen. Glücklicherweise scheint die Softwareentwicklung weniger empfindlich gegenüber diesem Faktor zu sein. Ein weiterer Faktor ist das Können und die Sorgfalt derjenigen, die die Arbeit inspizieren.
Wenn Inspektoren feststellen, dass ein oder mehrere Aspekte des Prozesses außerhalb akzeptabler Grenzen liegen und das resultierende Produkt unakzeptabel wäre, müssen sie den Prozess oder die verarbeiteten Materialien anpassen. Anpassungen müssen so schnell wie möglich vorgenommen werden, um weitere Abweichungen zu minimieren.
Die drei Säulen in Scrum-Veranstaltungen
Lassen Sie uns nun untersuchen, wie Scrum die drei Säulen als Best Practices in das Framework durch verschiedene Veranstaltungen integriert.
Zum Beispiel:
- Die Daily Scrumwird verwendet, um den Fortschritt gegenüber dem Sprint-Ziel zu überprüfen und Anpassungen für die Arbeit des nächsten Tages vorzunehmen, um den Wert zu maximieren.
- Zusätzlich werden Sprint-Reviewund Sprint-Planung verwendet, um den Fortschritt gegenüber dem Release-Ziel zu überprüfen und Anpassungen vorzunehmen, um den Wert im nächsten Sprint zu optimieren.
- Schließlich wird die Sprint-Retrospektivewird verwendet, um die vergangene Sprint-Periode zu reflektieren und Anpassungen zu identifizieren, die den nächsten Sprint effizienter, wirksamer und angenehmer machen werden.
Diese Liste fasst die Beziehung zwischen Scrum-Veranstaltungen und den drei Säulen wie folgt zusammen:
- Artefakte
- Projektvisionserklärung
- Priorität Produkt-Backlog
- Release-Plan
- Veranstaltungen
- Sprint-Review-Veranstaltung
- Daily Stand-up
- Informationsstrahler
- Burndown-Diagramm
- Scrum-Aufgaben-Board
Inspektionin Scrum wird beschrieben durch:
- Verwendung gemeinsamer Scrum-Aufgaben-Boards und anderer Informationsstrahler
- Sammeln von Feedback von Kunden und Stakeholdern während der Entwicklung von Epics, Erstellen eines priorisierten Produkt-Backlogs und Planen von Release-Verhaltensweisen
- Product Owner und Kunden überprüfen und genehmigen Lieferungen während der Sprint-Demonstrationen und -Validierungen
Anpassung ist das Herzstück von Scrum, bei dem das Team und die Stakeholder aus Transparenz und Inspektion lernen und ihre Arbeit entsprechend anpassen. Die Anpassungsfähigkeit in Scrum wird wie folgt beschrieben:
- Tägliche Stand-up-Meetings
- Kontinuierliche Risikoidentifizierung
- Änderungsanfragen
- Scrum-Anleitung
- Retrospektive Sprint-Meetings