TopMenue

17. Frühe und kontinuierliche Auslieferung

Dieser Beitrag befindet sich noch in Bearbeitung!

Die kurzfristige, frühestmögliche und kontinuierliche Auslieferung in permanenten und kurzen Zyklen ermöglicht allen Beteiligten, frühes und wertvolles Feedback sowohl abgeben zu können, als auch zu erhalten, um auf diese Weise das Erreichen optimaler Ergebnisse zu unterstützen

Auch wenn sich eine Software noch im laufenden Fertigungsprozesses befindet, wird sie in den klassischen Softwareentwicklungsprozessen bereits als statisch und festgelegt angesehen, da auch ihre Beschreibung und Definition als statisch und festgelegt und damit als abgeschlossen angenommen wird.

Im Gegensatz dazu wird die Software in den agilen Softwareentwicklungsprozessen im laufenden Fertigungsprozesses durchgehend als dynamisch und potenziell inkomplett angesehen, da ihre Beschreibung und Definition das gesamte Projekt über als vorläufig und damit als jederzeit änderbar angesehen werden.

Klassisch: späte Erstauslieferung  ^

In den klassischen Softwareentwicklungsprozessen wird das Projekt zunächst komplett durchgeplant, der Projektplan, der den gesamten Fertigungszyklus des Produktes umschließt, erstellt, dann das Projekt begonnen und bis zu einem bestimmten Reifegrad des Produktes — der zumeist in der Nähe der Fertigstellung des Produktes liegt — durchgeführt. Zu diesem Zeitpunkt wird die Software den Stakeholdern als alpha- / beta-Version oder als Release-Kandidat erstmalig ausgeliefert. Das bedeutet, dass die Stakeholder die Software erst in der zeitlichen Nähe des Projektendes erstmalig zu Gesicht bekommen.

Insbesondere für engagierte Stakeholder kann dieses Vorgehen nicht zufriedenstellend sein. Bis zu dem Zeitpunkt, wo sie ein mit hoher Wahrscheinlichkeit lauffähiges Produkt in Händen halten, sind sie nicht in der Lage, herauszufinden, ob in dem Projekt die von Ihnen gewünschte, benötigte und erwartete Software erstellt wird. Ist das, aus welchen Gründen auch immer, dann auch nicht der Fall, stehen sie vor einem ganz erheblichen Problemen: zum einen ist die Projektlaufzeit und damit das Budget fast vollständig aufgebraucht und zum anderen ist das Produkt in diesem Fall zumindest in Bezug auf ihre wirklichen Anforderungen und Bedürfnisse fast vollständig unfertig.

Ein steter Quell unbändiger Freude … für Anwälte.

Scrum: frühestmögliche Auslieferung  ^

Scrum als agiler Prozess verfolgt einen gänzlich anderen Ansatz. Scrum setzt auf die frühestmögliche Auslieferung eines jeweils im Rahmen seines Funktionsumfanges vollständig fertig realisierten Produktes. Je früher die Stakeholder auf diese Weise ein für sie wertvolles Produktinkrement erhalten, umso früher

  • bekommen sie einen Eindruck von Produkt und Team,
  • können sie prüfen, ob es das ist, was sie brauchen und haben wollen,
  • eröffnet sich ihnen die Möglichkeit, es potenziell im Rahmen der vollständig fertig realisierten Anforderungen produktiv einsetzen zu können,
  • können sie dem Scrum-Team im Gegenzug wertvolles Feedback und Hinweise liefern, dass dann wieder in die Realisierung des Produktes einfließen kann … und einfließen wird.
Alle profitieren  ^

Für die Stakeholder spielt die frühestmögliche Auslieferung eine ganz besondere Rolle. Entscheidend ist für sie, dass sie zu jeder Zeit den Projektfortschritt selbst überprüfen können, das schafft Vertrauen in Projekt und Team. Das Projektteam profitiert dabei vom frühen Feedback, das Unternehmen von steigender Kundenzufriedenheit.

Wie funktioniert die frühestmögliche Auslieferung?  ^

In Scrum werden alle Anforderungen mit einer eindeutigen Priorität (in der eventuell bestehende Abhängigkeiten der Anforderungen untereinander bereits berücksichtigt sein müssen) versehen. Die Liste der Anforderungen (das Product-Backlog) wird nach dieser Priorität absteigend sortiert. Das hat zur Folge, dass immer die wichtigsten und damit für die Stakeholder wertvollsten Anforderungen ganz oben im Product-Backlog stehen und diese somit — das Product-Backlog wird stets vom Anfang her durchgearbeitet — immer zuerst realisiert werden.

