Sprint Geschwindigkeitsberechnungen

Question

Brauchen Sie einen Ratschlag zum Erarbeiten der Teamgeschwindigkeit für einen Sprint.

Unser Team besteht normalerweise aus ungefähr 4 Entwicklern und 2 Testern. Der Scrum-Master besteht darauf, dass jedes Teammitglied gleichmäßig zur Geschwindigkeitsberechnung beiträgt, d. H. Wir sollten nicht zwischen Entwicklern und Testern unterscheiden, wenn wir herausfinden, wie viel wir in einem Sprint machen können. Das stimmt nach Scrum, aber hier ist das Problem.

Trotz gegenteiliger Vorschläge helfen Tester nie mit Nicht-Test-Aufgaben und Entwickler helfen nie mit Nicht-Entwickler-Aufgaben, so dass wir keine funktionsübergreifenden Teammitglieder sind. Trotz verschiedener Vorschläge verbringen die Tester normalerweise die ersten Tage jedes Sprints damit, auf etwas zu testen.

Das Endergebnis ist, dass wir in der Regel viel mehr Entwickler arbeiten, als wir tatsächlich im Sprint haben. Zum Beispiel könnten die Entwickler 20 Tage zur Geschwindigkeitsberechnung beitragen und die Tester 10 Tage. Wenn Sie die Aufgaben nach der Sprint-Planung addieren, addieren die Aufgaben für die Entwicklung bis zu 25 Tage und die Testaufgaben bis zu 5 Tage.

Wie geht es euch mit dieser Situation?

Answer 1

FogBugz verwendet EBS (Evidence Based Scheduling), um eine Wahrscheinlichkeitskurve für den Versand eines Projekts basierend auf vorhandenen Leistungsdaten und Schätzungen zu erstellen.

Ich denke, man könnte das Gleiche mit dies zu tun, nur würden Sie für die Tester eingeben müssen: „Browsing Internet für Entwickler warten (1 Woche)“

Answer 2

Klingt wie Sie Ihr System für mich arbeitet, nur nicht so gut wie du möchtest. Ist das ein bezahltes Projekt? Wenn es so ist, könnten Sie eine Meritokratie bezahlen. Bezahlen Sie Menschen basierend darauf, wie viel Arbeit sie erledigen. Dies würde die disziplinübergreifende Arbeit fördern. Es könnte aber auch Menschen dazu ermutigen, an Teilen zu arbeiten, die ihnen ursprünglich nicht gehörten, oder interne Sabotageversuche.

Offensichtlich müssen Sie auf Leute aufpassen, die versuchen, das System zu spielen, aber es könnte funktionieren. Sicherlich möchten Tester nicht die Hälfte dessen verdienen, was Entwickler tun.

Answer 3

Da es bei der agilen Entwicklung um Transparenz und Verantwortlichkeit geht, klingt es so, als hätten die Tester Aufgaben zugewiesen bekommen, die ihre Geschwindigkeit berücksichtigen. Selbst wenn das bedeutet, dass sie eine Aufgabe haben, um im Internet zu surfen und auf Tests zu warten (obwohl ich denke, dass sie besser dazu dienen würden, Testpläne für die Aufgaben des Entwicklerteams zu entwickeln). Dies zeigt die Ineffizienz in Ihrer Organisation, die nicht populär ist, aber darum geht es bei Agile. Der schlechte Teil davon ist, dass Ihre Tester für etwas bestraft werden können, das ein organisatorisches Problem ist.

Die Firma, für die ich arbeitete, hatte zwei separate (dev und qa) Teams mit zwei verschiedenen Iterationszyklen. Der qa-Zyklus wurde um eine Woche verschoben. Das führte leider zu einer Komplexität bei der Aufgabenakzeptanz, da ein Produkt erst am Ende der Qa-Iteration wirklich bereit für die Freigabe war. Das ist kein richtig integriertes Team, aber das gehört Ihnen auch nicht. Leider hat das Qa-Team nie wirklich Gepraktiken praktiziert (keine wirkliche Planung, Aufstehen oder Retrospektive), so dass ich nicht wirklich sagen kann, ob das eine gute Lösung ist oder nicht.

Answer 4

Wir kämpfen auch mit diesem Problem.

