Worauf muss man achten, um technische Schulden bei der agilen Entwicklung oder bei der Wasserfallentwicklung zu erkennen?

Auf Anhieb ist es wichtig zu beachten, dass es nicht immer einfach ist, herauszufinden, dass es sich bei Ihrem Problem um technische Schulden handelt. Komplexe Projekte, die heute gebaut werden, können eine Vielzahl von Problemen aufweisen, die von unzureichender Hardware über schlechte Architektur bis hin zu komplexen und ineffizienten Algorithmen und vielem mehr reichen.

Zweitens, wenn Sie eine Person sind, die sich mit IT-Technologie nicht auskennt, werden die meisten technischen Informationen zu technischen Schulden für Sie sehr wahrscheinlich nicht viel Sinn machen.

Wenn wir zu unserem ersten Stück zurückkehren technische Schulden, dann wissen Sie schon, was eigentlich als technische Schuld angesehen werden kann, und diese technische Schuld ist heute mehr oder weniger Teil jedes IT-Projekts. Manchmal handelt es sich bei technischen Schulden um eine vorkalkulierte Wette mit umso mehr Gewinnpotenzial. Manchmal ist es andererseits nur die Unwissenheit des menschlichen Verstandes oder die Rücksichtslosigkeit des Entwicklungsteams. Im letzten Fall ist es „nur“ das unglaublich schnelle Wachstum der gesamten IT-Branche und so ist es möglich, dass das, was heute modern und funktionell ist, in zwei Jahren von einer anderen und besseren Technologie übertroffen wird und dann liegt es an jedem Urteil, ob eine solche Technologie zu Ihrem Projekt passt oder nicht.

Unter dem Strich müssen Sie sich auf einige grundlegende Punkte konzentrieren und wenn Sie diese befolgen, haben Sie in den meisten Fällen die Kontrolle. Im Wesentlichen kommt es also auf Kommunikation und Transparenz der Entwicklung an. Kommuniziert das Entwicklungsteam mit Ihnen über den Status Ihres Projekts? Diskutieren sie offen mit Ihnen über die Möglichkeiten, zusätzliche Funktionen zu entwickeln, und wenn die gewählte Lösungsoption die technischen Schulden erhöhen könnte, informieren sie Sie darüber? Wird hier und da (normalerweise ein paar Mal im Jahr) ein größeres oder kleineres Upgrade der in einem Sprint verwendeten Technologien durchgeführt? Haben Sie Zugriff auf den Quellcode?

Wenn das Entwicklungsteam transparent ist, nicht über den Status des Projekts lügt und alles klar erklärt und Sie auch im Voraus benachrichtigt und im Falle einer möglichen Erhöhung der technischen Schulden um Ihre Zustimmung bittet, ist wahrscheinlich alles in Ordnung. Wenn Sie beispielsweise eher technisch versiert sind, können Sie sich auch an einem Ort einen Überblick über die verwendeten Technologien und deren Versionen verschaffen. Aber wenn nichts dergleichen passiert, ist es eine gute Idee, dem Entwicklungsteam ab und zu ein paar Fragen zu stellen und deren Antworten zu erhalten.

Beispiele für solche Fragen sind:

1. Wie steht es um technische Schulden? Gibt es etwas, das uns langfristig negativ beeinflussen kann?
2. Was sind die Versionen unserer Bibliotheken und Technologien und wie weit liegen wir im Vergleich zu aktuellen Hauptversionen zurück? Gibt es in den neuen Versionen etwas, das uns helfen kann?
3. Was sind derzeit unsere dringendsten technischen Schuldenprobleme und wie wirkt sich das auf uns aus?
4. Gibt es etwas, das das Entwicklungsteam davon abhält, neue Funktionen effektiv zu entwickeln? Was können wir dagegen tun?

Dies ist nur ein grundlegender Satz verschiedener Fragen, führt Sie jedoch häufig zu Folgefragen und Antworten.

In diesem Kapitel ein kleiner Hinweis zur Verwendung der neuesten Versionen von Bibliotheken und Technologien. Die allgemeine Erfahrung im IT-Bereich ist, dass es sich immer lohnt, mindestens ein paar Monate nach der Veröffentlichung einer neuen Hauptversion einer Technologie zu warten, es sei denn, Ihr Projekt benötigt sie unbedingt oder die Vorteile einer neuen Version einer Technologie überwiegen die Nachteile (z. B. eine starke Erhöhung der Geschwindigkeit und der Anzahl der verarbeiteten Anfragen). Nach der Veröffentlichung einer neuen Version gibt es oft kleinere oder größere Fehler, die immer noch damit verbunden sind oder die von sogenannten Early Adoptern entdeckt werden, das sind Einzelpersonen oder Unternehmen, die auf eine neue Version aktualisieren, weil sie es müssen. Diese Bugs werden dann sehr schnell geloggt, behoben und nach ein paar Wochen oder Monaten gibt es im Wesentlichen eine sehr stabile Version, mit der man problemlos arbeiten kann.

