Wir haben ein "typisches" SCRUM-Team und verpflichten uns, für einen Sprint zu arbeiten und auch einen Rückstand aufrechtzuerhalten. Vor kurzem hatten wir das Problem, die Arbeit eines übererfahrenen Entwicklers zu integrieren / zu handhaben, der außerhalb der Bandarbeit arbeitet (wobei wir uns entschieden haben, außerhalb der normalen Arbeitszeiten / des normalen Sprints zu arbeiten).

Nehmen wir zum Beispiel an, dass das Team, wenn es 50 Punkte erledigt, die gesamte Arbeit im Rahmen von SCRUM bis zum Ende des Sprints erledigt und sie und das Unternehmen zufrieden sind. Eines der Teammitglieder beschließt, in seiner Freizeit selbstständig an einem Rückstand zu arbeiten. Sie checken diese Arbeit nicht ein, sondern speichern sie (wir verwenden TFS und sie befindet sich in einem Regal).

Wie geht man damit um? Ein paar der Probleme ..

• Während des nächsten Sprints sagt dieses Teammitglied, dass die Programmierarbeit zu 99% abgeschlossen ist und nur noch Codeüberprüfung und -tests erforderlich sind. Wie gehen Sie in der SCRUM- und Agile-Methodik damit um?
• Andere Entwickler beschweren sich darüber, dass sie nicht an Designentscheidungen im Zusammenhang mit diesen Geschichten beteiligt sind, da die Arbeit außerhalb der Band erfolgte.
• Unser Produktbesitzer ist versucht, diese "freie" Arbeit in Anspruch zu nehmen, und die übererfüllten Mitglieder tun dies wahrscheinlich absichtlich, um mehr Funktionen in das Produkt zu integrieren, die das Team sonst im Sprint (in den Sprints) nicht erreichen könnte. Es besteht die Ansicht, dass dies den "Prozess" bricht. Offensichtlich müssen noch QS-, UI- und Dokumentationsarbeiten an dieser Arbeit durchgeführt werden.

Ich sehe viele Diskussionen darüber, ein SCRUM-Team nicht zu Überstunden zu zwingen, aber was ist mit einem Mitglied des Teams, das über die Erwartungen hinausgeht, die bei der Planung und Durchführung von Sprints gestellt wurden? Ich würde zögern, diese Person zu regieren und zu sagen, dass Sie nicht extra arbeiten können (Vorsicht natürlich beim Ausbrennen), aber gleichzeitig scheint es einige Probleme mit bestimmten Mitgliedern des Teams (aber nicht allen) zu verursachen.

Wie kann die Arbeit eines überfordernden Mitglieds in den SCRUM- und agilen Prozess für die Softwareentwicklung integriert werden?

Also gut, jemand schreibt enthusiastisch großartigen Code, der getan werden muss, nur nicht in der richtigen Reihenfolge. Bei allem Nachdruck:

LASSEN SIE SIE

Es verursacht einige Komplikationen bei Ihren Scrum-Sprints. Ist es im großen Schema der Dinge wirklich wichtig? Wenn er das erreicht, was er erreichen soll, dann lass ihn weitermachen und großartige Dinge für dich bauen.

Ich kenne einige erstaunliche Programmierer, die Unternehmen verlassen haben, weil sie die Programmierer nicht aus den Zwängen eines künstlichen Systems wie Scrum herausgelassen haben (ich selbst habe meinen letzten Job verlassen, nachdem ich wie nichts anderes als eine verherrlichte Qualitätssicherung behandelt worden war). Wenn es Beschwerden von anderen Entwicklern über Eingaben gibt (ich füge hinzu, es sind vollkommen gültige Beschwerden), ist es möglicherweise am besten, ein "20% -Zeit" -Programm einzuführen, damit er (und andere) das tun, was sie am besten können, und zwar mit minimaler Beeinträchtigung.

