Ratschläge für den Umgang mit einem Cowboy-Programmierer in einem agilen Team

So wie es sich anhört, haben Sie dieses Problem auf den Entwickler isoliert, und das (imo) bedeutet, dass Sie Ihren Prozess ändern müssen, um sicherzustellen, dass solche Probleme nicht ständig auftreten, oder die Interaktionen mit diesem Entwickler ändern.

Nebenbei bemerkt: Zählen Sie die Aufgaben/Geschichten an der Tafel nicht als mögliche Ursache für diesen Scope Creep.

Scope Creep resultiert aus einer schlecht verstandenen User Story:

Haben Sie in das Schreiben guter User Stories investiert ?

Haben Ihre Stories klar definierte Akzeptanzkriterien (Akzeptanzkriterien sind die Anforderungen, die erfüllt werden müssen, damit eine Story als vollständig bewertet wird) ?

Wenn Sie diese Fragen mit Ja beantworten, möchten Sie vielleicht mit dem Team darüber sprechen, den Prozess zu ändern, wenn ein Teammitglied eine Aufgabe vom Board aufnimmt, um eine Diskussion mit dem Product Owner (oder wer auch immer den PO vertritt) aufzunehmen. . Diese Diskussion soll lediglich sicherstellen, dass der Entwickler klar versteht, was „Fertig“ bedeutet.

Scope Creep ist ein Symptom des Entwicklers und nicht des Prozesses:

Sie müssen ein offenes Gespräch mit dieser Person führen. Sie müssen wissen, dass der Scope Creep, den sie den Geschichten hinzufügen, an denen sie arbeiten, das Projekt und das gewünschte Ergebnis der Geschichte beeinflusst. Wenn sie „Ideen“ haben, sollten Sie sie ermutigen, sie vorzubringen, aber sie nicht blindlings in die Geschichte einprogrammieren.

Wenn sich ihr Verhalten nach dieser Diskussion nicht ändert, würde ich sie aus dem Team entfernen.

Scope Creep ist ein Symptom der Team-Definition of Done:

Wie werden Geschichten in Ihrem Team akzeptiert? Den Geräuschen nach sagen Sie, dass, wenn die Geschichte auf "erledigt" verschoben wird, eine große Menge an Aufblähung hinzugefügt wird, aber sie wird immer noch auf "erledigt" und "akzeptiert" verschoben.

In jedem Team, in dem ich gearbeitet habe, hätte ich, wenn die „Schnickschnack“ nicht zur User Story beigetragen hätten (oder manchmal sogar existierten), sie abgelehnt und zurück in den Status „In Bearbeitung“ verschoben, bis die Akzeptanzkriterien erfüllt wären für diese Geschichte. Sie tun dies ein paar Mal und es wird den Einzelnen ziemlich klar, dass sie das Nötigste entwickeln sollten, das die Akzeptanzkriterien der Geschichten erfüllt

Scope Creep ist ein Symptom des individuellen Designs:

Wird das Design vom Team überprüft, bevor ein Entwickler die Story programmiert? Wenn nicht, könnte dies etwas sein, das Sie Ihrem Prozess in Form einer Designsitzung hinzufügen. Stellen Sie sicher, dass Sie den PO oder PO-Vertreter einbeziehen, um sicherzustellen, dass das vorgeschlagene Design das absolute Minimum ist, um die Annahmekriterien der Geschichten zu erfüllen. Beachten Sie, dass diese Designsitzung einfach eine Ad-hoc-Diskussion vor einem Whiteboard sein könnte.

Individuen und Interaktionen über Prozesse und Tools

Ich würde ein Gespräch mit einzelnen führen, es im Nachhinein oder vielleicht sogar im Stehen ansprechen. Verbringen Sie nicht zu viel Zeit damit, herauszufinden, wie Sie dieses Problem über den Prozess lösen können. Soweit Sie wissen, könnte diese Person all diese Goldplattierungen vornehmen, weil sie der Meinung ist, dass dies erforderlich ist, um in den Augen des Managements „gut auszusehen“. Vermute nicht.

Ich würde vorschlagen, sich mit dieser Person zu paaren (Paarprogrammierung), wenn sie das nächste Mal eine Geschichte von der Tafel nimmt.

Als ich das letzte Mal mit einer Cowboy-Programmiererin gearbeitet habe, überließ ich ihr die volle Verantwortung für das „ Etwas mehr “:

1. Sie musste es alleine integrieren, bereitstellen und freigeben
2. Als jemand anderes ihre Lösung nicht testen, integrieren oder bereitstellen konnte, hörte das Team auf zu arbeiten, ebenso wie sie, und sie musste das Problem beheben
3. Als das Management uns nach der aufgewendeten Zeit fragte, musste sie das "Plus" erklären, einschließlich der Verzögerungen, die ich zuvor erwähnt hatte

Es mag hart klingen, aber Cowboy -Programmierer haben das Gefühl, dass sie tun können, was sie wollen, während im Hintergrund jemand anderes die Beinarbeit erledigt. Sobald sie die Beinarbeit machen müssen, "beruhigen" sie sich und werden Teil des Teams oder sie bitten ums Verlassen.

Ich habe die Antworten gelesen und ich habe das Gefühl, dass es einige kleine Einblicke gibt, derer Sie sich bewusst sein sollten.

Untersuchen. Was ist die Quelle eines Cowboy-Codierungsverhaltens?

