Java 1 – Java 8: Von der Einfachheit zur Komplexität

Mit der zunehmenden Verbreitung agiler Softwareentwicklung steigt auch die Zahl der problematischen Projekte. Ziele wie eine schnelle Reaktionsfähigkeit auf Änderungswünsche werden nicht erreicht, obwohl (vordergründig) nach agilen Grundsätzen vorgegangen wird. In diesem Artikel fassen wir wiederkehrende Praxiserlebnisse in Form von Anti-Patterns zusammen und schildern, wie agile Entwicklung in vielen Fällen zu dogmatisch gelebt oder als Ausrede für schlechte Projektorganisation missbraucht wird. Diese so genannten Anti-Patterns ermöglichen dem Leser, eigene Projekte auf ähnliche Missstände zu prüfen und gegebenenfalls dagegen vorzugehen.

Bereits kleinere und mittlere Softwareprojekte unterliegen vielfältigen Einflüssen und erzeugen damit ein hohes Maß an Planungsunsicherheit. Noch bis weit in die Neunzigerjahre hinein wurde versucht, diesen Gegebenheiten mit strukturierten, phasenbasierten Vorgehensmodellen zu begegnen, die da

bei helfen sollten, eine zuvor definierte Menge von Anforderungen systematisch in ausführbare Software zu verwandeln. Erst langjährige und oft schmerzhafte Erfahrungen mit ins Stocken geratenen oder komplett fehlgeschlagenen Projekten ließen in Praxis und Wissenschaft die Erkenntnis reifen, dass die kontinuierlichen Wendungen und Überraschungen eines Softwareprojekts auch durch eine noch so gute Planung nicht aus der Welt zu schaffen sind. Entsprechend fanden in den letzten Jahren agile Vorgehensmodelle, die pragmatisch auf Änderungen reagieren, immer weitere Verbreitung. Dogmatisch oder schlicht falsch angewendete agile Prinzipien führen jedoch nach unseren Beobachtungen in der Praxis häufig zu altbekannten Problemen: Projekte geraten ins Stocken, sodass Entwicklungsorganisationen ihre Agilität im Wettbewerb um Aufträge und Kunden verlieren. Häufig treten dabei wiederkehrende Fehler („Anti-Patterns“) zu Tage, die wir in diesem Artikel näher beleuchten möchten, um mögliche Vermeidungsstrategien aufzuzeigen.

Grundideen agiler Entwicklung…

Agile Entwicklung ist ein Schlagwort, unter dem verschiedene „leichtgewichtige“ Ideen und Best Practices mit dem Ziel zusammengefasst werden, trotz Planungsunsicherheit auf dem Weg zum Projektziel zu bleiben. Das agile Manifest aus dem Jahre 2001 beschreibt einige grundlegende Ideen, die das Verständnis von agiler Entwicklung bis heute prägen. Es setzt bewusst Akzente auf nicht technische Aspekte wie Individuen und deren Interaktionen, die vor dem Hintergrund der bis dahin vorherrschenden wasserfallartigen Entwicklungsprozesse provokant erscheinen, bestätigt aber gleichzeitig den Wert etablierter Entwicklungspraktiken. Während das agile Manifest nur grundsätzliche Eckpfeiler definiert, gibt es mittlerweile zahlreiche agile Methoden und Entwicklungspraktiken, die Agilität praktikabel machen: Scrum ist wahrscheinlich das derzeit bekannteste Beispiel dafür, beschränkt sich im Wesentlichen aber auf Handlungsempfehlungen für das Projektmanagement. Es empfiehlt, die Systementwicklung in überschaubare Sprints zu untergliedern und den Projektfortschritt durch regelmäßige Überprüfungen transparent zu machen, um erkannte Probleme dynamisch zu beheben. Darüber hinaus gibt es Ansätze, die eher technisch orientierte Praktiken zur Softwareentwicklung beitragen, wie die testgetriebene Entwicklung aus Extreme Programming (XP).

Aber auch agile Methoden und Entwicklungspraktiken definieren keinen allgemeingültigen Standardprozess, der ohne Anpassungen für alle Organisationen und Projekte Verwendung finden könnte. Es sollte daher selbstverständlich sein, dass auch agile Methoden und die darin verwendeten Praktiken an den jeweiligen Kontext angepasst werden müssen.

…und was davon in der Praxis ankommt

