Scrum verstehen

Question

Ich habe als ein .net-Entwickler nach dem Wasserfall-Modell gearbeitet. Bei der Arbeit, sagen wir ein 12-monatiges Projekt, folgt mein Team gewöhnlich den Phasen Analyse, Design, Kodierung und Test. Aber wenn es darum geht, dem Scrum-Prozess zu folgen, verstehe ich nicht wirklich, wie ich damit umgehen muss.

Betrachten Sie einen Sprint für 4 Wochen und der Rückstand hat 10 Artikel. Lass den Sprint jetzt beginnen. Wenn Entwickler in den ersten 10 Tagen an einigen Rückständen arbeiten, weiß ich nicht, ob Tests (sowohl SIT als auch UAT) JUST für die verbleibenden 10 Tage benötigen, um die Arbeit abzuschließen. Und jetzt hat unser Sprint keine Zeit mehr, um Bugfixes in letzter Minute zu machen und nur ein paar Bugs konnten im PLN SPRINT behoben werden.

Und wenn wir die Entwicklung zu tun, wie können wir sicherstellen, dass wir das Test-Team beschäftigt abgesehen von nur die Vorbereitung von Testfällen und warten lassen für uns die Funktionalität zu liefern?

Dies wirft die Frage auf, ob wir die erste Aufgabe/Funktion innerhalb der ersten 3 Tage des Sprints liefern müssen, so dass Tester mit ihren Testfällen bereit sein könnten, dieses Teil zu testen.

Ich brauche auch meine Kunden zu erziehen bei der Anpassung des Scrum-Prozesses zu helfen.

Ich brauche ein paar Richtlinien, Referenzen oder eine Fallstudie, um sicherzustellen, dass unser Team einen richtigen Scrum-Prozess folgt. Jede Hilfe wäre willkommen.

Answer 1

In einer idealen Scrum Team, Tester und Entwickler von sollte parallel der Entwicklung auftreten, das Team und Testteil sind, sind die Phasen sich überlappenden, nicht sequentiell (nacheinander Dinge tun innen ein Sprint eine anti- ist Muster bekannt als Scrumerfall). Und im Gegensatz zu einigen hier geäußerten Meinungen produziert eine ultimative Scrum-Implementierung DONE DONE-Geschichten, so dass Tests - einschließlich IST, UAT - während des Sprints durchgeführt werden sollten.

Und nein, Tester müssen nicht für Product Backlog Artikel warten (PBI) vollständig umgesetzt werden, ihre Arbeit zu tun zu beginnen, sie können starten Abnahmen scenarii schreiben, automatisieren sie (zB mit Fitness), eingestellt up test data set, etc (dies benötigt etwas Zeit, besonders wenn das Geschäft kompliziert ist), sobald der Sprint beginnt.

Natürlich erfordert dies eine sehr enge Zusammenarbeit und Freigabe von Schnittstellen oder UI-Skelette früh wird die Arbeit von Testern erleichtern, aber immer noch müssen Tester nicht warten, bis ein PBI vollständig implementiert ist. Und tatsächlich sollten Akzeptanztests von Entwicklern als DONEness-Indikator verwendet werden ("Ich weiß, dass ich fertig bin, wenn Akzeptanztests bestanden werden"). .

Ich sage nicht, das ist einfach, aber das ist, was reife (d. H. Lean) Scrum-Implementierungen und ausgereifte Scrum-Teams tun.

Ich empfehle das Lesen Scrum And XP from the Trenches von Henrik Kniberg, das ist sehr gute praktische Anleitung.

_{Wie Mary Poppendieck schreibt, sei die Aufgabe der Tester sollten Defekte (wesentlich) zu verhindern, nicht zu Defekte (Abfall) zu finden.}

Answer 2

Der Sprint endet nicht mit perfektem Code; Wenn noch Fehler vorhanden sind, können sie im nächsten Sprint starten und einige der anderen Gegenstände, die im nächsten Sprint gelaufen wären, müssen entfernt werden. Du brichst einen Sprint nicht mit etwas perfektem ab, aber idealerweise mit etwas Stabilem.

Answer 3

Sie wenden (ironisch) zu viel Härte auf den Prozess an. Der ganze Sinn eines agilen Prozesses wie Scrum ist, dass der Zeitplan dynamisch ist. Nach dem ersten Sprint arbeiten Sie mit dem Benutzer/Testteam zusammen, um den Fortschritt zu bewerten. An diesem Punkt werden Sie entweder aufgefordert, Details und Features zu ändern, die im ersten Sprint geliefert wurden, oder Sie werden gebeten, mehr Arbeit zu erledigen. Es liegt an Ihnen.

