​​Jedes Projekt hat seine eigenen Regeln für die Entwicklung. Meistens beschreiben diese Regeln Entwicklungspraktiken und die Arbeit mit einem Versionskontrollsystem (VCS), das die Art und Weise des Testens und der Bereitstellung des Produkts, die Struktur, die Architektur des Projekts und den Codestil umreißt, aber die Regeln können auch die Grundlagen der sicheren Entwicklung und mehr umfassen.

Diese Regeln können ungeschrieben sein, werden aber in der Regel in einem gemeinsamen Raum definiert und festgehalten, wo sie für alle zugänglich sind. Noch wichtiger ist jedoch, wie diese Regeln in der Praxis angewendet und durchgesetzt werden.

Die Weisen wissen es am besten

Manche Leute glauben, dass Programmieren in Paaren oder Code Review eine geeignete Plattform für die Überarbeitung von Regeln ist. Die Teilnehmer können sich auf die Anwendung der Regeln einigen oder sie je nach Kontext ändern. Wenn Entwickler dies gewissenhaft angehen, kann das Ergebnis ein Projekt sein, das vielleicht nicht konsequent ist, aber dessen einzelne Teile in bestmöglicher Verfassung sind.

Dieser Ansatz kann zu Beginn eines Projekts für kurze Zeit zu besseren Ergebnissen führen, aber seine Unzulänglichkeiten werden mit der Zeit zum Vorschein kommen. Auch erfahrene Entwickler und technische Leiter sind nur Menschen. Sie können gelegentlich müde werden oder einfach etwas übersehen. So häufen sich kleinere Abweichungen von den vereinbarten Regeln und bilden die so genannten technischen Schulden.

Zeitfahren

Der nächste Aspekt, der sich in der Zeit widerspiegelt, ist die Ausweitung des Projekts, und zwar auf zwei Ebenen.

Der erste ist die Erweiterung des Produkts selbst. Wenn das Produkt erfolgreich wird, erhält es neue und anspruchsvollere Funktionen, die beginnen, zuvor einfachere und unabhängige Funktionen zu verbinden. Hier begannen die kleinen Abweichungen und Inkonsistenzen aufzutauchen, die zunächst für die Funktionalität gut schienen. Das Problem ist, dass jetzt mehr dieser Funktionen miteinander kompatibel sein müssen, aber sie sind noch nicht bereit dafür.

Dies ist nicht nur ein Problem der Inkompatibilität von Funktionen. Oft versuchen Entwickler in guter Absicht, vorhandene Komponenten so weit wie möglich wiederzuverwenden, um Code-Duplikationen zu vermeiden. Sie vergessen die Regel, dass wir eine Komponente wiederverwenden können, wenn wir das gleiche Verhalten erwarten, aber auch die gleichen Gründe für eine Änderung haben. Wenn diese Bedingung nicht erfüllt ist, wird das Prinzip der einzigen Verantwortung Single Responsibility Principle verletzt und das Projekt hat eine geringe Flexibilität für zukünftige Entwicklungen.

Die zweite Ebene der Projekterweiterung ist das Entwicklungsteam selbst. Sobald das Produkt erfolgreich wird, führt dies früher oder später zur Erweiterung des Entwicklungsteams. Die neuen Teammitglieder kennen nicht die gesamte Entstehungsgeschichte des Projekts und haben daher nicht das gleiche Verständnis für die Regeln wie die älteren Mitglieder, die die Regeln selbst aufgestellt haben. Dies führt zu Missverständnissen und einer weiteren geringfügigen Abweichung von den vereinbarten Regeln, was wiederum die technische Schuld erhöht. Ein Nebeneffekt ist ein erhöhter Kommunikationsbedarf bei der Paarprogrammierung und der Codeüberprüfung, was die Gesamtproduktivität des Teams verringert.

Diese Probleme bei der Projekterweiterung sind nicht auf große Entwicklungsteams beschränkt, sondern treten auch bei kleineren Teams auf. Wenn z. B. ein Zweierteam zwei neue Entwickler einführt, ändert sich die Produktivität des Teams möglicherweise kaum. Und all dies ist auf die oben beschriebenen Umstände zurückzuführen. Ohne die Ursache des Problems zu kennen, kann dies zu einer weiteren blinden „Verstärkung“ des Teams führen und es noch schlimmer machen.

Nach dem Stolpern kommt der Sturz

Wenn ein Entwicklungsteam wiederholt vereinbarte Funktionen nicht fertig stellt oder aus technischen Gründen nicht in der Lage ist, eine neue Version eines Produkts zu veröffentlichen, tritt eines der kritischen Szenarien ein. An diesem Punkt werden Personen außerhalb des Standardentwicklungsteams in die Suche nach der Ursache und die Lösung des Problems einbezogen. Gemeinsam arbeiten sie unter Stress und mit viel menschlichem Einsatz daran, die Entwicklung wieder in den Griff zu bekommen. Erst zu diesem Zeitpunkt findet eine rückblickende Analyse statt, um die wahren Ursachen der Probleme aufzudecken.

Die Begleitsymptome und die Quelle dieser Probleme haben sich jedoch schon lange im Voraus manifestiert. Ein paar subtile Situationen als Beispiele:

• Ein Entwickler erhält bei der Codeüberprüfung wiederholt Rückmeldungen über falsche Benennungen.
  
• Ein Ticket im Fehlerverfolgungssystem Issue Tracker des Projekts enthält aufgrund eines Tippfehlers im Quellcode des Projekts keinen Verweis auf die Implementierung.
  
• Eine Funktion, die sich noch in der Entwicklung befindet, ist in der Testversion der Anwendung aktiviert.
  

Oft sehen sie nur wie kleine Unklarheiten, individuelle Fehler oder Unfälle aus, die manchmal während der Entwicklung passieren. Wenn sich diese Situationen wiederholen, nehmen die negativen Auswirkungen auf die Produktivität des Teams und die Fehlerquote des Projekts schnell zu. Aber wenn wir sie genau betrachten, können wir Leerstellen in unserer Arbeitsweise erkennen, die eigentlich leicht zu füllen sind und das Problem ein für alle Mal lösen.

Live-Regeln

Um die oben genannten Probleme zu vermeiden, brauchen wir klar definierte Entwicklungsregeln. Ihr Inhalt sollte die individuellen Bedürfnisse eines jeden Projekts widerspiegeln. Für einige Projekte wird es entscheidend sein, die Zusammenarbeit mit dem QA-Team klar zu definieren und das Release-Management des Produkts zu beschreiben, während andere Teams sich mehr auf die Zusammenarbeit zwischen den Entwicklern innerhalb der Entwicklung selbst konzentrieren werden.

Je detaillierter und spezifischer die Regeln sind, desto besser werden sie sich auf die Arbeit des Teams auswirken. Es ist daher nicht möglich, von einer allgemeinen Vorlage auszugehen, sondern jedes Team muss diese Regeln selbst festlegen.

Manchmal kommt es vor, dass ein Team zu Beginn eines Projekts einige grundlegende Regeln allgemeiner Art festlegt, diese aber im Laufe der Zeit nicht weiterentwickelt. Auf diese Weise geben die Regeln nie genau wieder, wie das Team arbeitet, und selbst das wenige, was sie enthalten, wird mit der Zeit bedeutungslos.

Nichts ist in Stein gemeißelt, und selbst ein etabliertes Team ändert im Laufe der Zeit die verwendeten Tools oder entdeckt neue Arbeitsweisen. All diese natürlichen Veränderungen haben Auswirkungen auf die Teamregeln. Sie bleiben lebendig und gültig.

Alles automatisieren

In der Einleitung haben wir kurz erörtert, wie die Regeln aussehen können und welche Möglichkeiten es gibt, sie anzuwenden. Um möglichst effektiv zu sein, müssen die Regeln automatisch angewendet werden, ohne dass eine manuelle Kontrolle erforderlich ist. Ebenso müssen wir über die Produktivität des Teams nachdenken, die durch den Einfluss einer großen Anzahl von repressiven Regeln verringert werden kann. Daher sind Werkzeuge, die Teammitgliedern helfen, bestimmte Schritte zu automatisieren, ein wesentlicher Bestandteil dieses Prozesses. Diese Werkzeuge sind zeitsparend und ihr Output entspricht natürlich den festgelegten Regeln.

In der Praxis ist es so üblich, dass der Code-Stil oder die Projektarchitektur durch automatisierte Regeln durchgesetzt wird, aber gleichzeitig gibt es Code-Vorlagen und Formatierungswerkzeuge, die den Entwicklern die meiste Arbeit abnehmen, ohne dass sie sich dessen bewusst sind.

Die meisten Problemverfolgungswerkzeuge bieten eine programmatische Schnittstelle, so dass es einfach ist, die Erstellung eines neuen Entwicklungszweigs im VCS zu automatisieren, so dass der neue Code mit einem bestimmten Problem verknüpft wird. Ebenso ist es möglich, einen VCS-Hook zu erstellen, der prüft, ob ein entsprechendes Issue für einen bestimmten Branch oder Commit existiert, wenn der Entwickler den neuen Entwicklungszweig manuell erstellt hat.

