🥇Infrastructure as Code: wie man Probleme mit XP löst

Hallo, Habr! Früher habe ich mich über das Leben im Paradigma "Infrastructure as Code" beschwert und nichts zur Lösung der Situation beigetragen. Heute bin ich zurückgekehrt, um zu erzählen, welche Ansätze und Praktiken helfen können, aus dem Abgrund der Verzweiflung auszubrechen und die Situation in die richtige Bahn zu lenken.

Im vorherigen Artikel "Infrastructure as Code: Erste Bekanntschaft" Ich habe meine Eindrücke in diesem Bereich geteilt, versucht über die aktuelle Situation nachzudenken und sogar angedeutet, dass die Standardpraktiken, die allen Entwicklern bekannt sind, helfen könnten. Es könnte den Anschein erweckt haben, dass es dort viele Klagen über das Leben gab, aber keine Vorschläge, um aus der bestehenden Situation herauszukommen.

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

Im Moment befinden wir uns im SRE Onboarding Team, das aus sechs Programmierern und drei Infrastrukturtechnikern besteht. Wir alle versuchen, Infrastructure as Code (IaC) zu schreiben. Wir tun dies, weil wir grundsätzlich in der Lage sind, Code zu schreiben und in unserer Vorgeschichteentwickler auf "überdurchschnittlichem" Niveau sind.

Wir haben eine Reihe von Vorteilen: einen bestimmten Hintergrund, Wissen über Praktiken, die Fähigkeit, Code zu schreiben, den Wunsch, Neues zu lernen.
Und es gibt einen hängenden Teil, das ist der Nachteil: Mangel an Wissen über die materielle Grundlage der Infrastruktur.

Technologiestack, den wir in unserem IaC verwenden.

Terraform zur Erstellung von Ressourcen.
Packer zur Erstellung von Images. Dies sind Windows- und CentOS 7-Images.
Jsonnet, um eine leistungsstarke Build-Konfiguration in drone.io zu erstellen, sowie zur Generierung von Packer-JSON und unseren Terraform-Modulen.
Azure.
Ansible bei der Vorbereitung von Images.
Python für Hilfsservices sowie Provisionsskripte.
Und das alles in VSCode mit den Plugins, die zwischen den Teammitgliedern geteilt werden.

Mein Fazit war folgendes: Ich habe versucht, (vor allem in mir selbst) Optimismus zu wecken und wollte sagen, dass wir versuchen werden, die uns bekannten Ansätze und Praktiken anzuwenden, um mit den Herausforderungen und Schwierigkeiten umzugehen, die in diesem Bereich bestehen. des vorherigen Artikels Aktuell kämpfen wir mit folgenden Problemen in IaC:

Unvollkommenheit der Werkzeuge und Mittel zur Entwicklung von Code.

Langsame Bereitstellung. Die Infrastruktur ist Teil der realen Welt, und diese kann nicht schnell sein.
Mangel an Ansätzen und Praktiken.
Wir sind Neulinge und wissen viel nicht.
Extreme Programmierung (XP) eilt zur Hilfe.

Extreme Programmierung (XP) eilt zur Hilfe

Allen Entwicklern ist Extreme Programming (XP) und die damit verbundenen Praktiken gut bekannt. Viele von uns haben nach diesem Ansatz gearbeitet, und er war erfolgreich. Warum also nicht die Prinzipien und Praktiken nutzen, die dort verankert sind, um die Herausforderungen der Infrastruktur zu bewältigen? Wir haben beschlossen, diesen Ansatz anzuwenden und zu sehen, was dabei herauskommt.

Überprüfung der Anwendbarkeit des XP-Ansatzes auf Ihr GebietIch beschreibe die Umgebung, für die XP gut geeignet ist, und wie das mit uns zusammenhängt:

1. Dynamisch veränderliche Softwareanforderungen. Uns war klar, was das Endziel ist. Aber die Details können variieren. Wir entscheiden selbst, wo wir hinsteuern, daher ändern sich die Anforderungen regelmäßig (hauptsächlich von uns selbst). Wenn man das SRE-Team betrachtet, das die Automatisierung selbst durchführt und auch die Anforderungen und den Arbeitsumfang selbst festlegt, passt dieser Punkt gut.