Erste Erfolge in der Produktentwicklung zeigen sich bei der Anwendung von agilen Methoden in der Praxis meistens schnell: Iterative Entwicklung und frühe Releases liefern nach wenigen Wochen oder Monaten benutzbare Produktinkremente und machen Hoffnung auf eine dauerhaft hohe Entwicklungsproduktivität. Aber wie nachhaltig sind diese Fortschritte tatsächlich? Mittel- und langfristig macht sich vielfach Ernüchterung breit, wenn beispielsweise an einem System mehr weitreichende Refactorings durchgeführt werden müssen als neue Funktionalitäten integriert werden können. Selbst wenn agile Methoden vordergründig einfacher, leichtgewichtiger und weniger starr erscheinen als traditionelle Prozessmodelle, können sie doch unmöglich die gesamte Komplexität der Softwareentwicklung im Handumdrehen lösen. Insbesondere ihre großen Freiräume, die geeignet mit konkreten Entwicklungspraktiken gefüllt werden müssen, werden oft nicht erkannt, geschweige denn sinnvoll genutzt.

In zahlreichen Kooperationen und Gesprächen mit Firmen haben wir in den letzten Jahren verstärkt den Eindruck gewonnen, dass viele agile Werte und „Best Practices“ entweder zu dogmatisch ausgelegt oder aber bewusst ignoriert werden, was den mittel- und langfristigen Erfolg von Projekten in Frage stellt. Entsprechend sind heute viele Firmen innerhalb ihrer agilen Entwicklungsprojekte in Situationen gefangen, die ähnlich starr und unkontrollierbar geworden sind, wie es mit konventionellen Vorgehensmodellen der Fall gewesen ist.

Da sich die Ursachen und Symptome dieser Problematik oft über Organisationsgrenzen hinweg ähneln oder gar wiederholen, liegt die Verwendung des Begriffs „agiles Anti-Pattern“ auf der Hand. Wir möchten im Folgenden einige Anti-Patterns, die uns in Zusammenarbeit mit der Industrie in den letzten Jahren am häufigsten begegnet sind, sowie Lösungsmöglichkeiten dafür aufzeigen. Die Anti-Patterns lassen sich in zwei Kategorien unterteilen: Bei der „dogmatischen Agilität“ werden Prinzipien und Techniken der agilen Welt zu eng ausgelegt und sklavisch befolgt. Im Falle der „Ad-hoc-Agilität“ wird Agilität nur als Vorwand oder Ausrede genutzt wird, um ein planloses Vorgehen zu rechtfertigen.

Agile Anti-Patterns: Gesammelte Erlebnisse aus der Praxis

Erkannte Anti-Patterns dokumentieren wir mithilfe einer Struktur, die sich an das Anti-Pattern-Buch von Brown anlehnt und jedes Pattern mit einer kurzen Anekdote einleitet. Die dargestellten Beispiele sind bewusst pointiert beschrieben. Nichtsdestotrotz wurden wir vielfach in der Praxis damit konfrontiert und erleben beständig weitere Beispiele, wie langfristige Projekterfolge durch falsch verstandene agile Entwicklungspraktiken gefährdet werden und agile Teams nicht mehr in der Lage sind, sich eigenständig aus diesem Dilemma zu befreien.

Diese Anti-Patterns schleichen sich oft unbemerkt in die tägliche Projektpraxis ein, sodass die folgende Auflistung einen guten Ausgangspunkt für ihre Erkennung und Vermeidung bietet.

Anti-Pattern: Planungsverweigerung

Anekdote: Team: „Wenn jetzt demnächst noch die Integration mit dem zweiten Zahlungsdienstleister kommt, sollten wir das Paket my.payIntegration schon mal auf die Erweiterung vorbereiten.“ Scrum Master: „Das machen wir erst in dem Sprint, in dem wir das neue Feature auch tatsächlich umsetzen.“
Symptome und Auswirkungen: Durch einen stark verkürzten Planungshorizont wird vorhandenes Wissen über zukünftige Entwicklungen nicht in die aktuelle Planung einbezogen, weil es erst in einem späteren Sprint thematisiert werden „darf“. Mögliche Synergie- und Vorbereitungseffekte verpuffen und senken mittelfristig die Gesamtproduktivität sowie die Produktqualität. Das führt entweder zu enormen Refactoring-Aufwänden oder zu einer schnell erodierenden Architektur.
Hintergründe: Es werden nur genau die Anforderungen umgesetzt, die für den aktuellen Sprint notwendig sind, das weitere Product Backlog wird ignoriert. Eine Berücksichtigung von zukünftigen Anforderungen und eine entsprechende Planung über den aktuellen Sprint hinaus finden nicht statt.
Konkurrierende Kräfte: Dogmatische Entscheidungen vs. überschaubare Vorausplanung.