Es ist nur schließlich, wenn Sie die Geschwindigkeit des Teams bestimmt haben (dh., Wie viele Geschichten man vernünftigerweise in einem Sprint erreichen kann), dass Sie Termine und Dinge für größere Projekte beginnen

Answer 4

allererst zu schätzen, Nicht jeder Sprint produziert (wenn überhaupt) ein Big Release. Es ist völlig akzeptabel, dass die ersten Sprints frühe Prototypen/Alpha-Versionen produzieren, von denen nicht erwartet wird, dass sie fehlerfrei sind, aber immer noch in der Lage sind, dem Kunden etwas zu zeigen. Dies ist möglicherweise nicht einmal ein Feature - es kann einfach eine Skelett-Benutzeroberfläche sein, nur um dem Benutzer zu zeigen, wie er aussehen und funktionieren wird.

Auch kann Entwickler selbst (und tut in der Regel) Schreib Unit-Tests, so etwas in einem Sprint geliefert wird, in einem recht stabilen Arbeitszustand sein sollte. Wenn ein neues Feature halb gebacken ist, sollte das Team es einfach nicht liefern. Große Features sollen in kleine Stücke zerlegt werden, die in einen Sprint passen.

Answer 5

Sie definitiv nicht wollen, alle Entwicklung in der ersten Hälfte des Sprints zu tun und alle Tests in der zweiten Hälfte. Das ist nur ein kleiner Wasserfall.

Ihre eigenen Geschichten und Aufgaben sollten in sehr kleine, diskrete Stücke von Funktionalität aufgebrochen werden. (Es kann eine Weile dauern, sich daran zu gewöhnen, besonders wenn die Software, an der du arbeitest, eine monolithische Bestie ist, wie eine meiner früheren Arbeiten, die mit Scrum arbeitet.) Zu Beginn des Sprints entwickeln die Tester ihre Tests und die Entwickler entwickeln ihren Code, und während des Sprints werden die Aufgaben und Geschichten vervollständigt und getestet. Es sollte eine ziemlich konstante Interaktion zwischen ihnen geben.

Das Ende des Sprints kann ein bisschen hektisch sein, während Sie sich an die Methodik gewöhnen. Entwickler werden sich während der Bearbeitung des restlichen Codes belastet fühlen und gleichzeitig Fehler erhalten, die von den Testern korrigiert werden können. Tester werden ungeduldig, weil sie das Ende des Sprints sehen, und es gibt immer noch Code, der nicht getestet wurde. Es gibt eine Lernkurve und es wird etwas gewöhnungsbedürftig sein, das muss dem Unternehmen bewusst sein.

Es ist wichtig, dass die Entwickler und Tester wirklich zusammenarbeiten, um ihre Schätzungen zu erstellen, nicht nur die Zahlen jedes anderen zu addieren. Die Entwickler müssen sich darüber im Klaren sein, dass sie bis zur letzten Minute keine neuen Features programmieren können, da die Tester dort über das Wochenende ihre Aufgabe in Eile erledigen müssen, was letztendlich auf die Entwickler zurückfallen wird in und reparieren Sachen usw.

Einige Aufgaben müssen auf dem Weg neu definiert werden. Einige Geschichten werden am Ende des Sprints scheitern. Es ist OK, du wirst es im nächsten Sprint bekommen. Das Planungstreffen zu Beginn jedes Sprints ist der Ort, an dem diese Geschichten/Aufgaben definiert werden. Denken Sie daran, geduldig zu sein und sicherzustellen, dass das Geschäft mit der Prozessänderung geduldig ist. Es wird sich auf lange Sicht auszahlen, nicht im ersten Sprint.

Answer 6

Ein Scrum-Team ist normalerweise funktionsübergreifend, was bedeutet, dass das gesamte Team dafür verantwortlich ist, in jedem Sprint abgeschlossene Funktionen zu erstellen. Wenn also die QS-Tester die Tests nicht abgeschlossen haben, bedeutet das nur, dass das Scrum-Team den Test nicht abgeschlossen hat. Scrum zählt dazu, dass jeder seinen Teil dazu beiträgt.Wann immer etwas benötigt wird, übernehmen die Leute mit diesen Fähigkeiten die Führung, aber sie alle müssen ihren Teil dazu beitragen.

