Wechsel von einem 2-wöchigen Entwicklungs-Sprint-/1-wöchigen QA-Sprint-Modell zu einem „echten“ 2-wöchigen Sprint-Modell – Tipps?

Nachdem ich selbst etwas Ähnliches durchgemacht habe, hier einige Überlegungen. Ich werde versuchen, nicht zu wortreich zu werden, aber es gibt einige Aspekte von Scrum, die angesprochen werden müssen.

1. Diese Art von Änderung kann äußerst vorteilhaft sein, erfordert aber in erster Linie die Zustimmung der Entwickler . Wenn sie Änderungen nicht unterstützen, wird es nicht funktionieren, und Scrum sollte von den Entwicklern ausgeführt werden.

Entwicklungsteams werden von der Organisation strukturiert und befähigt, ihre eigene Arbeit zu organisieren und zu verwalten. Die daraus resultierende Synergie optimiert die Gesamteffizienz und Effektivität des Entwicklungsteams. http://www.scrumguides.org/scrum-guide.html

Vor diesem Hintergrund würde ich sicherstellen (falls Sie dies noch nicht getan haben), dass Sie die Herausforderungen Ihres aktuellen Prozesses ansprechen, die Scrum-Prinzipien und den Grund für ihre Existenz überprüfen und dann das Entwicklerteam fragen, was getan werden sollte, um dies zu erreichen Arbeit. Führen Sie sie in die richtige Richtung, anstatt es ihnen zu sagen, und das Team wird viel erfolgreicher sein. Wie ich schon sagte, Sie machen es vielleicht schon so, aber es ist erwähnenswert.

Wenn Sie durch Verbesserungen Ihres befähigten Teams Erfolge vorweisen können, wird dies Ihnen auch dabei helfen, weitere Veränderungen und Akzeptanz auf der Geschäftsseite voranzutreiben.

2. Die wichtigste Prozessänderung zur Unterstützung dieser Arbeit besteht darin , das gesamte Team so früh wie möglich einzubeziehen . Damit meine ich, sicherzustellen, dass die Entwickler und die Qualitätssicherung von Beginn des Sprints an zusammenarbeiten. Sie sollten alle in Scrum-Meetings anwesend sein und zusammenarbeiten, um das Sprint-Ziel zu erreichen. Der beste Weg, den ich gefunden habe, um dies zu tun, ist wie folgt:
   • Stellen Sie sicher, dass jedes Mitglied des Teams die geschäftliche Seite des Projekts, das Warum, den Anwendungsfall und den Wert, den es bringen wird, kennt. Geben Sie ihnen die Möglichkeit, frühzeitig Fragen zu stellen (ich bevorzuge es eigentlich, wenn dies geschieht, bevor der Product Owner den Stakeholdern, Führungskräften und Kunden überhaupt etwas gezeigt hat. Das ist jedoch nicht immer notwendig, wenn Sie eine großartige Bestellung haben.)
   • Lassen Sie jede Story von der QA überprüfen, bevor mit der Arbeit begonnen wird (also in der Backlog-Planung oder in der Sprint-Planung) und lassen Sie sie ihre Akzeptanzkriterien hinzufügen. Dadurch wird sichergestellt, dass die QA mit der Aufgabe vertraut ist und dass die Entwickler darüber nachdenken, was sie tun muss, bevor sie überhaupt mit dem Codieren beginnen. Es wird auch frühzeitig ein Gespräch anregen, wenn es Verwirrung über das gewünschte Ergebnis gibt, und es wird deutlich gemacht, dass Entwickler und QA zusammenarbeiten sollten. (Eine Sache, die ich hier gerne tue, ist, allen den Rest des Tages nach der Sprintplanung zu geben, um die Geschichten zu überprüfen, den Code einzugeben, zu recherchieren, Notizen hinzuzufügen usw. und ihnen dann die Möglichkeit zu geben, am nächsten Tag Folgefragen zu stellen Dies kann auch sehr hilfreich sein, um Fragen an den PO vorab zu laden, damit diese nicht alle gleichzeitig gegen Ende des Sprints kommen) .
   • Teilen Sie die Geschichten so klein wie möglich auf . Dadurch wird sichergestellt, dass Stories sehr schnell und stetig zur Qualitätssicherung gelangen, sodass sie im Grunde vom ersten Tag des Sprints an getestet werden können. Dies wird die Entwickler auch ermutigen, ihren eigenen Code zu testen (was sie tun sollten), bevor er zur QA gelangt, und die Last der QA am Ende des Sprints reduzieren.
   • Verbreiten Sie die Idee, dass das gesamte Team (Entwickler und QA) für das Erreichen des Sprint-Ziels verantwortlich ist . Passen Sie die Spalten Ihres Scrum Boards bei Bedarf an, aber stellen Sie sicher, dass das Team versteht, dass es in der Verantwortung des gesamten Teams liegt, den Umfang der Arbeit im Sprint abzuschließen. Dies ist einer der Hauptgründe, warum Scrum im Entwicklerteam keinen anderen Titel als Entwickler anerkennt.

     Scrum erkennt keine Titel für andere Mitglieder des Entwicklungsteams als Entwickler an, unabhängig von der Arbeit, die von der Person ausgeführt wird; es gibt keine Ausnahmen von dieser Regel; http://www.scrumguides.org/scrum-guide.html

