Wie oft im Scrum-Sprint veröffentlicht werden

10

Wie oft du während eines Sprints loslässt. Nur am Ende des Sprints oder jedes Mal, wenn ein Feature bereit ist. Und wie gehen Sie mit Bugfix-Releases um?

Eskimoblood
quelle
3
Wenn Sie jedes Mal veröffentlichen, wenn ein Feature fertig ist, sollten Sie sich vielleicht Kanban anstelle von Scrum ansehen
David

Antworten:

10

TL; DR: Bei Bedarf freigeben

Wir machen Releases immer dann, wenn es sinnvoll ist, ein Release zu machen. Manchmal bedeutet dies, eine Veröffentlichung durchzuführen, nachdem eine einzelne Funktion oder ein Bugfix abgeschlossen wurde. Manchmal bedeutet dies, eine Sammlung von Funktionen und / oder Bugfixes freizugeben.

Dies bedeutet nicht, dass wir häufig "Notfälle" haben, die eine schnelle Freigabe erfordern. Es bedeutet, dass wir hart gearbeitet haben, um Veröffentlichungen zu vereinfachen. Unser Code wird bei jedem Build getestet, markiert und verpackt. Wir verwenden automatisierte Abnahmetests und haben daher ein hohes Maß an Vertrauen in den Code entwickelt, der die Tests besteht. Da unsere Pakete sofort über ein lokales Yum Repo verfügbar sind, ist die Bereitstellung einer Version trivial.

Dietbuddha
quelle
10

Niemals während. Das verstößt gegen die Grundvoraussetzung eines "Sprints". Sie rennen, bis Sie fertig sind, was Sie zu Ende gebracht haben. Nachdem Sie fertig sind, ist es wirklich fertig und funktioniert wirklich. Sie können es dann freigeben.

Release kann eine separate Art von Sprint sein, bei dem Dinge zur Veröffentlichung verpackt werden.

Bugfix-Releases können nur kurze Sprints sein. Viele halten es für eine schlechte Idee, keinen regelmäßigen Zeitplan für Sprints gleicher Länge zu haben. Daher ist die übliche Regel, dass Fehlerkorrekturen einfach eine Arbeit mit hoher Priorität sind, die beim nächsten Sprint ausgeführt wird.

Wenn es sich um einen Notfall handelt, sind zu viele Dinge im Gange - Unterstützung und Entwicklung - und Sie sollten in Betracht ziehen, die Organisation zu ändern, um weniger Dinge zu erledigen.

S.Lott
quelle
Wie sollen die Tester also kontinuierlich testen?
Melbourne Entwickler
4

Wenn die Arbeit, zu der sich das Team verpflichtet, dazu beiträgt, mehrere Releases innerhalb des Sprints durchzuführen, geben Sie sie so oft frei, wie Sie möchten.

Gleiches gilt für Fehlerbehebungsversionen. Wenn es sinnvoll ist, sie freizugeben, tun Sie dies.

Matthew Flynn
quelle
Ja, ich stimme zu. Der beste Ansatz besteht darin, Releases von der Implementierung von Funktionen und / oder Sprints zu entkoppeln. Die (Release-) Prozesse müssen dies unterstützen. Ein Sprint ist ein Zeitrahmen. Eine Veröffentlichung kann jederzeit erfolgen, wenn die von Ihnen freigegebene Version die Qualitätssicherung besteht. Die beiden Dinge können unterschiedlich sein. Wie erreicht man das? Eine Option ist die Verwendung des Konzepts "Kein Müll im Trunk" für die Zweigstellenverwaltung.
Manfred
3

Der letzte Agile-Job, bei dem ich gearbeitet habe, hatte bei jedem Sprint Veröffentlichungen; Der Code wurde jeden zweiten Donnerstag eingefroren (zweiwöchige Sprints), und dann wurde das Produkt verpackt und auf einem UAT-Server veröffentlicht, damit unsere Kunden damit arbeiten können. Dies war während der anfänglichen Entwicklung des Produkts; Für ein ausgereiftes Produkt, insbesondere ein verteilbares Programm und keine Web-App, möchten Sie Ihre Benutzer wahrscheinlich nicht mit einem Upgrade alle zwei bis drei Wochen belasten.

