TopMenue

16. Jederzeitige Veränderung der Anforderungen

Dieser Beitrag befindet sich noch in Bearbeitung!

Veränderung ist Teil unserer Natur und daher auch in einem Projekt unausweichlich. Sie zu jeder Zeit zu erwarten, sie zu begrüßen und zeitnah zu berücksichtigen, ist das Kernprinzip agiler Softwareentwicklung und ermöglicht optimale Projektergebnisse für alle Beteiligten

Vollständige Planung ist ein Mythos  ^

Komplexe Problemstellungen unter Zuhilfenahme der Organisationsform „Projekt“ zu lösen, ist ein sehr aufwändiger Prozess, der im Laufe seiner jeweilgen Existenz vieler und zum Teil nicht vorhersehbarer Entscheidungen bedarf. Im Zuge der Realisierung solch einer Lösung werden sich nicht nur für das Projektteam, sondern auch für die Stakeholder viele neue große wie kleine Erkenntnisse, Erfahrungen, Gedanken, Wünsche, Erfolge, Ideen, Pleiten und Pannen ergeben haben, die mit hoher Wahrscheinlichkeit dazu führen werden, dass sich die Sicht auf die ursprüngliche Problemstellung und ihre mögliche Lösung verändern wird. Diese veränderte Sicht wird mit ebenso hoher Wahrscheinlichkeit Auslöser und Grundlage für eine Veränderung der ursprünglichen Ziele des Projektes und der Lösung sein, potenziell sogar in signifikanter Weise.

Das Ziel ist nicht irgendeine, sondern die optimal erzielbare Lösung  ^

Bei dem Weg zu einer möglichst optimalen Lösung im Rahmen der vorgegebenen Ressourcen — und nicht weniger erwarten die Auftraggeber — handelt sich daher nicht um einen Durchmarsch vom Kickoff bis zur Endabnahme, sondern um ein zyklisches Näherungsverfahren, das dem Projektteam die außerordentliche Chance gibt, den Auftraggebern nicht irgendeine der vielen möglichen Realisationsvarianten zur Lösung ihrer Anforderung zu liefern, sondern die eine Lösung, die im Hinblick auf Rahmenbedingungen wie, Zeit, Budget, Geduld und Fragen der Verfügbarkeit von Ressourcen (z.B. des Projektteams), etc., die optimal mögliche Lösung darstellt.

Chancen erkennen und nutzen  ^

Die Chancen, die sich daraus ergeben, zu erkennen, ist das eine, sie dann auch zu nutzen, ist dann noch einmal etwas ganz anderes. Sie zu nutzen, bedeutet zum einen, zu akzeptieren, dass während des Realisationsprozesses jederzeit Veränderungen auftreten können und mit hoher Wahrscheinlichkeit auch auftreten werden und zum anderen, diese Veränderungen dann auch zeitnah im Projekt und im Lösungsweg zu berücksichtigen. Das bietet die Chance, ein besseres, optimal auf den jeweils wirklichen Bedarf der Auftraggeber ausgerichtetes Produkt zu erstellen und ihnen damit das Erreichen des für sie höchstmöglichen Wertschöpfungspotenzials zu ermöglichen.

Die Schlüssel sind der Product-Owner und die Stakeholder  ^

Der Product-Owner und die Stakeholder führen das gesamte Projekt über permanent die Anforderungsanalyse, bzw. das Anforderungsmanagement durch. In der Anforderungsanalyse erarbeiten der Product-Owner und die Stakeholdern gemeinsam die Anforderungen, die sie eindeutig priorisieren und in das Product-Backlog eintragen. Zum Abschluss sortiert der Product-Owner das Product-Backlog absteigend nach der Priorität, sodass die für die Stakeholder wichtigsten und wertvollsten Anforderungen immer ganz oben am Anfang des Product-Backlogs zu finden sind.

