Wie entspannt (oder nicht) sollte ein Sprint sein?

Wie sollte die Einstellung sein, Geschichten zu erstellen, die einem Sprint zugeordnet sind? Natürlich möchten Sie Prioritäten setzen, um sie im Sprint zu erledigen, aber für mich ist es der springende Punkt, dynamisch zu sein: Sie möchten es nicht absichtlich aufschieben oder "ok" machen, User Stories im Sprint zu verpassen, sondern auf Auch wenn unerwartete Dinge auftauchen und diese Geschichten nicht vollständig sind und zum nächsten Sprint weitergeleitet werden, möchten Sie nicht das Gefühl haben, etwas falsch gemacht zu haben. Das sollte doch keine beängstigende oder negative Erfahrung sein, oder?

Sind negative / beängstigende Erfahrungen für verpasste Sprint-Verpflichtungen akzeptabel? Sollten Entwickler für versäumte Sprint-Verpflichtungen zur Verantwortung gezogen werden, wenn unerwartete Aufgaben auftreten, die erledigt werden müssen (z. B. Produktionsunterstützung)?

Sie sollten unbedingt darauf abzielen, die Aufgaben innerhalb eines Sprints zu erledigen.

Einer der Hauptvorteile von SCRUM ist, dass es dem Projekt einen „Herzschlag“ verleiht.

Sie priorisieren, wählen Elemente aus einer Liste aus, Sie liefern sie aus, Sie führen sie vor, Sie reflektieren, wie sie verlaufen sind, und Sie tun es dann erneut in beschleunigten Zyklen.

Alle Planungen, Schätzungen und Priorisierungen basieren auf diesem Konzept. Dass wir X Punkte im Sprint erreichen können und werden und mit der Zeit eine Geschwindigkeit ermitteln können, die wir für eine bessere Planung verwenden können.

Wenn Sie über den Inhalt und die Verpflichtungen Ihrer Sprints zu lässig sind, bricht SCRUM meiner Meinung nach einfach zusammen und Sie verlieren eine Menge seiner Vorteile.

Natürlich wird die reale Welt manchmal etwas dazu zu sagen haben, aber das sollte eher die Ausnahme als die Regel sein ...

Der Schlüssel ist, dass es Rechenschaftspflicht geben muss, wenn die Geschichten nicht vollständig sind.

Das bedeutet, dass es einen soliden Grund geben sollte, warum eine Geschichte nicht vollständig war, und dass dieser Grund im Projektplan für die Zukunft berücksichtigt wird, sodass er nicht wiederholt wird.

Dieser Grund muss mehr sein als ein vages "Zeug kam auf".

Wenn beispielsweise eine Story nicht vollständig war, weil ein Teammitglied an einem Produktionsproblem arbeiten musste, muss diese Möglichkeit in zukünftigen Iterationen behoben werden - entweder indem weniger Stunden von diesem Teammitglied eingeplant werden oder eine andere Berichterstattung veranlasst wird.

Wenn der Grund mit mehr Fleiß oder harter Arbeit im Vorfeld hätte vermieden werden können, dann kann diese Rechenschaftspflicht ein wenig schmerzhaft sein. Hoffentlich ist der Schmerz eher von der Sorte "Dies ist, was wir beim nächsten Mal besser machen müssen" als von der Sorte "Du machst deinen Job nicht".

Das sollte doch keine beängstigende oder negative Erfahrung sein, oder?

Wenn es ein- oder zweimal passiert, nein, dann sollte es keine negative Erfahrung sein. Wenn es regelmäßig passiert, haben Sie ein Problem. Das Team ist dann immer überfordert. Überlegen Sie sich zweimal, was Sie für einen Sprint unternehmen, aber seien Sie nicht besorgt.

Entspannte Sprints bedeuten, dass Sie eine Unterbindung hatten.

Nicht entspannte Sprints bedeuten, dass Sie zu viel Engagement hatten.

Ich liefere nur das, was ich festschreibe, und versuche, das Festschreiben besser zu machen. Nur unter besonderen Umständen würde ich eine Geschichte zum nächsten Sprint verschieben. Ich bevorzuge es, jeden Tag einen leichten Druck zu haben, als kurz vor Ablauf einiger Fristen einen gewaltigen Druck.

Basierend auf meiner Erfahrung - Wie alles andere in der Agilität passen wir uns einem kontinuierlichen Feedback-System einschließlich der Schätzung an.

Es ist in Ordnung, eine Deadline für den ersten Sprint (Beginn des Projekts) zu verpassen, aber Sie LERNEN daraus, was schief gelaufen ist (Unterschätzung, keine Kenntnis der Teamstärken usw.). Dann nehmen Sie das Feedback und geben es an den nächsten Sprint weiter, um eine bessere Schätzung zu erhalten.

Meiner Erfahrung nach haben wir in meinem neuen agilen Projekt seit 11 Monaten selten die Frist verpasst, wenn überhaupt. Wir haben jedoch die Deadline für den ersten Sprint verpasst, weil wir das Tempo und die Stärke unserer Teammitglieder nicht kannten.

