Ist es richtig, Scrum-Mitglieder nach der Anzahl der erfolgreich abgeschlossenen User Stories zu bewerten?

Als mein Manager dem Team sagte, dass "ab jetzt erfolgreiche User Stories für die Bewertung berücksichtigt werden! "

Wir saßen schockiert da und das war einer der vielen atemberaubenden Momente, die er uns gab :-)

Wir hielten das für eine dumme Idee, da dies alle Konzepte und Ziele einer agilen Entwicklungsmethodik ruinieren wird.

Lassen Sie mich wissen, was Sie Leute denken? und wie können wir ihn überzeugen?

Sandy, leider ist die Aussage Ihres Managers ein klassisches Missverständnis von Scrum im Besonderen und Agilität im Allgemeinen.

Der vorgeschlagene Ansatz beendet die Zusammenarbeit und wirkt dem Prinzip des kollektiven Code-Eigentums entgegen . Agile User Stories (wenn es sich um echte Agile handelt) werden selten fertiggestellt, bevor sie von mehreren Personen berührt werden. Außerdem haben Sie von Zeit zu Zeit User Stories, die schwärmen müssen, um innerhalb der Iteration fertig zu werden. Wie kommen Sie alle dazu, wenn die einzelnen Anreize um 180 Grad in die entgegengesetzte Richtung ausgerichtet sind?

Die Instinkte Ihres Teams sind korrekt. Welche Quellen würde ich Ihnen kurzfristig vorschlagen, um sie zu lesen, während Sie die Antwort an Ihren Manager erarbeiten? Schauen Sie sich Blogs renommierter agiler Experten wie Mike Cohn , Martin Fowler , Elizabeth Hendrickson , Jürgen Appelo , Esther Derby und einige andere an und suchen Sie nach Artikeln über agile Teamorganisation.

Mein hauptsächlicher Einwand gegen diese Bewertungsmethode ist, dass sie ein Hindernis für die Zusammenarbeit zwischen Entwicklern sein kann. Ich denke, dass ein wichtiger Teil der Produktivität eines Entwicklungsteams die Bereitschaft der Teammitglieder ist, sich gegenseitig zu helfen. Soweit ich das vorgeschlagene Schema verstehe, könnte es dazu führen, dass Entwickler bei ihren eigenen zugewiesenen Aufgaben bleiben und andere Teammitglieder ignorieren, die stecken bleiben und leicht durch ein wenig Unterstützung gelöst werden können.

Wir sind immer auf der Suche nach dem Beitrag, den der Programmierer zum Team und zum Unternehmen leistet.

Dies entspricht dem Messen von Codezeilen oder der Anzahl von Fehlern - ist jedoch etwas ausgefeilter.

Auf den ersten Blick ist an der Messung nichts auszusetzen, aber wenn Sie darüber nachdenken, erheben Sie Einwände:

• Was ist mit komplizierteren Geschichten?

ist die offensichtlichste, die mir in den Sinn kommt - ich bin mir sicher, dass es noch andere gibt.

Ihr Manager hält dies offensichtlich für eine gute Idee. Sie müssen also darauf achten, dass Sie bei Einwänden auch Lösungen präsentieren können. Diese Lösung muss möglicherweise eher eine Änderung seines Schemas als ein neues Schema sein.

So möchten Sie vielleicht darauf hinweisen, dass jemand, der nur an "einfachen" Geschichten arbeitet, mehr vervollständigt als jemand, der an einer "schwierigeren" arbeitet, und dies könnte zu einer Konzentration auf die weniger wichtigen Aspekte der Entwicklung führen. Eine Lösung könnte also darin bestehen, die Anzahl der Story-Punkte und nicht nur die Anzahl der Storys zu berücksichtigen.

Ich stimme ChrisF zu, dass dies bei jeder Messung auf dasselbe Problem zurückgeht. Was Sie loben, bekommen Sie. Es wird immer Leute geben, die das System spielen, was auch immer dieses System sein wird.

Die einzige wirklich effektive Methode, die ich gefunden habe, um Programmierer zu belohnen, besteht aus drei Schritten.

1. Leads kennen und verstehen die Fähigkeiten der Mitarbeiter in ihrem Team.
2. Manager hören auf die Empfehlungen der Leads für Teammitglieder, die nicht ihr Gewicht ziehen.
3. Das Team wird insgesamt für erfolgreiche Sprints gelobt.

Der gesamte Schlüssel ist, dass Programmierer keine Zahnräder in einer Maschine sind, die durch Betrachten von Statistiken "eingestellt" werden können. Die realen Menschen müssen als Ganzes untersucht und verbessert werden, und das Team muss in der Lage sein, sich kooperativ und nicht wettbewerbsfähig aufeinander zu verlassen.

Die schlechten Leistungsträger im Team erhalten jede Gelegenheit zur Verbesserung und Bereicherung, bevor sie als entlassen gelten. Letztendlich werden gute Programmierer in diesem Umfeld gedeihen und die armen Programmierer, die sich weigern, verbessert zu werden, werden entlassen.

In den meisten Fällen werden User Stories gemeinsam erstellt. Dies macht es praktisch unmöglich, eine individuelle Bewertung auf diese Metrik zu stützen.

Die Metrik selbst kann leicht manipuliert werden, da der Planungsprozess auch eine Teamleistung ist und sogar früher als später das gesamte System manipuliert wird. Das ist definitiv das, was Sie in einem auf Menschen ausgerichteten Prozess nicht wollen.

Ich denke, eine gute Leistung muss durch eine Art Bonussystem anerkannt werden, das auf dem Teamerfolg basiert, aber User Stories sind kein guter Indikator für den Erfolg.