2. Risiken durch feste Zeitprojekte unter Verwendung neuer Technologien. Es können Risiken auftreten, wenn wir unbekannte Dinge verwenden. Und das ist 100 % unser Fall. Unser gesamtes Projekt besteht darin, Technologien zu nutzen, mit denen wir nicht ganz vertraut sind. Das ist ein ständiges Problem, da im Bereich Infrastruktur ständig viele neue Technologien entstehen.

3,4. Kleines, ko-lokalisiertes erweitertes Entwicklungsteam. Die von Ihnen verwendete Technologie ermöglicht automatisierte Unit- und Funktionstests. Diese beiden Punkte passen nicht ganz zu uns. Erstens sind wir kein ko-lokalisiertes Team, und zweitens sind wir neun Personen, was als großes Team angesehen werden kann. Obwohl, nach einigen Definitionen ist ein „großes“ Team ab 14+ Personen.

Lassen Sie uns einige Praktiken aus XP betrachten und wie sie die Geschwindigkeit und Qualität des Feedbacks beeinflussen.

Das Prinzip des Feedbackzyklus in XP

Für mich ist Feedback die Antwort auf die Frage, ob ich es richtig mache, ob wir in die richtige Richtung gehen. Dazu gibt es in XP eine großartige Grafik: 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 zur Diskussion, das in unserer IT-Industrie die Möglichkeit bietet, schnell Feedback zu erhalten. Stellen Sie sich vor, wie schmerzhaft schwierig es wäre, ein Projekt über ein halbes Jahr zu machen und erst dann zu erfahren, dass von Anfang an ein Fehler eingebaut wurde. Das passiert sowohl in der Planung als auch beim Bau komplexer Systeme.

In unserem Fall hilft uns IaC mit Feedback. Ich nehme sofort eine kleine Anpassung im obigen Schema vor: Der Release-Plan hat keinen monatlichen Zyklus, sondern findet mehrmals täglich statt. An diesen Zyklus sind einige Praktiken gebunden, die wir näher betrachten werden.

Wichtig: Feedback kann die Lösung für alle oben genannten Probleme sein. In Kombination mit XP-Praktiken kann es aus der Tiefe der Verzweiflung helfen.

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

Tests

Tests werden im Feedback-Zyklus von XP zweimal erwähnt. Das ist nicht zufällig. Sie sind für die gesamte Technik des extremen Programmierens äußerst wichtig.

Es wird vorausgesetzt, dass du Unit- und Akzeptanztests hast. Die einen geben dir Feedback innerhalb weniger Minuten, die anderen erst nach mehreren Tagen, da sie länger geschrieben werden und seltener ausgeführt werden.

Es gibt eine klassische Testpyramide, die zeigt, dass von bestimmten Tests mehr vorhanden sein sollten.

Wie ist dieses Schema auf unser IaC-Projekt anwendbar? Tatsächlich… überhaupt nicht.

Es kann nicht zu viele Unit-Tests geben, obwohl es sehr viele geben sollte. Entweder testen sie etwas sehr indirekt. Tatsächlich kann man sagen, dass wir sie überhaupt nicht schreiben. Aber hier sind einige Anwendungen für solche Tests, die wir dennoch gemacht haben:
1. Testen des Codes in Jsonnet. Zum Beispiel unser Build-Pipeline in Drone, die recht komplex ist. Der Code in Jsonnet wird gut getestet.
  Wir verwenden dieses Unit Testing Framework für Jsonnet.
2. Tests für Skripte, die beim Starten der Ressource ausgeführt werden. Skripte in Python, daher können auch entsprechende Tests dafür geschrieben werden.
Es ist grundsätzlich möglich, die Konfiguration in den Tests zu überprüfen, aber wir machen das nicht. Es gibt auch die Möglichkeit, die Prüfung von Konfigurationsrichtlinien für Ressourcen über tflint. Allerdings sind die Prüfungen dafür in Terraform zu grundlegend, aber viele Prüfungs-Szenarien wurden für AWS geschrieben. Aber wir sind auf Azure, also passt das wieder nicht.
Komponententests: hier hängt es davon ab, wie du sie klassifizierst und wohin du sie legst. Aber sie funktionieren grundsätzlich.
So sehen die Integrationstests aus.

Dies ist ein Beispiel beim Erstellen von Images in Drone CI. Um dorthin zu gelangen, muss man 30 Minuten warten, bis das Packer-Image erstellt ist, dann noch etwa 15 Minuten warten, bis sie durchlaufen. Aber sie existieren!
Algorithmus zur Überprüfung von Images
1. Zuerst muss Packer das Image vollständig vorbereiten.
2. Neben dem Test gibt es ein Terraform mit lokalem Status, mit dem wir dieses Image bereitstellen.
3. Bei der Bereitstellung wird ein kleines Modul verwendet, das nebenan liegt, um die Arbeit mit dem Image zu erleichtern.
4. Wenn das VM-Image bereitgestellt ist, können die Überprüfungen beginnen. In der Regel werden die Überprüfungen auf der Maschine selbst durchgeführt. Es wird überprüft, wie die Skripte beim Hochfahren ausgeführt wurden und wie die Daemons funktionieren. Dazu gelangen wir über ssh oder winrm auf die gerade gestartete Maschine und überprüfen den Zustand der Konfiguration oder ob die Dienste hochgefahren sind.
Eine ähnliche Situation gilt für Integrationstests und die Module für Terraform. Hier ist eine kurze Tabelle, die die Besonderheiten solcher Tests erklärt.

Das Feedback im Pipeline ist etwa 40 Minuten. Alles dauert sehr lange. Es kann für Regressionstests verwendet werden, ist aber für neue Entwicklungen praktisch unmöglich. Wenn man sich sehr gut darauf vorbereitet, die Skripte und die Laufzeit vorbereitet, kann man es auf 10 Minuten reduzieren. Aber es sind trotzdem keine Unit-Tests, die in 5 Sekunden 100 Tests ermöglichen.

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

Zum Beispiel mussten wir sicherstellen, dass sich die virtuelle Maschine beim Start im Dienst registriert ScaleFT, und sie sich beim Löschen der virtuellen Maschine selbst entfernt.

Da ScaleFT bei uns als Dienst fungiert, sind wir gezwungen, über die API mit ihm zu arbeiten. Es wurde eine Wrapper geschrieben, die aufgerufen werden kann mit: "Geh und lösche dies und das". Sie speichert alle notwendigen Einstellungen und Zugriffe.

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

Ergebnisse der Tests: Unit-Tests, die innerhalb einer Minute von der OS bereitgestellt werden sollten, liefern dies nicht. Höhere Testarten in der Pyramide bringen zwar Ergebnisse, decken aber nur einen Teil der Probleme ab.

Pair Programming

Tests sind natürlich gut. Man kann viele davon schreiben, sie können unterschiedlich sein. Sie werden auf ihren Ebenen funktionieren und uns Feedback geben. Aber das Problem mit schlechten Unit-Tests, die die schnellste ОС ermöglichen, bleibt bestehen. Dabei bleibt der Wunsch nach einer schnellen ОС, mit der es leicht und angenehm ist zu arbeiten. Ganz zu schweigen von der Qualität der resultierenden Lösung. Glücklicherweise gibt es Techniken, die ein noch schnelleres Feedback als modulare Tests ermöglichen. Das ist das Ziel des Pair Programmings.

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

Aber das Warten kann lange dauern. Die Leute sind alle beschäftigt, und die Antwort, selbst wenn sie kommt, könnte von nicht allzu hoher Qualität sein. Angenommen, die Antwort kommt sofort, der Reviewer versteht sofort den ganzen Plan, aber die Antwort kommt trotzdem mit Verzögerung, nachträglich. Man möchte das eher. Das Paar-Programmieren zielt darauf ab, dies zu ermöglichen – um sofort, im Moment des Schreibens, Feedback zu erhalten.

Im Folgenden beschreibe ich die Stile des Pair Programmings und deren Anwendbarkeit bei der Arbeit mit IaC:

1. Klassisch, Erfahrener+Erfahrener, Wechsel nach Zeit. Zwei Rollen – Driver und Navigator. Zwei Personen. Sie arbeiten an demselben Code und wechseln die Rollen nach einem zuvor festgelegten Zeitintervall.

