Paarprogrammierung mit Scrum

Ich bin in einem Team, das derzeit Scrum verwendet, und wir erwägen, Paarprogrammierung hinzuzufügen, um die funktionsübergreifenden Fähigkeiten des Teams zu verbessern und Fehler mit der Philosophie "Zwei Köpfe sind besser als einer" zu reduzieren.

In unserem Team meldet sich jedes Teammitglied normalerweise während der Sprintplanung für eine vollständige Arbeitsbelastung an (wobei "voll" eine Zahl ist, die weniger als 40 Stunden pro Woche beträgt und Besprechungen, Zusammenarbeit usw. ermöglicht), mit einem einzigen dedizierten Eigentümer für Jede Aufgabe. Ich glaube, dass dies in Scrum-Teams ziemlich häufig vorkommt, aber nicht unbedingt nach dem Buch.

Insbesondere möchte ich eine Situation vermeiden, in der Teammitglieder zögern, sich zu paaren, weil sie ihre eigenen Aufgaben haben, an denen sie arbeiten müssen. Ich befürchte, dass dies wahrscheinlich passiert, wenn sich das Team einfach selbst organisiert, ohne Zeit für das Pairing aufzuwenden .

Was ist vor diesem Hintergrund der beste Weg, um Aufwand / Stunden / Story-Punkte in einem Pairing-Szenario zu berücksichtigen, um sicherzustellen, dass wir ausreichend Zeit für das Pairing haben?

Einige Optionen sind:

1. Erlauben Sie zwei Personen, sich für jede Aufgabe anzumelden, und verdoppeln Sie (ungefähr) die Anzahl der geschätzten Stunden
2. Nur das Teammitglied "Hände auf der Tastatur" meldet sich für jede Aufgabe an, die basierend auf den geschätzten Stunden dieser Person geschätzt wird. Jeder im Team, der das Pairing unterstützt, meldet sich für weniger Aufgaben im Sprint an, um Zeit für das Pairing zu haben.

Die häufigste Option, die ich bei der Verwendung der Paarprogrammierung in Scrum gesehen habe, besteht darin, die Entwicklungsschätzungen zu verdoppeln.

Das heißt, wenn die Aufgabe für eine Person auf 3 Stunden geschätzt wird, beträgt die zugewiesene Zeit für das Paar 6 Stunden.

Ersetzen Sie Punkte durch Stunden, wenn Sie sich dadurch sauberer fühlen;)

Ich denke, andere haben bereits gute Antworten geliefert, aber ich werde meine nur hinzufügen, weil ich denke, dass Ihr Team gerade zu Scrum gewechselt ist und Sie sich jetzt in einer sehr ähnlichen Position befinden, als wir angefangen haben.

Zunächst einmal war unsere Einführung in Agile und insbesondere in Scrum nicht sehr reibungslos. Grundsätzlich kam das Management herunter und sagte, von diesem Tag an werden Sie Scrum machen und dies ist ein Prozess, dem Sie alle folgen werden. Soviel zu People over Process .

Der Prozess, dem wir ursprünglich gefolgt sind (blind, möchte ich hinzufügen), verlief sehr ähnlich wie Sie es beschrieben haben. Die Leute bekommen Aufgaben zugewiesen, jeder wird gebucht und wir gehen alle zurück zu unseren Schreibtischen und stecken weg. Dann haben wir jeden Tag ein langweiliges Stand-up-Meeting.

Der Schlüssel zu erkennen ist, dass es bei Agile und Scrum tatsächlich um Menschen geht. Wenn das Team mit der Iterationsplanung beginnt, lassen Sie sich von Ihrem Scrum-Master (der wahrscheinlich Ihr Manager ist) nicht Stunden, Geschichten und Aufgaben zuweisen. Es liegt ganz beim Team. Ich denke, für viele Leute ist dies ein sehr schwieriges Konzept, weil sie jahrelang zuvor zur Arbeit gekommen waren und einen Chef (Manager, technischer Leiter ...) hatten, der einfach Arbeit zuweisen würde. Sie tauchen in Scrum ein, aber jeder (einschließlich Scrum Master selbst) arbeitet weiterhin im selben Modus.

