Mein Name ist Russ Martin und ich benutze Mendix fast drei Jahre lang als Senior Software Engineer bei Erie Insurance. Wir haben die Mendix Plattform, um mehrere Projekte abzuschließen und waren sehr erfolgreich. Ich möchte die Schwierigkeiten und Schwierigkeiten teilen, die wir erlebten, als wir versuchten, unseren Fokus von einem Wasserfall auf Agile Projektmethodik, zusammen mit einigen Tipps, wie Sie diese überwinden können.

Agile in einem Wasserfall-Team einführen

Wie Sie sich vorstellen können, wenn man das erste Mal das Konzept der agilen, wird Ihr Wasserfallteam zunächst zögern und besorgt sein. Das ist zu erwarten, da Veränderungen für viele Menschen schwierig sind, insbesondere wenn es um die Umstellung auf etwas so Anderes geht. Die beiden größten Hürden waren unserer Meinung nach die Einführung der Konzepte der iterativen Entwicklung und der fortlaufenden Anforderungen.

In vielen Organisationen mit Wasserfallmodellen besteht der allgemeine Trend darin, das gesamte Projekt zu entwerfen und zu planen, bevor mit der Entwicklung begonnen wird. Wenn Sie mit Wasserfallmodellen vertraut sind, wissen Sie, dass dies monatelange Anforderungserfassungs- und Designsitzungen erfordert, bevor ein Team überhaupt mit der Arbeit am Code beginnen kann. Dies führt auch zu einer Trennung zwischen den Disziplinen, da nicht das gesamte Team an diesen Sitzungen beteiligt ist und außerdem ein Wissenstransfer erforderlich ist. Dieser Prozess verursacht einen hohen Mehraufwand und wird ziemlich zeitaufwändig. Ein agiler Prozess ist im Vergleich zu Wasserfallmodellen eine komplette Kehrtwende. Wenn man versucht, die Denkweise der Leute so zu ändern, dass sie gegen all ihre vorherige Ausbildung und Erfahrung verstoßen, wird es Befürchtungen geben. Das ist normal und zu erwarten.

Ein agiler Prozess ist im Vergleich zum Wasserfallmodell eine komplette Kehrtwende. Bedenken hinsichtlich dieser Änderung sind zu erwarten, sogar normal.

Um dieses Problem zu lösen, habe ich festgestellt, dass es hilft, den Menschen die Vorteile der agilen Methodik zu zeigen, um ihren Wert zu erkennen. Beginnen Sie mit der Arbeit an einem kleinen Proof of Concept. Nehmen Sie einen kleinen Teil Ihrer Anwendung oder einen, dessen Ersetzung voraussichtlich viel Zeit in Anspruch nehmen wird, und sehen Sie, was Sie innerhalb weniger Wochen erreichen können. Beziehen Sie mindestens eine Person aus Ihren verschiedenen Disziplinen ein – Business Analyst, Software Engineer, Qualitätssicherung usw. Der Grund dafür ist, dass Sie Menschen mit unterschiedlichen Perspektiven an Ihrer Seite brauchen, um diese Art von Veränderung zu beeinflussen. Wenn Sie mehrere Personen dazu bringen können, die neue Methodik zu verstehen, ist es viel einfacher, den Rest der Organisation an Bord zu holen. Nutzen Sie außerdem das Fachwissen der Mendix Team. Sie haben Erfahrung im Umgang mit dieser Art von Kulturwandel. Indem Sie eine externe Person zur Verfügung haben, die Ihnen bei der Beantwortung von Fragen hilft, schaffen Sie eine zusätzliche Ebene des Verständnisses, die die Akzeptanz fördert.

