Wann ist die beste Zeit, um Story-Aufgaben zu erstellen?

Vom Command-and-Control zur Selbstorganisation

Es sieht so aus, als ob Ihr Team (und vielleicht auch Ihre Organisation) mit dem Übergang von einem Command-and-Control-Managementstil zu einem agilen Management zu kämpfen hat. Dieser Artikel enthält einige Tipps.

Hier sind aus meiner Erfahrung einige Dinge, die helfen könnten:

• Beschreibt der Product Owner das Sprint-Ziel zu Beginn jedes Sprint-Planungsmeetings? Dies hilft dem Team zu verstehen, was von ihm erwartet wird und warum.
• Der Scrum Master sollte keine Aufgaben erstellen. Dies sollte dem Entwicklungsteam überlassen werden. Sie sind diejenigen, die die Arbeit machen werden.
• Wie schätzen Sie Story Points ein? Ich empfehle die Planning-Poker-Methode . Das gesamte Entwicklungsteam erhält die Chance, sich mit der anstehenden Arbeit vertraut zu machen.
• Eine Möglichkeit, die Entwickler zur Teilnahme zu ermutigen, besteht darin, das Sprint Planning in zwei Teile aufzuteilen. Im ersten Teil der Sprint-Planung kann das Team die Storys in der Prioritätsreihenfolge diskutieren, vom Product Owner Erläuterungen zu den Anforderungen und Akzeptanzkriterien erhalten und festlegen, wie viel Arbeit im Sprint erledigt werden kann (basierend auf Story Points). . Im zweiten Teil kann der Scrum Master zurücktreten und dem Entwicklungsteam die Führung überlassen. Das Team erstellt Aufgaben für jede Geschichte, basierend darauf, wie sie sie erreichen wollen.
• Schicken Sie, wie @CodeGnome vorgeschlagen hat, mehr Leute zum Scrum-Training. Wenn Sie ein knappes Budget haben, lassen Sie diejenigen, die bereits ausgebildet sind, die anderen schulen.

Einführung

Die Aufteilung der Stories in kleinere Stories sollte vom Product Owner vorgenommen werden. Scrum Master und Entwickler können dabei helfen, insbesondere beim Backlog Refinement (Grooming).

Die Aufteilung von Stories in Tasks (gemeint sind: technische Aufgaben) liegt ausschließlich in der Verantwortung des Entwicklungsteams – hier geht es darum, WIE die Stories umgesetzt werden.

Daher glaube ich, dass weder Scrum Master, PO noch Sie (wenn Sie kein Entwickler sind) Geschichten nicht auf (technische) Aufgaben aufteilen sollten.

Ich habe gerade eine Frage zu „wer?“ beantwortet. und nicht „wann?“, aber das war zur Klarstellung. Jetzt Antworten auf Ihre Fragen:

Antworten

a) Die Antwort auf „Wann?“ ist meiner Meinung nach: beim Sprint Planning . Ich denke, dafür ist kein anderes formelles Meeting in Scrum vorgesehen. Auch wenn jemand sieht, dass der Geschichte eine Aufgabe hinzugefügt werden kann, kann er sie hinzufügen. Aber formal wird WIE die Geschichten implementiert werden, unter den Entwicklern während des Sprint-Planungsmeetings besprochen.

b) Bitten Sie den Scrum Master, mit dem Reden aufzuhören ;), während des Planungsmeetings keine Daten mehr in JIRA einzugeben. Er sollte das Treffen moderieren und die Entwickler ermutigen, diese Arbeit zu erledigen und dies nicht an ihrer Stelle zu tun. Geben Sie den Entwicklern Stifte und Postit-Sticker mit Story-Namen und lassen Sie sie die Aufgaben für diese Story auf einen Sticker schreiben. Und nimm die Tastatur von Scrum Master . Während des Meetings braucht er es nicht. Geben Sie es jemand anderem.

Denken Sie an Empowerment, an die Förderung der Selbstorganisation des Entwicklerteams. Sie werden diese Arbeit nicht anfangen, wenn SM sie für sie erledigt. Etwas „Raum“ muss geschaffen werden. Geben Sie ihnen das Gefühl, für technische Lösungen verantwortlich zu sein, Geschichten in Aufgaben aufzuteilen.

c) SM sollte PO vor der Planung dabei unterstützen , User Stories zu erstellen, aufzuteilen und besser verständlich zu machen . Tut er das?

UPDATE zu a):

Die Aufgaben wie: Design, Tests, Review sollten Teil der allgemeinen Definition of Done des Teams sein. Ich glaube nicht, dass es notwendig ist, sie während der Planung in die Geschichte einzufügen. Es hängt davon ab, was das Ziel ist, sie dort hinzuzufügen - sie visualisieren zu lassen, damit der Umfang der Geschichte gut eingeschätzt werden kann, oder einfach eine Checkliste zu haben, ob alle Schritte erledigt wurden.

