Was tun, wenn ein Teammitglied eine Sprintplanung verpasst?

Nehmen wir an, ein Teammitglied hat einen Jahresurlaub. Er wird nicht an der Sprintplanung teilnehmen, aber er wird mitten im Sprint zurück sein. Nehmen wir an, er hat eine Kapazität von 50%, dh er wird für die spätere Hälfte der Iteration verfügbar sein, sollten wir:

1. Ich habe eine Planungssitzung mit ihm, nachdem er zurück ist.

2. Machen Sie eine Planungssitzung mit ihm, bevor er in den Jahresurlaub geht, dh vor der Sprintplanung.

3. Planen Sie ihn nicht für irgendeine Aufgabe und weisen Sie ihn nicht für Sprintaufgaben zu, zB Spikes etc

4. Lassen Sie Ihre Kollegen während der Sprint-Planung in seinem Namen planen. Abwesende Personen können dann Aufgaben hinzufügen, wenn sie zurück sind und wenn sie nicht die gesamte Arbeit erledigen können, die sie erledigen können.

5. Lassen Sie ihn mit einem anderen Entwickler zusammensitzen und eine Weile lang Pair-Programmierung durchführen.

6. noch etwas..

Ich bin interessiert zu wissen, was du tust.

Hinweis: Wir machen (1) und es fühlt sich nicht richtig an.

Bei der Planung geht es darum, sich zu engagieren und engagierte User Storys in Aufgaben aufzuteilen.

Ich habe eine Planungssitzung mit ihm, nachdem er zurück ist.

Auf jeden Fall nein. Eine Planungssitzung nach seiner Rückkehr ist nicht sinnvoll, da bereits Verpflichtungen eingegangen werden mussten.

Machen Sie eine Planungssitzung mit ihm, bevor er in den Jahresurlaub geht, dh vor der Sprintplanung.

Auf jeden Fall nein. Es sollte keine Planung geben, wenn der aktuelle Sprint nicht abgeschlossen ist = das Ergebnis des aktuellen Sprints ist unbekannt und niemand weiß, ob alle User Stories abgeschlossen sind und der Kunde bei der Überprüfung mit ihnen zufrieden sein wird.

Planen Sie ihn nicht für irgendeine Aufgabe und weisen Sie ihn nicht für Sprintaufgaben zu, zB Spikes etc

Auf jeden Fall nein. Er wird zurück sein und seine Kapazität sollte für das Sprintziel verwendet werden.

Lassen Sie Ihre Kollegen während der Sprint-Planung in seinem Namen planen. Abwesende Personen können dann Aufgaben hinzufügen, wenn sie zurück sind und wenn sie nicht die gesamte Arbeit erledigen können, die sie erledigen können.

Das ist richtig. Das Team engagiert sich - kein bestimmtes Teammitglied. Das Team verpflichtet sich, eine Reihe von User Stories zu erstellen, da es seine Geschwindigkeit kennt und das Engagement für den nächsten Sprint basierend auf der verfügbaren Kapazität ändern kann. Es sollten im Voraus keine Aufgaben für einen einzelnen Entwickler vergeben werden. Entwickler sollten funktionsübergreifend sein, auch wenn dies nicht immer möglich ist. Sie sollten in der Lage sein, die User Story zumindest in Aufgaben aufzuteilen. Es kann ein Problem mit der Schätzung von Aufgaben geben, aber meiner Meinung nach wird es überhaupt nicht benötigt.

Lassen Sie ihn mit einem anderen Entwickler zusammensitzen und eine Weile lang Pair-Programmierung durchführen.

Auf jeden Fall nein. Die Paarprogrammierung sollte von der Velocity selbst abgedeckt werden. Wenn Sie nicht mit dem Entwickler rechnen, ist es dasselbe wie zu sagen, dass er den ganzen Sprint weg sein wird. Warum sollte der Kunde die Zeit des Entwicklers bezahlen, der während des Sprints nichts getan hat?

In einem idealen agilen Team sind die Mitglieder mit allen in einem Projekt verwendeten Technologien vertraut und jede Aufgabe kann von (fast) jedem Mitglied eines Teams ausgeführt werden. Wenn dies der Fall ist, nachdem Sie die Größe der Aufgaben im Backlog festgelegt und die Iteration definiert haben und die Teammitglieder ihre ersten Aufgaben aus dem Backlog ausgewählt haben, können Sie die restlichen Aufgaben einfach im Bucket belassen und sie werden vom Team übernommen Mitglieder einschließlich derjenigen, die die Planungssitzung verpasst haben.

In einer anderen üblichen Situation sind die Teammitglieder spezialisiert (einer ist ein Benutzeroberflächen-Experte, ein anderer ein Datenbank-Experte, der dritte ein Middleware-Guru usw.). In diesem Fall würde das fehlende Teammitglied seine Aufgaben in Abwesenheit zugewiesen bekommen. Möglicherweise muss er die Größe anpassen, nachdem er an Bord gekommen ist.

In einem Team, in dem "scrum" arbeitet, wird das Team selbst die Lücke schließen und eine kreative Lösung finden. Diese Situation tritt nicht oft genug auf, um die Beschreibung von Sonderfällen zu rechtfertigen. Gehen Sie für den Rest des Sprints einfach mit. Immerhin sind diese Sprints sowieso nicht sehr lang.

Urlaub, ob geplant / ungeplant, ist nur ein Teil des Spiels. @Asim Ghaffar, die vorgeschlagenen Methoden - zumindest die meisten von ihnen scheinen eine Person zu kriminalisieren, die sich vom Sprint-Planungstreffen abwesend gemacht hat. In einem Team, das einen gesunden Respekt füreinander hat, werden die persönlichen Bedürfnisse eines Menschen verstanden, und in solchen Teams herrscht gesundes Vertrauen in die Art der Arbeit, die er / sie leistet. Mit dieser Zuversicht planen sie, was sie tun können, unter Berücksichtigung der Zeit, in der verschiedene Personen für eine bestimmte Iteration / einen bestimmten Sprint von der Arbeit abwesend wären.

Es sind die harten Zeiten, die zeigen, wie professionell ein Team ist. In einem mittelständischen Team gibt es in unserem Unternehmen immer jemanden, der das Sprint-Planungstreffen verpasst. Wir kriminalisieren ihn nicht. Wir glauben, dass er reif genug ist, um seine Entscheidung zu treffen :)

Ich freue mich über Ihre Frage, solange Sie Durst haben, den Geist der agilen Methodik der Softwareentwicklung zu lernen und zu schätzen.

Wo ich arbeite, wäre 4 die übliche Lösung. Die Person (en), die das Meeting verpasst haben, sind möglicherweise im Urlaub, sind krank oder haben etwas anderes zu tun, was in einigen Fällen, in denen nur jemand vermisst wird, nicht bedeutet, dass der Sprint nicht fortgesetzt werden sollte. Die Idee dabei ist, dass das Team erkennt, welche Anpassungen vorgenommen werden können, wenn jemand für einen halben Sprint abwesend ist, obwohl am Ende möglicherweise mehr als ein paar Anpassungen vorgenommen werden.

Die Leute neigen immer dazu, Urlaub zu haben :-) Kein Schaden.

Wenn jemand in einer agilen Gruppe Urlaub braucht, wenn die agile Gruppe ordnungsgemäß funktioniert, sollte eine Person, die fehlt, keinen großen Unterschied machen.