Technische Schulden für ein Projekt oder das Verlassen eines Schwarzen Lochs

  • Tutorial
Jeder Entwickler ist mit einer Situation vertraut, in der die Implementierung einer neuen Funktion im System viel Zeit in Anspruch nimmt, die Veröffentlichung jedoch kurz bevorsteht, und der Teamleiter oder Projektmanager stellt zum fünften Mal an einem Tag die langweilige Frage: "Nun, wann ist sie fertig?". Und dann gibt es eine schwierige Wahl - alles richtig zu machen und die Veröffentlichungstermine nicht einzuhalten oder eine Funktion zu implementieren, die minimal funktioniert, aber vom Standpunkt einer technischen Lösung nicht ideal ist. Offensichtlich wird in den meisten Fällen die zweite Option gewählt, da die Freigabe und Bereitstellung des Ergebnisses für Kunden hier und jetzt wichtiger ist als die Reinheit des Codes und die Architektur des Systems. Aber mehrere Monate vergehen, und jetzt stört die alte, nicht ideale technische Lösung die Implementierung anderer Funktionen. Und weitere solche Entscheidungen werden sich in einem riesigen Klumpen ansammeln. Umgang mit diesem Problem, Es ist sehr wichtig, die richtigen Schlussfolgerungen zu ziehen und die richtige Lösung zu wählen. Das Schicksal des gesamten Projekts wird von dieser Entscheidung abhängen. In diesem Artikel werden wir versuchen, die Natur der technischen Verschuldung zu verstehen und Möglichkeiten zu finden, diese zu beseitigen.

Die Art der technischen Schulden


Das Konzept der technischen Schulden ersten Ward Cunningham (eingeführt Ward Cunningham ), Technologie - Entwickler Wiki und einer der Gründer von Extreme Programming . In seinem Artikel von 1992 formulierte er dieses Konzept in Form einer Metapher für Finanzschulden: Genau wie bei einem Finanzkredit können Entwickler hier und jetzt zusätzliche Mittel erhalten, indem sie schnelle und nicht optimale technische Lösungen verwenden, die sie jedoch zwangsläufig bezahlen mit der Weiterentwicklung, unabhängig davon, wie diese Schulden beglichen werden - schrittweise Zinszahlungen oder eine Zahlung.

Bild

Aber wenn das Problem der technischen Verschuldung vor 25 Jahren beschrieben wurde und bei fast jedem Projekt auftritt, warum gibt es dann noch keine Projektmanagementmethode, die die Entstehung der technischen Verschuldung verhindern würde? Die Antwort liegt im eigentlichen Konzept des Projekts. Einer der Hauptunterschiede zwischen dem Projekt und anderen Aktivitäten ist die Einzigartigkeit des Endprodukts. Wo es Einzigartigkeit gibt, gibt es Unvorhersehbarkeit, und es ist das, was Änderungen im Design hervorruft und Schwierigkeiten beim anfänglichen Design des Systems mit sich bringt.

Natürlich können Sie versuchen, die Architektur so zu gestalten, dass mögliche Änderungen vorgenommen werden. Hier wird das Team jedoch auf ein Konzept wie " Millers Brieftasche " stoßen”: Eine Regel, bei der nicht mehr als neun“ Münzen ”in ein Kurzzeitgedächtnis einer Person“ gelegt ”werden können. Und wenn die Anzahl der Elemente diesen Wert überschreitet, versucht das Gehirn, die Informationen so zu gruppieren, dass ihre Anzahl zwischen fünf und neun liegt.
Sie können versuchen, die Komponenten in kleinere zu unterteilen, um sie in diese „Brieftasche“ einzufügen. Dies verringert jedoch nicht die Komplexität, und die Anzahl der Abstraktionen mit diesem Ansatz nimmt katastrophal zu. Und wie Sie wissen, kann jedes Problem gelöst werden, indem eine zusätzliche Abstraktionsebene eingeführt wird, mit Ausnahme des Problems zu vieler Abstraktionsebenen.

Andere Teams ziehen es vor, das ursprüngliche Design ganz aufzugeben und so viel wie möglich zu versuchen, während der Entwicklung universelle Tools zu verwenden. Einerseits ist es einfacher, Änderungen vorherzusagen, und in den ersten Phasen wird sich herausstellen, dass das System flexibel genug ist, um Änderungen vorzunehmen. Mit der Zeit wird die Komplexität des Systems nach der zweiten Regel von Lehman jedoch unweigerlich zunehmen, es wird weniger flexibel, und es können Änderungen auftreten, die sich gegen die aktuelle Architektur richten. In diesem Fall verbringen Entwickler auch mehr Zeit mit der Lösung von Architekturproblemen.

Auf die eine oder andere Weise führt die Unvermeidlichkeit von Änderungen im Projekt zur Entstehung von technischen Schulden.

Feststellen, ob das Projekt ein technisches Schuldenproblem hat


Der wichtigste Indikator dafür, dass ein Projekt ein Problem mit der technischen Verschuldung hat, ist natürlich der Code selbst. Zuallererst ist es wert, die Eigenschaften des Schreibens von Code zu erwähnen. Tatsache ist, dass das Schreiben und Lesen von Code zwei völlig unterschiedliche Prozesse sind. Wenn ein Entwickler Code schreibt, konzentriert er sich nur auf den Kontext der Aufgabe. Das Ändern eines einzelnen Codeteils wirkt sich jedoch auf das Gesamtbild des Geschehens aus. Bevor Sie den geschriebenen Code ändern können, müssen Sie sich nicht nur eine Vorstellung über eine bestimmte Site machen, sondern auch über das gesamte Bild. Beim Lesen werden jedoch die Grenzen der Kontexte, in denen der Code geschrieben wurde, in einer allgemeinen Ansicht gelöscht. Dieser Unterschied zwischen dem Lesen und Schreiben von Code erzeugt zusätzliche Komplexität, die sich direkt auf die Qualität auswirkt.