Der Schlüssel zu diesem Proof of Concept: TEAMARBEIT! Sie werden mit Sicherheit einen harten Kampf vor sich haben. Sie müssen Ihr Team an einer Sprint-Zero-Übung teilnehmen lassen. Dabei werden sie einige Geschichten zusammenstellen, um zu entscheiden, was sie von der Benutzeroberfläche sehen wollen. Durch die Einbeziehung aller Teammitglieder werden sie stärker in das Ergebnis involviert sein. Sie werden das Gefühl haben, im Prozess mitreden zu können. Ich kann nicht genug betonen, wie wichtig dies auf lange Sicht ist. Die Umstellung von einem dokumentationsintensiven Prozess auf einen Story-Card-Ansatz ist für viele, die die Wasserfallmethode anwenden, ein fremdes Konzept. Seien Sie auf Widerstand Ihrer Teammitglieder vorbereitet, das ist normal. Denken Sie einfach daran, dass dieser Proof of Concept eher ein Experiment, eine Trainingsübung ist. Es ist kein vollwertiges Projekt, das in Produktion gehen wird, was dazu beiträgt, die Bedenken vieler Skeptiker zu zerstreuen. Denken Sie einfach aus Entwicklerperspektive daran: Wenn dies das Projekt ist, das Sie langfristig verwenden möchten, dann ist dies Ihre Chance, den Grundstein für das gesamte Projekt zu legen und sich in Zukunft Zeit zu sparen.

Die meisten Leute übertreiben es mit der Planung, bevor sie überhaupt angefangen haben. Bauen Sie einen Ford, bevor Sie auf einen Mercedes Benz umsteigen.

Ein Konzept, das wir verwendeten, um zu verdeutlichen, was wir zu tun versuchten, war dieses: „Wir brauchen keinen Mercedes Benz, um von Punkt A nach Punkt B zu kommen. Wir müssen nur dorthin gelangen. Also entwickeln wir den Ford. Sobald wir auf der Straße sind, können wir uns auf die Upgrades konzentrieren, die wir in unserem Fahrzeug haben möchten.“ Das war ein nützliches Konzept, denn die meisten Leute wollen das fertige Produkt. Sie wollen schon viel mehr designen, bevor sie überhaupt angefangen haben. Wenn Sie in kleinerem Maßstab beginnen, können Ihre Entwickler den „Pinto“ entwickeln, ein minimal funktionsfähiges Produkt, das die Aufgabe erfüllt. Dann zeigen Sie, wie schnell Sie Ihr Fahrzeug zum „Cadillac“ aufrüsten können, einem vollwertigen Produkt mit erweiterten Funktionen und Merkmalen. So können Ihre Benutzer in den Pinto einsteigen und Feedback geben, wonach Sie ihnen zeigen können, wie einfach es ist, diese neuen Funktionen zu entwickeln.

Umstellung auf Projektarbeit

Vorausgesetzt, der Proof of Concept ist gut verlaufen und Sie haben jetzt grünes Licht für das gesamte Projekt, können Sie sich einige Elemente ansehen, die Sie in Ihr Projekt integrieren können, um den Übergang zu erleichtern.