Es gibt in dem auszuliefernden Produktinkrement also keine unfertigen oder nur zum Teil realisierten oder gerade angefangenen Funktionalitäten; sie werden, um den Aufbau technischer Schuld zu vermeiden, immer vollständig fertig realisiert. Ist eine Anforderung zum Zeitpunkt der Abgabe des Produktinkrements nicht vollständig fertig realisiert, ist sie nicht abnahmefähig und kann und darf daher nicht Bestandteil des zu präsentierenden und auszuliefernden Produktinkrements sein und auch nicht werden. Diese Anforderungen werden (mit dem gleich Aufwandschätzwert wie zuvor) zurück ins Product-Backlog gestellt und im folgenden Sprint erneut bearbeitet.

Der Kunde ein König  ^

Die Stakeholder / Kunden / Auftraggeber können also fest damit rechnen, dass in dem ihnen übergebenen Produktinkrement immer die für sie wichtigsten und wertvollsten Funktionalitäten vollständig realisiert enthalten sind. Dieses Produktinkrement können sie, sofern es ihnen aufgrund der Menge der in den vollständig realisierten Anforderungen enthaltenen Funktionalitäten möglich und sinnvoll erscheint, sofort produktiv einsetzen. Auf diese Weise erreicht Scrum, bzw. das Scrum-Team, dass die wichtigsten Anforderungen stets als erstes und damit stets sehr früh im Projekt abschließend realisiert werden und die Stakeholder dadurch bereits zu einem sehr frühen Zeitpunkt eine Software erhalten, die ihre wichtigsten Anforderungen abdeckt.

Frühzeitiger Abschluss des Projektes ist möglich  ^

Ist ein Stand erreicht, mit dem die Stakeholder produktiv arbeiten können, bietet sich ihnen die Möglichkeit, das Projekt zu beenden, auch wenn noch nicht alle ihre Anforderungen umgesetzt wurden. Ob das sinnvoll ist oder nicht, liegt ausschließlich der Entscheidung der Stakeholder.

Wertvolles Feedback ermöglicht weitreichende Reifungsprozesse  ^

Je früher die Stakeholder ein für sie wertvolles Produktinkrement erhalten, desto früher bekommen sie einen Eindruck von dem Produkt und können es frühzeitig (zumindest potentiell) produktiv einsetzen und umso früher liefern sie dem Scrum-Team wertvolles Feedback zurück, dass wiederum in das Projekt einfließt und dadurch den Entwicklungsprozess und das zu erstellende Produkt weiter zu verbessern hilft.



Prinzipien und Werte bilden ein System  ^

Jedes Prinzip und jeder Wert ist der Kopf einer eigenen Beeinflussungskaskade anderer Prinzipien und Werte, denn jede Wertänderung wirkt sich auf weitere Prinzipien und Werte, die auf ihnen aufbauen, aus. An vielen Stellen stehen die Prinipien und Werte sogar in direkter Wechselwirkung zueinander.

Aus diesem Grund müsste jede Wertänderung eines beliebigen Prinzips oder Wertes durch die Kaskadierung Wertänderungen aller anderen Prinzipen und Werte nach sich ziehen, so dass dieses System -- einmal angestoßen -- im Grunde nie wieder zur Ruhe kommen dürfte. Das ist in der Praxis jedoch nicht der Fall, da es sich bei den Abhängigkeiten und Wechselwirkungen um ein soziales, gedämpftes System handelt, dessen innere Wirkung sich von Ebene zu Ebene abschwächt.

Aus diesem Grund werden hier als Quellen und Ziele der wertändernden Beeinflussungen nur die jeweils direkten Addressaten angegeben und nicht diejenigen, die in einer tieferen Ebenen der jeweiligen Kaskade betroffen sind.

Sowohl die Definitionen der Prinzipien und der Werte und ihre jeweiligen Zusammenhänge, Beeinflussungen, bzw. Verknüpfungen oder Nicht-Verknüpfungen, können nicht den Anspruch von Vollständigkeit und Korrektheit erheben, da es sich um eine weitestgehend subjektive Sicht handelt. Man kann daher aus diesen oder jenen Gründen durchaus anderer Meinung sein (zumal die Auswahl und die Beziehungen zueinander aktuell auch noch nicht vollständig von mir kommentiert sind). Sollten Sie also anderer Meinung sein als ich, würde ich mich über einen diesbezüglichen Kommentar sehr freuen; recht vielen Dank!

Was aktuell noch vollständig fehlt, sind Darstellung und Beschreibung der Beeinflussung der Werte untereinander; dieser Teil befindet noch in der Analyse.


[zurück zum Seitenanfang]


, ,

No comments yet.

Schreibe einen Kommentar

V1710260636DE