Der Grund dafür ist nicht, die Dinge zu erschweren, sondern sicherzustellen, dass das Team zusammenarbeitet, bis es das Sprintziel mit seiner Definition of Done erreicht hat.

3. Sie haben erwähnt, dass sich die Entwickler zur Sprintarbeit verpflichten. Als Teil dessen, was ich oben gesagt habe, stellen Sie sicher, dass Dev und QA sich zur Sprint-Arbeit verpflichten . Sie stehen gemeinsam da und müssen sich gegenseitig gleichermaßen unterstützen. Die QA-Arbeit muss sich in Ihrer Schätzung widerspiegeln.

4. Bringen Sie diese Dinge noch einmal in Retrospektiven zur Sprache. Holen Sie sich Ideen und Unterstützung vom Team. Zeigen Sie dem Unternehmen Verbesserungen, damit sie sehen, wie effektiv die Stärkung des Teams ist. Wenn Sie Änderungen vornehmen, finden Sie heraus, was funktioniert und was nicht, und passen Sie sich an, seien Sie agil. Denken Sie daran, dass Agile und Scrum Frameworks sind, die Ihnen Möglichkeiten bieten sollen, schnell große Änderungen vorzunehmen, um die beste Arbeitsqualität zu erzielen, die den Kundenanforderungen entspricht.

Denken Sie als letzte Anmerkung daran, dass Velocity nicht dazu dient, den Teamfortschritt miteinander zu vergleichen oder den Führungskräften allein darüber Bericht zu erstatten. Es soll bestimmt werden, wie viel Arbeit das Team in einem bestimmten Sprint erledigen kann.

Einige Vorschläge:

Automatisieren Sie Ihre Regressionstests so weit wie möglich. Dadurch können sich die QAs auf neue Funktionen konzentrieren. Dies ermöglicht es dem Team dann, während eines Sprints zu testen, anstatt auf das Ende zu warten.

Denken Sie sorgfältig darüber nach, wie Sie die Versionsnummerierung und Umgebungen verwenden. Beispielsweise führen einige Teams, mit denen ich zusammengearbeitet habe, alle paar Tage in einem Sprint einen Drop in eine QA-Umgebung durch. Wenn Sie diesen Ansatz wählen, ist es wichtig, Fehler in Bezug auf eine bestimmte Version zu melden, damit es nicht zu Verwechslungen mit der laufenden Arbeit kommt.

Versuchen Sie, sich kontinuierlich zwischen den Teams zu integrieren. Warten Sie damit nicht bis zum Ende des Sprints. Noch besser ist es, Continuous Integration mit der Automatisierung von Regressionstests zu kombinieren, um regelmäßiges Feedback zum zusammengeführten Code zu erhalten.