Einen Teil der höchstpriorisierten Anforderungen werden im folgenden Sprint realisiert. Hierfür wählt der Product-Owner eine Anzahl der höchstpriorisierten Anforderungen aus, und stellt sie dem Entwicklungsteam zu Beginn der ersten Phase des Sprint-Plannings vor. Das Entwicklungsteam legt im Verlauf des Sprint-Plannings die konkrete Menge der zu realisierenden Anforderungen auf Basis der vorgeschlagenen Liste fest. Während des Sprints führen Product-Owner und Stakeholder intensiv die permanente Anforderungsanalyse fort und ergänzen das Product-Backlog um weitere Anforderungen. Am Ende des Sprints erhalten die Stakeholder nach erfolgter Abnahme durch den Product-Owner das aktuelle Produktinkrement, in dem realisierten Anforderungen vollständig fertig umgesetzt enthalten sind.

Nicht vollständig fertig realisierte Anforderungen werden, genauso wie in der Abnahme zurückgewiesene Anforderungen, nicht in das Produktinkrement übernommen, sondern in das Product-Backlog zurückgestellt und mit ihrem originalen Schätzwert (zwar wurde eine Leistung erbracht, die aber in den aktuellen Sprint nicht eingeflossen sind) in die Planung eines folgenden Sprints übernommen.

Nun begutachten die Stakeholder, ggf. gemeinsam mit dem Product-Owner, das Produktinkrement und stellen vielleicht fest, dass sich in der Zwischenzeit die Sicht auf einige fachliche Sachverhalte verändert hat und wieder einige andere der Anforderungen in der realisierten Form zwar korrekt erstellt wurden, sie aber aufgrund der veränderten Sicht nicht mehr die optimale Lösung darstellen. Der Product-Owner nimmt daher neben einigen Neuanforderungen auch die Änderungsanforderungen jeweils individuell priorisiert in das Product-Backlog auf.

Ähnlich verhält es sich, wenn bereits realisierte Anforderungen vielleicht wieder überflüssig geworden sind und entfernt werden sollen. Sie werden ebenfalls priorisiert und auch in diesem Fall als Änderungs-Anforderung in das Product-Backlog aufgenommen.

Diese Änderungsanforderungen werden selbstverständlich genauso gehandhabt, wie neue Anforderungen, d.h., sie werden im Sprint-Planning / Refinement-Meeting besprochen, geschätzt, priorisiert und zu gegebener Zeit in das jeweilige Sprint-Backlog aufgenommen.

Chancen und Risiken der Veränderung  ^

Entscheidend ist, dass sich alle Beteiligten der Chancen und Risiken dieses Verfahrens bewusst sind und verantwortungsvoll damit umgehen.

  • Das Projektteam muss sich der Herausforderung potenziell permanent zu erwartender Veränderungen stellen und sie offen annehmen; ja, sie sogar als unausweichlich erwarten und annehmen.
  • Die Stakeholder müssen die darin liegenden Chancen, aber auch die Risiken erkennen und ebenfalls verantwortungsbewusst damit arbeiten.

Natürlich hat auch die Medaille „Veränderungen annehmen und begrüßen“ mehrere Seiten, die man sich vergegenwärtigen muss, um mit den Chancen und Risiken, die sich aus dem Verfahren ergeben, umgehen zu können.

Vorgehen klassischer Softwareentwicklungsprozesse  ^

In den klassischen Softwareentwicklungsprozessen wird

  1. im Vorfeld des Projektes die Anforderungsanalyse durchgeführt,
  2. der Projektplan erstellt,
  3. das Projekt gestafft,
  4. das eigentliche Softwareentwicklungsprojekt gestartet und
  5. der Projektplan vom Anfang bis zum Ende abgearbeitet (Hauptphase), dann
  6. das Produkt an die Stakeholder ausgeliefert.