Anti-Pattern: Alles für den Kunden

Anekdote: Team: „Wir müssten im nächsten Sprint endlich einmal das Buchungssubsystem refaktorisieren. Wir haben damit immer mehr Probleme und die Transaktionen sind schnarchlangsam!“ Product Owner: „Dafür haben wir keine Zeit, wir müssen unbedingt Feature AB implementieren und ein Sprint ohne Generierung von Kundennutzen lässt sich mit der agilen Vorgehensweise nicht vereinbaren.“
Symptome und Auswirkungen: Von Iteration zu Iteration sinkende Produktivität und Qualität. Refactoring, Prototyping etc. werden „vergessen“, sodass nach einiger Zeit die Entwicklungsgeschwindigkeit deutlich zurückgeht und das Projekt mit beständig steigenden Änderungsaufwänden zu kämpfen hat.
Hintergründe: Was keinen direkten Kundennutzen bringt, wird nicht angegangen, jeder Sprint muss zwingend neue Kundenwünsche umsetzen. Releases an den Kunden werden unter Berufung auf agile Prinzipien in jedem Sprint eingeplant, was aber im Agilen Manifest gar so nicht gefordert wird. Eine falsche Anreizbildung innerhalb der Organisation führt ferner zur Unterpriorisierung interner Softwarequalität, wodurch später ein hoher Bedarf an Refactoring entsteht.
Konkurrierende Kräfte: Kurzfristige Priorisierung von Kundenwünschen vs. langfristige Softwarequalität (Abb. 1).

Abb. 1: Geschäftsnutzen ist mehr als kurzfristiger Kundennutzen: Er entsteht durch die Erzeugung von nachhaltigem Kundennutzen, der nur auf Basis eines wartbaren Systems geliefert werden kann

Anti-Pattern: Sprechender Code ist genügend Dokumentation

Anekdote: Team: „Unser Code ist gut strukturiert und dokumentiert sich selbst, wir brauchen keine weitere Dokumentation von Anforderungen, Architektur etc.“ Circa dreizehn Monate später: „Warum kommuniziert denn diese Komponente mit der anderen?“
Symptome und Auswirkungen: Der Quellcode ist sauber strukturiert und enthält sprechende Bezeichner, jedoch nur wenige bis gar keine Kommentare. Das „Wie“ ist damit meist aus dem Code ersichtlich. Das „Warum“, also die Begründung von Entwurfsentscheidungen, der Bezug zu Anforderungen u. Ä. sind jedoch nicht mehr aus dem Code rekonstruierbar.
Hintergründe: Die Dokumentationsartefakte werden auf das Minimum beschränkt, das zur Beantwortung von Fragen in der Initialentwicklung notwendig ist. Andere Blickwinkel (z. B. Wartung, Betrieb) werden ignoriert. Eine spätere Nachvollziehbarkeit von Entwurfsentscheidungen wird damit stark erschwert.
Konkurrierende Kräfte: Kurzfristiger Produktivitätsgewinn (durch eingesparte Dokumentationsaufwände) vs. langfristige Wartbarkeit (durch bessere Nachvollziehbarkeit).

Aufmacherbild: Agility, Dynamic, Adjust and Adapt Word Letter Tiles Game von Shutterstock / Urheberrecht: iQoncept

[ header = Seite 2: Anti-Pattern: Allzeit änderungsbereit ]

Anti-Pattern: Allzeit änderungsbereit

Anekdote: Management: „Der Kunde hat gerade eben gesagt, dass er das Feature für das neue Bezahlverfahren baldmöglichst haben möchte. Warum weigert sich das Entwicklungsteam, das Feature noch im aktuellen Sprint umzusetzen? Sie sind doch angeblich so agil.“
Symptome und Auswirkungen: Agile Entwicklungsprozesse werden von nicht agilen Akteuren mit einer überzogenen Erwartungshaltung bezüglich der Reaktionsfähigkeit auf Änderungswünsche verbunden. Die ohnehin schon kleinen Strukturierungs- und Planungseinheiten der Prozesse (z. B. Sprints) werden noch weiter aufgebrochen und bringen ständig Unsicherheit in die Entwicklerteams.
Hintergründe: Durch Einflüsse von Personen, die überzogene Erwartungen an agile Prozesse haben, sind selbst Sprintplanungen von wenigen Wochen nur schwer durchzuhalten. Das steht in krassem Widerspruch zur Idee agiler Entwicklungsprozesse, kurze, aber stabile und planbare Iterationen durchzuführen.
Konkurrierende Kräfte: Durch den Entwicklungsprozess vorgegebene Strukturen vs. Vorstellungen über Einflussmöglichkeiten auf die Entwickler.