Als Manager sollten Sie Ihr(e) Team(s) und die Motivation der Menschen kennen. Eines der möglichen Probleme wurde von @Jeese erwähnt und es könnte das wahrscheinlichste sein. Aber denken Sie bitte daran, dass Sie sich sicher sein sollten, was Sie heilen möchten, um die richtige Lösung zu finden.

(alternative Motivationen: Cowboy zeigt sich gerne in einem guten Licht / sie ist eine kreative Person / sie kümmert sich mehr um die Benutzer als um Product Owner / Ihrer Organisation fehlt es an Erfindungen und sie findet es die einzige Möglichkeit, einige vorzustellen / etc.)

Machen Sie es zu einer Win-Win-Situation

@ Jeese sagte auch etwas sehr Wichtiges: Wenn sie "Ideen" haben, sollten Sie sie ermutigen, sie vorzubringen, aber sie nicht blindlings in die Geschichte einzucodieren.

Es mag sein, dass am Aufgabenumfang nichts auszusetzen ist, aber der Programmierer ist eine sehr kreative Person. Das Schlimmste wäre, ihre Arbeitsfreude und ihren kreativen Output zu verlieren. Du könntest die Kreativität nicht aufhalten, es wird passieren, egal was passiert. Aber sie kann andere Geschichten für die Ideen erstellen und die aktuelle Arbeit von zusätzlichen Verbesserungen trennen.

Messen und entscheiden

@ David sagte eine wichtige Sache: Gute Dinge könnten von einer Schurken-Personalquelle kommen, aber viele schlechte Dinge werden von ihm kommen

... und ich würde das hinzufügen: wahrscheinlich kommen schon viele gute und schlechte Dinge von ihr.

Im Laufe der Zeit sollten Sie entscheiden, ob Ihre Gesamtbilanz positiv oder negativ ist. Sie sind derjenige, der entscheidet, ob Sie Zeit haben, um in der Situation Ihres Projekts eine Win-Win-Situation zu erzielen. Wie hoch sind die Kosten des Problems, gibt es ein gutes Ergebnis und wie sind die Prognosen?

Wenn Sie eine vollautomatisierte Aufgabe hätten, die "lange dauert, bis sie fertig ist, und als Lösung und "etwas mehr" herauskommt", würden Sie das tolerieren? Oder würden Sie die störende Komponente finden und reparieren/ersetzen?

Gute Dinge könnten von einer schurkischen Personalabteilung kommen, aber viele schlechte Dinge werden auch von ihm kommen, Dinge wie Scope Creep, Gold Plating, das letztendlich abgelehnt wird, verlängerter Zeitplan, erhöhte Kosten. Sie balancieren also aus, was gut passieren könnte, und was schlecht passieren wird.

Lohnt sich meiner Meinung nach nicht. Finden Sie die störende Komponente, reparieren oder ersetzen Sie sie.

Wie wäre es mit einer integrierten Zuckerbrot-Peitsche-Methodik:

Stock: Erklären Sie ihm, dass Geschichten aus der Tafel so schnell wie möglich wie beschrieben umgesetzt werden müssen. Wenn eine verbesserte/erweiterte Version der Story implementiert wird, verzerrt dies nicht nur die Schätzung, sondern erzeugt auch einen Test-/Bereitstellungs-/Wartungsaufwand, den das Projekt als Ganzes tragen muss. Üben Sie Druck auf ihn aus, die Aufgabe innerhalb der geschätzten Zeit zu erledigen, und wenn er es immer noch schafft, mehr als erforderlich zu erledigen, drücken Sie die Schätzungen nach unten. Machen Sie es ihm schwer, die geschätzte Zeit zu überschreiten.

Karotte: Erklären Sie ihm, dass er, wenn ihm während der Implementierung der Story zusätzliche Funktionen einfallen, diese notieren und beim nächsten Story-Meeting vorstellen sollte. Ermutigen Sie dieses Verhalten, indem Sie gute Ideen loben, ihre Vorzüge besprechen etc. Stellen Sie ihn und seine Idee für ein paar Minuten in den Mittelpunkt und sorgen Sie dafür, dass mindestens ein oder zwei davon tatsächlich umgesetzt werden, wenn auch nur in einem geänderte Form.

Hoffentlich hat er mehr davon, die Geschichten in einem öffentlichen Forum beizutragen, als er derzeit davon hat, sie alleine umzusetzen.

Sie haben gerade einen großartigen Kandidaten und eine zukünftige Führungskraft gefunden. Dieser Mann hat seine eigenen Ideen. Er hat den Charakter, für sie zu schleifen. Er hat keine Angst davor, das zu tun, was er für das Beste hält. Er hat keine Angst vor Hitze usw. Ich frage mich, ob ihm einfach langweilig ist und ob er neue herausfordernde Projekte oder Aufgaben braucht? Du solltest ihn herausfordern. Geben Sie ihm etwas sehr Schwieriges oder fast Unmögliches. Geben Sie ihm dafür eine kurze Frist. Planen Sie eine ehrliche Belohnung ein, wenn er erfolgreich ist, und sagen Sie es ihm im Voraus. Ich würde mit Ihrem Vorgesetzten über diesen Mann sprechen und ihm einen Mentor ernennen. Wenn er mit all dem zusammenarbeitet und seine Fähigkeiten unter Beweis stellt; Er wird eine große Bereicherung für Ihr Team und Ihr Unternehmen sein.