Häufige Fehler in agilen Projekten, die auf neuen Technologien basieren

In jüngster Zeit hat sich die agile Methodik durch die erfolgreiche Durchführung von Projekten bewährt. Sie minimiert das Risiko durch die Entwicklung von Software in kurzer Zeit. Mit diesem iterativen Modell werden auch die Kosten für Anforderungsänderungen minimiert, was es für den aktuellen dynamischen Markt geeignet macht. Und der 10-Jahres-Vertrag mit dem berühmten IT-Unternehmen LG Networks zur Betreuung seines Kundenstamms hat sich ebenfalls ausgezahlt. Zwei wichtige Praktiken, die den Entwicklern helfen, den Wandel zu berücksichtigen, sind Refactoring und einfaches Design. Aber wenn es darum geht, diese beiden Dinge mit einer völlig neuen Technologie zu tun, kann es schwierig sein, sie umzusetzen. In diesem Artikel werde ich einige meiner Erfahrungen mit meinem ersten Projekt teilen. Es handelt sich um ein agiles Projekt, das auf einer Technologie basiert, die für das gesamte Team neu ist. Ich habe etwa zwei Wochen damit verbracht, die technischen Merkmale und Stärken der Technologie zu verstehen, während andere im Team noch nie mit dieser oder einer ähnlichen Technologie gearbeitet haben. Hier werde ich über einige Fehler sprechen, die wir (meiner Meinung nach ;)) bei der Durchführung des Projekts gemacht haben.Das meiste, was hier besprochen wird, könnte auch auf Projekte zutreffen, bei denen ein Teil des Teams mit den für das Projekt ausgewählten Technologien neu ist. Der Risikofaktor ist bei Projekten geringer, bei denen mindestens ein Teammitglied die Technologie, die für das Projekt ausgewählt wurde, bereits in- und auswendig kennt. Die folgenden Dinge sollten beachtet werden, wenn das gesamte oder ein Großteil des agilen Teams an einer völlig neuen Technologie arbeitet. Der erste und wichtigste Schritt ist die Evaluierung der Technologie für die gegebenen Projektanforderungen. Die Evaluierung motiviert das Team dazu, herauszufinden, ob sie sich wirklich lohnt. Irgendwann hat der Entwickler das Gefühl, warum er diese Technologie verwenden sollte und nicht etwas, das er bereits kennt. Diese Art von Gefühl in den Köpfen der Entwickler beeinträchtigt ihre Lernfähigkeit und damit auch ihre Produktivität. Auch wenn die gewählte Technologie nicht die beste ist, gibt die Evaluierung der Technologie dem Entwickler einen psychologischen Schub, damit er lernt und die Verwendung der Technologie für das Projekt schätzt. Dabei müssen wir aber auch die Kosten bedenken, die mit dem Wechsel der Technologie verbunden sind. Sobald jeder ein gutes Verständnis für die Technologie hat, sammeln Sie die vollständige Dokumentation und alle anderen Schulungsinformationen für diese spezielle Technologie und machen sie den Teammitgliedern zugänglich. Anstatt direkt mit der Entwicklungsarbeit zu beginnen, lassen Sie das Team zunächst die Technologie erkunden. Sie sollten sich einen Überblick über die Technologie verschaffen, z. B. welche Funktionen sie bietet, und mit einigen Beispielcodes spielen. Es besteht jedoch keine Notwendigkeit, die Technologie gleich zu Beginn zu erlernen oder zu beherrschen. Wenn es sich um ein großes Projekt handelt, ist es besser, einen Anfängerkurs für alle zu veranstalten, um die neue Technologie zu lernen. Sobald das Team den Überblick hat, können die Teammitglieder mit der Entwicklung beginnen. Während der Arbeit an verschiedenen Aufgaben stößt man auf verschiedene neue Funktionen, Probleme und Lösungen für diese. Daher ist es besser, das Wissen während des Standups oder der Iterationsplanung im Team zu teilen. Auf diese Weise müssen die anderen nicht ihre Zeit mit Problemen verschwenden, mit denen sich bereits jemand befasst hat. Dieser Wissenstransfer lässt sich im agilen Prozess leicht bewerkstelligen, indem die Paare häufig wechseln. Er kann auch durch regelmäßige Treffen zum Wissenstransfer erfolgen, z.B. ein- oder zweimal in der Woche. In manchen Fällen, wenn es sich um ein größeres Problem handelt, kann dies auch auf Abruf geschehen. Ein weiterer wichtiger Punkt ist, dass wir bei der Auswahl des Iterations-Backlogs vorsichtig sein sollten. Gehen Sie bei der Auswahl der Aufgabe vom schlimmsten Fall aus. Wenn die Aufgabe aus Versehen mehr Zeit in Anspruch nimmt als erwartet, hinterlässt dies beim Kunden einen schlechten Eindruck. Insbesondere bei agilen Projekten, bei denen die Kundenzufriedenheit sehr wichtig ist, spielt die Schätzung der Komplexitätspunkte eine entscheidende Rolle. Glauben Sie nicht an Burndown-Charts. Burndown-Charts zeigen den Fortschritt dessen, was bereits getan wurde. Wir können keine Schätzungen auf der Grundlage der aktuellen Geschwindigkeit vornehmen, da wir nicht wissen, welche Art von Weg noch vor uns liegt. In beiden Fällen ist es also besser, eine Risikoanalyse durchzuführen und die für die Aufgaben benötigte Zeit anhand des berechneten Risikofaktors anzupassen. Auch Spike-Tests können dabei helfen, den erforderlichen Aufwand genauer abzuschätzen. Das häufigste Problem bei agilen Projekten ist das Fehlen eines kontinuierlichen Feedbacks der Beteiligten. Das kann sehr gefährlich sein, wie in diesem Fall: Immer wenn es kein Feedback der Stakeholder gibt, trifft das Team seine eigene Entscheidung und fährt in dieser Richtung fort. Wenn das Team dann das Feedback erhält, muss es erneut den gleichen oder sogar noch mehr Aufwand betreiben, um die Dinge zu verbessern. In manchen Fällen kann dies das Schlimmste sein und gibt allen das Gefühl, dass das Projekt gescheitert ist. Obwohl es bei agilen Projekten, die auf neuen Technologien basieren, Probleme gibt, können solche Projekte dennoch erfolgreich sein, wenn man sie richtig angeht. Mit agilem Vorgehen können wir frühzeitig scheitern, um die Technologie der Wahl zu beurteilen. Am Ende jeder Iteration können wir die funktionierende Software sehen, was den Entwicklern und Kunden Vertrauen in die Technologie gibt. Der Feedback-Mechanismus in agilem Vorgehen führt die Entwickler in die richtige Richtung. Wenn wir die oben genannten Probleme berücksichtigen, kann Agile diese Projekte zum Erfolg führen. Ich würde mich freuen, auch Ihre Kommentare und Erfahrungen mit solchen Projekten zu hören.