Planen Sie außerdem sorgfältig. Wenn Sie während des gesamten Sprints testen möchten, benötigen Sie kleine Stories ohne Abhängigkeiten. Sprechen Sie während der Planung immer darüber, was Sie zuerst testen und wie schnell es fertig sein wird. Ein Team könnte beispielsweise darauf abzielen, die ersten paar Stories nach 2 Tagen des Sprints zum Testen fertig zu haben. Wenn Sie eine Story haben, die besonders schwer zu testen ist, macht es keinen Sinn, am letzten Tag des Sprints mit dem Testen zu beginnen. Versuchen Sie, es früh im Sprint anzugehen und genügend Zeit zum Testen zu haben.

Schließlich fördern Sie die Kommunikation zwischen den Teammitgliedern. Hören Sie auf, das Testen als QA-Aktivität zu betrachten. Es ist eine Teamaktivität und bezieht alle mit ein (einschließlich des Product Owners).

Offensichtlich wird Ihre erste Hürde darin bestehen, Unterstützung zu erhalten, sowohl vom oberen Management als auch vom Team. Aber vorausgesetzt du hast das schon...

Ein Problem, auf das Sie möglicherweise stoßen, ist, dass die QA zu Beginn von Sprints unterfordert ist, wenn es nicht viel zu testen gibt, während die Entwickler gegen Ende unterfordert sind, wenn die meisten Stories in der QA sind. Während 100 % Auslastung ein Trugschluss ist, ist eine starke Unterauslastung auch kaum wünschenswert.

Es gibt andere Fragen und Antworten dazu, aber die grundlegende Erkenntnis besteht darin, zu versuchen, alternative Aufgaben zu finden, um die leichteren Zeitpläne zu füllen. Idealerweise sollten Entwickler in der Lage sein, beim Testen zu helfen, und QA-Personal sollte in der Lage sein, bei der Entwicklung zu helfen. Natürlich sind in Wirklichkeit eines oder beide davon oft nur ein Wunschtraum.

Abgesehen davon gibt es Dinge, die sowohl Entwickler als auch QA-Mitarbeiter tun könnten, um ihre Zeit produktiv zu verbringen, einschließlich, aber nicht beschränkt auf:

• Schreiben von mehr Tests (sei es Einheit, Integration, Akzeptanz, was auch immer).
• Spikes ausführen.
• Erforschung neuer Technologien.
• Technische Schulden angehen.
• Backlog-Verfeinerung.
• Arbeiten an kleineren/niedrigeren Nebenprojekten.

Erwähnenswert auch: Sie haben erwähnt, dass Sie derzeit einen dreiwöchigen Veröffentlichungsplan haben und sich auf zweiwöchige Sprints zubewegen. Haben Sie an dreiwöchige Sprints gedacht? Dies könnte im Wesentlichen mit dem übereinstimmen, was Sie planen, nur ohne das etablierte Release-Zeitplanmuster Ihrer Organisation durcheinander zu bringen.

Ich bin in einem meiner Projekte auf ein paar ähnliche Probleme gestoßen. Wie bei Ihnen häuften sich bei einem Mitglied meines Teams gegen Ende des Sprints die Testanstrengungen. Wenn Stories unvollständig waren (d. h. in diesem Fall keine Tests durchgeführt wurden), führte dies dazu, dass Stories in den nächsten Sprint übertragen wurden, der Fluss unterbrochen wurde, Lieferverzögerungen auftraten, Koordinationsprobleme (zwischen QA und Dev), Chaos usw.

Daraus bin ich herausgekommen, indem ich diese Denkweise entwickelt habe, was wir in einem Sprint verpflichten, MUSS innerhalb des Sprints erledigt werden.
Bitten Sie das Team, die Geschichten zu schätzen und auszuwählen, von denen sie glauben, dass sie innerhalb der 2-Wochen-Timebox entwickelt, getestet und bereitgestellt werden können.