Aus Sicht eines Business Analysten und einer Qualitätssicherung gibt es mehrere Dinge, die Sie nutzen können, um den Verständnisprozess weiter zu fördern. Wir haben festgestellt, dass „Amigos-Sitzungen“ zu Beginn äußerst hilfreich sind. Bei einer Amigos-Sitzung treffen sich Entwickler, Analysten und Tester spontan, um die für einen bestimmten Sprint zugewiesenen Karten zu überprüfen. Auf diese Weise können sich alle Teilnehmer darüber einig werden, was für jede Karte entwickelt wird, und es besteht die Möglichkeit, spezifische Fragen zur Arbeit zu stellen. Diese Besprechungen sollten informell sein und in einem Ad-hoc-Format vor der Entwicklung stattfinden. Wenn die Entwicklung abgeschlossen ist, halten Sie eine weitere Amigos-Sitzung ab, um die fertige Codierung zu überprüfen. Auf diese Weise kann jeder die Arbeit überprüfen, während sie abgeschlossen wird. Gleichzeitig haben die Entwickler die Möglichkeit zu zeigen, wie schnell sie sich auf Elemente einstellen können, die geändert werden müssen. Beispielsweise weist ein Analyst in einer abschließenden Amigos-Überprüfung auf eine fehlende Anforderung hin. Dadurch kann der Entwickler die Änderung sofort vornehmen und den korrigierten Code auf dem Bildschirm anzeigen. So kann er den Teammitgliedern die Anpassungsfähigkeit der Codebasis und die schnelle Reaktionszeit auf Änderungsanforderungen beweisen. Dies hilft anderen dabei, zu verstehen, was Sie mit der Plattform tun können. Es ist nicht beabsichtigt, diese Vorgehensweise für immer fortzusetzen. Zunächst sollten die Amigos-Überprüfungen stattfinden, bis sich alle mit dem neuen Prozess wohl fühlen. Ab diesem Zeitpunkt sollten Sie diese Technik nur noch am Ende der Story-Card-Entwicklung einsetzen müssen.

Aus Sicht der Qualitätssicherung liegt der Hauptvorteil von Agile in der testgesteuerten Entwicklung.

Aus Sicht der Qualitätssicherung ist der Hauptvorteil von Agile die testgetriebene Entwicklung (TDD). TDD ist ein in der IT-Community bekannter Prozess. Durch die Verwendung der Unit-Test-Modul erhältlich in der Mendix App Store, Entwickler können mehrere Unit-Tests erstellen, die an jeden Entwicklungssprint gebunden sind. Mit dem Unit-Test-Modul können Sie außerdem bei jedem Deployment Berichte ausführen, die zeigen, ob Unit-Tests erfolgreich waren oder nicht (und Ihnen als Entwickler helfen, sicherzustellen, dass Sie keinen neuen Defekt verursacht haben). So kann das QA-Team sehen, dass der Code stabil ist und dass zuvor getesteter Code noch funktioniert. Natürlich werden sie ihre eigenen Tests durchführen wollen, wie sie es sollten. Aber diese Methode wird ein gewisses Verständnis dafür vermitteln, dass die Codebasis nicht mit jedem abgeschlossenen Sprint verschlechtert wird. Das ist wichtig, weil sie nach einem iterativen Zeitplan testen werden, statt einmal am Ende eines Projekts. Alles, was Sie tun können, um ihnen zu zeigen, dass ihre Testbemühungen nicht umsonst waren, ist auf lange Sicht ein großer Gewinn.

Aus der Sicht eines Entwicklers haben wir festgestellt, dass Codeüberprüfungen für den Erfolg eines jeden Projekts von entscheidender Bedeutung sind. Die Begründung dafür ist einfach: Je mehr Augen den Code überprüfen, desto geringer ist die Fehlerwahrscheinlichkeit. Dies hilft auch bei der Implementierung von Codierungsstandards und -prozessen für Entwickler, die alle Teammitglieder nutzen können. Wenn Sie sehen können, was andere getan haben, um die Codierung effizienter zu gestalten, können Sie Ihre Markteinführungszeit verkürzen. Es wird auch bei Leuten von großem Nutzen sein, die sich nur langsam an Agile gewöhnen. Warum? Weil sie wissen, dass Sie alles tun, um sicherzustellen, dass Ihr Team soliden Code erstellt, und dies dazu beiträgt, die Anzahl der im System gefundenen Fehler zu verringern. Je weniger Fehler Sie entwickeln, desto besser wird Ihr Team mit diesem neuen agilen Ansatz umgehen.

Was ist mit dem Management?

Das Management kümmert sich nicht um die Details der Teamentwicklung und das sollte es auch nicht. Es kümmert sich mehr um Ressourcen, Geschwindigkeit und Qualität. Wie können wir ihnen also etwas Konkretes bieten, um zu zeigen, dass wir ein großartiges System entwickeln, das leicht zu warten ist? Ich empfehle dringend die Verwendung des Mendix Tool für Qualitäts- und Sicherheitsmanagement.