Anti-Pattern: Unzuverlässigkeitsformel: Spontanität = Agilität

Anekdote: Management: „Ich benötige für den neu hereingekommenen Auftrag ab morgen zwei Mitarbeiter aus dem agilen Team, die bei dem neuen Kunden vor Ort eingesetzt werden können. Warum reagieren meine Entwickler mit Ablehnung? Die Mitarbeiter kommen doch in drei Wochen wieder in ihr Team zurück.“
Symptome und Auswirkungen: Mitarbeiter erleben Agilität als fortwährende, unvorhersehbare und kurzfristige Plan- und Verantwortlichkeitsänderungen. Folglich sind sie verunsichert, die Gesamtproduktivität sinkt und durch wechselnde Verantwortlichkeiten schleichen sich ein fehlendes Verantwortlichkeitsgefühl sowie Qualitätsmängel ein.
Hintergründe: Häufige ungeplante Ressourcenumverteilungen führen zu fehlender Verlässlichkeit. Entwickler benötigen (wenigstens bis zum Iterationsende) ein Mindestmaß an Planungssicherheit, ohne die keine dauerhaft produktive Arbeit möglich ist.
Konkurrierende Kräfte: Erwartungen des Managements vs. Planungssicherheit für die Entwickler.

Anti-Pattern: I believe in Miracles

Anekdote: Product Owner: „Wir haben zwar für die ersten dreißig Story Points sechs Monate gebraucht, aber wir dürfen das Budget nicht überziehen. Wenn wir uns alle ein wenig mehr anstrengen und etwas weniger Gold Plating machen, kriegen wir die restlichen dreißig Story Points leicht in den nächsten drei Monaten erledigt.“
Symptome und Auswirkungen: Trotz anderslautender Beobachtungen wird eine unrealistisch hohe Produktivität angenommen, die dann aber nicht erreicht werden kann. Das zeigt sich in immer wieder verfehlten Sprintzielen, auch die Fertigstellungskriterien für User Stories werden nur teilweise oder gar nicht erreicht.
Hintergründe: Die Produktivitätserwartungen stehen im Widerspruch zu den im Projekt ermittelten Werten und werden trotz eines beständig hohen Drucks durch die Projektverantwortlichen nicht erreicht. Die aus den kurzen Feedbackschleifen gewonnenen Erkenntnisse geraten immer wieder unter die Räder, weil man die Realität nicht wahrhaben möchte. Zudem dürfen auch kurzzeitige Produktivitätsschübe nicht zu überoptimistischen Schätzungen führen, da die langfristige Umsetzungsgeschwindigkeit deutlich von kurzzeitig erreichbaren Werten abweichen kann.
Konkurrierende Kräfte: Optimismus bzgl. Produktivität vs. empirisch erhobene Daten aus dem Projekt.

Anti-Pattern: Der „agile Ad-hoc-Prozess“

Anekdote: Team: „Wir sind agil, darum organisieren wir uns selbst und brauchen keinen Prozess. Wir sehen dann schon, wer spontan welche Features in diesem Sprint noch in das Release einbauen kann.“
Symptome und Auswirkungen: Entwicklerteams werfen (Sprint-)Ziele und Absprachen aus den täglichen Teammeetings selbstständig um und begründen dies mit ihrer Selbstorganisation. Vorgesehene Treffen (Stand-ups, Reviews, Retrospektiven) werden „agil“ verschoben. Agile Entwicklungsprozesse und Werte aus dem agilen Manifest werden in der Art interpretiert, dass möglichst viel Freiheit für die Entwickler und möglichst wenig Strukturen daraus resultieren.
Hintergründe: Oftmals sind sowohl Entscheider als auch Entwickler unzureichend über die tatsächlichen Hintergründe und Wirkungsprinzipien agiler Entwicklungsmethoden informiert. Das führt dazu, dass Entwickler ihre neu gewonnene Selbstverantwortung auszunutzen und auszubauen versuchen. Entscheider können häufig die Konsequenzen lange nicht abschätzen und erkennen resultierende Qualitätsprobleme erst sehr viel später.
Konkurrierende Kräfte: Strukturen und Verlässlichkeit vs. persönliche Freiheiten.

