TL;DR

Keine Ihrer angegebenen Optionen ist wirklich agil. Sie missbrauchen Punkte in dem Versuch, Fortschritt darzustellen oder „Menschen zur Rechenschaft zu ziehen“. Beides ist im Rahmen von Scrum nicht angemessen.

Punkte sind ein Schätzinstrument. Sie sind nur in der Summe aussagekräftig und werden in erster Linie zur Einschätzung der Teamkapazität während des Sprint Plannings benötigt. Sie als Produktivitätsmetrik zu verwenden, ist irreführend, und der fortgesetzte Missbrauch des Story-Point-Systems schadet letztendlich sowohl dem Team als auch dem Projekt.

Punkte sind keine Belohnungen

Auf diese Weise holt das Team in beiden Sprints einige Punkte.

In Scrum ist eine Story entweder fertig oder nicht fertig; es ist nie teilweise fertig. Sie können das System sicherlich manipulieren, indem Sie Storys künstlich zerlegen, sodass Sie in einem Sprint Punkte „verdienen“ können, indem Sie bestimmte Storys abschließen, selbst wenn das eigentliche zugrunde liegende Feature nicht vollständig ist, aber dies dient keinem anderen praktischen Zweck als der Erhöhung der Geschwindigkeit . Eine überhöhte Geschwindigkeit wird letztendlich Ihre Schätzungen verzerren, dem Team schaden und Ihrem Projekt schaden. Tu das nicht.

Punkte sind auch keine Belohnungen. Sie sind keine Lutscher, die Sie für eine gut gemachte Arbeit verteilen; sie sind einfach eine Arbeitsaufwandsmetrik. Insbesondere Story Points:

1. Werden in eine Geschwindigkeitsmetrik umgewandelt, indem sie über ein historisches Fenster aggregiert werden und die Arbeitskapazität des Teams im Laufe der Zeit verfolgen .
2. Werden als Plausibilitätsprüfung verwendet, um festzustellen, ob eine Story ihren beabsichtigten Wert innerhalb einer einzigen Iteration liefern kann.

Punkte messen die Kapazität

Punkte sind sowohl ein Schätzwerkzeug als auch ein Mittel, um die Teamkapazität im Laufe der Zeit zu verfolgen. Beim Schätzen sagen Ihnen Story Points:

1. Wie viel Aufwand das Team für eine Geschichte hält.
2. Ob die Geschichte (in ihrer Gesamtheit) in die aktuelle Iteration passt oder nicht.
3. Ob das Team die Story unverändert in den Sprint übernehmen soll oder ob das Team mit dem Product Owner zusammenarbeiten muss, um die Story zu verfeinern, zu klären, zu zerlegen, zu verwerfen oder neu zu definieren, um das aktuelle Sprint-Ziel zu erreichen.

Punkte dienen auch als Indikator für die Teamkapazität im Laufe der Zeit. Das Sammeln von Punkten bringt keinen Mehrwert für das Projekt, aber die Aussage, dass das Team in einer typischen Iteration normalerweise durchschnittlich 12-16 Punkte erreichen kann, hilft dem Team, seine Fähigkeit einzuschätzen, Geschichten während der Sprint-Planung zu akzeptieren. Dies hilft dem Team, eine Überverpflichtung zu vermeiden, verhindert, dass das Team scheitert, indem es eine untragbare Arbeitsbelastung erzeugt, und vermeidet die Planung eines Sprints, der das angegebene Sprint-Ziel für die Iteration nicht erreicht.

Geschichten sollten in einen Sprint passen

Wenn Ihre Stories nicht in einen einzelnen Sprint passen, haben Sie entweder ein Epic, das zerlegt werden muss, oder Ihre Sprintlänge wurde nicht für Ihr Projekt optimiert. Es gibt immer einen Kompromiss bei der Bestimmung der optimalen Sprintlänge für ein Projekt, aber die Herausforderung, Geschichten zu schreiben, die in eine endliche Zeitbox passen, bleibt eine ständige Herausforderung.

In Scrum sollte eine Story ein vollständiges, vertikales Stück Funktionalität sein, das das gesamte funktionsübergreifende Team einbezieht. Testen ist nie eine separate Geschichte; Vielmehr ist es eine integrale Aufgabe, die erforderlich ist, um sicherzustellen, dass ein bestimmtes Feature die formale "Definition of Done" erfüllt, wie sie vom Projekt definiert wird.

Storys, von denen erwartet wird, dass sie über das Ende einer Iteration hinausgehen, weisen auf ein Prozessproblem hin, das während der Backlog-Grooming- oder Sprint-Planung behoben werden muss. Ebenso sind Stories, die nicht der Definition of Done entsprechen, auch Prozessprobleme, die das Team dringend angehen muss.

