Ein Scrum-Sprint ist also ein fester Zeitraum, in dem eine bestimmte Reihe von Funktionen implementiert werden sollte. Ein Scrum-Team besteht aus allen Personen, die sich für die Bereitstellung dieser Funktionen einsetzen. Die meisten von ihnen sind in der Regel Entwickler und Tester.
Nachdem man diese Regeln aufgestellt hat, könnte man sich fragen, wie man all diese Leute während des gesamten Sprints beschäftigt. Zu Beginn des Sprints gibt es noch nichts zu testen, und am Ende des Sprints gibt es normalerweise nichts oder nur noch sehr wenig zu entwickeln / zu reparieren.
Ich habe 2 Ansätze gesehen, um damit umzugehen, aber keiner von beiden scheint das Problem richtig zu lösen.
1) Lassen Sie die Teammitglieder entscheiden, was zu tun ist, wenn sie keine Aufgaben mehr haben.
Nachteile:
- Wenn das, was sie tun, nicht sorgfältig geplant ist (z. B. größere Umgestaltungen, Umstellung auf ein neues Test-Framework), kann sich herausstellen, dass ihre Arbeit unbrauchbar ist oder zur Hälfte ausfällt
- Andererseits kann die Planung solcher Arbeiten viel Zeit in Anspruch nehmen, und der Kunde kann enttäuscht sein, wenn das Team Zeit mit etwas verschwendet, das keinen unmittelbaren Wert bringt
- Solche Aufgaben lassen sich normalerweise nicht genau abschätzen, sodass es für Mitarbeiter ohne Grundkenntnisse recht einfach ist, YouTube-Katzen zu beobachten, ohne dass dies auf dem Scrum Board oder anderswo zum Ausdruck kommt
2) Platz im Sprint nur für die Entwicklung schaffen und nach Abschluss des Sprints mit dem Testen beginnen (wenn die Entwickler mit der Arbeit an den Funktionen des nächsten Sprints beginnen)
Nachteile:
- Während der Entwicklung von Funktionen für den aktuellen Sprint werden Entwickler durch die Behebung von Fehlern des vorherigen Sprints abgelenkt, und sie können möglicherweise nicht die Menge an Arbeit ausführen, die voraussichtlich während des aktuellen Sprints erledigt wurde
- Es werden zwei Scrum-Boards benötigt: eines für die aktuellen Sprint-Features und eines für die vorherigen Sprint-Bugs
Meine Frage lautet also: Wie kann man die Arbeit während des Sprints richtig zwischen Entwicklern und Testern verteilen, damit niemand mit Arbeit überlastet wird oder irgendwann ohne Aufgaben endet? Gibt es Möglichkeiten, die oben beschriebenen Ansätze zu verbessern? Oder gibt es bessere Ansätze?
Antworten:
"Ja wirklich?" Sie haben keine Validierungsanforderungen? Keine Gespräche mit Ihrem Kunden? Keine zu bewertenden Wire-Frames? Keine Testpläne zum Nachdenken?
Ich war noch nie an diesem Ort in einem Projekt. Keine Arbeit mehr zu tun? Da ist immer etwas. Sind alle Ihre Tests voll automatisiert? Wie sieht Ihr CI aus? Könnte die Datenbankzugriffsebene einfacher umgestaltet werden? Und ich habe noch nie an etwas mit einer leeren Fehlerliste und einem leeren Rückstand gearbeitet. Was haben Ihre Entwickler in einer Wasserfall-Testphase gemacht?
Ich weiß, dass manche Leute sehr religiös sind, was SCRUM ist und was nicht. Das könnte mich nicht weniger interessieren. Aber ich denke, Sie haben hier zwei Probleme:
Eine "traditionelle" QA-Abteilung, die den Code testet, sobald er von den Entwicklern "fertiggestellt" wurde, anstatt mit Kunden und Entwicklern zusammenzuarbeiten, um sicherzustellen, dass Sie das Richtige und das Richtige erstellen. Schauen Sie sich die agilen Testquadranten von Lisa Crispin an. Die besten Tester sind in jeder Phase des Softwareentwicklungszyklus involviert und die besten Entwickler schreiben ihre eigenen Tests.
Versuchen Sie, sich zu eng an einen SCRUM-Zeitplan für Sprints von einer Woche / zwei Wochen zu halten, ohne einen priorisierten und bemessenen Rückstand zu haben, der in Aufgaben aufgeteilt ist, die sich innerhalb kurzer Zeit in einem Sprint leicht erledigen lassen . Wenn du das hättest, gäbe es immer mehr Arbeit, mit der du weitermachen könntest. Vielleicht wird die letzte Funktion, an der Sie in diesem Sprint arbeiten, nicht in die Veröffentlichung dieses Sprints aufgenommen, aber sie kann immer in die nächste übernommen werden.
Beiseite. Wenn Sie ein kleines zusammenhängendes Team haben, sind die Rollen weniger wichtig. Anstatt jemanden mit dem Etikettentester zu haben, der keinen Produktionscode schreiben darf, oder jemanden, der einen Entwickler beschriftet, der glaubt, über den Test zu stehen, sollte jeder das tun, was für den Erfolg des Teams erforderlich ist, einschließlich der gefürchteten Projektmanagementaufgaben, wenn Sind sie notwendig, spricht man von einem funktionsübergreifenden Team.
Ein zusätzlicher Punkt, den @Cort Ammon in den Kommentaren angesprochen hat. Im agilen Manifest geht es um die Zusammenarbeit der Kunden bei Vertragsverhandlungen. Du sagst das:
Es kann schwierig zu erklären sein und ich verstehe, dass Kunden manchmal sehr schwierig sein können, aber das wäre eine große rote Fahne für mich. Sie vertrauen Ihnen ihren Quellcode, ihre Kundenbeziehung, ihr Geschäft und alles, was Sie für sie entwickeln. Wenn sie nicht darauf vertrauen können, dass Sie in ihrem besten Interesse professionell handeln, dann haben Sie entweder ein Problem oder sie tun es.
Ich habe einen Beitrag geschrieben , in dem es darum geht, dass Softwareentwickler nicht als Profis gelten. Ein professioneller Arzt, Anwalt oder Bauingenieur, der sich mit einem Kunden konfrontiert sah, der die Anforderungen an ihn im Laufe der Zeit änderte, würde nicht nur die Qualität mindern und darüber jammern. Sie würden ihren Kunden sagen, dass es ein Problem sein würde. Wenn der Kunde Druck ausübte, würde ein Fachmann dies nicht einfach blindlings auf gefährlich minderwertige Weise tun, weil er haftbar wäre. Wir machen keine professionellen Aufnahmeprüfungen und haften daher nicht. Das heißt nicht, dass wir nicht versuchen sollten, besser zu werden.
Zusammenfassend würde ich mir nicht zu viele Sorgen machen, wenn ich versuchen würde, die Mitarbeiter zu Beginn und am Ende eines Sprints effizienter zu machen, sondern dies als Symptom für ein größeres Problem im Team betrachten würde. Haben Sie etwas gehört eXtreme Programming (XP) . Ich würde sagen, die Grundsätze von XP, die hier gelten, sind Kommunikation und Respekt:
quelle
Der erste Punkt ist, dass es bei Scrum darum geht, das Team zu optimieren , nicht jeden einzelnen. Wenn das Team produktiv und effizient ist, spielt es keine Rolle, ob jemand zu Beginn oder am Ende der Aufgabe untätig ist.
In jedem Team, in dem ich war, gibt es jedoch immer viel Arbeit. Lassen Sie mich auf einige Ihrer spezifischen Probleme eingehen:
Dies mag zwar im wahrsten Sinne des Wortes zutreffen, impliziert jedoch, dass der einzige Job für einen Tester darin besteht, "zu testen". Es gibt viel zu tun, bevor sie mit dem Testen beginnen. Zum einen können sie sich mit dem Product Owner und den Entwicklern treffen, um die Anforderungen vollständig zu verstehen. Sie können damit beschäftigt sein, an einem Testplan zu arbeiten, Testdaten zu sammeln und so weiter. Wenn sie den Luxus eines guten Frameworks haben, können sie frühzeitig mit dem Schreiben automatisierter Tests beginnen.
Ich habe noch kein Entwicklerteam gesehen, dem die zu reparierenden Dinge ausgegangen sind. Dies ist jedoch nicht das, was sie am Ende des Sprints tun sollten. Gegen Ende des Sprints sollten sie den Testern helfen, das Produkt zu testen. Sie können helfen, automatisierte Tests zu schreiben, sie können Tests und Fixtures / Keywords / etc, die von den Testern geschrieben wurden, mit Code überprüfen. Sie können mit dem Dokumentationsteam zusammenarbeiten, um ihre Arbeit usw. abzuschließen.
Der Fehler in Ihrem Denken ist, dass Einzelpersonen keine Aufgaben mehr haben. Aufgaben gehören zum gesamten Team. Sie sollten keine andere Arbeit verrichten, solange im aktuellen Sprint noch Geschichten oder Aufgaben für das Team übrig sind .
Dieser Ansatz entspricht nicht der traditionellen Definition von Scrum oder Agile. Der springende Punkt ist, dass ein ganzes Team daran beteiligt ist, auf ein gemeinsames Ziel hinzuarbeiten. Das bedeutet, dass alle für die Fertigstellung einer Story erforderlichen Arbeiten in einem Sprint dargestellt werden müssen - Entwurf, Entwicklung, Test, Dokumentation usw.
Schließlich ist dies nicht die einzige andere praktikable Lösung. Sie vernachlässigen die wahre Lösung: Jedes Teammitglied sollte sich nach Bedarf einschalten, um die Storys im Sprint zu beenden.
Das Ziel ist , ein Team Ziel, aber Sie schreiben , als ob jede einzelne Person hatte individuelle Ziele ( „meine Aufgaben beenden“). Wenn jemand nichts zu tun hat, kann er sehen, woran gerade gearbeitet wird, und bietet Hilfe an. Oder sie können die nächste Aufgabe oder Geschichte übernehmen und mit der Arbeit beginnen.
quelle
In allen agilen Läden, in denen ich gearbeitet habe, werden Tester als Hühner angesehen, damit sie im Sprint nicht wie die Entwickler in einer Zeitbox landen. Bevor Sie die Software in die Hände bekommen, sollten Tester Pläne schreiben und sicherstellen, dass die Umgebungen für den Empfang der Software ordnungsgemäß eingerichtet sind. Als Teil davon sollten sie alle Designdokumente im Auge behalten, wie sie sind.
Als nächstes sollten Sie versuchen, den Sprint zu füllen. Am Ende des Sprints sollte es keine Freizeit geben, wenn die Schätzungen gut sind, obwohl die Schätzung natürlich eine schwarze Kunst ist, sodass sie sich selten genau ausfüllt .
Wenn ein Entwickler am Ende des Sprints Freizeit hat, sollte diese Zeit trotzdem aufgezeichnet werden, um sicherzustellen, dass sie einen Mehrwert bietet (Erlernen eines neuen Frameworks, Ausführen von Analysen, weitere Tests usw.).
Fehlerbehebung ist eine durchaus akzeptable Aktivität, um in einen Sprint versetzt zu werden. Es trägt zu einer Funktion bei und schafft so einen Mehrwert. Dies sollte nicht als Zeitdiebstahl für den nächsten Sprint angesehen werden - um ein Feature besser zu beenden.
quelle
In einer idealen Welt wäre Ihr Team funktionsübergreifend . Jeder hat seine Spezialisierung, aber jeder kann auch als eine andere Spezialisierung arbeiten. Wenn Ihre Tester die einfachsten Aufgaben nicht codieren können, haben Sie kein funktionsübergreifendes Team.
Der SCRUM Weg wäre, um Ihr Team zu ermöglichen, zu sein Quer funktional. Ihre Tester sollten sowieso über Kenntnisse in der Testautomatisierung verfügen. Dies ist ein kurzer Schritt, um einige der weniger komplexen Dinge zu codieren.
quelle