Lassen Sie den Entwickler mit neuen Technologien oder Funktionen experimentieren, anstatt mit zukünftigen Geschichten (für die möglicherweise andere Beiträge erforderlich sind). Möglicherweise finden Sie eine großartige neue Gelegenheit, die sonst nie in Betracht gezogen worden wäre. Ich bin sicher, dieser Entwickler hat ein paar Dinge, die er ausprobieren möchte, wenn Sie sie einfach zulassen.

Es gibt zwei Dinge, die Sie meiner Meinung nach hier berücksichtigen sollten:

1. Behindern Sie nicht den kreativen Fluss von jemandem.
   • Wenn ein Entwickler außerhalb der Geschäftszeiten arbeiten möchte, lassen Sie ihn dies tun.
2. Schaffen Sie keine Arbeit für andere.
   • Wenn ein Entwickler außerhalb der Arbeitszeit arbeiten möchte, ist es verdammt sicher besser, nicht mehr Arbeit für andere zu schaffen .

Punkt 2 ist wahrscheinlich das, worüber sich die anderen Entwickler Sorgen machen.

Wie Sie bereits erwähnt haben, gefällt ihnen die Tatsache nicht, dass der Code ohne die Eingabe des gesamten Teams geschrieben wurde. Dies kann daran liegen, dass es in Bezug auf das Design minderwertig ist. Code mit minderwertigem Design kann auch anderen Code infizieren.

Also was kannst du tun?

Lassen Sie den ehrgeizigen Entwicklercode nach Herzenslust, aber machen Sie deutlich, dass es keinen Grund gibt, anzunehmen, dass sein außerschulischer Code verwendet wird .

Schließlich ist er Teil eines Teams, und daher sollte das Team in die Entwicklung des gesamten Codes einbezogen werden.

Wenn seine Arbeit jedoch solide ist und zum vereinbarten Design des Teams passt, kann er viel von dem, was er bereits geschrieben hat, verwenden (Bonus!). Wenn nicht, wird er gezwungen sein, das nächste Mal, wenn er sich für einen Vorsprung entscheidet, mehr über sein Design nachzudenken.

Auf diese Weise wird niemandem NEIN gesagt , und niemand hat zusätzliche Arbeit für sie erstellt.

Bring ihn zurück ins Team

Sie sollten sich fragen (oder besser das Team, einschließlich des Überholers):

Warum ist dieses Verhalten ein Problem?

Da Sie den Entwickler als Überflieger bezeichnen, denke ich, dass seine Arbeit von guter Qualität ist, also gehe ich davon aus, dass dies kein Problem ist.

Aber es scheinen andere Probleme zu geben:

• Die zusätzliche Arbeit wird nicht richtig getestet
• es ist nicht dokumentiert
• Der Rest des Teams weiß es nicht
• Der Entwickler entscheidet über die nächste zu implementierende Sache, nicht die PO
• Der Entwickler erhält von den verschiedenen Stakeholdern kein Feedback, das er in seine Arbeit einbeziehen könnte.

Das nächste Warum ich so wäre:

Warum macht der Entwickler das?

• Wenn am Ende des Sprints nicht mehr genug Arbeit übrig ist, sollte eine Teamentscheidung (einschließlich der PO) darüber getroffen werden, was als nächstes angegangen werden soll. Warum vermeidet der Entwickler diese Entscheidung?

Sobald Sie diese Fragen beantwortet haben, können Sie Ihre eigene Frage beantworten:

• Wenn es kein Problem ist, lass ihn sein Ding machen. Obwohl manche Leute SCRUM als Religion behandeln, sollte es nicht so sein.
• Es ist wahrscheinlicher, dass Sie zwei Probleme im Team haben: das Problem, das vom Schurkenentwickler verursacht wurde, und das Problem, das das Verhalten des Schurkenentwicklers ausgelöst hat. Finde einen Weg, um das Problem zu lösen. Der erste wird verschwinden.