Wenn Sie sich problematische Geschichten ansehen, ist der beste Rat, die INVEST-Prinzipien zu verwenden und insbesondere:

Geschichten liefern Mehrwert

Wenn QA eine Aktivität ist, die durchgeführt werden muss, um überhaupt etwas zu liefern, dann können Sie sie nicht abspalten. Gab es ein „Definition of Done“ -Meeting? Schließt „erledigt“ QA ein?

Wenn Ihre Geschichte keinen Wert liefert, ist es keine Geschichte.

Geschichten sind klein

Alle Storys müssen weniger als einen Sprint lang sein, um geplant werden zu können. Teilen Sie Ihre Geschichte auf, indem Sie eine Teilmenge der Funktionen bereitstellen (weniger Wert, aber immer noch ein gewisser Wert).

Option 2 scheint nur gültig zu sein, wenn Sie das Testen als Dienstleistung und nicht als Verantwortung des Teams betrachten. Wenn das der Fall ist, würde ich fragen, wie agil das Team ist und ob Sie wirklich zwei separate Teams (Entwicklung und QA) in einen Sprint quetschen müssen. Wenn Ihr Ziel darin besteht, agil zu sein, kann es sich lohnen, nicht zwischen Entwicklung und Test zu unterscheiden und eine Story als „fertig“ zu betrachten, wenn sie ordnungsgemäß getestet wurde. Auf diese Weise schätzen Sie am Ende die Gesamtarbeit, die als Team erledigt werden muss, und nicht nur Teilbereiche davon.

In Ordnung, bitte erschießen Sie mich nicht, aber ich werde gegen das argumentieren, was die meisten Leute hier empfehlen, nämlich bestimmte Testaktivitäten in ihre eigenen Geschichten aufzuteilen. Nur um das klarzustellen, mit Testaktivitäten beziehe ich mich speziell auf das Erstellen automatisierter Testfälle. Manuelles/exploratives Testen ist ein Bonus.

Beginnen wir mit etwas Theorie, für die ich meine Referenz für (Microservice-)Teststrategien verwenden werde. Ich denke, wir werden uns alle einig sein, dass die Testpyramide sinnvoll ist, dass es VIEL mehr Unit-Tests als (automatisierte) Komponententests geben wird , und noch weniger (automatisierte) End-to-End-Tests. Lassen Sie uns für einen Moment außer Acht lassen, wer was macht … Ich beobachte typischerweise das folgende Muster in Agile/Scrum/was auch immer:

• Ein Feature besteht aus mehreren Storys (Durchschn. 3-5)
• Jede Geschichte ist in der Regel ein individuelles Ergebnis, das vorgeführt werden kann und (hoffentlich) einen gewissen Mehrwert für den Endbenutzer bietet.
• Jede Story enthält den Quellcode, Komponententests, möglicherweise einige Integrationstests (siehe Definition von Integrationstests hier ), Dokumentation usw. Keine Diskussion hier, dass diese Arten von Tests Teil einer Story sein müssen, da diese Arten von Tests es müssen sowieso vom Ersteller der Geschichte geschrieben werden.
• Für jede Funktion gibt es nur eine Handvoll E2E-Tests, und diese E2E-Tests testen normalerweise nicht einmal jede Story einzeln, sondern testen die Beiträge mehrerer Storys in einem Testfall.
• Es ist schwierig, E2E-Tests zu schreiben, wenn die zu testende Funktionalität noch nicht vollständig in einer DEV- oder TEST-Umgebung verfügbar ist.
• Eine damit zusammenhängende Beobachtung ist, dass sich die für Unit- und Integrationstests verwendeten Tools normalerweise von denen für E2E-Tests unterscheiden.
• Aufgrund des unterschiedlichen Toolings, aber auch historisch bedingt, hält sich auch in agilen Zeiten überall die Spezialisierung auf Entwickler und Tester/QA-Ingenieure.

Die Frage ist nun, wie mit E2E-Tests umgegangen wird: In jede Story einbinden oder eigene Storys erstellen? Meiner Meinung nach, wenn ich alle oben aufgeführten Einflüsse in Betracht ziehe, ist die Schlussfolgerung, sie aufzuspalten. Bei meinen Projekten fügen wir normalerweise jedem Feature eine Komponente/E2E-Teststory hinzu. Das Verfassen von Testfällen wird in der Regel einen Sprint nach Abschluss der letzten Story-Implementierung abgeschlossen. Funktionen können nicht auf abgeschlossen gesetzt werden, es sei denn, die zugehörige E2E-Testgeschichte ist vollständig, ein sauberer und einfacher Kontrollmechanismus.