Wenn es für die Schätzung benötigt wird und das Team es vorzieht, es aufgeschrieben zu haben, dann ist es in Ordnung. Wenn das Team diese Aufgaben in JIRA haben möchte, um eine Art Checkliste zu haben (möchten sie? Oder wollen Sie es? :)), dann kann ein Entwickler diese allgemeinen Aufgaben hinzufügen, wenn er mit der Arbeit an einer Story beginnt. Bei der Planung würde es reichen, es zu erwähnen - das kann SM: "Leute denken daran, dass Sie auch Unit-Tests brauchen".

In meinem Team sind Aufgaben, die während der Planungssitzung zu einer Story hinzugefügt wurden, eher wie folgt: Hinzufügen einer neuen Schaltfläche zu Bildschirm A, Erstellen eines neuen Bildschirms B, Erstellen einer neuen DB-Tabelle, Verbessern der SQL-Abfrage. Wir stellen "Unit-Tests"-Aufgaben normalerweise dann, wenn wir wissen, dass wir in einer bestimmten Geschichte viel Aufwand bei der Erstellung/Wartung von Unit-Tests erwarten. Normalerweise schreiben wir "Unit-Tests"-Aufgaben nicht in eine Story, da wir alle wissen, dass sie erledigt werden müssen.

Dies ist das häufige Problem, mit dem alle konfrontiert waren, die neu bei Agile sind. Denn bei Agile geht es mehr darum, Eigenverantwortung und Verantwortung zu übernehmen, was bei anderen Methoden fehlte. Zur Beantwortung Ihrer Frage..

1. Bevor Sie zum Sprint Planning Meeting gehen, sollten Business Analyst und Product Owner eine Diskussion führen und die Liste der Funktionen, die Sie haben, entsprechend Ihren Geschäftsanforderungen priorisieren. Vor der Priorisierung sollte der Business Analyst die Funktionen in kleine Aufgaben aufteilen und diese mit PO priorisieren. Auf diese Weise können Sie beim Sprint-Planungsmeeting Zeit für Diskussionen vermeiden, welche Funktionen angesprochen werden sollen.

2. Um Ihre Entwickler stärker einzubeziehen, sollten Sie ihnen zunächst beibringen, wie Agile funktioniert. Machen Sie ihnen klar, dass Sie die Verantwortung übernehmen sollen. Dies kann auf einfache Weise geschehen. Vermeiden Sie in Ihren ersten Meetings Personen aus dem Managementteam, sorgen Sie dafür, dass sich Ihr Entwicklerteam wohl fühlt, und stellen Sie sicher, dass das, was auch immer sie sprechen, nicht an das Managementteam weitergegeben wird. An den ersten Tagen können Sie ihnen etwas Zeit geben. Sagen Sie ihnen, dass dies Funktionen nach Priorität sind. Gehen Sie zurück. Führen Sie eine Aufwandsschätzung durch. Teilen Sie dem Team mit, wie viel Zeit Sie benötigen, wer an welcher Funktion arbeitet usw. Auf diese Weise können Sie sie einbeziehen.

3. Wie ich oben erwähnt habe, sollten sich PO und BA vor dem Planungsmeeting treffen und die für jeden Sprint zu erstellenden User Stories priorisieren.

Wie andere Antworten bereits angedeutet haben, geht es wirklich um Eigentum. Meiner Erfahrung nach lösen Entwickler wirklich gerne Probleme – das bringt ihnen Zufriedenheit bei ihrer Arbeit. Normalerweise, wenn ich ein geringes Maß an Interaktion sehe, liegt das daran, dass die Entwickler das Gefühl haben, dass sie eine Liste mit Dingen geben, die zu tun sind, und sie sich nur fügen. Das mag passieren oder auch nicht, aber ich habe noch nie einen Fall von geringer Beteiligung gesehen, bei dem dies nicht die Wahrnehmung war.

Das ist das gleiche Problem, das Wasserfall hat. Tier 1, die Unternehmensführung, entscheidet über einige Anforderungen und gibt sie an Tier 2, das PMO, weiter, dann erstellen sie Aufgaben und geben sie an Tier 3, die Entwickler, die sie erstellen, dann gehen wir die Kette wieder hinauf und hoffen, sie zu flüstern Die Gasse ist nicht passiert.