Praktisch alle unsere Veröffentlichungen enthielten eine Mischung aus Story Points und Defekten (Bugs). Mängel gelten als "nicht ideale Stunden"; Ein Arbeitstag hat 5 ideale Stunden, dh eine Heads-Down-Codierung der neuen Punktarbeit. Die anderen drei bis vier Stunden am Tag sind Besprechungen, Diskussionen, Design, manchmal "Spikes" (fokussierte Forschung / Proof-of-Concept-Entwicklung) und Fehlerarbeiten. Dinge, die zu einem besseren Produkt beitragen und ein notwendiger Teil des Prozesses sind, aber einfach nicht den gesamten Sprint des gesamten Teams aufnehmen können. Das einzige Mal, dass wir Nur-Fehler-Releases durchgeführt haben, war, als im Backlog ab einem IPM keine Story-Point-Arbeit verfügbar war. Dann haben wir einfach einen QS-Sprint geplant, bei dem wir angewiesen wurden, "so viele Fehler wie möglich zu beseitigen". Da es IMMER die Schuld der Bestellung ist, keine Anforderungen bereit zu haben (und die Bestellung für die Kunden funktioniert hat), Wir könnten einfach eine Vertragsänderungsmitteilung herausgeben und mit dem arbeiten, was wir hatten. Sobald die eigentliche Story-Arbeit beendet war und wir uns mit der "Garantie" -Entwicklung befassten, gab es natürlich nur noch Mängel.

In einem gut verwalteten Agile-Projekt sollten niemals die Anforderungen ausgehen. Der Rückstand sollte immer die Arbeit eines Sprints bereithalten. Aber manchmal wird die PO überflutet und produziert Anforderungen; Manchmal halten die BAs / Tester die Veröffentlichung von Storys aus Gründen der Anforderungsqualität oder von Story-Konflikten für den Entwicklungsstau zurück. Manchmal entscheidet ein Team, dass es sich auf eine Geschichte "stürzen" muss, die nicht genau definiert oder geschätzt wurde, und es gibt nichts, was die verbleibenden Zyklen leicht in Anspruch nehmen kann. Kurz gesagt, selbst in Agile passiert Scheiße.

KeithS
quelle
3
Ich denke, der Punkt von Agile ist, dass wir erwarten, dass Scheiße passiert.
Matthew Flynn
Wenn Ihr Erstellungsprozess einem Paket automatisch den Code markiert, müssen Sie ihn nicht "einfrieren"? Die Arbeit kann fortgesetzt werden, die überprüfte Version kann herausgeschoben werden usw.
Dietbuddha
Das "Einfrieren" war symbolisch; Wir sagten im Grunde, dass der letzte Build, für den CI am Donnerstag um 17:00 Uhr bestanden hatte, der Release-Build war, und wir schnitten einen SVN-Zweig für diese Revision ab und gingen weiter. Wenn Sie bis dahin kein Commit durchgeführt haben oder Ihr Commit nicht alle CI-Tests bestanden hat, war es nicht in der Version enthalten.
KeithS
1

Was meinst du mit Release? Wenn Sie PSP - wahrscheinlich versandfähiges Produkt meinen, haben Sie zwei Möglichkeiten:

  • Scrum by Book (oder Scrum Level 2) Sie haben PSP am Ende des Sprints und das zeigen Sie bei einem retrospektiven Meeting
  • Ich habe auch den Begriff Scrum Level 3 kennengelernt, bei dem das Team seine Tools wie Quellcodeverwaltung und kontinuierliche Integration beherrschte und zur kontinuierlichen Bereitstellung überging. Ein solches Team kann PSP nach jedem nächtlichen Build (oder im besten Fall nach jedem Build) haben. PSP nach jedem Build zu haben bedeutet nicht, dass Sie es dem Kunden nach jedem Build zeigen - es ist immer noch nur eine interne Version.