Ich werde argumentieren, dass dies nicht gegen den Geist der Bereitstellung von Geschichten verstößt, da jede Geschichte immer noch vollständig demonstrierbar ist und mit einem vollständigen Satz von Einheiten- und Integrationstests geliefert wird und daher von hoher Qualität ausgegangen werden kann. Mit der Aufteilung in Entwickler- und Testerrollen hat sich dies für mich als der effizienteste und systematischste Weg erwiesen. Andernfalls „verzögern“ E2E-Testerstellungsaktivitäten ständig die Fertigstellung einzelner Storys, insbesondere derjenigen, für die die „Entwicklungs“-Arbeit gegen Ende eines Sprints abgeschlossen wurde.

Nun, in einer idealen Welt gäbe es wahrscheinlich keine Spezialisierung auf Entwickler und Tester/QA-Ingenieur. Dann konnte ich sehen, dass Komponenten- und E2E-Tests in jede Story gerollt werden konnten (immer noch mit Ineffizienzen aufgrund der Diskrepanz zwischen feinkörnigen Geschichten und grobkörnigen Komponenten-/E2E-Tests). Aber in den Organisationen, in denen ich gearbeitet habe, war es bereits schwierig genug, eine agile Denkweise zu etablieren, um nicht das Konzept der dedizierten Tester-/QA-Rollen zu verwerfen.

Vielleicht nicht der reinste Ansatz, aber der praktischste und praktikabelste, den ich mir vorstellen konnte.

Seien Sie vorsichtig, wenn Sie Geschichten aufteilen

Wenn Sie feststellen, dass Sie eine User Story aufteilen, fragen Sie sich: „Hat diese Story, die ich erstelle, einen Mehrwert für sich?“. Wenn die Antwort nein ist, dann sollte es eine Aufgabe als Teil einer größeren User Story sein.

Die richtige Antwort hängt vollständig von Ihren Zielen ab.

Wenn das Ziel darin besteht, die Scrum-Anforderungen zu erfüllen: Sie sollten die Story nicht in, nennen wir es Aufgaben, aufteilen, da es keinen Wert in jeder von ihnen gibt.

Wenn Sie jedoch eine Option sehen, um mehr Transparenz und Vorhersehbarkeit in Ihrem Entwicklungsprozess zu schaffen: Die Aufteilung von Aufgaben in kleine solide Elemente bringt Ihnen viele Erkenntnisse (z. B. welcher Teil Ihrer Lieferpipeline ein Engpass ist usw.).

Hier noch ein paar abstraktere Gedanken: (Meinungen)

Lassen Sie sich von „Punkten“ nicht in die Quere kommen: Punkte sind ein sehr abstraktes Konzept – wer möchte nicht mehr davon gewinnen? Das Streben nach ihnen kann von dem ablenken, was Sie wirklich erreichen möchten. Aus diesem Grund verwende ich sie nicht.

„User“ -Storys gehen nur so weit: Viele der Dinge, die beim Erstellen eines Softwaresystems getan werden müssen, sind für den Benutzer nie explizit sichtbar. Viele dieser Dinge überschneiden sich mit vielen „Benutzergeschichten oder -aktivitäten“.

Benutzer sind keine Programmierer, und ihre „Geschichten“ können Programmierer nicht vollständig informieren: Sie steigen ins Auto und fahren es – aber sie öffnen nie die Motorhaube und sie wissen nicht wirklich, womit die Schaltung verbunden ist. Sie sind sich nie darüber im Klaren, was getan werden muss, damit sie sicher auf der Straße fahren können. Sie haben Vorstellungen davon, was es braucht, um ein Auto zu bauen, aber sie wissen es nicht wirklich. "Und warum sollten sie? Sie sind Fahrer, keine Automechaniker!"

"User Stories" sind im Grunde [IMHO ...] ein Kommunikationsmittel : Sie halten Sie fest in Kontakt mit dem, was der Benutzer sehen wird, und wissen, dass das, was Sie produzieren, tatsächlich für ihn nützlich sein wird, und sie geben beiden Parteien etwas gemeinsamen Bezugsrahmen, der keine "Programmierkenntnisse" erfordert. All das ist sehr gut!! ... Sehr wertvoll!! ... Aber es gibt noch mehr , was das Team für sich selbst generieren muss, um die Probleme anzugehen, von denen "Benutzer" nichts wissen, die aber wesentlich sind, um ihnen das zu geben, was sie brauchen. Als Projektmanager und als Designteam sind „User Stories“ Inputs. Sie sind keine Umsetzungspläne – aber sie helfen, diese Pläne voranzutreiben.

„Scrum ist [IMHO …] eine Metapher: eine sehr, sehr nützliche. Umfassen Sie es für das, was es gibt, und wissen Sie, wann Sie es loslassen müssen. Es ist keine Religion, und es war nie beabsichtigt, es zu sein ist ein wertvoller Prozess und eine hervorragende Denkweise – soweit es geht.Es wird Ihnen nicht Ihren Implementierungsplan schreiben, noch sollten Sie es jemals (natürlich ...) erwarten.