Eines Tages werden Sie es satt haben, also werden Sie anfangen, Bücher und Blogs zu lesen und beim Stapeltausch immer wieder Fragen wie diese zu stellen. Die Erkenntnis, die Sie erhalten, ist, dass Sie als Entwickler und Ihre Teamkollegen die treibende Kraft hinter dem Festlegen von Geschichten und dem Zuweisen von Aufgaben sein sollten. Wenn Sie der Meinung sind, dass Sie von der Paarprogrammierung profitieren werden, erstellen Sie auf jeden Fall zwei Aufgaben für jeden der Ingenieure und weisen Sie beiden Stunden zu. Das einzige, was Scrum Master tun sollte, ist die Geschwindigkeit anhand abgeschlossener Storys zu messen, die Sie in der vorherigen Iteration als Team geliefert haben.

Eine andere Sache, die mich nervt, ist, wie den Leuten gesagt wird, dass ihre Kapazität IMMER 75% der Gesamtstunden beträgt. Deshalb verpflichten sie sich dazu und beschweren sich dann für die gesamte Dauer der Iteration, dass a) sie nicht können Ihnen helfen oder b) sie können nicht das Richtige tun, weil ihnen zu viele Stunden zugewiesen wurden. Den Leuten sollte nicht gesagt werden, wie viele Stunden sie festlegen sollen, und sie sollten auf jeden Fall zurückschieben, wenn der Scrum Master versucht, so etwas zu ziehen! Jeder sollte sich genau dazu verpflichten, womit er sich wohl fühlt. Zum Beispiel bin ich ein Teamleiter und lande häufig in einer zufälligen ungeplanten Designdiskussion oder helfe jemandem mit Code oder bei der Fehlerbehebung bei seltsamen Dingen, sodass meine Kapazität nie über 50% liegt.

Unser Team hat 4 Release-Zyklen gebraucht, um zu lernen, die oben genannten Dinge nicht zu tun, und obwohl wir uns definitiv verbessert haben, sind wir nicht einmal halbwegs agil, wenn Sie die Experten fragen. Also noch viel zu lernen.

Update 1: Antwort auf Cliffs Kommentar Nun, Sie haben Ihre Ohren angeboten, also hier ist es ...

Sie haben Recht, kultureller Wandel ist der Schlüssel, aber dieser Wandel muss nicht auf Führungsebene stattfinden. Ihr eigener Gruppenmanager kann die Kultur in Ihrem Team ändern und Sie von der Unternehmens-BS isolieren, mit der er sich befassen muss. Was Sie beschreiben, waren genau wir von 2007 bis 2010. Unser Team (und auch andere Teams) haben Release für Release gefloppt. In einer der Releases, die den "Prozess des Agilismus" des Managements verwenden, schaffen wir es, dass 9 Personen die Arbeit produzieren, die normalerweise von einer einzelnen Person erledigt wird, und wir haben die doppelte Zeit gebraucht. Ich hatte so viel Freizeit, dass ich sogar meinen Lebenslauf aktualisiert habe.

Dann hatte ich ein Gespräch mit meinem Chef und erklärte ihm all diese Dinge, wie agil Menschen sind. Wenn Sie möchten, dass wir uns um das Produkt kümmern, lassen Sie uns Entscheidungen treffen, die sich auf unsere Arbeit und Lieferung des Produkts auswirken. Ich denke, er hat beschlossen, daraus ein Experiment zu machen, er hat jede einzelne Änderung vorgenommen, die wir ... nun, hauptsächlich ich selbst, aber ich spreche viel mit dem Rest des Teams, daher 50% Kapazität :) ... vorgeschlagen. Es ist möglich, dass er dachte, wenn er alle Änderungen vornimmt, die wir verlangen, und wir immer noch scheitern, wird er mit einem siegreichen "Ich habe es dir gesagt" zurückkommen.