Wir konnten Kennzahlen des Systems bereitstellen, bevor wir Änderungen an der Codebasis vornahmen. Auf diese Weise konnten wir leicht zeigen, dass eine Idee, die wir umsetzen wollten, einen Mehrwert bot, indem sie unseren AQM-Score erhöhte.

AQM nutzt die McCabe-Komplexität, indem es den festgeschriebenen Code in Ihrem Repository scannt, um eine Bewertung auf einer Skala von 1 bis 5 zu ermitteln. Für diejenigen, die mit der McCabe-Komplexitätsmessung nicht vertraut sind: Es handelt sich um eine Softwaremetrik, mit der die Komplexität eines Programms angegeben wird. Das AQM-Tool unterteilt Ihre Codebasis in acht verschiedene Kategorien. Diese Kategorien sind auch aus Entwicklungsperspektive sehr hilfreich. Sie ermöglichen es Ihnen zu erkennen, dass Ihr Team Elemente erstellt, die nicht zu komplex und leicht zu warten sind. Dies ist auch bei der Einarbeitung neuer Entwickler hilfreich. Das Team kann so erkennen, über welches Verständnisniveau der Entwickler verfügt, und Sie können leicht darauf hinweisen, wo er möglicherweise falsch programmiert hat. Dies bietet die Gelegenheit, ihnen die richtige Art und Weise beizubringen, Mikroflüsse basierend auf den Standards Ihres Unternehmens zu strukturieren.

Und was ist mit dem Management? Wir alle wissen, dass das Management kurze, prägnante und auf den Punkt gebrachte Berichte bevorzugt, die leicht lesbare Diagramme für den Einsatz in Besprechungen enthalten. Das AQM-Tool bietet mehrere Berichtsoptionen, die Einblick in den entwickelten Code geben. Dies hat sich in unserer Organisation als äußerst nützlich erwiesen. Wir konnten Kennzahlen des Systems bereitstellen, bevor wir Änderungen an der Codebasis vornahmen. Auf diese Weise konnten wir leicht zeigen, dass eine Idee, die wir umsetzen wollten, einen Mehrwert bot, indem wir unseren AQM-Score erhöhten. Mit diesem Ansatz konnten wir auch einige unserer größten Verstöße gegen Mikroflüsse beseitigen, indem wir dem Management eine Vorher- und Nachher-Kennzahl zeigten.

Mit AQM können Sie erkennen, dass Ihr Team Artikel herstellt, die nicht zu komplex und leicht zu warten sind.

Sie können dem Managementteam auch Benutzeranmeldungen einrichten, damit es auf diese Kennzahlen zugreifen und sie in Diskussionen im gesamten Unternehmen verwenden kann. Denken Sie daran: Je mehr Komfort Sie den Leuten bieten, desto einfacher wird die Zustimmung sein.

Moving Forward

Dies ist ein hochrangiger Ansatz, den ich bereitgestellt habe, um Ihnen dabei zu helfen, die Kultur Ihrer Organisation zu ändern. Seien Sie sich bewusst, dass es nicht immer reibungslos verlaufen wird. Während des gesamten Prozesses wird es viele Höhen und Tiefen geben. Denken Sie einfach daran, dass es sich am Ende lohnen wird. Die Verwendung dieser Elemente wird jedem helfen, den neuen Prozess zu verstehen und sich damit wohlzufühlen. Die Beständigkeit bei der Wiederholung des Prozesses kommt bei den Leuten sehr gut an. Je mehr Sie Ihrem Team von jedem Sprint geben, desto mehr werden sie die Früchte ihrer Arbeit sehen. Diese Schritte haben unserem Entwicklungsteam erheblich geholfen zu verstehen, dass der agile Ansatz äußerst erfolgreich sein kann.