Diese sieben beispielhaft vorgestellten Anti-Patterns verdeutlichen, dass auch vermeintlich einfache agile Methoden leicht missverstanden und daher zu einem Risiko für den Projekterfolg werden können.

Weitere Anti-Patterns

Die vorgestellte Liste agiler Anti-Patterns ließe sich nach unseren Erfahrungen leicht um weitere Einträge ergänzen, die hier aus Platzgründen aber nur kurz angerissen werden sollen: Zu nennen ist sicher das Anti-Pattern „Contract as contract can“ als weitere Verletzung der agilen Prinzipien. Detaillierte Pflichtenhefte als Vertragsgrundlage zwischen Auftraggeber und Auftragnehmer führen bei diesem Pattern die iterative Anforderungserhebung ad absurdum. Beim „agilen Großprojekt“ wird aus dem Stand versucht, die mit einem Team erprobte agile Entwicklung ohne Anpassungen auf viele Teams zu übertragen, ohne negative Skaleneffekte zu berücksichtigen. Manchmal wird auch einfach nur „das schlechteste aus allen Welten“ übernommen, beispielsweise wird versucht, eine detaillierte Voraberfassung der Anforderungen mit detailliert geplanten Pseudoiterationen von bis zu sechs Monaten Länge zu kombinieren. Dies muss letztlich zu Planungsoverhead und den bekannten Notwendigkeiten für kurzfristige Änderungen führen. Ein ähnliches Problem haben Teams bei „Agilität unter voller Kontrolle“, wo das Management zwar ein agiles Vorgehen verlangt, gleichzeitig aber auf traditionellen Projektmanagementansätzen wie auf starren Projektplänen mit ausgewachsenem Änderungsmanagement besteht.

Zusammenfassung und Empfehlungen für die Praxis

Tabelle 1 stellt einen zusammenfassenden Überblick über die im Detail vorgestellten Anti-Patterns sowie mögliche Lösungsvorschläge dar. Sie bietet sich auch als Grundlage für eine Checkliste an, die beispielsweise in Retrospektiven Verwendung finden kann, wenn ein längerer Produktivitätsrückgang nicht anderweitig aufgeklärt werden kann. Im Anschluss an die Tabelle diskutieren wir, welche Schlussfolgerungen aus ihr für die Entwicklungspraxis gezogen werden sollten.

Kategorie Anti-Pattern Leitspruch Verursacher Lösungsvorschlag
Dogmatische Agilität Planungsverweigerung Wir planen nur von Sprint zu Sprint! Product Owner oder Scrum Master Verwendung der vorgesehenen Pläne (z. B. Releaseplan), aber wo nötig auch eines Architekturplans
Alles für den Kunden Jeder Sprint muss den Customer Value erhöhen! Product Owner Durchführung von Refactoring-Zyklen und ggf. Vorausplanung der Architektur
Sprechender Code ist genügend Dokumentation Guter Code dokumentiert sich selbst! Äußerer Druck, aber auch das Entwicklerteam selbst Entwurfsentscheidungen wo nötig dokumentieren
Gefühlte Agilität
(fließender Übergang zwischen Laissez faire und Nichtverstehen)
Allzeit änderungsbereit Auf alle Wünsche des Kunden ist sofort zu reagieren! Vor allem Management und Product Owner Einhaltung geschützter Sprints und der Anforderungspriorisierung; der Product Owner spielt Kundenwünsche in das Product Backlog und nicht in den laufenden Sprint
Unzuverlässigkeitsformel: Spontanität = Agilität Agile Teams müssen auch mit spontanen Organisations-änderungen umgehen können! Management Schaffung eines geschützten Raums für agile Teams, zumindest innerhalb eines Sprints
I believe in Miracles Wir schaffen das, wenn wir uns nur genug anstrengen! Product Owner, Management Akzeptieren der empirisch ermittelten Entwicklungsgeschwindigkeit
Der agile Ad-hoc-Prozess Das Team organisiert sich selbst und löst Probleme spontan! Scrum Master, Product Owner, aber auch das Entwicklerteam Erstellung einer Sprintplanung und Einhaltung der getroffenen Absprachen

Tabelle 1: Zusammenfassung der Anti-Patterns mit Lösungsvorschlägen

Praxiserprobte Leitlinien agiler Entwicklung

Abbildung 2 illustriert schematisch, wie sich dogmatische und gefühlte Agilität im Gestaltungsspielraum des Agilen Manifests wiederfinden. Definierte Methoden wie Scrum oder XP nutzen diesen Spielraum, um einen methodischen Rahmen zu definieren. Sie lassen aber gleichzeitig noch viele Möglichkeiten zur Auswahl konkreter Praktiken offen. Im dogmatischen Fall wird hingegen eine zu enge Interpretation gelebt, die sich buchstabengetreu an Beschreibungen in der Literatur orientiert und auch gegenüber sinnvollen Anpassungen ablehnend bleibt. Im Falle der gefühlten Agilität wird oftmals ad hoc entschieden und reagiert, ohne agile Praktiken anzuwenden. Stattdessen beruft man sich auf die „bequemen“ Seiten des Agilen Manifests, hält Prozesse, Architektur, Dokumentation etc. außen vor und versucht das entstehende „kreative Chaos“ als agile Entwicklung zu rechtfertigen.

Abb. 2: Interpretation des agilen Manifests

Eine dogmatische Auslegung von Agilität ist offensichtlich ebenso schädlich für die Produktivität wie die Verwendung des Labels „agil“ für nicht vorhandene Planung und ein Ad-hoc-Vorgehen. Auch wenn es der Begriff „agil“ Manchem zu suggerieren scheint: Er bedeutet keinesfalls die Abschaffung jeglicher Planung. Zusammenfassend möchten wir unseren Lesern daher einige Leitlinien für eine erfolgreiche Anwendung agiler Methoden mit entsprechenden Anwendungsbeispielen mit auf den Weg geben (Tabelle 2).

Leitlinie Beispiel
Richtig eingesetzt führen agile Entwicklungsmethoden zu mehr Agilität (aber nicht zu Wundern). Lieferbare Einheiten bei Iterationslängen von zwei Wochen ermöglichen früheres Feedback, die gesamte Entwicklungszeit wird sich aber nicht verkürzen.
Agilität bietet viele Freiräume, die sinnvoll genutzt werden wollen. Die Dauer von Sprints kann in gewissen Grenzen ebenso angepasst werden wie ihr Inhalt (z. B. für Refactoring).
Agilität verkraftet so wenig Planung wie möglich, aber keinesfalls weniger. Im Sprint-Planning-Meeting sollte eine explizite Vorausschau auf künftige Anforderungen aufgenommen werden.
Ausreichend Erfahrung und Verständnis für Software Engineering im Allgemeinen und Teamdynamik im Speziellen sind auch bei der Verwendung von agilen Methoden zwingend erforderlich. Kenntnisse von Entwurfsmustern, Softwarearchitektur, Projektplanung etc. sollten bei allen Teammitgliedern vorhanden sein.
Auch agile Entwicklungsmethoden benötigen einen wohldosierten Einsatz von Engineering-Praktiken (wie die Verwendung und Dokumentation einer tragfähigen Architektur), die auf den jeweiligen Kontext und die Anforderungen zugeschnitten werden müssen. Auch in agilen Projekten dürfen die Entwurfsprinzipien einer Architektur (wie Schichten und Zugriffsregeln) Verwendung finden; Begründungen für wichtige Entwurfsentscheidungen sollten dauerhaft dokumentiert werden.

Tabelle 2: Leitlinien agiler Entwicklung mit Praxisbeispielen

Unter Beachtung dieser Leitlinien lassen sich agile Entwicklungsmethoden erfahrungsgemäß auch nachhaltig gewinnbringend einsetzen. Das Einschleichen von Anti-Patterns bleibt aber nach wie vor eine nicht zu unterschätzende Gefahr, auf die Projekte regelmäßig, zum Beispiel in den Retrospektiven, untersucht werden sollten. So lassen sich mittel- und langfristig Produktivitätsverluste vermeiden und es kann über Jahre hinweg eine gleichbleibend hohe Softwarequalität an den Kunden geliefert werden, ohne die Entwickler auszubrennen und in den altbekannten Teufelskreis aus nachlassender Produktivität und ansteigendem Stressniveau fallen zu lassen.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.