Der Schlüssel ist, dass alle Ebenen gleichzeitig aktiviert werden. Das Projekt sollte damit beginnen, dass das Team einen allgemeinen Überblick darüber erhält, was es im Projekt zu erreichen versucht. Wenn Sie sich dann jedem Abschnitt nähern, bevor Sie mit der Sprintplanung beginnen, überprüfen Sie Ideen und Anforderungen mit Teammitgliedern (nicht Wenn Sie ein großes Team haben, müssen es nicht alle sein. Wenn Sie beispielsweise beabsichtigen, das Benutzerfeedback im nächsten Sprint anzugehen, bitten Sie den Product Owner einige Tage vorher, das Team zum Mittagessen einzuladen und zu sagen: „Ich möchte, dass Benutzer in der Lage sind, mit einem einzigen Klick von jeder Seite aus Feedback zu geben“ – oder Was auch immer das übergeordnete Bedürfnis ist - "So wie diese Seite - was denkt ihr? Wie könnten wir X verwirklichen?" Nehmen Sie dieses Gespräch und bügeln Sie einige grundlegende Geschichten aus, um während der Sprintplanung zu arbeiten. Jetzt haben Sie die Idee für ein paar Tage in ihren Köpfen, sie haben einige Ideen ins Rollen gebracht, und sie kommen in die Sprint-Planung, wissen, worüber sie sprechen werden, und sind bereit, einige Lösungen zu teilen.

Haftungsausschluss: Ich weiß, dass dies Scrum irgendwie bricht, weil Sie POs und Stakeholdern erlauben, das Team von der Arbeit zu nehmen. Meiner Erfahrung nach überwiegen die Vorteile, das Team dazu zu bringen, sich für die Lösung zu engagieren und sie zu besitzen, bei weitem die Tatsache, dass Sie sie für eine Weile von der Arbeit nehmen. Abgesehen davon ist es etwas, dessen man sich bewusst sein und das man kontrollieren muss – wenn es außer Kontrolle gerät, spule es wieder ein.

Dies kann auch sehr gut funktionieren, wenn es in anderen Meetings nicht üblich ist. Projekt-Kickoffs und Release-Planung zum Beispiel sind ebenfalls großartige Orte, um diese Gespräche zu beginnen. Zusätzliche Zeit für Entdeckungs- und Brainstorming-Aktivitäten in umfassenderen Planungssitzungen wie der Release-Planung aufzuwenden, kann sich während des gesamten Projekts wirklich auszahlen.

Eine letzte Sache: Machen Sie sich nicht zu viele Gedanken darüber, wie lange es dauert. Sie haben Recht, sich Sorgen zu machen, dass es keine Beteiligung gibt, aber wenn die Meetings produktiv sind und es den ganzen Tag dauert, dann muss es vielleicht so lange dauern. Wenn Sie für solche Besprechungen willkürliche Zeitfenster auswählen, fühlen sich die Leute gehetzt und überspringen wertvolle Diskussionen, die später noch schlimmere Probleme verursachen.

Wir arbeiten im Wesentlichen an der agilen Methodik und ich arbeite für das Team, das fast ähnlich ist, aber ein Haufen QA, nicht die Entwickler. Bevor Sie die Fragen beantworten, sollten Sie einige Grundlagen über die Personen wissen, mit denen Sie zusammenarbeiten. Wenn Sie etwas einführen, erwarten Sie nicht, dass Sie Antworten erhalten, insbesondere wenn Sie etwas wirklich Neues einführen. Motivation ist für sie wirklich wichtig, indem sie ein wenig kichern und freundlich sind, um ihnen irgendwie zu zeigen, was ihr Interesse an welchem ​​Teil der Entwicklung ist, da nicht jeder Experte für alle von ihnen entwickelten Funktionalitäten sein kann. Wenn Sie also in ihrer Freizeit in ihren Köpfen graben, hilft Ihnen das zunächst, ihr Gehirn zu verstehen!

Beantwortung der von Ihnen gestellten Fragen:

1. Stellen Sie sicher, dass sich Entwickler wohlfühlen, wenn sie Sie brauchen, wenn sie Sie brauchen. Sie können tatsächlich mit Sitzungen als „Interaktive Sitzungen“ beginnen, in denen jeder einzelne Entwickler über das Thema des jeweiligen Projekts spricht oder etwas sein kann, das Sie einführen, und das Thema von Ihnen zugewiesen wird. Dies sollte im Voraus informiert werden, um auf diese Themen vorbereitet zu sein und alle dazu zu bringen, ihnen zuzuhören! Bitten Sie sie, 10 bis 15 Punkte zu dem vorgegebenen Thema vorzubereiten! Jeder kann Fragen stellen und Zweifel äußern, und das wäre obligatorisch, und in diesen interaktiven Sitzungen muss sich jeder öffnen und sagen, worauf er Lust hat, da hochrangige Mitglieder der Organisationen nicht an diesen Sitzungen teilnehmen werden, damit sie diese Freiheit haben. Durch diese Sitzungen sind sie gut auf das Projekt oder das Thema vorbereitet, was Sie wollen,
2. Nach diesen aufeinanderfolgenden Treffen zwischen Ihnen und den Entwicklern vor der Einführung des Projekts können Sie die Entwickler einbeziehen. Es ist anfangs schwer, dies zu tun, aber sobald Sie ihnen beigebracht haben, wie man spricht, was man fragen soll und was nicht! dann bin ich sicher, dass Sie die Menge schlagen werden! Nun, das kann passieren, aber nur durch die Anstrengung, die Sie investieren. Da dies ein reales Szenario ist, was ich Ihnen als erklärende Antwort gegeben habe, bin ich zuversichtlich, dass Sie es gewinnen werden!
3. Ich würde Sie tatsächlich darauf hinweisen, den folgenden Link für PO vor einer Sprint-Planung durchzugehen: http://www.cs.fsu.edu/~baker/swe1/restricted/notes/scrum.html#(8) Bitte Lassen Sie mich wissen, ob diese Antworten für Sie hilfreich sind. Vielen Dank !