Bild

Was Sie beachten sollten:

  • Codeteile, die häufig Änderungen unterliegen. Höchstwahrscheinlich müssen diese Websites ernsthaft überarbeitet werden.
  • Eine große Anzahl von FIXME- und TODO-Markierungen und eine kleine Anzahl von Kommentaren im Code sollten alarmieren. Moderne IDEs verfügen über eine integrierte Unterstützung für die Arbeit mit solchen Tags. Dies ist eine der schnellsten und zuverlässigsten Methoden, um Schwachstellen im System zu erkennen.
  • Fehlende Tests. Ohne sie sind Entwickler nicht sicher, ob ihre Änderungen das System nicht stören. Das Team bezeichnet den Code, der von Tests nicht abgedeckt wird, als ein Kartenhaus, das versucht, unnötige und manchmal notwendige Änderungen zu vermeiden.
  • Fehlende Dokumentation. Die Situation ist ähnlich wie im vorherigen Absatz. Der Mangel an regulierten Informationen zwingt den Entwickler, sich ein Bild davon zu machen, was passiert, und es besteht die Möglichkeit, dass er eine falsche Vorstellung von dem System hat. Erschwerend kommt hinzu, dass in den allermeisten Fällen Entwickler unterschiedlicher Ausbildungs- und Kompetenzstufen an dem Projekt arbeiten. Und der Unterschied beim Verstehen des Codes verkompliziert den Prozess des Lesens und Schreibens von Code weiter.
  • Veraltete Technologien und Entwicklungstools. Jede Bibliothek oder jedes Modul wird aktualisiert, und es wird immer schwieriger, ältere Versionen im Laufe der Zeit zu warten.
  • Fehlende Entwicklungsstandards. Jeder Entwickler macht was und wie er will.

Technologische Entschuldungstechniken


  • Wie bei der Behandlung jeder Krankheit besteht der allererste Schritt zur Genesung darin, sich als Patient zu erkennen. In der Tat muss jeder Projektteilnehmer, vom Kunden bis zum Entwickler, das Problem der Erhöhung der technischen Schulden erkennen. Vor nicht allzu langer Zeit wurde ich Teamleiter bei einem großen Projekt, das wir geerbt haben, und es wurde nie an technischen Schulden gearbeitet. Während ich mich mit einer Vielzahl von Aufgaben befasste, stieß ich ständig auf Aufgaben zur Beseitigung technischer Schulden, die von verschiedenen Personen zu unterschiedlichen Zeiten erstellt, aber nie realisiert wurden. Dies lässt darauf schließen, dass Versuche, allein mit einer technischen Aufgabe fertig zu werden, mit einem Kampf gegen Windmühlen vergleichbar sind. Es ist sehr wichtig, dass sich die Projektteilnehmer dieses Problems bewusst sind, da für seine Lösungen ein ausschließlich systematischer Ansatz erforderlich ist .

    Bild

  • Verwenden Sie agile Entwicklungsmethoden ( Agile ). Das Hauptaugenmerk der Methoden liegt darin, die Entwicklung in kleine, isolierte Iterationen von einer bis vier Wochen zu unterteilen. Somit wird die Einschränkung "Miller's Wallet" umgangen, da Sie jetzt in jeder Iteration nur mit einem begrenzten Informationsfluss arbeiten müssen, der die Verwaltung der Komplexität und damit der technischen Verschuldung erleichtert.
  • Geben Sie ein allgemeines und verständliches Verfahren für die Arbeit mit technischen Schulden ein. Erstellen Sie einen Rückstand, in dem Aufgaben für die Zahlung vorhanden sind. Nehmen Sie sich Zeit, um diese Aufgaben zu erledigen, wenn Sie neue Funktionen hinzufügen oder die nächste Iteration planen. Sie können versuchen, nur Zeit für die Ausführung dieser Aufgaben zuzuweisen, aber dann friert die Entwicklung neuer Funktionen ein und es kommt höchstwahrscheinlich zu Missverständnissen auf Seiten des Unternehmens. In unserem Projekt haben wir beschlossen, 20-30% der Zeit von der nächsten Iteration bis zur Rückzahlung der technischen Schulden zu verwenden.
  • Erstellen Sie Metriken, mit denen Sie die Implementierung von technischen Schulden bequem überwachen können. Solche Metriken sind für jedes Projekt individuell. Zum Beispiel haben wir für unser Projekt solche Metriken als Prozentsatz der Abdeckung mit Tests und Dokumentation, Code-Konformität mit akzeptierten Style Guides und die Komplexität der Bereitstellung des Systems in der lokalen Umgebung des Entwicklers identifiziert. Einige der Metriken werden automatisch erfasst, andere nur subjektiv von jedem Entwickler. Es ist wichtig, dass diese Metriken für alle zugänglich sind, jeder Teilnehmer den Fortschritt sieht und damit einverstanden ist.

Fazit


Das technische Schuldenproblem ist derzeit sehr aktuell, und jedes Projekt erfordert eine individuelle Herangehensweise an das Problem seiner Beseitigung.

Haben Sie keine Angst vor Zahlungen, denn wenn Sie die richtige Strategie anwenden, wird die technische Verschuldung zu der Kraft, die Ihr Projekt zur Entwicklung zwingt. Die Arbeit mit technischen Schulden zeigt den Reifegrad sowohl des Projekts selbst als auch des Teams, das daran arbeitet.

Jetzt auch beliebt: