🥇Infrastructure as Code: wie man Probleme mit XP überwinden kann

Hallo, Habr! Früher habe ich über das Leben in der Infrastruktur-als-Code-Perspektive geklagt und nichts zur Lösung der aktuellen Situation angeboten. Heute bin ich zurück, um über Ansätze und Praktiken zu sprechen, die helfen können, aus der Abwärtsspirale der Verzweiflung auszubrechen und die Situation in die richtige Richtung zu lenken.

Im vorherigen Artikel „Infrastructure as Code: Erste Begegnung“ Ich habe meine Eindrücke aus diesem Bereich geteilt, versucht über die aktuelle Lage nachzudenken, und sogar angedeutet, dass die gängigen Praktiken, die allen Entwicklern bekannt sind, hilfreich sein könnten. Es schien, als gäbe es viele Klagen über die Lebensbedingungen, aber keine Vorschläge, wie man aus der aktuellen Situation herauskommt.

Wer wir sind, wo wir sind und welche Probleme wir haben

Derzeit sind wir im SRE Onboarding Team, das aus sechs Programmierern und drei Infrastruktur-Ingenieuren besteht. Wir alle versuchen, Infrastructure as Code (IaC) zu schreiben. Wir tun dies, weil wir im Grunde genommen wissen, wie man Code schreibt und in der Vergangenheit Entwickler auf "überdurchschnittlichem" Niveau waren.

Wir haben eine Reihe von Vorteilen: einen bestimmten Hintergrund, Kenntnisse über Praktiken, die Fähigkeit, Code zu schreiben, und den Wunsch, Neues zu lernen.
Und hier ist der Nachteil: mangelndes Wissen über die Materie der Infrastruktur.

Die Technologiestack, den wir in unserem IaC verwenden.

Terraform zur Erstellung von Ressourcen.
Packer zum Erstellen von Images. Dies sind Windows- und CentOS 7-Images.
Jsonnet, um leistungsstarke Builds in drone.io zu erstellen und unsere Packer-JSON- sowie Terraform-Module zu generieren.
Azure.
Ansible beim Vorbereiten von Images.
Python für unterstützende Dienste sowie Provisionierungsskripte.
Und das alles in VSCode mit Plugins, die zwischen den Teammitgliedern geteilt werden.

Die Quintessenz aus meinem vorherigen Artikel war folgender: Ich wollte (vor allem mir selbst) Optimismus einflößen, ich wollte sagen, dass wir bewährte Ansätze und Methoden ausprobieren werden, um mit den Herausforderungen und Schwierigkeiten in diesem Bereich umzugehen.

Jetzt kämpfen wir mit folgenden Problemen in IaC:

Unvollkommenheit der Werkzeuge und der Mittel zur Codeentwicklung.
Langsame Bereitstellung. Infrastruktur ist ein Teil der realen Welt, und diese kann nicht schnell sein.
Mangel an geeigneten Ansätzen und Praktiken.
Wir sind neu und wissen noch viel nicht.

Extreme Programmierung (XP) eilt zur Hilfe.

Alle Entwickler sind mit Extreme Programming (XP) und den Praxisansätzen vertraut, die damit verbunden sind. Viele von uns haben nach diesem Ansatz gearbeitet, und er war erfolgreich. Warum also nicht die Prinzipien und Praktiken, die dort verwurzelt sind, nutzen, um die Herausforderungen in der Infrastruktur zu meistern? Wir haben beschlossen, diesen Ansatz anzuwenden und zu sehen, was daraus wird.

Überprüfung der Anwendbarkeit des XP-Ansatzes in Ihrem BereichHier ist eine Beschreibung der Umgebung, die gut für XP geeignet ist, und wie dies mit uns in Beziehung steht:

1. Dynamisch wechselnde Softwareanforderungen. Wir wussten, was das Endziel ist. Aber die Details können variieren. Wir entscheiden selbst, wohin wir steuern möchten, deshalb ändern sich die Anforderungen regelmäßig (hauptsächlich von uns selbst). Wenn wir ein SRE-Team betrachten, das die Automatisierung selbst durchführt und gleichzeitig die Anforderungen und den Umfang der Arbeiten einschränkt, passt dieser Punkt gut.

2. Risiken durch fix geplante Projekte mit neuen Technologien. Wir könnten Risiken eingehen, wenn wir mit Technologien arbeiten, die uns unbekannt sind. Und das ist zu 100 % unser Fall. Das gesamte Projekt basiert auf Technologien, mit denen wir nicht vollständig vertraut sind. Dies ist ein dauerhaftes Problem, da ständig zahlreiche neue Technologien im Bereich Infrastruktur auftauchen.

3,4. Klein, ko-lokales erweitertes Entwicklungsteam. Die Technologie, die Sie verwenden, ermöglicht automatisierte Unit- und Funktionstests. Diese beiden Punkte passen nicht ganz zu uns. Erstens sind wir kein ko-lokales Team, und zweitens sind wir neun Personen, was als ein großes Team angesehen werden kann. Laut einiger Definitionen ist ein „großes“ Team allerdings mehr als 14 Personen.

Betrachten wir einige Praktiken aus XP und wie sie die Geschwindigkeit und Qualität des Feedbacks beeinflussen.

Das Prinzip des Feedbackzyklus in XP

Meiner Auffassung nach ist Feedback die Antwort auf die Frage, ob ich richtig handle und ob wir auf dem richtigen Weg sind. In XP gibt es dazu ein beeindruckendes Schema: den zeitlichen Feedbackzyklus. Das Interessante daran ist, dass je tiefer wir uns befinden, desto schneller können wir das Feedback erhalten, um die notwendigen Fragen zu beantworten.

Das ist ein ziemlich interessantes Thema für eine Diskussion, besonders wie man in der IT-Branche schnell zu einem Betriebssystem gelangen kann. Stellen Sie sich vor, wie schmerzhaft es wäre, über ein halbes Jahr an einem Projekt zu arbeiten und dann festzustellen, dass zu Beginn ein Fehler gemacht wurde. Solche Situationen können sowohl beim Design als auch beim Aufbau komplexer Systeme auftreten.

In unserem Fall hilft uns IaC durch Rückmeldungen. Ich möchte sofort eine kleine Anpassung am obigen Schema vornehmen: der Veröffentlichungsplan hat keinen monatlichen Zyklus, sondern erfolgt mehrmals täglich. An diesen Zyklus sind bestimmte Praktiken gebunden, die wir näher betrachten werden.

Wichtig: Rückmeldungen können die Lösung für alle oben genannten Probleme sein. In Kombination mit XP-Praktiken kann sie aus der Tiefe der Verzweiflung helfen.

Wie man sich aus der Tiefe der Verzweiflung befreit: drei Praktiken

Tests

Tests werden im XP-Rückmeldezyklus zweimal erwähnt. Das ist kein Zufall. Sie sind äußerst wichtig für die gesamte Technik des extremen Programmierens.

Es wird vorausgesetzt, dass Sie Unit- und Akzeptanztests haben. Erstere geben Ihnen innerhalb von Minuten Feedback, während letztere einige Tage benötigen, da sie länger geschrieben werden und seltener ausgeführt werden.

Es gibt eine klassische Testpyramide, die zeigt, dass es mehr Tests geben sollte.

Wie ist dieses Schema auf unser Projekt IaC anwendbar? Eigentlich… gar nicht.

Unit-Tests, obwohl es davon sehr viele geben sollte, können nicht übermäßig zahlreich sein. Entweder testen sie sehr indirekt etwas. Tatsächlich kann man sagen, dass wir sie überhaupt nicht schreiben. Aber es gibt einige Anwendungen für solche Tests, die uns trotzdem gelungen sind:
1. Testen von Code in Jsonnet. Das ist zum Beispiel unser Build-Pipeline in Drone, die recht komplex ist. Der Code in Jsonnet wird gut durch Tests abgedeckt.
  Wir verwenden diesen Unit Testing Framework für Jsonnet.
2. Tests für Skripte, die beim Starten der Ressource ausgeführt werden. Skripte in Python, und daher können auch Tests dafür geschrieben werden.
Eine potenzielle Überprüfung der Konfiguration in Tests ist möglich, aber wir machen das nicht. Es gibt auch die Möglichkeit, die Überprüfung von Regeln zur Konfiguration von Ressourcen über tflint. Allerdings sind die Überprüfungen für Terraform zu grundlegend, aber viele Testfälle wurden für AWS geschrieben. Und wir sind auf Azure, also passt das wieder nicht.
Komponenten-Integrationstests: Das hängt davon ab, wie Sie sie klassifizieren und organisieren. Aber grundsätzlich funktionieren sie.
So sehen Integrationstests aus.

Das ist ein Beispiel beim Erstellen von Images in Drone CI. Um darauf zuzugreifen, müssen Sie 30 Minuten warten, bis das Packer-Image erstellt ist, und dann weitere 15 Minuten warten, bis sie durchlaufen. Aber sie sind da!
Algorithmus zur Überprüfung von Images
1. Zunächst muss Packer das Image vollständig vorbereiten.
2. Neben dem Test befindet sich Terraform mit einem lokalen Zustand, mit dem wir dieses Image bereitstellen.
3. Bei der Bereitstellung wird ein kleines Modulsystem verwendet, das nebenan liegt, um die Arbeit mit dem Image zu erleichtern.
4. Wenn die VM aus dem Image bereitgestellt ist, können die Tests beginnen. Im Wesentlichen werden die Tests auf der Maschine durchgeführt. Es wird geprüft, wie die Skripte beim Start ausgeführt wurden und wie die Daemons arbeiten. Dazu greifen wir über SSH oder WinRM auf die gerade hochgefahrene Maschine zu und überprüfen den Zustand der Konfiguration oder ob die Dienste gestartet wurden.
Eine ähnliche Situation gibt es bei den Integrationstests in den Terraform-Modulen. Hier ist eine kurze Tabelle, die die Besonderheiten solcher Tests erklärt.

Das Feedback im Pipeline liegt bei etwa 40 Minuten. Alles dauert sehr lange. Es kann für Regressionstests verwendet werden, aber für neue Entwicklungen ist das völlig unrealistisch. Wenn man sich sehr gut darauf vorbereitet, das Running und die Skripte vorbereitet, könnte man es auf 10 Minuten reduzieren. Aber das sind trotzdem keine Unit-Tests, die man in 5 Sekunden für 100 Stück durchführen kann.

Das Fehlen von Unit-Tests beim Erstellen von Images oder Terraform-Modulen zwingt uns dazu, die Arbeit auf separate Dienste zu verlagern, die einfach über REST abgerufen werden können, oder auf Python-Skripte.

Zum Beispiel mussten wir sicherstellen, dass sich die virtuelle Maschine beim Start in den Dienst ScaleFTregistriert und beim Löschen der VM sich selbst entfernt.

Da ScaleFT als Dienst vorliegt, sind wir gezwungen, über die API mit ihm zu arbeiten. Eine Wrapper-Funktion wurde geschrieben, die wir aufrufen können und sagen: „Geh rein und lösche das und das.“ Sie speichert alle erforderlichen Einstellungen und Zugriffsrechte.

Darauf können wir jetzt normale Tests schreiben, da es sich nicht von herkömmlicher Software unterscheidet: Eine API wird gemockt, du rufst sie auf und beobachtest, was passiert.

Ergebnisse der Tests: Unit-Tests, die innerhalb einer Minute von einem Betriebssystem geliefert werden sollten, tun dies nicht. Höher angesiedelte Testarten zeigen zwar Wirkung, behandeln jedoch nur einen Teil der Probleme.

Pair Programming

Tests sind natürlich gut. Man kann viele davon schreiben, und sie können in verschiedenen Formen erfolgen. Sie funktionieren auf ihren jeweiligen Ebenen und geben uns Feedback. Doch das Problem mit schlechten Unit-Tests, die das schnellste Betriebssystem erzeugen sollen, bleibt bestehen. Gleichzeitig wünscht man sich weiterhin ein schnelles Betriebssystem, mit dem sich einfach und angenehm arbeiten lässt. Ganz zu schweigen von der Qualität der Lösung. Glücklicherweise gibt es Techniken, die uns noch schnelleres Feedback als modulare Tests ermöglichen. Das ist Pair Programming.

Beim Schreiben von Code möchte man so schnell wie möglich Rückmeldung zur Qualität erhalten. Ja, man kann alles in einem Feature-Branch schreiben (um niemandem etwas kaputt zu machen), einen Pull Request auf GitHub erstellen, jemanden benennen, dessen Meinung zählt, und auf eine Antwort warten.

Aber das Warten kann lange dauern. Die Menschen sind alle beschäftigt, und selbst wenn eine Antwort kommt, könnte sie von minderer Qualität sein. Angenommen, die Antwort kommt sofort und der Reviewer versteht sofort das ganze Konzept, aber die Antwort kommt immer noch verspätet, im Nachhinein. Man möchte jedoch früher eine Rückmeldung. Genau dafür ist Pair Programming gedacht – um sofort, während des Schreibens, Feedback zu erhalten.

Im Folgenden erläutere ich die Stile von Pair Programming und deren Anwendbarkeit bei der Arbeit mit IaC:

1. Klassisch, Erfahren+Erfahren, zeitgesteuerte Rollenwechsel. Zwei Rollen – Driver und Navigator. Zwei Personen. Sie arbeiten am gleichen Code und wechseln alle festgelegte Zeitintervalle die Rollen.

Betrachten wir die Vereinbarkeit unserer Probleme mit dem Stil:

Problem: Unzulänglichkeit der Werkzeuge und Mittel zur codeentwicklung.
Negative Auswirkung: längere Entwicklungszeiten, Wir verlangsamen uns, der Arbeitsfluss wird gestört.
Wie wir damit umgehen: Wir verwenden andere Tools, ein gemeinsames IDE und lernen zusätzlich die Shortcuts.
Problem: Langsame Bereitstellung.
Negative Auswirkung: verlängert die Zeit zur Erstellung eines funktionierenden Codes. Man langweilt sich während des Wartens, die Hände möchten etwas anderes tun, während man wartet.
Wie wir damit umgehen: Wir haben es nicht geschafft.
Problem: Mangel an geeigneten Ansätzen und Praktiken.
Negative Auswirkungen: Es fehlt an Wissen darüber, was gut und was schlecht ist. Dies verlängert den Erhalt von Feedback.
Wie wir das bekämpfen: Der Austausch von Meinungen und Praktiken in der Paararbeit löst das Problem nahezu.

Das Hauptproblem beim Einsatz dieses Stils in IaC liegt im unregelmäßigen Arbeitstempo. In der traditionellen Softwareentwicklung hast du einen sehr gleichmäßigen Fluss. Du kannst fünf Minuten investieren und N schreiben. Zehn Minuten für 2N, 15 Minuten für 3N. Hier hingegen kannst du fünf Minuten investieren und N schreiben, und dann weitere 30 Minuten und nur ein Zehntel von N erstellen. Du weißt nichts, hast einen Block, bist festgefahren. Die Klärung benötigt Zeit und lenkt vom Programmieren selbst ab.

Fazit: Im reinsten Sinne passt es nicht zu uns.

2. Ping-Pong. Dieser Ansatz sieht vor, dass ein Teilnehmer einen Test schreibt und der andere ihn implementiert. Angesichts der Schwierigkeiten mit Unit-Tests und der Notwendigkeit, zeitaufwändige Integrationstests zu schreiben, geht die gesamte Leichtigkeit des Ping-Pong-Ansatzes verloren.

Ich kann sagen, dass wir versucht haben, die Aufgabenteilung zwischen der Erstellung von Test-Szenarien und der Implementierung des Codes zu gestalten. Ein Teilnehmer entwickelte das Szenario und war in diesem Teil der Arbeit verantwortlich, er hatte das letzte Wort. Der andere war für die Implementierung zuständig. Das hat gut funktioniert. Die Qualität des Szenarios verbessert sich mit diesem Ansatz.

Fazit: Leider erlaubt der Arbeitstempo keine Ping-Pong-Praxis wie beim Pair Programming in IaC.

3. Strong Style. Komplexe Praxis. Die Idee ist, dass ein Teilnehmer als direktionaler Navigator fungiert, während der andere die Rolle des ausführenden Fahrers übernimmt. Dabei liegt das Entscheidungsrecht ausschließlich beim Navigator. Der Fahrer tippt einfach und kann durch Worte Einfluss auf das Geschehen nehmen. Die Rollen wechseln über längere Zeit nicht.

Geeignet für das Lernen, erfordert jedoch starke Soft Skills. Hier sind wir gescheitert. Die Technik war schwierig. Und es lag nicht einmal an der Infrastruktur.

Fazit: Potenziell anwendbar, wir geben nicht auf.

4. Mobbing, Swarming und alle bekannten, aber hier nicht aufgelisteten Stile werden nicht betrachtet, da wir sie nicht ausprobiert haben und nichts dazu im Kontext unserer Arbeit sagen können.

Zusammenfassende Ergebnisse zur Nutzung von Paarprogrammierung:

Wir haben ein ungleichmäßiges Arbeitstempo, das stört.

Wir stoßen an unzureichende Soft Skills. Und das Themengebiet begünstigt nicht die Überwindung dieser Mängel.

Lange Tests und Probleme mit den Werkzeugen machen die Paarentwicklung mühsam.

5. Trotzdem gab es auch Erfolge. Wir haben unsere eigene Methode "Konvergenz - Divergenz" entwickelt. Ich werde kurz beschreiben, wie sie funktioniert.

Wir haben feste Partner für mehrere Tage (weniger als eine Woche). Wir arbeiten zusammen an einer Aufgabe. Eine Zeit lang sitzen wir zusammen: einer programmiert, der andere beobachtet als Unterstützungsteam. Dann trennen wir uns für eine Weile, jeder arbeitet unabhängig, dann treffen wir uns wieder, synchronisieren uns sehr schnell, arbeiten gemeinsam und trennen uns erneut.

Planung und Kommunikation

Der letzte Block von Praktiken, mit denen Probleme im Betriebssystem gelöst werden - das ist die Organisation der Arbeiten an den Aufgaben selbst. Dazu gehört auch der Austausch von Erfahrungen, die außerhalb der Paararbeit liegen. Lassen Sie uns drei Praktiken betrachten:

1. Aufgaben durch Zielbaum. Das gesamte Projektmanagement haben wir über einen Baum organisiert, der unendlich in die Zukunft führt. Technisch wird die Verwaltung in Miro durchgeführt. Es gibt eine Aufgabe – sie ist ein Zwischenziel. Von ihr gehen entweder kleinere Ziele oder Gruppen von Aufgaben aus. Von diesen leiten sich die eigentlichen Aufgaben ab. Alle Aufgaben werden auf diesem Board erstellt und verwaltet.

Dieses Schema bietet ebenfalls Feedback, das einmal täglich erfolgt, wenn wir uns in Meetings synchronisieren. Ein gemeinsam strukturierter und vollständig transparenter Plan ermöglicht es jedem, über die aktuellen Entwicklungen und den Fortschritt informiert zu sein.

Vorteile der visuellen Darstellung von Aufgaben:

Kausalität. Jede Aufgabe führt zu einem globalen Ziel. Aufgaben werden nach kleineren Zielen gruppiert. Der Infrastruktur-Domain ist von Natur aus recht technisch. Es ist nicht immer sofort klar, welchen konkreten Einfluss beispielsweise das Schreiben eines Runbooks zur Migration auf einen anderen Nginx auf das Geschäft hat. Eine danebenstehende Zielkarte macht dies verständlicher.

Kausalität ist eine wichtige Eigenschaft von Aufgaben. Sie beantwortet direkt die Frage: 'Mache ich das Richtige?'
Parallelität. Wir sind neun Personen, und es ist einfach physisch unmöglich, dass alle an einer Aufgabe gleichzeitig arbeiten. Manchmal reichen die Aufgaben aus einem Bereich nicht aus. Daher teilen wir die Arbeit zwangsweise auf kleinere Arbeitsgruppen auf. Diese Gruppen arbeiten eine gewisse Zeit an ihrer Aufgabe, und sie können mit weiteren Personen verstärkt werden. Von dieser Arbeitsgruppe scheiden manchmal Mitglieder aus. Jemand geht in den Urlaub, jemand hält einen Vortrag auf der DevOps-Konferenz, jemand schreibt einen Artikel für Habr. Es wird sehr wichtig, zu wissen, welche Ziele und Aufgaben parallel bearbeitet werden können.

2. Wechselnde Leitung der morgendlichen Meetings. Bei den Stand-ups gab es folgendes Problem – viele Aufgaben werden parallel erledigt. Manchmal sind die Aufgaben nur schwach verbunden, und es fehlt das Verständnis, wer was macht. Die Meinung eines weiteren Teammitglieds ist jedoch sehr wichtig. Es ist zusätzliche Information, die den Verlauf der Problemlösung verändern kann. Natürlich ist man normalerweise mit jemandem im Paar, aber Beratung und Hinweise sind immer hilfreich.

Um diese Situation zu verbessern, haben wir die Technik des "Wechselns des Lead-Standup-Moderators" angewendet. Jetzt rotieren sie entsprechend einer festgelegten Liste, und das hat seine Wirkung. Wenn du an der Reihe bist, musst du eintauchen und verstehen, was passiert, um das Scrum-Meeting gut zu gestalten.

3. Internes Demo. Hilfe bei der Lösung von Aufgaben durch Pair Programming, Visuellisierung im Aufgabenbaum und Unterstützung in den Scrum-Meetings am Morgen – das ist gut, aber nicht perfekt. In einer Partnerschaft bist du nur durch dein Wissen limitiert. Der Aufgabenbaum hilft, ein globales Verständnis dafür zu entwickeln, wer was macht. Der Moderator und die Kollegen in der morgendlichen Sitzung werden nicht tief in deine Probleme eintauchen. Dabei können sie sicher etwas übersehen.

Die Lösung wurde im gegenseitigen Vorführen der abgeschlossenen Arbeiten und der anschließenden Diskussion darüber gefunden. Wir treffen uns einmal pro Woche für eine Stunde und zeigen die Details der Lösungen zu den Aufgaben, an denen wir in der vergangenen Woche gearbeitet haben.

Im Verlauf der Demonstration sollten die Details der Aufgabe offen gelegt und unbedingt deren Funktion demonstriert werden.

Der Bericht kann nach einem Checklistenformat gehalten werden.1. Führe in den Kontext ein. Woher kam die Aufgabe, warum war das überhaupt nötig?

2. Wie wurde das Problem vorher gelöst? Gab es zum Beispiel Massenklicks, oder war es überhaupt unmöglich, etwas zu tun?

3. Wie verbessern wir das? Zum Beispiel: „Sehen Sie, jetzt gibt es ein kleines Skript, hier ist die Readme“.

4. Zeigen Sie, wie das funktioniert. Es wäre ideal, ein Nutzungsszenario direkt zu demonstrieren. Ich möchte X, mache Y und sehe Z (oder J). Zum Beispiel: Ich deploye NGINX, teste die URL und erhalte 200 OK. Wenn eine Aktion lange dauert, bereiten Sie dies im Voraus vor, um es zeigen zu können. Es ist wünschenswert, dass man eine Stunde vor der Demo nicht mehr viel daran ändert, wenn es anfällig ist.

5. Erklären Sie, wie erfolgreich das Problem gelöst wurde, welche Herausforderungen geblieben sind, was noch nicht abgeschlossen ist und welche Verbesserungen in Zukunft möglich sind. Zum Beispiel: Jetzt haben wir CLI, später wird es vollständige Automatisierung im CI geben.

Es wäre wünschenswert, dass jeder Redner in 5-10 Minuten bleibt. Wenn Ihre Präsentation offensichtlich wichtig ist und mehr Zeit in Anspruch nehmen wird, klären Sie dies im Voraus im Kanal sre-takeover.

Nach dem vor Ort stattfindenden Teil folgt unbedingt eine Diskussion im Thread. Hier erhalten wir das benötigte Feedback zu unseren Aufgaben.

Am Ende wird eine Umfrage durchgeführt, um den Nutzen des Geschehens zu ermitteln. Das ist bereits ein Feedback zur Relevanz des Vortrags und der Wichtigkeit der Aufgabe.

Lange Schlussfolgerungen und was kommt als Nächstes

Es könnte den Anschein haben, dass der Ton des Artikels etwas pessimistisch ist. Das ist jedoch nicht der Fall. Zwei grundlegende Ebenen zur Einholung von Feedback, nämlich Tests und Pair Programming, funktionieren. Nicht ganz so perfekt wie in der traditionellen Entwicklung, aber der positive Effekt ist vorhanden.

Die Tests, in ihrer aktuellen Form, bieten nur eine teilweise Codeabdeckung. Viele Konfigurationsfunktionen bleiben ungetestet. Ihr Einfluss auf die tatsächliche Arbeit beim Programmieren ist gering. Doch Integrationstests zeigen positive Ergebnisse, und gerade sie ermöglichen es, Refactoring ohne Bedenken durchzuführen. Das ist ein großer Fortschritt. Mit dem Wechsel zum Hochsprachenentwicklungsfokus (bei uns Python, Go) verschwindet das Problem. Und für die "Kleber" sind zu viele Prüfungen nicht notwendig, eine allgemeine Integration reicht aus.

Die Zusammenarbeit hängt stark von den spezifischen Personen ab. Es gibt die Aufgabe und unsere Soft Skills. Mit manchen klappt es sehr gut, mit anderen weniger. Der Nutzen ist definitiv vorhanden. Es ist klar, dass selbst bei unzureichender Einhaltung der Regeln für die Partnerarbeit der gemeinsame Ansatz bei der Aufgabenbewältigung sich positiv auf die Qualität des Ergebnisses auswirkt. Persönlich arbeite ich in der Partnerschaft einfacher und angenehmer.

Höherwertige Ansätze zur Beeinflussung des Betriebssystems – die Planung und Bearbeitung von Aufgaben zeigen deutliche Effekte: einen qualitativ hochwertigen Austausch von Wissen und eine Verbesserung der Entwicklungsqualität.