Answer 7

Versuchen Sie eine kontinuierliche Integration. Das Team sollte sich diese Gewohnheit aneignen und sich kontinuierlich integrieren. Darüber hinaus sollte eine automatisierte Komponententestsuite, die nach jedem Check-in/Delivery erstellt und ausgeführt wird, ein gewisses Maß an Vertrauen in Ihre Codebasis bieten. Diese Praxis stellt sicher, dass das Team jederzeit Code in einwandfreiem und funktionierendem Zustand hat. Außerdem wird es zu Beginn des Sprints eine Integration und einen Systemtest ermöglichen.

Durch Definition und Erstellung von (automatisierten) Abnahmetests werden Personen mit primären QA-/Testfähigkeiten gleich zu Beginn des Sprints beschäftigt und involviert. Stellen Sie sicher, dass dies in Zusammenarbeit mit dem/den Product Owner (s) geschieht, damit alle auf derselben Seite sind und involviert sind.

Answer 8

Wir begannen unser agiles Projekt mit den Entwicklern zuerst (viel Training in Enterprise Framework, etc.) im ersten Sprint. Dann fügten wir QA langsam in den zweiten Sprint ein. Am Ende von Sprint 2 begann QA mit dem Testen. Am Ende des Sprints 3 hatte QA die Geschwindigkeit erhöht und stand mehr oder weniger neben den Entwicklern. Ab Sprint 4 ist QA mehr oder weniger mit Tests abgeschlossen, wenn die Entwickler die Storys abgeschlossen haben. Die Elemente, die normalerweise getestet werden müssen, sind große Elefanten, die die Datenreplikation zwischen neuem und altem System beinhalten. Und es ist eher ein "Sicherstellen, dass Daten OK sind" als tatsächliche Tests.

Wir haben einige Probleme mit unserer Definition von Done. Z.B. wir haben keine. Wir arbeiten an einer komplett neuen Version eines Systems und jetzt, wo wir uns am Ende von Sprint 6 befinden, machen wir uns bereit für den Einsatz in der Produktion. Sprint 6 ist eigentlich etwas, was ich einen kleinen Wasserfall nennen würde. Wir haben die Anzahl der zu implementierenden Elemente reduziert, um sicherzustellen, dass wir genügend Zeit haben, potenzielle neue Probleme zu bewältigen. Wir haben einen Code-Freeze, und Entwickler werden im Grunde mit dem nächsten Sprint beginnen und Probleme in der Branche beheben.

Der Product Owner steht an der Spitze der Lieferung, daher erwarte ich keine Probleme in Bezug auf die Bereitstellung.

Ich kann sehen, dass Pascal über reife Sprint-Teams + die Definition von Done schreiben. Und agil immer auf "Lieferung sofort nachdem Sprint hat sein Ende erreicht" konzentrieren. Allerdings - ich bin mir nicht sicher, ob es sehr viele Teams auf der Welt gibt, die das tatsächlich tun? Wir sind zumindest noch nicht da :)

Answer 9

Es gibt kein Testteam in Scrum. Sein Entwicklungsteam, das funktionsübergreifend ist. Scrum schreckt Spezialisten im Team ab, um Abhängigkeiten zu vermeiden. Die Rolle des Testers ist in Scrum etwas anders als in Waterfall. Es ist eine andere Debatte, aber jetzt bleiben wir bei der Frage.

Ich würde vorschlagen, dass Sie die Geschichten vertikal in so kleinere Aufgaben wie Sie während Teil des Sprint Planning Meeting schneiden können. Es wird empfohlen, die Aufgaben in kleine Einheiten aufzuteilen, so dass sie in ein oder zwei Tagen abgeschlossen werden können.

Definieren Sie ein DoD zu Beginn des Projekts und verfeinern Sie es weiter. Arbeiten Sie jeweils an einer Aufgabe und begrenzen Sie die laufenden Arbeiten. Arbeiten Sie nach Priorität und reduzieren Sie den Abfall in Ihrem System. Gehen Sie nicht für eine detaillierte Vorausplanung und verzögern Sie Ihre besten Entscheidungen bis zum unbeliebtesten Zeitpunkt. Stellen Sie technische Kompetenzen wie BDD und Automation vor.

Und denken Sie daran, dass die Qualität in der Verantwortung des gesamten Teams liegt, also machen Sie sich keine Sorgen darüber, dass Tests von einer engagierten Person durchgeführt werden.