Einige Leute argumentieren, dass sie mehr Zeit für den ersten Sprint "reservieren", um das Problem des ersten Sprints zu lösen.

Es ist interessant, die Antworten / Kommentare hier zu sehen. Bei allen agilen (Typ-) Projekten, an denen ich gearbeitet habe, bestand der Hauptvorteil darin, den Termindruck auf viele Ministermine zu verteilen und nicht auf einen Termintotenmarsch am Ende eines Projekts. IMO, die Sprints sollten ernst genommen werden. Eventuelle Termin- oder Funktionsverschiebungen sollten als potenzielle Probleme im Projektmanagement oder in der Entwicklung angesehen werden.

Agile Prozesse fördern eine nachhaltige Entwicklung. Die Sponsoren, Entwickler und Benutzer sollten in der Lage sein, auf unbestimmte Zeit ein konstantes Tempo beizubehalten. - Prinzipien des Agilen Manifests

Wenn es eine beängstigende oder negative Erfahrung ist und sie die ganze Zeit passiert, haben Sie ein Problem. Softwareentwicklung soll Spaß machen. Nicht negativ oder beängstigend.

Wenn sich das Team jedoch dazu verpflichtet, einige Storys in einem Sprint zu beenden und ständig nicht zu liefern, haben Sie auch ein Problem. Dieses Problem wird mit ziemlicher Sicherheit nicht gelöst, wenn das Team mehr Druck ausübt, um die Storys zu vervollständigen. Wenn das Problem auf externe Faktoren zurückzuführen ist, müssen diese verwaltet werden. Wenn das Team zu viel festlegt, kann der ScrumMaster das Team dazu bringen, weniger Story-Punkte festzusetzen. Es kann viele Gründe geben und jeder muss anders angesprochen werden. Ein tatkräftiges und motiviertes Team sollte viel Motivation haben, um voranzukommen.

Im Idealfall wird das Problem in der Retrospektive angesprochen und behoben.

Es sollte für das Team nicht so kompliziert sein, herauszufinden, was sie in der relativ kurzen Zeit des Sprints erreichen können, und es dann auszuführen (eine gelegentliche Geschichte, die zum nächsten Sprint verschoben wird, ist in Ordnung, Geschwindigkeit kann schwanken, Dinge ändern sich usw.) .). Wenn du das nach ein paar Sprints nicht ganz reibungslos hinbekommst, machst du was falsch.

Es hängt wirklich von Ihrer Zeitachse ab.

Manchmal MÜSSEN Sie alle Geschichten erledigen, oder die meisten sowieso. Agile bietet zwar einige Flexibilität, aber Sie müssen das Projekt möglicherweise in einem engen Zeitrahmen fertigstellen. Wenn Sie also die meisten Storys fertigstellen, können Sie Ihr Projekt rechtzeitig fertigstellen.

Wenn das gesagt ist, werden Dinge auftauchen, die Sie daran hindern, jede Geschichte zu Ende zu bringen, jeden Sprint.

Befindet sich das Produkt in einer Zeitleiste und werden wichtige Storys übersehen, kann dies dazu führen, dass sich das Produkt verspätet. In einigen Fällen kann ein verspätetes Produkt die Wettbewerbsposition eines Unternehmens beeinträchtigen. In diesem Fall möchten Sie vielleicht, dass es eine negative Erfahrung ist, wenn Geschichten fehlen. Sie können dann das nächste Mal alles erledigen.

Bei richtiger Dosierung ist Stress gut. Sie möchten nicht allen Stress abbauen, sondern ihn mit der Zeit gleichmäßiger verteilen. Selbst wenn Sie Ihr Lieblingsspiel spielen, werden Sie Stress und negative Gefühle abbauen. Sie bekommen tatsächlich mehr Energie daraus.

Ein Team sollte sich bei verpassten Geschichten wirklich schlecht fühlen. Es wird ihnen die Energie geben, das nächste Mal etwas zu verändern (anders arbeiten oder weniger Geschichten planen, beide sind gut). Sie sollten natürlich auch stolz sein, wenn sie ihre Geschichten schreiben.

Sie erwähnen auch unerwartete Aufgaben (Produktionsunterstützung). Das weckt bei mir eine rote Fahne. Für alle Themen, die nicht mit den Geschichten zu tun haben, sollte ein Zeitrahmen vereinbart worden sein. Ansonsten ist das Spiel nicht fair, die Mannschaft fühlt sich hilflos und die negativen Gefühle werden nicht zur Verbesserung genutzt.

Sie sollten sich die Faktoren ansehen, die dazu führen, dass Ihre Verpflichtungen scheitern, und versuchen, sie zu beheben. Große Mengen zufälliger Ereignisse werden Ihre Sprints immer wieder durcheinander bringen und Ihre Geschwindigkeit unvorhersehbar machen. Entweder beheben Sie die Ursachen für diese oder einführen schlaff in Ihrem Sprint. Ich repariere lieber.

In jedem Fall kann das Team nicht zur Verantwortung gezogen werden, wenn seine Arbeit durch externe Faktoren gestört wird. Verwenden Sie Retrospektiven, um dies zu untersuchen.