Wie arbeitet man mit technischen Schulden in Agile und Scrum?

Wir haben diese Passage bereits in unserem ersten Beitrag zum Thema leicht umrissen technische Schulden, aber wir werden es hier wiederholen.

1. Denken Sie daran, dass technische Schulden für jedes Projekt gelten. Manchmal handelt es sich nur um eine vorsätzliche Verschuldung mit der Vision des Gewinns, manchmal ist die Situation schlechter/anders. In Wirklichkeit bedeutet es, die Zeit und damit die Mittel zur Verfügung zu stellen, um das Problem anzugehen.
2. Notieren Sie genau, was es ist, und versuchen Sie, die technischen Schulden Teil für Teil zu löschen. Eine einzelne Seite in Confluence, ein offenes Ticket in GitHub oder eine Aufgabe in JIRA, die dein Produktmanager unter seiner Fuchtel hat, reicht aus, um einen Datensatz zu führen.
3. Wenn Sie eine schnelle Entwicklung durchführen müssen, auch um den Preis steigender technischer Schulden, um einen Meilenstein zu erreichen, müssen Sie damit rechnen, dass Sie in Zukunft Zeit finden müssen, um diese neu entstandenen technischen Schulden in Angriff zu nehmen.
4. Wenn es für Sie sinnvoll ist, ziehen Sie einen externen Experten hinzu, der ein technisches Audit für Ihr Projekt durchführen kann.
5. Lassen Sie technische Schulden nicht schwelen. Je länger es unbeaufsichtigt bleibt, desto schlimmer können die langfristigen Folgen für das Projekt sein. Priorisieren.
6. Halten Sie Prozesse bereit, mit denen sich technische Schulden erheblich verringern lassen. Dies können zum Beispiel automatisierte Tests, Regeln für die Entwicklung neuer Module oder Komponenten, strengere Code-Reviews usw. sein.
7. Die Kommunikation zwischen dem Entwicklungsteam und Ihnen als Kunde ist ebenfalls wichtig. Sprechen Sie also offen über das Thema und Sie sind auf dem besten Weg, immer einen Schritt voraus zu sein.

Einige Beispiele für technische Schulden, die wir in unserer jahrelangen Erfahrung gesehen haben

Wieder rein Teil eins In unserer kurzen Serie über technische Schulden haben wir Ihnen ein Beispiel für ein solches Problem und seine Auswirkungen auf ein Projekt gezeigt. Heute haben wir drei weitere verschiedene Beispiele, die wir (von vielen) gesehen haben, seit Moravio 2011 auf dem Markt ist.

Schlechtes Datenbankdesign

Diese Situation ereignete sich im Rahmen eines Projekts, das wir in Moravio unter unsere Fittiche genommen haben. Als wir das Projekt übernahmen, stellten wir fest, dass das Projekt in Bezug auf die Datenbank schlecht konzipiert war. Ein Hauptobjekt, das während einer bestimmten Aktion auf dem Portal erstellt wurde, gruppierte zwar mehrere Entitäten darunter, erstellte jedoch immer eine eigene Kopie der Datenbankstruktur, in der es Daten speicherte. Dadurch wurde die gesamte Datenbank sehr schnell unübersichtlich, und außerdem war es aufgrund der schlechten Benennung der Tabellen und der zugehörigen Entitäten sehr schwierig, etwas ausfindig zu machen. Diese Architektur hatte auch direkte Auswirkungen auf die Entwicklung einiger Funktionen, die standardmäßig nicht implementiert werden konnten. Angesichts des schnellen Wachstums des Projekts war es notwendig, die Datenbank zu modifizieren und alles zu vereinheitlichen. Dies führte dazu, dass die Arbeit des Entwicklungsteams beschleunigt, der Teil des Codes, der mit der Datenbank interagiert, umgestaltet und auch die Klarheit des gesamten Datenbankschemas erhöht wurde.

Versäumnis, die Technologie zu aktualisieren