Betrachten wir die Vereinbarkeit unserer Probleme mit dem Stil:

Problem: Unvollkommenheit der Werkzeuge und Ressourcen zur Codeentwicklung.
Negative Auswirkung: Längere Entwicklungszeit, wir verlangsamen uns, der Arbeitsrhythmus gerät ins Stocken.
Wie wir damit umgehen: Wir verwenden andere Tools, eine gemeinsame IDE und lernen außerdem Shortcuts.
Problem: Langsame Bereitstellung.
Negative Auswirkung: Verlängert die Zeit zur Erstellung eines funktionierenden Codes. Wir langweilen uns während des Wartens, und während wir warten, greifen wir zu anderen Aktivitäten.
Wie wir damit umgehen: Das haben wir nicht gelöst.
Problem: Mangel an Ansätzen und Praktiken.
Negative Auswirkung: Kein Wissen, wie man gut oder schlecht macht. Verlängert den Erhalt von Feedback.
Wie wir damit umgehen: Der Austausch von Meinungen und Praktiken in der Paararbeit löst das Problem fast.

Das Hauptproblem bei der Anwendung dieses Stils in IaC ist das unregelmäßige Arbeitstempo. In der traditionellen Softwareentwicklung hast du eine sehr gleichmäßige Bewegung. Du kannst fünf Minuten investieren und N schreiben. Zehn Minuten investieren und 2N schreiben, 15 Minuten – 3N. Hier kannst du fünf Minuten investieren und N schreiben, und dann weitere 30 Minuten und ein Zehntel von N schreiben. Hier weißt du nichts, du hast einen Stau, einen Stillstand. Das Klären der Situation benötigt Zeit und lenkt vom Programmieren ab.

Fazit: Es passt uns in reiner Form nicht.

2. Ping-pong. Dieser Ansatz sieht vor, dass ein Teilnehmer einen Test schreibt, während der andere die Implementierung dafür übernimmt. Angesichts der Schwierigkeiten mit Unit-Tests und der Notwendigkeit, einen zeitintensiven Integrationstest zu schreiben, geht die gesamte Leichtigkeit des Ping-Pong-Ansatzes verloren.

Ich kann sagen, dass wir versucht haben, die Aufgaben im Entwurf des Test-Szenarios und in der Umsetzung des Codes zu trennen. Ein Teilnehmer hat das Szenario entworfen, war in diesem Teil der Arbeit verantwortlich und hatte das letzte Wort. Der andere war für die Umsetzung zuständig. Das hat gut funktioniert. Die Qualität des Szenarios steigt mit diesem Ansatz.

Fazit: Leider erlaubt das Arbeitstempo nicht, Ping-Pong als Praxis des Pair Programming in IaC zu nutzen.

3. Strong Style. Eine komplexe Praxis.Die Idee ist, dass ein Teilnehmer der leitende Navigator wird, während der andere die Rolle des ausführenden Fahrers übernimmt. Das Entscheidungsrecht liegt ausschließlich beim Navigator. Der Fahrer tippt lediglich und kann verbal Einfluss auf das Geschehen nehmen. Die Rollen bleiben lange Zeit unverändert.

Es eignet sich gut für Schulungen, erfordert aber starke Soft Skills. An diesem Punkt sind wir gescheitert. Die Technik war schwierig. Und dabei liegt es 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 es nicht ausprobiert haben und dazu im Kontext unserer Arbeit nichts sagen können.

Allgemeine Ergebnisse zur Verwendung von Pair Programming:

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

Wir sind auf nicht ausreichende Soft Skills gestoßen. Und das Fachgebiet trägt nicht dazu bei, diese Defizite zu überwinden.

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

5. Dennoch gab es auch Erfolge. Wir haben unsere eigene Methode "Konvergenz - Divergenz" entwickelt. Ich werde kurz erläutern, wie sie funktioniert.

Wir haben feste Partner für einige Tage (weniger als eine Woche). Wir bearbeiten gemeinsam eine Aufgabe. Eine Zeit lang sitzen wir zusammen: einer schreibt, der andere sitzt da und beobachtet als Unterstützungsteam. Dann trennen wir uns für eine Weile, jeder kümmert sich um eigene Dinge, dann treffen wir uns wieder, synchronisieren uns sehr schnell, machen etwas gemeinsam und trennen uns wieder.

