Einführung
Was ist DoR?
Warum brauchst du ein DoR?
Verwendungszweck von DoR
Wann wird DoR verwendet?
INVEST-Modell
Fazit
Referenzliste
Einführung
Sicherlich haben Sie mehr als einmal gehört, wahrscheinlich haben Sie sogar das Scrum-Artefakt - Definition of Done mit dem Team, im Folgenden - DoD - verwendet. Vielleicht benutzen Sie es, ohne es zu merken. Viele russischsprachige Artikel wurden über DoD geschrieben. Sie sprechen auf Konferenzen und Schulungen über ihn. Es ist nicht schwierig zu verstehen, warum dieses Artefakt benötigt wird, und Beispiele zu finden. DoD definiert die Kriterien, anhand derer jedes Teammitglied versteht, dass die Aufgabe geschlossen ist. Das tiefste Ziel ist es, das Konzept von Done zwischen jedem Teammitglied zu synchronisieren. Über diesen Kriterien arbeitet das Team häufig während einer Retrospektive. Es gibt ein ähnliches Artefakt, über das Scrum aus russischsprachigen Quellen aus irgendeinem Grund nicht erwähnt wird, und wo dieses Artefakt erwähnt wird, wird nicht erklärt, was es ist, warum es benötigt wird und wie es verwendet wird.
Höchstwahrscheinlich klangen in Ihrem Team Sätze wie Ihre: "Wir haben das Ziel nicht erreicht, weil wir die Aufgabe falsch bewertet haben" oder "Unsere Bestellung kam mit der Aufgabe ohne ordnungsgemäße Beschreibung zurück". In meinem Team traten solche „Signale“ mehr als einmal auf, und ich suchte lange nach einer Möglichkeit, dieses Problem zu lösen.
Die Definition von Ready, im Folgenden als DoR bezeichnet, ist mir zufällig in einem Profil-Chat über Agile begegnet. Beim Versuch, Informationen zu finden, habe ich in RuNet keine einzige Erwähnung zu diesem Thema gefunden. Deshalb habe ich englischsprachige Artikel gelesen und übersetzt. Jetzt teile ich das Ergebnis mit Ihnen. Ich hoffe, dass dies dazu beiträgt, Ihr Team noch cooler und produktiver zu machen.
Was ist DoR?
Was ist DoR? Der Google-Übersetzer teilt Ihnen mit, dass dies eine "Definition der Bereitschaft" ist. Wenn DoD Kriterien zum Ausführen einer Aufgabe enthält, dann DoR - Kriterien für die Bereitschaft einer Aufgabe, zur Arbeit gebracht zu werden. Das heißt, wenn eine Aufgabe die Kriterien von DoR erfüllt, kann das Team sie zur Arbeitsplanung mitnehmen. Es scheint einfach zu sein, Sie haben wahrscheinlich bereits darüber nachgedacht, wie Sie schließlich zusammen mit dem Team eine ganze Liste von Anforderungen für Ihre Bestellung erstellen können, damit eine Menge Dokumentation geschrieben wird und der Rest der Teammitglieder ruhig an ihrem Computer sitzen und still Code schreiben kann. Dies ist nur der Anfang, und DoR ist nicht das, was es auf den ersten Blick scheint.
Warum brauchst du ein DoR?
Zunächst beantworten wir die Frage: Warum wird dieses Artefakt benötigt? Welchen Nutzen wird er dem Team bringen? DoR wird dem Team helfen:
- Vermeiden Sie es, mit der Arbeit an Features zu beginnen, für die die Abschlusskriterien nicht klar definiert sind. Das Team wird verstehen, wann die User Story als vollständig betrachtet wird und was zu tun ist, um dies zu tun.
- Verschwenden Sie nicht viel Zeit umsonst mit langen Diskussionen und schlecht durchdachten Aufgaben. Eine vorverarbeitete Aufgabe spart Zeit für das gesamte Team. Berechnen Sie, wie viel Zeit es dauert, eine „schlechte“ Aufgabe für eine Person zu besprechen. Multiplizieren Sie nun mit der Anzahl der Personen im Team. Und nun zur Anzahl solcher Aufgaben.
- Konzentrieren Sie Zeit und Energie auf Dinge, die so "sicher" wie möglich sind. Einer der leistungsstärksten Demotivatoren ist die Funktionalität, die in den Papierkorb geworfen wird.
- Binden Sie jeden Teilnehmer in die Diskussion der Aufgaben ein. Erstens motiviert es das Team. Zweitens hilft es, jedes Teammitglied als Spezialisten zu präsentieren. Drittens werden Entwickler ihre eigene Vision des Problems anbieten. Während der Diskussion können andere Lösungen entstehen, die sich radikal von der ursprünglichen Idee unterscheiden.
Werfen wir einen Blick auf die Liste der Probleme, die indirekt oder direkt auf das Fehlen von DoR zurückzuführen sind:
- Zwischen den Teammitgliedern treten regelmäßig Unstimmigkeiten beim Verständnis des Problems auf. Am Ende des Sprints verstärkt sich die Diskrepanz, was zu Vorfällen führt, bei denen Änderungen im Entwicklungsprozess aufgetreten sind, was natürlich ist. Aber angesichts der Tatsache, dass diese Momente nicht aufgezeichnet wurden, weiß nur derjenige über sie Bescheid, der dies direkt erlebt hat.
- Funktionale Anforderungen ändern sich schneller, als das Team sie verstehen kann. Da die Aufgabe mit hoher Unsicherheit in den Sprint eingetreten ist, werden zum Zeitpunkt der Fertigstellung des Teils und der Grundsteinlegung neue Informationen angezeigt, die eine Rückkehr zum Anfang erfordern. Je schlechter die Aufgabe gelöst ist, desto häufiger tritt eine solche Situation im Sprint auf. Am Ende wird dies zu einem Fakap führen.
- Oft gibt es Probleme bei der Bewertung des Ergebnisses der Funktion. Das Team weiß nicht, wie Metriken erfasst werden sollen, oder, noch schlimmer, es wurde vergessen. Bei Scrum geht es in erster Linie um die Vorteile für den Kunden, Benutzer oder Käufer. Wenn das Team die Vorteile der Aufgabe nicht bewertet, erhält es kein Feedback und kann den Verlauf der Produktentwicklung nicht anpassen. Dies kann zu einem vollständigen Ausfall führen.
- Das Fehlen von DoR hat auch einen großen Einfluss auf das Testen. Statt der Erwartungen an die Qualitätssicherung in der User Story werden die Erwartungen der Entwickler getestet. Der Code kann perfekt funktionieren, Autotests funktionieren wie am Schnürchen, aber die Funktionalität funktioniert in der Produktion nicht.
Am Ende führt dies zur Freigabe eines Produkts, das nicht funktioniert, nutzlos ist und das Hauptproblem nicht löst. Und das ist Zeitverschwendung, die jeder für wichtige Dinge aufwenden möchte. In einem der Artikel stieß ich auf ein ausgezeichnetes Sprichwort: "Müll kam herein, Müll kam heraus."
Verwendungszweck von DoR
DoRs werden bei der Verfeinerung des Product Backlog verwendet, im Folgenden als PBR oder der bekanntere Artefaktname Grooming bezeichnet. Während dieser Aktivität werden User Stories bereit - bereit. Dies bedeutet, dass das Ergebnis des Ereignisses im Product Backlog Ready US ist. DoR wird benötigt, um den Zustand zu beschreiben, in dem die USA bei der Planung diskutiert werden können. Dies wird von den USA als Takin akzeptiert.
Um weiter zu gehen, achte ich darauf, wie Jeff Sutherland, einer der Gründer des Scrum and Agile-Manifests, in seinen Videos über DoR und DoD spricht. Sutherland führt die Konzepte von Done-Done und Ready-Ready ein. Wenn ein Teammitglied angibt, dass eine Aufgabe fertig oder abgeschlossen ist, wird davon ausgegangen, dass sie die Kriterien erfüllt, die das Team in DoD bzw. DoR definiert hat. Dies ist ein wichtiger Aspekt, den jedes Mitglied des Teams verstehen und nicht vergessen darf. Andernfalls entstehen lustige Situationen, in denen Petya im Daily mitteilt, dass die Aufgabe bereits abgeschlossen ist, und sich dann herausstellt, dass dort Tests hinzugefügt werden müssen, und es wäre schön, den Code umzugestalten, und die Codeüberprüfung noch nicht bestanden hat.
Bis die USA den Bereitschaftszustand erreichen, existiert er also nicht und wird in der Planung nicht erörtert. Der obere Teil des Rückstands sollte nur in den USA mit einem Bereitschaftszustand sein. Der beste Weg, dies zu erreichen, besteht darin, die USA mit dem Team zu trainieren. Auf diese Weise können wir das Problem aus verschiedenen Blickwinkeln betrachten, jedes Teammitglied in den Prozess einbeziehen und anschließend die kollektive Verantwortung für die freigegebene Funktionalität entwickeln. Entwickler sind selbst für das Ergebnis und die Qualität verantwortlich, wenn sie erkennen, dass dies das Ergebnis „ihrer“ gemeinsamen Arbeit ist.
Wann wird DoR verwendet?
Wenn das Team während der PBR versteht, dass die Aufgabe nicht der DoR entspricht und zu viel Unsicherheit mit sich bringt, erstellen Sie eine Liste mit Fragen, wählen Sie einen Forscher aus und verschieben Sie die Aufgabe auf die nächste PBR. In meinem Team hieß es "Forschung", aber später wechselten wir von XP zu Spike, weil wir dachten, dass dies mehr Ergebnisse und Klarheit über das Ergebnis der Studie bringt. Stellen Sie sicher, dass Sie die Studie zeitlich begrenzen und das Ergebnis angeben, das Sie bis zum Ende erhalten möchten. Während Spike kann der Forscher jede Hilfe von außen anwerben, zum Beispiel Mitglieder anderer Teams, Methodologen, POs, Architekten ... im Allgemeinen jeden, der es für richtig hält. Ergebnis - Antworten auf Fragen, neue Daten, Prototyp. Wenn es viele solcher User Stories gibt, können Sie in jedem Sprint 1-2 Spike für die nächste Iteration verwenden, um einen konstanten Fluss von Ready-Aufgaben sicherzustellen.
Wie oben erwähnt, ist DoR eine Reihe von Kriterien. Das Team kann versuchen, diese Kriterien zu erstellen. Arbeiten Sie die „Signale“ durch, die in Iterationen verfolgt werden. Besprechen Sie diese Punkte im Nachhinein und finden Sie die Grundursache. Wenn Sie die nächste Retrospektive nicht dafür ausgeben möchten, verwenden Sie vorgefertigte Lösungen.
Viele Artikel beschreiben das INVEST-Modell, das SMART ähnelt, jedoch besser für User Story geeignet ist. Neben Artikeln wird dieses Modell auch in der Agile-Literatur empfohlen. Zum Beispiel Roman Pichler im Buch „Product Management in Scrum“ oder Mike Cohn - „User Stories. Flexible Softwareentwicklung. “
INVEST-Modell
- Unabhängige Unabhängigkeit - Versuchen Sie zu vermeiden, voneinander abhängige USs zu schaffen. Solche Abhängigkeiten verursachen Probleme bei der Priorisierung und Planung. Der Kunde kann US mit einer hohen Priorität wählen, was von der Aufgabe mit einer niedrigeren Priorität abhängt. Abhängige USA müssen zusammengeführt, anders aufgeteilt oder gespitzt werden.
- Verhandelbare Verhandlungsfähigkeit - Die USA sind keine formelle vertragliche Verpflichtung oder Anforderung. USA ist keine technische Aufgabe. Während des Sprints können und sollten sie diskutiert und geändert werden. Eine Karte mit einer Historie, in welcher Form auch immer, ist eine kurze Beschreibung der Funktionalität, deren Details während der Arbeit geklärt werden sollten. Hinterlassen Sie Notizen auf den Karten, um eine Diskussion zu generieren, wenn die Aufgabe abgeschlossen ist. Es ist wichtig, hier einen Mittelweg zu finden, da das Team den Überschuss an Notizen als erschöpfende Information wahrnimmt und es überhaupt keine Diskussion gibt. Mein Team ist sehr schnell darauf gestoßen. Die besprochenen Details werden zu Tests, die auf die Rückseite des Papiers oder in den Kommentar auf der elektronischen Karte geschrieben werden können. Abnahmetests sind für alle einfach und klar.
- Wertvoller Wert für den Benutzer oder Kunden - „Jede Geschichte sollte für den Benutzer einen bestimmten Wert haben“ - eine Aussage, die falsch ist. Die meisten vergessen ständig den Käufer. Fokus je nach Unternehmen: B2C, B2B, B2G. Die Hauptsache ist, Geschichten zu vermeiden, die nur für Entwickler wertvoll sind. Solche Geschichten sollten neu formuliert werden, damit die Vorteile offensichtlich werden und der Kunde Prioritäten setzen kann. Sie müssen keine architektonischen Aufgaben in den Papierkorb werfen, dem Kunden erklären, welche Vorteile eine solche Aufgabe bringt, und sie neu formulieren.
- Schätzbare Bewertung - Entwickler sollten in der Lage sein, die Größe der USA zu schätzen, dh die ungefähre Zeit, die für die Implementierung benötigt wird. Es gibt drei Hauptgründe, warum die Arbeitsintensität möglicherweise nicht messbar ist:
- Dem Team fehlen Fachkenntnisse
- Dem Team fehlt technische Erfahrung
- Die Geschichte ist zu groß
Im ersten und zweiten Fall hilft Ihnen Spike. Im dritten Fall müssen die USA in kleinere zerlegt werden. - Kleine Kompaktheit - vieles hängt von der Größe der USA ab, zu große und zu kleine US sind schwer zu bewerten. Epen sind schwer zu bearbeiten, da sie aus mehreren USs bestehen. Epen können in zwei Typen unterteilt werden:
- Verbindung. Hier ist alles einfach - wir zersetzen uns. Betrachten Sie den Rest der Punkte, das erste, was das Team wahrscheinlich vorschlagen wird: Teilen Sie die USA nach Art der Architekturebene: nach USA in eine Datenbank, ein Backend, ein Frontend usw.
- Kompliziert. Die Größe der USA beruht auf ihrem Wesen, sie werden entweder nicht zersetzt oder es ist sehr schwierig. In diesem Fall verwenden wir Spike.
- Testbare Testbarkeit - Die Bestätigung, dass die USA erfolgreich entwickelt wurden, dient als erfolgreicher Test. Wenn die USA nicht getestet werden können, weiß das Team nicht, wann die Erstellung abgeschlossen ist, oder legt die Kriterien selbst fest. Darüber hinaus wird jedes Mitglied des Teams anders sein.
Fazit
Fazit: Mit DoR werden Sie die Lücken, die in den Sprint eindringen, nicht beseitigen. Dies bedeutet auch nicht, dass während des Sprints kein ständiger Kontakt zwischen PO und Entwicklern erforderlich ist. Zeichnen Sie die Ergebnisse der Diskussionen ständig in Form von Abnahmetests auf, damit keiner der Mitarbeiter das Verständnis für den Status der Aufgabe verliert. Analysieren und diskutieren Sie mit dem Team die aktuellen Probleme, möglicherweise hängen sie mit dem Fehlen von DoR zusammen.
DoR ist ein Artefakt, mit dem das Team die USA besser durchdenken kann, was letztendlich die Risiken verringert und es jedem Teammitglied ermöglicht, ständig über Aufgaben zu diskutieren. Viele detaillierte Informationen zu INVEST und User Story finden Sie im Buch „User Stories“. Ich empfehle jedem Teammitglied, dieses Buch zu lesen oder es zumindest selbst zu lesen und Informationen mit ihnen zu teilen.
Schreiben Sie in die Kommentare, welche DoD und DoR in Ihrem Team verwendet werden.
Referenzliste
1) Roman Pichler „Produktmanagement in Scrum“
2) Mike Cohn „Benutzerdefinierte Geschichten. Flexible Softwareentwicklung “
3) agilealliance.org
4) linkedin.com
5) boost.co.nz
6) scruminc.com