Hier ist, was wir tun. Wenn wir Kapazität und Aufgaben addieren, addieren wir sie zusammen und separat. Auf diese Weise wissen wir, dass wir die Gesamtdauer für jede Gruppe nicht überschritten haben. (Ich weiß, dass das nicht wirklich Gedränge ist, aber wir haben QA-Leute, die nicht programmieren, und damit unsere Ressourcen maximiert werden, enden sie mit dem Testen und wir (die Entwickler) entwickeln uns.)

Das zweite, was wir tun, ist, dass wir uns wirklich darauf konzentrieren, in Scheiben zu arbeiten. Wir versuchen, Aufgaben auszuwählen, die zuerst erledigt werden müssen und schnell zu den QA-Leuten gehen können. Der Trick dabei ist, dass Sie sich darauf konzentrieren müssen, die am wenigsten testbare Menge zu erledigen und zu den Testern zu bewegen. Wenn Sie versuchen, eine ganze "Funktion" zu erhalten, dann fehlt Ihnen der Punkt. Während sie auf uns warten, erstellen sie normalerweise Testpläne.

Es ist immer noch eine Arbeit in Arbeit für uns, aber so versuchen wir es zu tun.

Answer 5

Dies könnte etwas dran, was Sie fragen, aber hier geht es:

ich im nächsten Sprint/Iteration zu tun, als ein Maß dafür, wie viel Arbeit mit Geschwindigkeit wirklich nicht mag. Für mich ist die Geschwindigkeit eher ein Werkzeug für Projektionen.

Der Teamleiter/Projektleiter/Scrum Master kann die durchschnittliche Geschwindigkeit der letzten Iterationen betrachten und hat eine ziemlich gute Trendlinie, um das Projektende zu projizieren.

Das Team sollte Iterationen durch Verpflichtung als Team erstellen. Erforsche die Geschichten, bis die Iteration eine Menge Arbeit hat, die das Team für die Fertigstellung festlegt. Es liegt in Ihrer Verantwortung als Team, dafür zu sorgen, dass Sie nicht nachlassen, indem Sie zu wenig auswählen und nicht zu viele auswählen. Unterschiedliche Fähigkeiten und Spezialgebiete arbeiten sich selbst aus, während sich das Team der Iteration verschreibt.

Unter diesem Modell gleicht sich alles aus. Das Team hat eine angemessene Arbeitsbelastung zu bewältigen und der Projektmanager hat eine Verpflichtung zur Fertigstellung.

Answer 6

Die Tester paarweise als passive Peers programmieren. Wenn sie nichts zu testen haben, können sie zumindest auf Fehler auf dem Spielfeld achten. Wenn sie etwas zu testen haben, wechseln sie im zweiten Teil der Woche in die Teststufe "Funktionalität/Benutzerfreundlichkeit". Auf diese Weise haben Sie beide Gruppen produktiv und im Grunde "durchkämmen" die Tester den Code im weiteren Verlauf.

Answer 7

Erste Antwort für Geschwindigkeit, als meine persönliche Einsicht über Tester in Scrum nicht cross-funktionale Team und frühen Tagen jedes Sprints.

Ich sehe dort Inkonsistenz. Wenn das Team nicht funktional ist, unterscheiden Sie Tester und Entwickler. In diesem Fall müssen Sie sie auch in der Geschwindigkeitsberechnung unterscheiden. Wenn das Team nicht funktionsübergreifend ist, erhöhen Tester ihre Geschwindigkeit nicht wirklich. Ihre Geschwindigkeit ist maximal, was Entwickler implementieren können, aber nicht mehr als was Tester testen können (wenn alles getestet werden muss).

Sprich mit deinem Scrum Master, sonst wird es immer Probleme mit Geschwindigkeit und Schätzung geben.

Jetzt wie für Tester und frühe Tage des Sprints. Ich arbeite als Tester in einem nicht funktionsübergreifenden Team mit 5 Entwicklern, daher kann diese Antwort etwas persönlich sein. Sie können dies auf zwei Arten lösen: a) Ändern Sie die Arbeitsorganisation, indem Sie einen separaten Testsprint hinzufügen, oder b) ändern Sie die Arbeitsweise der Tester.

In a) Sie separate Test Sprint Kiste. Es kann parallel zu Devs Sprint (nur verschoben diese paar Tage) passieren oder du kannst es alle zwei oder drei Dev Sprints passieren lassen. Ich habe von diesen Lösungen gehört, aber ich habe nie so gearbeitet.