Planung und Kommunikation

Der letzte Block an Praktiken, durch die Probleme im Betriebssystem gelöst werden, ist die Organisation der Arbeiten an den Aufgaben selbst. Dazu gehört auch der Erfahrungsaustausch, der außerhalb der Partnerarbeit stattfindet. Schauen wir uns drei Praktiken an:

1. Aufgaben durch Zielbaum. Das allgemeine Projektmanagement haben wir über einen Baum organisiert, der unendlich in die Zukunft reicht. Technisch erfolgt das Management in Miro. Es gibt eine Aufgabe – sie ist ein Zwischenziel. Davon leiten sich entweder kleinere Ziele oder Gruppen von Aufgaben ab. Von diesen wiederum die eigentlichen Aufgaben. Alle Aufgaben werden auf diesem Board erstellt und verwaltet.

Dieses Schema bietet ebenfalls ein Feedback, das einmal täglich erfolgt, wenn wir uns in Meetings synchronisieren. Ein gemeinsamer Plan, der strukturiert und vollkommen transparent ist, ermöglicht es jedem, über das Geschehen und den Fortschritt informiert zu sein.

Vorteile der visuellen Darstellung von Aufgaben:

Ursächlichkeit. Jede Aufgabe führt zu einem bestimmten globalen Ziel. Aufgaben werden nach kleineren Zielen gruppiert. Der Infrastruktur-Domäne ist an sich recht technisch. Es ist nicht immer sofort ersichtlich, welchen konkreten Einfluss das Schreiben eines Runbooks für die Migration auf einen anderen nginx auf das Geschäft hat. Das Nebeneinander einer Zielkarte macht das deutlicher.

Ursächlichkeit 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 sich alle auf eine einzige Aufgabe stürzen. Aufgaben aus einem Bereich reichen auch nicht immer aus. Wir sind gezwungen, die Arbeit zwischen kleinen Arbeitsgruppen parallel zu teilen. Dabei arbeiten die Gruppen eine Zeit lang an ihrer Aufgabe und können von jemand anderem verstärkt werden. Von dieser Arbeitsgruppe fallen manchmal Leute weg. Manche gehen in den Urlaub, andere halten einen Vortrag auf der DevOps-Konferenz, wieder andere schreiben einen Artikel auf Habr. Zu wissen, welche Ziele und Aufgaben parallel bearbeitet werden können, wird sehr wichtig.

2. Wechselnde Moderatoren für die Morgentreffen. In den Stand-up-Meetings gab es ein Problem – viele Aufgaben werden parallel bearbeitet. Manchmal sind die Aufgaben schwach miteinander verknüpft, und es gibt kein Verständnis dafür, wer was macht. Die Meinung eines weiteren Teammitglieds ist sehr wichtig. Es handelt sich um zusätzliche Informationen, die den Verlauf der Lösung einer Aufgabe verändern können. Natürlich ist meist jemand mit dir im Paar, aber Beratung und Hinweise sind immer nützlich.

Um diese Situation zu verbessern, haben wir die Technik "Wechsel des Moderators im Standup" angewendet. Jetzt rotieren sie nach einer bestimmten Liste, und das hat seine Wirkung. Wenn deine Reihe kommt, bist du gezwungen, dich einzutauchen und zu verstehen, was vor sich geht, um das Scrum-Meeting gut abzuhalten.

3. Internes Demo. Hilfe bei der Lösung von Aufgaben durch Pair Programming, Visualisierung in Baumstrukturen und Unterstützung bei den morgendlichen Scrum-Meetings ist gut, aber nicht ideal. Im Paar bist du nur durch dein Wissen beschränkt. Der Aufgabenbaum hilft, global zu verstehen, wer was macht. Der Moderator und die Kollegen im morgendlichen Meeting werden nicht tief in deine Probleme eintauchen. Sie können mit Sicherheit auch etwas übersehen.