Das Freigabemanagement ist ein ganz eigenes Kapitel. Bei der Freigabe einer neuen Version eines Produkts sind in der Regel routinemäßige und klar definierte Schritte erforderlich. Hier gibt uns die Automatisierung nicht nur die Gewissheit, dass die Freigabe einer neuen Version ordnungsgemäß und fehlerfrei erfolgt, sondern sie beschleunigt auch den Prozess und ermöglicht einen einfachen Wissensaustausch zwischen den Teammitgliedern. Ein Bonus ist die einfache Automatisierung der Erstellung von Versionshinweisen, auch wenn diese nur für interne Tester bestimmt sind.

Prüfer werden auch die Möglichkeit zu schätzen wissen, das Produkt für interne Tests zu konfigurieren. Sie können ein Funktionskennzeichen umschalten, die Umgebung konfigurieren, in der die Anwendung ausgeführt wird, oder Szenarien simulieren, die manuell nur schwer zu realisieren sind. Neben dem unbestreitbaren Nutzen dieser Testwerkzeuge für die Tester haben sie auch Vorteile für die Entwickler selbst. Sie müssen nicht mehr Versionen des Produkts als unbedingt nötig pflegen, was ihnen Zeit spart, da die Build-Logik grundlegend vereinfacht wird.

Dies ist nur eine kleine Auswahl der Regeln, die wir bei Projekten häufig antreffen. Die Möglichkeiten sind jedoch bei weitem nicht erschöpfend, sei es in Bezug auf die Menge, die Tiefe oder die Ausgereiftheit.

Wie weit soll es gehen?

Einige Regeln mögen so streng erscheinen, dass sie Ihre Arbeitsfreiheit einschränken. Andere können so vage erscheinen, dass sie nicht die gewünschte Wirkung haben. Das ist in Ordnung. Jedes Team und jedes Mitglied hat andere Bedürfnisse und ein anderes Risikoverständnis. All dies hat Auswirkungen auf die Form der Vorschriften.

In unseren Projekten versuchen wir, die Regeln strikt nach Vorgabe zu definieren. Wenn wir mit der Zeit feststellen, dass sie uns zu sehr einschränken, ist es leicht, die Regel zu verallgemeinern oder sie in eine Empfehlung oder Warnung umzuwandeln. Der umgekehrte Weg ist wesentlich komplizierter, weil sich das Team und seine Arbeitsweise bereits an die allgemeinere Regel gewöhnt haben, so dass eine Änderung möglicherweise nicht über Nacht möglich ist.

Nachhaltigkeit des Projekts

Bei der Entwicklung eines Produkts berücksichtigen wir neben den kurzfristigen Zielen, die notwendigen Funktionen zu schaffen, immer auch die Idee der langfristigen Nachhaltigkeit und Lebensfähigkeit des Projekts. Gerade in der mobilen Entwicklung ist die Meinung, dass ein Projekt alle 2-3 Jahre verworfen und von Grund auf neu entwickelt werden sollte, keine Ausnahme. Dies ist eine echte Katastrophe für die Produktivität.

In unserem Portfolio haben wir Anwendungen, die mehr als 7 Jahre alt sind und im Laufe ihrer Lebensdauer mehrere größere Änderungen erfahren haben. Auf geschäftlicher Ebene hat sich die Ausrichtung auf einen anderen Nutzerkreis geändert und wurde mit Änderungen bei Markenbildung und Design in Einklang gebracht. Auf technischer Ebene würde ich den Wechsel von der Programmiersprache Java zu Kotlin erwähnen, oder den Übergang der asynchronen Arbeit von einer benutzerdefinierten imperativen Lösung zu einem reaktiven Ansatz über RxJava und später Kotlin Coroutines. Trotzdem besteht das Entwicklungsteam immer noch aus nur zwei Personen (während sie sich ständig verändern) und liefert in gleichem Tempo neue Funktionalitäten entsprechend den Geschäftsanforderungen.

Klar definierte Entwicklungsregeln und die durch sie erzwungene Konsistenz haben in jeder Hinsicht einen großen Einfluss auf die Qualität des Endprodukts.

Nächstes Mal werden wir uns genauer ansehen, wie einige Regeln umgesetzt werden können und welche Werkzeuge uns dafür zur Verfügung stehen.