Eventuelle Änderungen und Ergänzungen am Anforderungsset, die den Ablauf des Projektplans behindern, verändern oder gar verzögern könnten, werden im Laufes des Projektes, wo immer dies möglich ist, beiseite geschoben und/oder auf später in weitere Entwicklungsphasen verschoben. Ist dies nicht möglich und sind damit Änderungen am Projektplan unausweichlich, verzögert sich das Projekt und damit der Auslieferungstermin, da der Projektplan aktualisiert und das Projekt ab einem gewissen Punkt in Teilen neu aufgesetzt werden muss.

Am Ende des Projektes wird das fertig gestellte Produkt an die Stakeholder ausgeliefert und nun können sie es prüfen, testen und Feedback liefern. Die sich aus dem Feedback ergebenden Korrekturen werden i. a. in einer folgenden Korrektur- / Stabilisierungsphase realisiert.

Die entlang des Hauptprojekts aufgenommenen Änderungs- und Ergänzungswünsche, die in die späteren Projektphasen verschobenen wurden, werden nach dem Abschluss des Hauptprojekts und der Korrekturphase in einer oder mehreren weiteren Projektphasen mit eigenen Projektplänen und eventuell sogar anderen Mitarbeitern realisiert. Eventuell werden die Korrektur- und die Erweiterungsphase(n) auch miteinander verschmolzen.

Die Integration neuer Anforderungen in das auf Basis des ursprünglichen Projektplanes fertig gestellten Produktes ist zu diesem Zeitpunkt zumeist nur noch unter hohem Aufwand und hohen Risiken (Auftreten von Seiteneffekten durch den zu integrierenden Code) möglich, da die notwendigen Änderungen zu diesem späten Zeitpunkt i.A. nicht mehr als einfache Zusätze realisiert werden können, sondern zumeist tief in die i.A. bereits sehr komplexe und in sich abgeschlossene Codebasis des Projektes eingearbeitet werden müssen. Hierbei dürfen auch in den weiteren Phasen nicht nur die neu zu realisierenden und zu integrierenden Funktionalitäten der jeweils aktuellen Anforderungen im Mittelpunkt stehen, sondern darüber hinaus auch, dass sowohl die Funktionalität, als auch die Qualität der bereits im Produkt fertig realisierten Anforderungen gewährleistet bleiben müssen!

Neue Anforderungen im Nachhinein phasenweise jeweils in ein bereits fertig gestelltes, potenziell sehr komplexes Softwareprodukt einzuarbeiten, ist daher weitaus aufwändiger und mit wesentlich höheren Risiken verbunden, als, die neu hinzukommenden Anforderungen frühzeitig im laufenden Entwicklungsprojekt zu berücksichtigen!

Vorgehen agiler Softwareentwicklungsprozesse  ^

In den agilen Prozessen ist die Anforderungsanalyse ein permanenter, das gesamte Projekt begleitender Prozess

  • Alle Anforderungen der Stakeholder werden in der Liste der zu realisierenden Anforderungen, das Produkt-Backlog, aufgenommen, eindeutig priorisiert, in der Reihenfolge ihrer Priorität sortiert.
  • Zu gegebener Zeit werden sie in kurzen, sich permanent wiederholenden Zeitabschnitten, den Sprints vollständig fertig und abschliessend realisiert und
  • am Ende jedes Abschnittes den Stakeholdern in Form eines aktuellen Produktinkrements zur Begutachtung und Prüfung übergeben.
  • Die Stakeholder begutachten und prüfen das ihnen übergebene Produktinkrement und liefern jeweils ihr Feedback zurück ins Projekt.
  • Die sich ergebenden Änderungen, Ergänzungen und Korrekturen werden wieder priorisiert,
  • in die Liste der zu realisierenden Anforderungen, dem Produkt-Backlog, integriert und sortiert und
  • zeitnah innerhalb der folgenden Zeitabschnitte realisiert.

Da alle Anforderungen, egal ob neue Anforderungen, Änderungen, Ergänzungen oder Korrekturen in die Liste der Anforderungen aufgenommen und priorisiert und einsortiert werden, ist das Projekt beendet, wenn entweder alle diese Anforderungen realisiert wurden oder die Stakeholder das Projekt beenden.

Anforderungen frühzeitig im laufenden Entwicklungsprojekt zu berücksichtigen ist daher viel einfacher, schneller und sicherer durchzuführen, als, sie im Nachhinein phasenweise jeweils in ein bereits fertig gestelltes und potenziell sehr komplexes Softwareprodukt einzuarbeiten!

Eine weitere Seite der Medaille: Die Handhabung der Veränderung an sich.
Das Platzen der IT-Blase Anfang dieses Jahrtausends wurde nicht zuletzt auch dadurch hervorgerufen, dass sich IT-Berater / -Projektverkäufer und ihre Kunden an den sich aufzeigenden Möglichkeiten der IT, insbesondere denen des Webs, nicht nur berauschten, sondern sich gegenseitig zu immer neuen und zu einem guten Teil an den realistisch vorhandenen Möglichkeiten vorbeigehenden Höhenflügen anstachelten. Daraus ergab sich, dass ihnen allzu oft der Blick für das Wünschenswerte und das dazu in einem guten Verhältnis stehende Machbare und Nutzbringende z.T. vollständig abhanden kam; freundlich formuliert kann man sagen, dass mit ihnen einfach die Pferde durchgingen.

Aus diesem Grund verpflichtet Scrum den Product-Owner dazu, Augenmaß zu wahren und verantwortungsvoll darauf zu achten, dass diese Werte (Anforderungen und Möglichkeiten) für seine Kunden in einem guten und realistischen Verhältnis zueinander stehen. Versteht er es jedoch so, dass das Prinzip der Veränderung ein tolles Instrument zur Verlängerung eines jeden Projektes ist (ohne dies irgendeinem Product-Owner unterstellen zu wollen), handelt er nicht mehr im Sinne seiner Kunden, denn nicht jede Idee ist eine gute Idee, nur weil sie eine neue Idee ist oder weil sie den allerneuesten Technologie-Hype berücksichtigt. Es ist die Aufgabe des Product-Owners, beide Gruppen, mit denen er kommuniziert (Entwickler und Stakeholder) und zwischen ihnen steht und vermittelt, dahin zu bringen, die für den jeweiligen Bedarf optimalen Ansprüche, bzw. Lösungen zu favorisieren und nicht die jeweils –- pardon — geilsten.

Risiko und Chancen liegen aber auch bei den Stakeholdern selbst. Dass sie jederzeit Änderungen an ihrem Anforderungsset vornehmen können, gibt ihnen die großartige Chance, das Produkt zu erhalten, das sie wirklich brauchen und nicht etwa das Produkt, das sie irgendwann zu Beginn des Projektes zu brauchen glaubten. Er muss sie, ggf. mit Unterstützung des Scrum-Masters, davon überzeugen, bzw. sie dazu animieren, sich ernsthaft, verantwortungsbewusst und auch selbstkritisch Gedanken über die eigenen Notwendigkeiten, Bedürfnisse und Möglichkeiten zu machen, statt ungehemmt nach dem Motto, „was soll der Geiz und das kostet ja auch nix„, alles Mögliche unreflektiert haben zu wollen und auszuprobieren, denn geleistete Aufwände (auch solche, die in die Irre führten) erzeugen Kosten — und müssen bezahlt werden.

Fazit  ^

Die Chancen in dem Prinzip der jederzeit möglichen Veränderung liegen also darin, schneller und preiswerter zum besseren, bzw. zum optimalen Produkt zu kommen. Die Risiken liegen darin, es unreflektiert und unbedacht gegen sich selbst und seine Interessen zu richten. Die Verantwortung dafür tragen alle am Projekt Beteiligten, sowohl Entwickler und Scrum-Master, als auch der Product-Owner und auch insbesondere die Stakeholder selbst.

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