Was passiert zwischen Sprints?

Ich arbeite an einem Projekt, das lose dem Scrum-Modell folgt. Wir machen zwei Wochen Sprints. Was mir nicht klar ist (und ich kein Buch zum Konsultieren habe), ist genau das, was zwischen den Sprints passieren soll: Es sollte einen "Wrap" -Prozess geben, bei dem das Produkt gebaut und geliefert wird, aber:

• Wie lange dauert das normalerweise?
• sollte das ganze Team beteiligt sein?
• Muss es unbedingt abgeschlossen sein, bevor Entwickler mit der Arbeit an den nächsten Sprint-Elementen beginnen?
• Ist dies der Zeitpunkt, an dem Code überprüft und getestet wird?

Es gibt drei Entwickler, die ungefähr 1 Vollzeitstelle ergeben. Die Sprints sind also in der Tat sehr kurz.

Ich arbeite an einem Projekt, das lose dem Scrum-Modell folgt.

Um es klar zu machen: Ihre Manager haben Ihnen wahrscheinlich von Scrum erzählt, aber was Sie ausführen, ist nicht Scrum.

Wie lange dauert das normalerweise?

Sprint Review Meeting + Sprint Retrospective Meeting beendet den aktuellen Sprint. In kurzen Sprints sollten sie zwischen 30 Minuten und 1 Stunde zusammen dauern. Am nächsten Arbeitstag beginnt ein neuer Sprint mit der Durchführung des Sprint-Planungsmeetings 1 und 2. Je nach Teamgröße und Sprintlänge kann dieses Meeting 2 bis 4 Stunden dauern.

Sollte das gesamte Team beteiligt sein?

Das gesamte Team muss an den in der vorherigen Antwort genannten Besprechungen beteiligt sein.

Muss es unbedingt abgeschlossen sein, bevor Entwickler mit der Arbeit an den nächsten Sprint-Elementen beginnen?

Ja, denn bis zum Abschluss des Überprüfungsmeetings wissen Sie nicht, ob der Kunde das Ergebnis des vorherigen Sprints akzeptiert, und Sie wissen nicht, welche User Storys bei der Planung von Meetings verwendet werden.

Ist dies der Zeitpunkt, an dem Code überprüft und getestet wird?

Die Überprüfung und Prüfung des Codes ist Teil des Sprints. Entwickler müssen alles tun, um Arbeitscode bereitzustellen, der die Anforderungen erfüllt. Dies kann Codeüberprüfungen beinhalten und muss immer eine Art automatisierten Tests beinhalten, die bestätigen, dass Code funktioniert und das tut, was er tun soll, sonst kann die User Story nicht als erledigt betrachtet werden.

Die wichtigste mentale Veränderung ist die Qualitätssicherung. Viele Entwickler glauben, dass die Qualitätssicherung dazu dient, zu überprüfen, ob der Code funktioniert und das tut, was er tun soll. Auf jeden Fall nein. Das ist Entwicklerjob.

Die Qualitätssicherung sollte an der Produktentwicklung teilnehmen. Ihre Hauptverantwortung im Sprint sollte die Kommunikation mit dem Produktbesitzer und die Erstellung automatisierter Abnahmetests für Abnahmekriterien (Definition von erledigt) sein, die bestätigen, dass die User Story wirklich erledigt ist und die Anwendung alle neuen Anforderungen erfüllt. In kleinen Teams kann dies auch in der Verantwortung der Entwickler liegen.

Die Qualitätssicherung sollte auch einige manuelle Tests durchführen, um die Produktkonsistenz zu gewährleisten und fehlende Funktionen zu entdecken, die Benutzererfahrung mit der Benutzeroberfläche zu überprüfen usw. Die Qualitätssicherung ist nicht dazu da, nach Fehlern und Regressionstests zu suchen. Regressionstests sollten hoch automatisiert sein.

Nach meiner Erfahrung scheitern hier die meisten Unternehmen, die auf Agilität umsteigen.

Nach meiner Erfahrung gibt es außer dem Wochenende keine Zeit zwischen den Sprints. Gegen Mitte des Sprints arbeiten die Teams, in denen ich Mitglied war, mit dem Product Owner zusammen, um je nach Bedarf Story-Grooming oder vorläufige Größen zu erstellen. Es liegt in der Verantwortung des Produktbesitzers, den Rückstand voll zu halten - an diesen Geschichten wird das Team arbeiten, mit einigen Beiträgen des Produktbesitzers zu den Prioritäten. Sobald der aktuelle Sprint beendet ist, beginnt der nächste Sprint und verwendet die Arbeit, die wir investiert haben, um Geschichten und Aufgaben für den nächsten Sprint vorzubereiten.

Es gibt einige Gemeinkosten (viele Besprechungen, Fragen und Antworten sowie Anforderungsbewertungen), aber insgesamt funktioniert es - wir machen stetige Fortschritte mit geringen Ausfallzeiten. Sprints haben normalerweise zwei oder drei Wochen gedauert. Die Qualitätssicherung findet normalerweise statt, sobald die Geschichten fertig sind. Das QS-Team hat jedoch möglicherweise andere Aufgaben, die es ausführen kann. In Bezug auf die Pflege von Geschichten können Aufgaben an hochrangige Mitglieder des Teams oder an das gesamte Team fallen. Dies kann je nach Größe des Teams und dem vereinbarten Prozess variieren. Codeüberprüfungen finden normalerweise während der Qualitätssicherung oder am Ende des Sprints statt, wenn die Zeit komprimiert ist. Und wenn nicht genug Zeit bleibt, um Geschichten zu beenden, werden diese Geschichten in der Praxis auf den nächsten Sprint verschoben. Die richtige Dimensionierung und Schätzung ist hier sehr wichtig.

... und wann ist die Schätzung? Planung?

Geschichten sollten wirklich einfach sein, um zwischen den Sprints keine Zeit zu haben.

Und ich weiß nicht, um welche Art von Test es sich handelt, aber Entwickler werden Einheiten- und Integrationstests durchführen, sonst nichts.

Ich habe in einem Projekt mit manchmal 2 bis 3 Tagen zwischen den Sprints gearbeitet und es fühlt sich richtig an. Jetzt arbeite ich an einem Projekt, bei dem es keine Zeit gibt und alles verschwommen ist. Das letzte Mal im Sprint haben wir eine Produktionsbereitstellung und das dauert einige Zeit meines letzten Sprinttages.