Scrum - Empirische Prozessteuerung

Die unangenehmste Eigenschaft von komplexen Problemen ist, dass sie meistens unvorhergesehen auftreten. Zusätzlich ist die Art und Weise, wie diese Probleme in Erscheinung treten nicht fest definiert, sondern unterscheidet sich von Fall zu Fall.

Die meisten Prozesse funktionieren nur deshalb, weil der Grad der Ungenauigkeit tolerierbar ist. Es gibt keine exakt rund laufenden Räder oder vollkommen plane Oberflächen im Alltag. Dies ist aber in sofern tolerierbar, weil es keinen Einfluss auf die Nutzung der entsprechenden Produkte hat. Viele Prozesse können mit dieser Toleranz erfolgreich bewältigt werden.
Sind allerdings höhere Präzisionsgrade gefragt, so müssen die Prozesse, die zu ungenau sind, angepasst werden. Ein höherer Grad der Präzision kann durch eine schrittweise Steuerung des Prozesses erreicht werden. Damit soll sichergestellt werden, dass sich die einzelnen Schritte innerhalb des Prozesses in ihren Toleranzbereichen befinden. Sollten einzelne Schritte mit zu hohen Toleranzen verarbeitet werden, so können diese recht schnell auf eingegrenzt und bearbeitet werden. Die Gestaltung eines solchen Prozesses, der ein stetiges Qualitätsniveau erreicht wird als definierte Prozesssteuerung bezeichnet.

In vielen Fällen ist aufgrund der Komplexität der Zwischenschritte keine definierte Prozessteuerung möglich und es muss die sogenannte empirische Prozessteuerung eingesetzt werden.

Ken Schwaber beschreibt die Unterschiede anhand der Produktion von Massenware. Die definierte Prozessteuerung ist dann zu gebrauchen, wenn ein Produkt als Massenprodukt hergestellt werden soll. Hohe Stückzahl mit mittlerer Qualität sozusagen. Wird das Produkt allerdings von der Qualität so schlecht, dass dieses unbrauchbar wird, so muss mit Hilfe der empirischen Prozesssteuerung nachgebessert werden. Die empirische Prozesssteuerung ist dabei kostengünstiger (auf lange Sicht) als die Nachbesserung durch die definierte Prozesssteuerung.

Säulen der empirischen Prozesssteuerung

Die drei Säulen der empirischen Prozesssteuerung sind die Sichtbarkeit, die Inspektion und die Anpassung.

• Sichtbarkeit
• Alle ergebnisorientierten Aspekte eines Prozesses müssen für die Überwacher des Prozesses sichtbar sein. Die Sichtbaren Eigenschaften müssen zwangsläufig wahrheitsgetreu sein, es gibt keinen Spielraum für Täuschungen und Fehlinterpretation.
• Inspektion
• Alle Aspekte des Prozesses müssen so oft untersucht werden, dass nicht tolerierbare Abweichungen im Prozess festgestellt werden können. Die Wahl der Häufigkeit muss berücksichtigen, dass die Inspektion an sich die Prozesse verändern kann. Bei hoher Dichte der Inspektionen wird die Inspektionstoleranz des Prozesses überschritten.
• Anpassung
• Sollten Abweichungen der Toleranzen heruasgefunden werden, so muss der Prüfer die Prozesse anpassen und justieren. Die Anpassungen müssen so schnell wie möglich durchgeführt werden.

Ken Schwaber erläutert die unterschiedlichen Säulen anhand einer Review des erstellten Codes.

Code Review durch erfahrene Entwickler

Dabei wird die erstellte Funktionalität einem Review durch erfahrene Entwickler unterzogen. Dieses Review erfolgt auf Basis der vorgegebenen Programmierstandards und unterschiedlichen Vorgehensweisen. Diese Überprüfung wird immer dann durchgeführt, wenn ein Abschnitt fertiggestellt worden ist. Eventuell auftretene Verbesserungen oder Kommentare werden durch den Entwickler duchgeführt.

Projektmanagement - Prozesse und Prozessverbesserungen

Prozesse und vor allem Prozessverbesserungen sind in jedem Projekt an der Tagesordnung. Dabei müssen nach DeMarco allerdings verschiedene wichtige Punkte berücksichtigt werden.

Prozesse und Prozessverbesserung

• Prozesse und Prozessverbesserungen sind wichtige Ziele für jedes Unternehmen.
• Beide Kategorien sind gleichzeitig auch natürliche Ziele, da gute Mitarbeiter automatisch diese Zeile umsetzen, egal ob dieses explizit gefordert wird oder nicht
• Ein formales Prozessverbesserungsprogramm kostet nicht nur Geld und Zeit, sondern führt in der Regel auch zu Rückschritten in den Projekten. Werden solche Programme in die Projekte eingebunden, wird der Verlust immer größer sein als der erzielte langfristige Gewinn.
• Das Projekt kann allenfalls von einer Methodenverbesserung profitieren, welche bereits vorher mit Zeit- und Geldaufwand erreicht worden ist.
• Kein Projekt ist in der Lage mehr als ein Prozessverbesserungsprogramm zu durchlaufen ohne signifikante Verzögerungen in der Fertigstellung zu riskieren.
• Standardisierte Prozesse bieten die Gefahr, dass wichtige Abkürzungen für ein Projekt durch die Mitarbeiter ungesehen bleiben.
• Überbesetzte Projekte bergen die Gefahr, dass standardisierte Prozesse streng eingehalten werden, da sonst nicht genügend Arbeit generiert wird und Mitarbeiter nicht ausgelastet sind.