So sehr mir die Idee gefällt, dass es gut ist, freie Arbeit in den Mix aufzunehmen, ist dies keine freie Arbeit - es sei denn, dieser einzelne Entwickler ist auch der Tester, die Qualitätssicherung und der Build-Typ, der Designer und alles andere. Wenn seine Arbeit ohne Auswirkungen in den nächsten Sprint gebracht werden kann, dann machen Sie es. Aber ich denke, das ist niemals der Fall. Zumindest alle anderen müssen verstehen, was er getan hat und welche Auswirkungen es auf sie hat. Sie müssen verstehen, dass seine Änderungen in Kraft sind, um seine Bemühungen nicht zu verdoppeln - es ist schwierig, jemandem mitzuteilen, dass sie hart an einer Aufgabe gearbeitet haben, nur um herauszufinden, dass der Schurke es letzte Woche getan hat.

Sie arbeiten jedoch in einer agilen Umgebung, und ich weiß, dass Agile darauf ausgelegt ist, für Sie und nicht gegen Sie zu arbeiten. Sie müssen also Ihre Arbeitsweise ändern, um diese Art von außerschulischer Aktivität zu ermöglichen. Das bedeutet, dass Sie die Meinung und Zustimmung aller einholen müssen. Ohne deren Zustimmung können Sie dies nicht tun. Es ist lebenswichtig. Wenn das Team es nicht mag, hört der Schurke damit auf. Ende des. Es ist nicht ein Typ, der tut, was er will, egal wie gut seine Arbeit ist, es ist immer eine Teamleistung. Das Team steht an erster Stelle.

Sie müssen sich also beim nächsten Planungstreffen an alle setzen und dies besprechen. Alle Teammitglieder müssen sich dafür entscheiden, dies zuzulassen oder Ihren Prozess zu ändern, um diese Art von Aktivität besser zu verwalten.

Vielleicht bekommen Sie eine Lösung, bei der jeder an seinen Lieblingsprojekten arbeitet und sie an den Tisch bringt (Sie können sich das Chaos in Ihrer Lieferung vorstellen, das dazu führen würde :), das das Problem an erster Stelle hervorhebt), oder Sie können ein Mandat erteilen Bereich, in dem jeder Entwickler die Möglichkeit hat, die von ihm gewünschte Lösung zu entwickeln, ist der "Beitrag", ähnlich wie viele Open-Source-Projekte funktionieren, oder Sie können jedem Zeit zum Experimentieren geben (die alten 20% Zeit).

Schreibt dieser Entwickler Tests und bereinigten / soliden Code oder schiebt er / sie einfach alles heraus, was er schnell erledigen kann? Ich persönlich erlaube niemandem, außerhalb der festgelegten Zeiten zu arbeiten, da dies Ihre Schätzungen durcheinander bringt und Sie auf andere Probleme aufmerksam machen.

Sie sollten jedoch niemals starr in Ihrem Prozess sein. Scrum ist nur ein Framework, so dass Sie den Prozess jederzeit anpassen können, um die zusätzliche Zeit einzuschließen (aber es ist wiederum schwierig zu planen, was jemand tun könnte).

Sie können ihn auch bitten, an anderen Dingen als dem Projekt zu arbeiten. Suchen Sie nach neuen Technologien oder trainieren Sie Dinge, die er anders macht. Unterm Strich wird jedoch alles, was außerhalb Ihres geplanten Zeitplans getan wird, Ihre Schätzungen zerstören und ich würde das nicht zulassen.

Wir standen auch vor dem gleichen Problem, im Grunde haben wir ungefähr 20 Punkte vergeben, aber in der letzten Woche oder sogar in der Mitte des Sprints hatten wir keine Codierungsaufgabe mehr, aber aufgrund der Tests und des restlichen Prozesses haben wir nicht riskiert, eine andere PBI zu wählen. Na und Die Programmierer mussten den Rückstand untersuchen und anfangen, zukünftige PBIs zu entwickeln (stillschweigend!) und den Rest des Teams darüber informieren, dass PBI zur Codeüberprüfung und zum Testen bereit ist! Genau so, wie Sie sagten.

