XP, Pair Programming – Additional Benefits vs. costs

Voraussetzungen:
Das Team muss harmonieren. Nur wenn die zwischenmenschliche Beziehung passt, sind die Grundvoraussetzungen erfüllt!

Zeit für die Einarbeitung – kalkulierbar?
Als allgemeingültig werden rund 3 bis 6 Monate an Einarbeitung in ein neues Projekt angesehen. Die tatsächliche Zahl ist natürlich abhängig von der Komplexität, den Vorkenntnissen und der Rolle, die es zu übernehmen gilt.
Es gilt: Je höher die Komplexität, desto höher die erforderliche Zeit. Je größer die Vorkenntnisse sind, desto schneller beginnt der produktive Einsatz.

Meine persönliche Empfehlung:
Gebt dem Pair rund zwei Wochen Zeit, sich aufeinander einzustellen.
Eine Vorhersage, wie lange es pro Team tatsächlich dauert, lässt sich nicht verallgemeinern. Bei dem einen Paar klappt das ab dem dritten Tag, bei einem Zweiten erst nach 10. Gebt den Teams genug Freiraum und die Möglichkeit zur Klärung der optimalen Arbeitsweise/- umgebung – vor allem bei einer Junior – Senior Konstellation. Auch ein Senior lernt nie aus.

Kleines Beispiel:
Lässt man alle anderen Faktoren weg und betrachtet ausschließlich die benötigte Zeit (netto) um eine zweite Person einzuarbeiten, kommt man – meiner persönlichen Einschätzung nach – mit rund 1/3 der durchschnittlichen Zeit für eine Einarbeitung aus. Das bedeutet für ein Unternehmen, dass beide Personen schneller produktiv eingesetzt werden können. Der Coach kann seinen eigentlichen Tätigkeiten nachkommen und die neue Person im Team wird von Anfang an stärker eingebunden, z.B. in das Tagesgeschäft. 

Weitere Faktoren:
Urlaub, Termine, Unterstützung von Kollegen verändern die Zeit (netto) natürlich, was zwangsläufig zu einem längeren Zeitraum führt.

Gefahren und Missverständnisse
Es muss immer beachtet werden, dass Pair Programming kein Allheilmittel darstellt. Auch diese Methode muss von Fall zu Fall geprüft werden, ob es dem Projekt oder dem Team den gewünschten Nutzen bringt.

Fazit:
Gehen wir aktuell von rund 2/3 der Zeit aus, die im klassischen Sinne benötigt wird, dann lassen sich immerhin bis zu 33% Arbeitszeit und somit Kosten für die Einarbeitung einsparen. Was das für ein Unternehmen in Zahlen bedeutet, lässt sich aus dieser Annahme leicht ableiten.

Werbeanzeigen

DevOps – was verbirgt sich hinter dem Begriff?

In den letzten Tagen und Wochen ist das Begriff „DevOps“ in aller Munde. Sogar auf der aktuellen Basta! Konferenz in Mainz ging Paul Stack in der Keynote auf diesen Begriff näher ein. Aber was bedeutet das für das tägliche Arbeiten? Nach welchen Kriterien wird man in welchen Bereich eingeordnet? Hier ist eine Begriffserklärung notwendig, um ein möglichst gutes Verständnis für die neue Rolle zu bekommen.

DevOps – eine kurze Erklärung

Es soll die Zusammenarbeit zwischen dem Entwicklungsteam (Dev steht für Development) und dem Betriebsteam (Ops steht für Operation) symbolisieren. Neben der Zusammenarbeit geht es auch um die Verantwortung, die beide Teams für Ihren Bereich tragen. Das schwierige dabei ist – wie so oft – der Übergang zwischen diesen Rollen zu finden und zu definieren. Viel zu oft entsteht eine Art Mauer, ein Gefälle oder sogar kaum zu überwindende Gräben. Hier stellt sich mir die Frage – wo beginnt und vor allem wo hört die jeweilige Verantwortung auf?

Dev – eine kurze Abgrenzungen

Zum Dev-Team gehört der komplette Entwicklungszyklus, d.h. die Berater, die Designer, Entwickler und Tester. In vielen Fällen funktioniert die Kommunikation hier schon sehr gut – man kennt sich, zieht im Team an einem Strang und schiebt die Aufgabe von Rolle zu Rolle weiter. Am Schluss entsteht ein Stück Software, dass aus Sicht des Dev-Teams fertig ist.

Ops – eine kurze Abgrenzungen

Zum Ops-Team gehören die Administratoren rund um die Infrastruktur, Applikation, die Web- und Datenbankserver, die Kollegen aus der Hotline und dem Support im 2nd und 3rd Level – kurz: das komplette Betriebsteam.
Sie sind dafür zuständig, dass die entwickelte Applikation stabil läuft und der Kunde zufrieden gestellt ist – und vor allem auch bleibt.
Neue Problemfälle werden vom Endkunden direkt an dieses Team gemeldet. Die Erfassung und Reproduzierbarkeit von auftretenden Fehlern ist das A und O der Tätigkeit. Ohne Betrieb gibt es keine Rückmeldung an das Entwicklungsteam. Ohne Rückmeldung gehen sehr oft wichtige Informationen verloren, die eine Verbesserung der Software ermöglichen.