In den letzten 12 Monaten haben wir so viel "Dummes" beseitigt, dass es nicht einmal lustig ist. Unsere Stand-up-Meetings sind jetzt tatsächlich sinnvoll, weil wir zusammenarbeiten, nicht isoliert. Wir sind (zumindest vorerst) immer noch Eigentümer bestimmter Teile des Produkts, aber wir wechseln auch sehr häufig in den Code des jeweils anderen. Wir führen ständig Codeüberprüfungen durch, damit nicht nur die Teammitglieder anderen Code lernen, sondern auch bessere Codierungs- und Designtechniken. Wir haben das monolithische, riesige "agile" Team in drei verschiedene Teams aufgeteilt, sodass Planungs- und andere Besprechungen viel kürzer sind und die Leute sich tatsächlich um sie kümmern, weil sie nicht herumsitzen und über Dinge hören, die ihnen egal sind. ICH' Ich habe Nächte gesehen, in denen 4 von 5 unserer Jungs (eines der Teams) abends um 23 Uhr online waren und niemand uns tatsächlich gesagt hat, dass wir hart arbeiten müssen oder uns jemals unter Druck gesetzt haben, über 40 Stunden zu arbeiten. Menschen, die sich vor einem halben Jahr nicht weniger interessieren konnten, sind plötzlich engagiert und aufgeregt über die Arbeit, die sie leisten. Und alles, was unser Manager brauchte, war zu sagen: "Ihr entscheidet, was richtig ist und tut, was ihr tun müsst, und ich werde Corporate BS so weit wie möglich aus dem Team heraushalten."

Es begann als Experiment (mein Verdacht, das hat er mir nie gesagt), aber jetzt tritt unsere Gruppe im Vergleich zu anderen Entwicklungsgruppen in der Abteilung in den Hintern und wir haben sogar andere Entwickler, die jetzt versuchen, zu uns zu kommen und sich uns anzuschließen.

Die größte Hürde für uns seit dieser Änderung (und auch heute noch ein Problem) war die Tatsache, dass Ingenieure in einer normalen Unternehmensumgebung wie experimentelle Mäuse in einem Käfig sind. Selbst wenn Ihr Manager beschließt, wirklich "agil" zu werden und den Käfig zu entfernen, sind alle so lange in diesem Käfig, dass sie nicht einmal erkennen, dass sie frei sind. Trotz aller Freiheit tun sie so, als wären sie immer noch eingeschränkt. Ich denke, was helfen würde, wenn mindestens wenige Leute im Team wären (wie Sie selbst), die über die Grenzen der Gruppe hinausgehen und nach besseren Möglichkeiten suchen, Dinge zu tun. Dann komm zurück in diese Gruppe und rühre sie ein wenig auf.

In Ihrem Fall ist gepaarte Programmierung möglicherweise keine Lösung, wenn Sie nach einer anderen externen Kraft suchen, die in das Team kommt und ihnen sagt, wie sie arbeiten sollen. Werfen Sie stattdessen die Regeln raus, setzen Sie sich ohne Management zu ihnen und fragen Sie sie, was sie tun möchten. Was wird sie glücklich machen? Produktiv? Identifizieren Sie die größten Probleme und fragen Sie das Team, welche Lösung Ihrer Meinung nach sein sollte.

Scrum schreibt nicht vor, dass Aufgaben Einzelpersonen zugewiesen werden - weit davon entfernt. Die Verantwortung für die zu erledigenden Aufgaben liegt beim gesamten Team. Wenn das Team eine Paarprogrammierung durchführen möchte, bei der jedes Paar eine Aufgabe übernimmt, sollte es dies mit Sicherheit tun.

Aus dem Scrum Guide :

Das Entwicklungsteam beginnt normalerweise mit dem Entwurf des Systems und der Arbeit, die erforderlich ist, um das Product Backlog in ein funktionierendes Produktinkrement umzuwandeln. Die Arbeit kann unterschiedlich groß sein oder einen geschätzten Aufwand haben. Während des Sprint-Planungstreffens ist jedoch genug Arbeit geplant, damit das Entwicklungsteam vorhersagen kann, was es im kommenden Sprint tun kann. Die vom Entwicklungsteam für die ersten Sprinttage geplanten Arbeiten werden bis zum Ende dieses Meetings in Einheiten von höchstens einem Tag zerlegt. Das Entwicklungsteam organisiert sich selbst, um die Arbeit im Sprint-Backlog sowohl während des Sprint-Planungstreffens als auch nach Bedarf während des gesamten Sprints durchzuführen .

Das Zuweisen von Aufgaben zur Planung von Besprechungen ist genau das, was gegen zeitliche Entscheidungen und die Stärkung des Teams verstößt. Es widerspricht auch der Beweglichkeit des Sprints, da jeder Entwickler seit dem ersten Tag im Sprint genau das ausgerichtet hat, was er tun soll. Dies bedeutet auch, dass jede Aufgabe sehr richtig geschätzt werden muss, was fast nie der Fall ist.