Es gab tatsächlich Anlass zur Besorgnis, dass wir in der Lage zu sein scheinen, aber das Potenzial unseres Teams nicht voll auszuschöpfen, was zum Teil zutrifft, aber ja, vielleicht könnten unsere Programmierer mehr tun, aber unsere Tester könnten diesem Tempo nicht folgen Es bestand die Gefahr, dass der Sprint fehlschlug. Nach einigem Nachdenken über dieses Thema fand heraus wir , dass wir unsere Ansicht ändern über Gedränge und der Hauptsache müssen , ist , dass die Menschen , dass das Risiko nicht nehmen wollen, weil wir Commit PBIs so Team , dass die Gefahr der Kommissionierung nicht zu nehmen ein gutes Gefühl neue PBIs für den Fall, dass wir freie Programmierer haben.

Einfach haben wir begonnen zu Prognose PBIs anstatt make Engagement. Prognostizieren bedeutet im Grunde, dass wir 25 Punkte bei der Planung und beim Start des Sprints auswählen. Wenn der Programmierer in der Mitte des Sprints frei ist, weil keine weitere Codierungsaufgabe mehr vorhanden ist, wählt er / sie eine der zukünftigen PBIs aus und legt sie im aktuellen Sprint ab und beginnt mit der Arbeit Wenn die PBI den gesamten Prozess (Testen, Zusammenführen und usw.) innerhalb desselben Sprints bestehen konnte, ist dies ein Bonuspunkt für das Team, wenn der Sprint aufgrund dieser PBI NICHT fehlschlägt und die verbleibende Arbeit fortgesetzt wird ( Testen oder Meging oder etc) bis zum nächsten Sprint und erneutes Poker für den verbleibenden Job. So kann es im ungünstigsten Fall in zwei verschiedenen Sprints durchgeführt werden. Ich weiß, es klingt vielleicht nach Scrumbut, aber es hat unsere Arbeitsweise tatsächlich verbessert. Ich kann die Vorteile wie folgt zusammenfassen:

• Es besiegt die Phobie, dass der Sprint fehlschlägt, weil es das Risiko eingeht, mehr PBI zu nehmen
• Es macht die Mehrarbeit Ihrer Programmierer und Ihres Teams sichtbar
• Es erhöht die Geschwindigkeit Ihres Teams

Aber vielleicht für ein Team mit weniger Erfahrung, vielleicht verringert es den Druck, den das Team aufbringt, um die PBIs zu beenden

Einige der anderen Antworten deuten darauf hin, dass der "übererfüllte" Entwickler "Schurke" oder "Verstoß gegen die Scrum-Prinzipien" ist. Dies ist falsch und dieser Entwickler sollte ermutigt werden (obwohl Sie die Leute nicht bitten sollten, in dieser zusätzlichen Zeit an etwas Bestimmtem zu arbeiten, aber Sie könnten Vorschläge machen und helfen, Ideen zu fördern).

In Scrum gibt es nichts, was vorschreiben würde, wie die Leute arbeiten, und alles, was er zusätzlich tat, würde natürlich in die Geschwindigkeit des Teams einfließen.

Seine Arbeit sollte in den Product Backlog einfließen und in der nächsten Planungssitzung geschätzt werden. Wenn Sie den verbleibenden Aufwand nicht sofort vorhersagen können, sollten Sie einige Zeit des Sprints einplanen, um ihn zu ermitteln (dh einen Spike).

Interessanterweise beschreiben Sie den Entwickler als "übererfüllt". Ich gehe davon aus, dass dies bedeutet, dass er wesentlich mehr Wert schafft als die anderen Teammitglieder.

Die Schwierigkeiten, die durch zusätzliche Arbeit entstehen, implizieren, dass in Ihrem Team etwas nicht optimal (oder möglicherweise sogar nicht funktionsfähig) ist.

Wenn dies der Fall ist, sollten Sie sich fragen, warum er mit vermutlich nur ein wenig zusätzlichem Aufwand so viel mehr erreicht?

Ist es möglich, dass Sie den Rest des Teams in die Lage versetzen, mehr zu erreichen?