Die Lösung wurde im gegenseitigen Vorführen der geleisteten Arbeiten und der anschließenden Diskussion gefunden. Wir treffen uns einmal pro Woche für eine Stunde und zeigen die Details der Lösungen für die Aufgaben, die wir in der letzten Woche bearbeitet haben.

Im Rahmen der Demonstration müssen die Details der Aufgabe offenbart und unbedingt ihre Funktionsweise demonstriert werden.

Der Vortrag kann nach einer Checkliste gehalten werden.1. Bringen Sie Kontext ein. Woher stammt die Aufgabe, warum war sie überhaupt notwendig?

2. Wie wurde die Aufgabe zuvor gelöst? Zum Beispiel war massives Mausklicken erforderlich, oder es war überhaupt unmöglich, etwas zu tun.

3. Wie verbessern wir das? Zum Beispiel: "Schaut, jetzt gibt es ein Skript, hier ist die README."

4. Zeigen Sie, wie es funktioniert. Es ist wünschenswert, ein bestimmtes Benutzungsszenario direkt durchzuführen. Ich möchte X, mache Y, sehe Й (oder Z). Zum Beispiel, ich deploye NGINX, öffne die URL und erhalte 200 OK. Wenn die Aktion lange dauert, bereiten Sie es im Voraus vor, damit Sie es später zeigen können. Es ist wünschenswert, dies mindestens eine Stunde vor der Demo nicht mehr zu ändern, wenn es fragil ist.

5. Erklären Sie, wie erfolgreich das Problem gelöst wurde, welche Schwierigkeiten bestehen bleiben, was unvollendet ist und welche Verbesserungen in Zukunft möglich sind. Zum Beispiel, jetzt CLI, später wird es vollständige Automatisierung in CI geben.

Es wäre wünschenswert, dass jeder Sprecher sich in 5-10 Minuten hält. Wenn Ihr Vortrag von vornherein wichtig ist und mehr Zeit in Anspruch nimmt, koordinieren Sie dies im Voraus im Kanäle sre-takeover.

Nach dem Präsenzteil folgt zwingend eine Diskussion im Thread. Hier zeigt sich dann das notwendige Feedback zu den eigenen Aufgaben.

Am Ende wird eine Umfrage zur Nützlichkeit des Geschehens durchgeführt. Dies ist bereits Feedback zum Inhalt des Vortrags und zur Relevanz der Aufgabe.

Lange Schlussfolgerungen und was als nächstes kommt

Es könnte den Anschein erwecken, dass der Ton des Artikels etwas pessimistisch ist. Das ist nicht der Fall. Zwei niedrigschwellige Ebenen des Feedbacks, nämlich Tests und Pair Programming, funktionieren. Nicht so perfekt wie in der traditionellen Entwicklung, aber der positive Effekt ist vorhanden.

Tests in ihrer aktuellen Form bieten nur eine teilweise Abdeckung des Codes. Viele Konfigurationsfunktionen bleiben nicht getestet. Ihr Einfluss auf die unmittelbare Arbeit beim Schreiben von Code ist gering. Dennoch gibt es einen Effekt von Integrationstests, und genau diese ermöglichen es, Refactorings ohne Bedenken durchzuführen. Das ist ein großer Fortschritt. Darüber hinaus verschwindet das Problem mit dem Fokus auf die Entwicklung in Hochsprachen (wir benutzen Python, Go). Und für den 'Kleber' sind viele Überprüfungen nicht nötig, eine allgemeine Integration reicht aus.

Die Arbeit im Pair hängt mehr von den jeweiligen Personen ab. Es gibt den Faktor Aufgabe und unsere Soft Skills. Mit manchen funktioniert es sehr gut, mit anderen schlechter. Der Nutzen ist auf jeden Fall vorhanden. Klar ist, dass selbst bei unzureichender Einhaltung der Regeln für Pair-Arbeit die Tatsache des gemeinsamen Arbeitens einen positiven Einfluss auf die Qualität des Ergebnisses hat. Persönlich arbeite ich im Pair einfacher und angenehmer.

Höherstufige Methoden zur Einflussnahme auf das OS – Planung und Arbeit mit Aufgaben bringen definitiv Ergebnisse: qualitativ hochwertiger Wissensaustausch und Verbesserung der Entwicklungsqualität.