Der Hauptunterschied zwischen Level 2 und Level 3 besteht darin, dass Sie in Level 2 einige Anstrengungen unternehmen müssen, um am Ende des Sprints die endgültige PSP zu erstellen. In Level 3 investieren Sie zunächst etwas Geld und Mühe in Ihre Tools und Konfigurationen und haben PSP vorbereitet automatisch die ganze Zeit = es ist kein manueller Aufwand erforderlich. Das vollständige Erreichen von Level 3 ist selten.

Ladislav Mrnka
quelle
sind diese "Scrum Levels" offizielle Namen? Ich habe gegoogelt und nichts gefunden.
David
@ David: Ich denke nicht, dass es etwas offizielles ist. Es ist nur ein weiterer Ansatz zur Messung der "Scrum-Reife". In dieser Präsentation wurden diese Ebenen erörtert, aber ich habe sie im CSM-Kurs kennengelernt.
Ladislav Mrnka
0

In Scrum gibt es absolut keine Regeln, wann neue Funktionen bereitgestellt werden dürfen. Jedes Team muss eine "Definition von erledigt" haben, die immer einige Kriterien zum Testen enthalten sollte. Sobald eine Funktion "fertig" ist, ist sie für die reale Welt bereit. Wenn keine anderen Abhängigkeiten oder Bedingungen erfüllt sein müssen, bevor sie bereitgestellt werden kann, gibt es keinen Grund, auf das Ende des Sprints zu warten Stellen Sie es bereit.

Nichts davon bedeutet, dass es beim Sprint Review / Planning-Meeting nicht vorgestellt wird. Das Konzept ist, dass alles, was das Team abgeschlossen hat, der PO (und anderen KMU der Kunden) gezeigt wird, damit sie es in ihr wachsendes Verständnis des Systems während seiner Entwicklung einbeziehen können.

Dave
quelle
0

Nach ein paar Wochen haben wir eine gute Lösung gefunden, die unseren Anforderungen entspricht. Wir beschließen zu veröffentlichen, wann immer wir wollen. Wie wir das machen:

  1. Wenn sich jemand entscheidet, den eigentlichen Entwicklungszweig freizugeben, führt er alle Änderungen im Hauptzweig zusammen, markiert ihn mit einer neuen Versionsnummer und überträgt ihn auf unser Staging-System.
  2. Dann erhalten unsere QS und alle anderen Teams eine E-Mail mit einem aktuellen Änderungsprotokoll und testen das Staging-System
  3. Wenn sie Fehler gefunden haben, beheben wir sie im Master, verschieben sie in die Bereitstellung und führen den Master wieder in den Entwicklungszweig ein
  4. Wenn das Staging-System die Qualitätssicherung bestanden hat, wird der Master live geschaltet

Das ist es. Wir verwenden Git und Maven als CI-System und haben eine gute Testabdeckung. Welches ist einer der Gründe, warum wir das so machen können.

Eskimoblood
quelle
0

Die Beantwortung einer Frage, die fast 2 Jahre alt ist, mag etwas überflüssig sein, aber um hoffentlich einen Mehrwert für andere zu schaffen, die zu dieser Frage kommen, möchte ich etwa 2 Cent hinzufügen. :) :)

Um die Frage zu beantworten: Sie sollten am Ende des Sprints vorzugsweise freigeben, was im Sprint festgelegt wurde. Dies hängt mit allen anderen Teilen / Prozessen / Richtlinien von Scrum zusammen, die darauf ausgerichtet sind, den besten Geschäftswert zum richtigen Zeitpunkt zu erzielen.

ABER Notfälle, Fehler, unerwartete Ereignisse usw. können Ihre Hand zwingen. Hier könnte sich das Konzept als nützlich erweisen, wenn "Release Planning". Mit "Release-Planung" meine ich nicht die Planung von Wasserfalltypen, sondern die Planung von Erwartungen, die dazu beitragen könnten, den Produktstau und die Priorität von Storys in Sprints usw. zu verwalten.

Aber vielleicht ist Davids Kommentar zu dieser Frage am besten zu berücksichtigen. Scrum ist nicht immer die richtige Antwort.

David 'der kahle Ingwer'
quelle