Ich habe die Situation erlebt, in der Teams mikroverwaltet wurden, möglicherweise über bestimmte User Stories, die Definition von erledigt, was die Entwickler letztendlich behindert. Macht dieser Entwickler die Arbeit, die er möchte? Ich gehe davon aus, dass er gute Entscheidungen trifft. Würde es auch dem Rest des Teams helfen, in der Arbeitswoche so zu arbeiten?

Lassen Sie sie auch Lehrer sein

Es ist großartig, dass Sie einen Star-Entwickler mit den besten und fortgeschrittensten Fähigkeiten in der Gruppe haben. Ich würde das loben und beglückwünschen. Oft sind solche Leute der „Klebstoff“, der Organisationen zusammenhält.

Ich würde die Herausforderung als "wie man weniger erfahrene Entwickler der Produktivität der fortschrittlichsten Entwickler näher bringt" betrachten.

Eine gute Möglichkeit, dies zu tun, besteht darin, sich darauf zu konzentrieren, dass der Star-Entwickler mehr Zeit für das Unterrichten, Trainieren und Führen der weniger erfahrenen und langsameren Teammitglieder aufbringt. Ich würde dies zuerst 1-zu-1 mit dem Star-Entwickler besprechen, damit er weiß, was Sie tun und warum. Andernfalls kann es mit Argwohn als versteckte Agenda / schlechtes Management angesehen werden

Wenn Sie ein- oder zweimal am Tag aufstehen und dieser Person die Arbeit ausgeht und andere noch Aufgaben erledigen, sollten Sie auf Pair-Programming achten, damit sie sich mit den Junior-Mitgliedern paaren und ihr großartiges Wissen und ihre Erfahrung weitergeben kann. Stellen Sie sicher, dass Sie die Frage "Braucht jemand Hilfe? Sucht jemand ein Paar?"

Sie könnten auch eine Nebenbeschäftigung für den besten Entwickler finden, wenn dieser gerade nicht arbeitet, z. B. das Toolset verbessern, das von allen verwendet wird, eine Diskussionsgruppe für technische Buchclubs leiten oder an anderen organisatorischen Projekten beteiligt sein.

Ich werde eine andere Frage beantworten. Ich denke, wie man mit dieser Situation in Scrum umgeht, ist wirklich nicht wichtig. Scrum ist sowieso eher eine Richtlinie. Wenn dies geschehen soll, finden Sie eine einfache Möglichkeit, Ihren Prozess anzupassen, indem Sie einfach davon ausgehen, dass die Arbeit bereits erledigt ist.

Die eigentliche Frage ist, ob Sie wollen, dass dieser Entwickler das tut, was er tut. Ich denke, dass verschiedene Aspekte eine Schlüsselrolle bei der Beantwortung dieser Frage spielen:

1. Macht der Programmierer gute Arbeit?
2. Ist es allen recht, wenn er seine Arbeit alleine macht (sei es gut oder schlecht)? Schließlich weicht er dem Designprozess aus!
3. Werden die zusätzlichen Stunden bezahlt oder nicht?

All diese Faktoren beeinflussen, ob es für Ihr Produkt sinnvoll ist, dass er das tut, was er tut. Auch hier ist es kein Problem, Ihre Entscheidung in den Entwurfsprozess einzubeziehen. Sei einfach flexibel.

Dies verstößt gegen einen Mieter von Scrum, da das Team nicht über die Arbeit im Sprint entscheidet. Dies ist ein Scrum- Team . Das Team muss diesen Programmierer disziplinieren, wenn Disziplin ausgegeben werden soll.

Ein weiteres Problem ist, dass es mit der Geschwindigkeit des Teams verschraubt. Out-of-Band-Arbeit zählt nicht für Velocity und Burn-Down. Damit ist diese Out-of-Band-Arbeit erledigt, das Team erreicht durchschnittlich 50 Geschwindigkeitspunkte, aber es werden mehr als 50 Punkte erledigt. Der Produktbesitzer wird dies bemerken und im nächsten Sprint eine höhere Geschwindigkeit fordern. Geschwindigkeit, die möglicherweise nicht möglich ist.

Das Team (nicht die PO oder der ScrumMaster) muss dies mit dem Schurkenprogrammierer besprechen.