In b) müssen Sie Tester bitten, ihre Herangehensweise an Testaktivitäten zu überprüfen. Vielleicht hängt es von den Praktiken und Werkzeugen ab, die Sie verwenden, oder dem Prozess, dem Sie folgen, aber wie können sie in diesen frühen Tagen nichts zu tun haben? Wie bereits erwähnt, arbeite ich als Tester mit 5 Entwicklern in einem nicht funktionsübergreifenden Team.Wenn ich mit meiner Arbeit warten würde, bis der Entwickler seine Aufgabe beendet, würde ich niemals alle Funktionen im gegebenen Sprint testen. Sofern Ihre Tester nicht nur explorative Tests durchführen, sollten sie Dinge tun, bevor das Feature zur Testumgebung freigegeben wird. Es gibt einige Aktivitäten, die getan werden können (oder müssen gemacht werden), bevor Tester Funktion/Code in seine Hände bekommt. Im Folgenden ist das, was ich tue, bevor Funktionen freigegeben werden Umgebung testen:
- Anforderungen durch für Features
umgesetzt werden - Design Test-Scripts (hohe Level-Design)
- Vorbereitung Fälle Entwurf Test
- durch möglichen Test gehen Daten (wenn Änderung, die implementiert wird, Daten im System manipuliert, müssen Sie einen Schnappschuss dieser Daten machen, um ihn später mit dem gegebenen Merkmal zu vergleichen)
- alles in Testsuiten einwickeln
- kommunizieren mit Entwickler als Feature wird entwickelt - so können Sie ein besseres Verständnis für die implementierte Lösung bekommen (anstatt zu fragen, wann er sich bereits Gedanken über andere gemacht hat) eature)
- Sie können alle notwendigen Änderungen vornehmen Fälle zu testen, wie Feature

Dann entwickelt sich, wenn die Funktion abgeschlossen ist Sie: - Fleisch aus Testfälle mit allen Details, die früher nicht bekannt ist (es ist trivial, aber Taste Name kann sich ändern, oder ein zusätzlicher Schritt im Assistenten wird angezeigt.)
- Tests durchführen
- Anstiegsprobleme
. Tatsächlich finde ich mich selbst mehr Zeit für den ersten Teil (Entwurf von Tests und Vorbereitung von Testskripten in einem geeigneten Tool), als tatsächlich diese Tests durchzuführen.

Wenn sie zu allen, die sie sofort können statt warten auf Code zu Testumgebung freigegeben werden, sollte es mit dieser anfänglichen Lücke helfen und es wird das Risiko von Testern minimieren ihre Aktivitäten vor Ende des Sprints zu beenden.

Natürlich wird es immer weniger für Tester geben, am Anfang und mehr am Ende, aber Sie können versuchen, diesen Unterschied zu minimieren. Und selbst wenn sie oben noch viel Zeit übrig haben, können sie ihnen keine Aufgaben widmen, die mit der Programmierung zu tun haben. Einige Konfiguration, einige Wartung, Dokumentationsaktualisierung, andere.

Answer 8

Die Lösung ist nie schwarz und weiß, da jeder Sprint Geschichten enthalten kann, die getestet werden müssen und andere nicht. Agile hat beispielsweise kein Problem, einen Tester aufzuteilen; für 50% ihrer Zeit während eines Sprints und 20% im nächsten Sprint. Es hat keinen Sinn, einen Tester 100% seiner Zeit auf einen Sprint zu verteilen und zu rechtfertigen. Zeitmanagement ist der Schlüssel.

Answer 9

Tester und Entwickler schätzen Geschichtspunkte zusammen. Die Geschwindigkeit eines Sprints ist immer eine kombinierte Anstrengung. QA/Tester können ihre separaten Geschwindigkeitsberechnungen nicht haben. Das ist grundsätzlich falsch. Wenn Sie 3 Geräteentwickler und 2 Tester haben und die Testerkapazität einschließen und diese mit Ihrer Ausgabe in Beziehung setzen, wird die Produktivität immer niedrig sein. Tester nehmen am Testfalldesign, Fehlermanagement und Testen teil, das nicht direkt der Entwicklung zugeschrieben wird. Sie können sich gegen jede dieser Testaufgaben nachverfolgen lassen, aber keine Geschwindigkeitspunkte zuweisen.