Das Schätzen von Aufgaben ist überflüssig. Sie haben sich zu einer Reihe von Geschichten verpflichtet, und die Planung von Meeting 2 ist gerade genug Zeit, um diese Geschichten in Aufgaben aufzuteilen und Karten für diese Aufgaben zu erstellen (oder sie in ein System zu füllen). Es ist nicht genügend Zeit vorhanden, um jede Aufgabe zu schätzen, und diese Schätzung sollte keine Zeit für die tatsächliche Entwicklung verbrauchen.

Warum? Schätzung ist ein Müll. Wie kann es ein Müll sein? Weil mehr Schätzungen nicht mehr Geschäftswert bringen = es ist Müll und sollte auf das notwendige Minimum reduziert werden. Das Minimum ist das Schätzen / Bemessen von Geschichten, was Ihnen hilft, Engagement zu zeigen. Sobald Sie eine Verpflichtung eingegangen sind, benötigen Sie keine weitere Schätzung. Sie wissen nur, dass Sie einen festen Termin haben, um etwas zu liefern, das Sie zugesagt haben. Sie können entweder engagierte Geschichten liefern oder nicht. Das Schätzen von Aufgaben hilft Ihnen bei dieser Lieferung nicht.

Das Überspringen der Aufgabenschätzung hat keinerlei Einfluss auf die Sichtbarkeit des Sprintfortschritts, da die einzige tatsächliche Messung des Fortschritts die Anzahl der abgeschlossenen Storys (Story Points) ist und diese weiterhin im Sprint-Burndown-Diagramm angezeigt werden kann.

Nur um es klar zu machen. Engagement bedeutet = Wir werden es tun . Nicht wir werden versuchen es oder irgendetwas anderes zu tun. Ja, Sie können möglicherweise nicht das liefern, was Sie begangen haben, aber Ihr Engagement sollte auf Ihrer Überzeugung beruhen, dass Sie mit Ihrem aktuellen Wissen ausgewählte Geschichten liefern werden. Wenn Sie diesen Glauben haben, brauchen Sie keine weitere Schätzung.

Ich habe Scrum immer so verwendet, wie Entwickler eine neue Aufgabe auswählen, sobald er seine letzte abgeschlossen hat. Entwickler sagen normalerweise, welches sie bei einem Stand-up-Meeting auswählen werden. Im Allgemeinen gibt es keine Regeln, welche Aufgabe er wählen sollte. Es liegt an der Selbstorganisation des Teams und an der Diskussion zwischen den Teammitgliedern (außerhalb des Stand-up-Meetings). Dies bedeutet, die Entscheidung auf den spätestmöglichen Zeitpunkt zu verschieben, an dem Sie auf einige Änderungen und Probleme reagieren können, ohne Ihren imaginären Plan zu beeinträchtigen. Die Aufgabe selbst kann sogar den Eigentümer ändern, wenn jemand Probleme hat, sie auszuführen. Alternativ kann eine solche Aufgabe paarweise entwickelt werden.

Wie kann die Paarprogrammierung daran beteiligt sein? Leicht. Das Team engagiert sich und das Team muss es schaffen, Platz für alle Entwicklungstechniken zu schaffen, die erforderlich sind, um das Arbeitsinkrement des Produkts zu erreichen. Schätzen Sie eine Aufgabe oder Aufgabenentwicklung und Aufgabentests? Der letztere Ansatz ist völlig falsch. Das Testen ist Teil der Entwicklung und ebenso ist die Codeüberprüfung oder das Pairing bei Bedarf Teil der Entwicklung.

Die Paarprogrammierung sollte dazu führen, dass die Aufgabe mit einer geringeren Anzahl von Fehlern und einer besseren Codequalität schneller erledigt wird. Es wird nicht doppelt so schnell sein, so dass immer noch ein gewisser Aufwand anfällt, aber die tatsächlichen Auswirkungen auf das Engagement, die durch gelegentliche Paarungen verursacht werden, sollten sehr gering sein. Dies ist kein Fall für Mentoring oder Unterricht. Wenn Sie einen solchen Entwickler haben, der betreut oder unterrichtet werden muss, sollten Sie seine Kapazität überhaupt nicht für Sprints planen, bei denen er die Codebasis des Produkts oder eine Technologie lernt.