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?
Antworten:
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.
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.
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.
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.
Was meinst du mit Release? Wenn Sie PSP - wahrscheinlich versandfähiges Produkt meinen, haben Sie zwei Möglichkeiten:
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.
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.
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:
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.
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.