Es ist schwierig, diese Umstellung vorzunehmen, aber Teams werden besser, wenn sie dies ein paar Sprints üben. Zu Beginn haben Sie vielleicht geschäftliche Beschwerden über langsame Lieferung, Team, das nicht leicht zu einem Ergebnis kommt, und vieles mehr. Aber tun Sie es sanft und langsam.

Unverzichtbare Faktoren, auf die Sie sich konzentrieren sollten:

1. Beginnen Sie Ihren Sprint mit der Planung.
2. Setzen Sie sich ein Sprintziel.
3. Machen Sie Geschichten granularer, kleiner und PRÜFBAR.
4. Planen Sie gemeinsam als Team (Entwickler und QA sind beide beteiligt)
5. Schätzen Sie eine Aufgabe/Geschichte unter Berücksichtigung von Entwicklung, Tests, Bereitstellung (Skripts, Konfigurationsänderungen usw.) – alle Aspekte, um diese Geschichte zum Leben zu erwecken, oder stimmen Sie sie mit der Definition of Done (DOD) ab.
6. Coachen Sie das Team, um BDD oder TDD durchzuführen, was die QA-Beteiligung früh in der Entwicklung fördert.
7. Retrospektiven sind in solchen Situationen sehr nützlich, damit Sie verstehen, was funktioniert und was nicht. Passen Sie sich entsprechend an.
8. Verbessern Sie den Prozess, aber führen Sie Verbesserungen nur langsam und schrittweise ein. Führen Sie eine Vorplanung durch und pflegen Sie den Rückstand, sobald die Dinge stabil sind. Bringen Sie etwas Rhythmus in den Prozess. (Ich fand das so nützlich, da es mir geholfen hat, die Geschäftserwartungen besser als zuvor zu verwalten.)
9. Fortschritt messen - Ich habe jeden Tag beim Start ein Burn-Down-Diagramm verwendet, um alle auf Verzögerungen aufmerksam zu machen.
10. Unterstützen Sie das Team wirklich und von ganzem Herzen, da Änderungen/Veränderungen in der Arbeitsweise Moral-/Motivationsprobleme verursachen können.

Hoffe das hilft.

Sie haben einen kritischen Fehler in Ihrem Verständnis davon gemacht, wie dies funktionieren wird.

Sie werden nicht von einem 3-wöchigen Release-Zyklus auf einen 2-wöchigen wechseln. Sie ziehen von 3 Wochen auf 6 Wochen um.

Die Probleme, die Sie mit Entwicklern erleben, die sich zu einem Sprint verpflichten, und dass sie „mit Fehlern überhäuft werden“, sind nicht auf eine Trennung zwischen ihnen und der QA zurückzuführen, sondern auf das Hinzufügen von Aufgaben zu einem laufenden Sprint.

Dieses Problem wird nur noch verschärft, wenn Sie der QA erlauben, Fehler in den aktuell laufenden Sprint einzufügen, damit Ihr Zyklus wie folgt aussieht:

S1: Feature-Entwickler mit einigen getesteten Features.

S2: Testen Sie die verbleibenden Funktionen und entwickeln Sie S1 berichtete Fehler.

S3 : Entwickler S2 hat Fehler gemeldet. abschließender QA-Durchlauf und Abmeldung. Beginnen Sie mit den Zweigfunktionen der nächsten Version, da nicht genügend Entwicklungsarbeit übrig ist

Ein besserer Ansatz besteht darin, versetzte, aber gleich lange Entwicklungs- und Test-Sprints zu haben und sie 1 Woche lang zu machen

Funktionen der S1-Entwicklerversion 1

S2-Test S1-Funktionen, Dev-Release 2-Funktionen in neuem Zweig

S3 Test Release 2 bietet dev S2 gemeldete Fehler

Release 1 am Ende von S3

S4-Entwickler S3 hat Fehler gemeldet

Release 2 am Ende von S4

Wenn Tests „Ausfallzeit“ haben, sollten sie diese nutzen, um die Tests für den nächsten Satz von Funktionen vor der Entwicklung zu schreiben