Dies ist einer der häufigsten Gründe, warum Projekte technische Schulden haben, egal ob es sich um eine agile Entwicklung oder um eine Wasserfallentwicklung handelt. Dieses Beispiel zeigt ein Projekt, bei dem wir unsere Dienstleistungen im Rahmen von erbracht haben Gemeinsame Entwicklung Das Projekt verwendet PHP als Haupttechnologie. Dies ist heute eine sehr leistungsfähige Sprache, die de facto alles kann, was andere moderne und fortgeschrittene Programmiersprachen (JavaScript, .NET Core usw.) können. Hauptversionen von PHP enthalten jedoch oft eine große Liste von Änderungen und auch viel Arbeit direkt am Kern der Sprache. Der Kunde hat bei diesem Projekt aus unserer Sicht zwei große Fehler gemacht. Der erste ist, dass er das Update auf eine neuere Technologie sehr lange hinausgezögert hat, weil es in seinem Fall nicht „nur“ ein einfaches Update war, sondern er auch einen Teil des Codes umgestalten musste, wofür er mehr Zeit einplanen musste. Und das zweite ist, dass der Kunde, nachdem er das Update gestartet und einige Zeit daran gearbeitet hatte, es irgendwann wieder auf Eis legte, weil sich andere und größere Prioritäten herauskristallisierten. In der Zwischenzeit ist das gesamte Projekt aufgrund neuer Funktionen für Kunden erheblich gewachsen und auch eine weitere neue Hauptversion von PHP wurde veröffentlicht. Dies führte dazu, dass sprunghaft an dem Update gearbeitet wurde und die Entwickler den Überblick verloren. Das machte die Arbeit sehr ineffizient. Die Vorteile der Aktualisierung auf die neue Technologie waren für den Kunden jedoch erheblich: eine enorme Erhöhung der Anwendungsgeschwindigkeit, die Bearbeitung von mehr Kundenanfragen in der gleichen Zeit und auch eine Erhöhung der Anwendungssicherheit.

Keine automatisierten Tests erstellen oder gar nicht testen

Heute gibt es immer noch viele Projekte, bei denen automatisierte Tests nicht vom Entwicklungsteam erstellt werden. Ja, man kann argumentieren, dass solche automatisierten Tests Zeit und Geld kosten und man kann es nicht wirklich sagen, aber das wäre eine etwas naive Sichtweise. Automatisierte Tests dienen unter anderem dazu, menschliche Gehirne zu ersetzen und Ihrem Projekt (und den Entwicklern) das Vertrauen und die Stabilität zu geben, die es benötigt. Denn ab einer bestimmten Größe Ihres Projekts ist es unseren Gehirnen nicht mehr möglich, alle Zusammenhänge und alle damit verbundenen Szenarien des Verhaltens Ihres Projekts zu erfassen. Für diese Fälle werden dann automatisierte Tests erstellt, die jedes Mal, wenn Sie neue Funktionen bereitstellen, immer dieselbe spezifische Funktionalität testen. Lassen Sie mich ein sehr einfaches fiktives Beispiel geben:

Sie verwenden das Drittanbieter-Login in Ihrem Projekt. Dies sind Google, Microsoft, Facebook und Twitter. Aufgrund eines API-Updates auf der Facebook-Seite müssen Sie das Facebook-Login ändern. Sie nehmen die Änderung vor, stellen sie in einer Testumgebung bereit, testen, stellen sie in der Produktion bereit, alles funktioniert. Bei der Änderung wurde jedoch auch der Quellcode geändert, der von den Anmeldeanbietern von Google, Microsoft und Twitter verwendet wird. Wenn es in Ihrem Projekt keine automatisierten Tests gibt, werden Sie wahrscheinlich erst von diesem Problem erfahren, wenn die Tickets auf Ihrer Kundenservice-Hotline fliegen und die Telefone verärgerter Benutzer klingeln, die Ihre App nicht verwenden können, und Sie es mit einem Hotfix zu tun haben. Wenn es jedoch ordnungsgemäß geschriebene automatisierte Tests gäbe, würde bereits bei der Bereitstellung in einer Testumgebung festgestellt, dass die Anmeldefunktion über Google, Microsoft und Twitter den Test nicht bestanden hat. Der Entwickler schaut sich also nicht nur die Funktion an, die er tatsächlich geändert hat (Facebook), sondern ändert auch die Funktion, mit der andere Anmeldeanbieter (Google, Microsoft, Twitter) arbeiten.

Also ja, automatisierte Tests kosten zusätzliche Zeit und Geld und sie lösen nicht alle Fehler in einem Projekt (Fehler sind Teil jedes Projekts, genau wie technische Schulden), aber auf lange Sicht sparen Sie ein Vielfaches dieser Zeit und dieses Geldes. Hauptsächlich, weil sich das gesamte Entwicklungsteam auf die Entwicklung neuer Funktionen konzentrieren kann und keine Zeit damit verbringen muss, ständig Fehler zu beheben. Ich persönlich habe Fälle gesehen, in denen das Entwicklungsteam im Grunde die Hälfte seiner gesamten Kapazität damit verbringt, Fehler zu beheben, und das ist etwas, das Sie in Ihrem Projekt nicht wollen.

Damit ist unsere zweiteilige Reihe über technische Schulden abgeschlossen, und wir möchten, dass Sie auf so wenige Beispiele wie möglich für die oben genannten Probleme stoßen.

Wenn Sie ein Audit Ihrer aktuellen Lösung oder eine allgemeine Übernahme Ihres aktuellen Projekts benötigen, setzen Sie sich mit uns in Verbindung und wir werden gemeinsam die nächsten Schritte herausfinden.