User Stories in Aufgaben aufzuteilen und ihre Entwicklungszeit in Stunden zu schätzen , ist ziemlich weit verbreitet. Wir haben jedoch nachfolgende Testaktivitäten, die durchgeführt werden müssen, bevor die Aufgabe und damit die Geschichte als erledigt gelten können.
Sollte die anfängliche Schätzung für die Entwicklung der Aufgabe Arbeitsstunden beinhalten , die geschätzt werden, um die Geschichte fertigzustellen, oder sollten wir zusätzliche stündliche Schätzungen für die Testaufgaben haben?
Wenn Sie dedizierte Tester haben, kann es sinnvoll erscheinen, eine separate Testaufgabe für sie zu haben. Aber wenn man darüber nachdenkt, ist das Testen wirklich eine Teamaktivität.
Beispielsweise muss ein Tester möglicherweise mit einem BA oder Product Owner sprechen, um mehr darüber zu erfahren, was er testet. Möglicherweise müssen sie auch mit den Entwicklern sprechen, um die neue Funktionalität zu verstehen. Und natürlich können sie Fehler aufwerfen, die von den Entwicklern behoben werden müssen.
Ich denke, es ist besser, Aufgaben als Ganzes zu schätzen, einschließlich all dessen, was erforderlich ist, um sie „erledigt“ zu machen.
Kurz gesagt: was für das Team, den Entwicklungsprozess und die Erledigung der Dinge am besten funktioniert.
Drilldown von der Story-Ebene:
Die Story soll ein voll funktionsfähiges Produkt liefern. Wenn das Testen in Ihrer Definition of Done oder den Akzeptanzkriterien enthalten ist, ist das Testen ein Teil der Geschichte.
Sie können Geschichten in Aufgaben unterteilen, wenn dies der Entwicklung hilft (alle sind sich im Detail einig, welche Aufgaben Teil der Fertigstellung der Geschichte sind). Das Testen könnte eine separate Aufgabe sein. Sie könnten auch Tests in jede Aufgabe einbeziehen. Sie könnten sogar eine separate Testaufgabe erstellen, die mit jeder Entwicklungsaufgabe verknüpft ist. Was auch immer dem Team hilft, das Produkt fertigzustellen.
Meine persönliche Meinung ist, dass es in den meisten Fällen zu viel ist, Stunden für separate Testaufgaben zu schätzen, die zu einer Entwicklungsaufgabe gehören. Es ist eine Menge Overhead, der besser für die eigentliche Arbeit ausgegeben werden sollte. Die Komplexität der Geschichte und ihre Tests sollten sich in der Anzahl der Story Points widerspiegeln. Die Schätzung sehr spezifischer Stunden für Testaufgaben sollte sich nicht auf die Gesamtkomplexität oder die benötigte Zeit auswirken. Ihre Situation kann dies erfordern oder auch nicht. Es ist unmöglich zu sagen, wenn Sie nicht wissen, wie Ihr Team und Ihr Prozess aussehen. Viele Vorteile halte ich für unwahrscheinlich.
Es hängt von der Mannschaft ab. Einige Teams haben dedizierte Tester, bei denen es sinnvoll ist, separate Testaufgaben zu haben, da dies Entwickler und Tester dazu zwingen kann, die Testanforderungen zu untersuchen. Andere Teams verwenden XP-Praktiken oder haben Entwicklungs-/QA-Teams, bei denen die meisten Tests im Einklang mit den Entwicklungsaktivitäten stattfinden.
Tasking ist ein Werkzeug, das dem Team hilft, die Geschichte im Hinblick auf die taktische Umsetzung zu erkunden. Die Zuweisung von Arbeitsstunden liegt am unteren Ende der Werteskala der Verwendung von Tasking und ist normalerweise kein guter Grund, Tasking zu verwenden, da es sich um eine (zeitlich) kostspielige Aktivität handelt.
Ich denke, es kommt darauf an, wer die Zielgruppe ist.
Wenn das Publikum der Kunde ist, denke ich, dass es ihnen nicht viel ausmachen würde, dass Sie X Stunden zum Entwickeln und Y Stunden zum Testen brauchen, nur wie lange es dauert, bis das Produkt zu ihnen kommt.
Wenn die Zielgruppe Ihr internes Projektteam ist, kann es eine große Hilfe sein, die Schätzungen für Entwicklung und Tests zu trennen. Wenn es Ihnen aus keinem anderen Grund Daten gibt, können Sie Ihre Schätzungen für nachfolgende Sprints verfeinern, sodass Sie leichter erkennen können, wo die Dinge zusammenbrechen, wenn (nicht wenn) Sie feststellen, dass Ihre Schätzungen ungenau sind.
Sofern Ihre Definition of Done das Testen nicht als eines der Kriterien ausschließt, müssen Sie das Testen in Ihre Gesamtschätzung für das Product Backlog Item einbeziehen. Ob Sie das Testen als implizite Aufgabe oder als explizite Aufgabe behandeln, wird durch das Framework nicht vorgeschrieben.
Sollte die anfängliche Schätzung für die Entwicklung der Aufgabe Arbeitsstunden beinhalten, die geschätzt werden, um die Geschichte fertigzustellen, oder sollten wir zusätzliche stündliche Schätzungen für die Testaufgaben haben?
In Scrum ist das Ergebnis für jeden Sprint ein potenziell auslieferbares Inkrement, das das Sprint-Ziel erreicht und die „Definition of Done“ erfüllt. Ihre Schätzungen für jedes Product Backlog Item (oder User Story, wenn Sie dieses Format verwenden) sollten immer alles enthalten, was erforderlich ist, um alle Elemente der Definition of Done zu erfüllen, einschließlich Tests, Dokumentation, Validierung und alles andere, was das Team vereinbart hat Stellen Sie sicher, dass ein Inkrement wirklich vollständig ist.
Im Allgemeinen werden Elemente der Definition of Done als implizite Aspekte jedes Product Backlog Items (PBI) verstanden und fließen einfach in die Gesamtschätzung des PBI ein, anstatt als einzelne Aufgaben für jedes Item oder jede User Story aufgeschlüsselt zu werden. Wenn Sie jedoch das Testen jedes Elements als explizite Aufgaben in Ihrem Sprint-Backlog austeilen, sollten Sie diese Aufgaben auf jeden Fall genauso schätzen wie jede andere Aufgabe.
Dies läuft wirklich auf ein Buchhaltungsproblem hinaus. Sicherzustellen, dass das Testen in Ihrer Gesamtschätzung des Aufwands zum Abschließen eines Product-Backlog-Eintrags berücksichtigt wird, ist eine agilere Schätztechnik als das falsche Gefühl der Genauigkeit, das man bekommt, wenn man vorgeschlagenen Testaufgaben exakte Stunden zuweist – zumal es oft viele gibt Ping-Pong zwischen Testen und Entwicklung in agilen Techniken wie Test-Driven Development – aber es ist nichts falsch daran, Testaufgaben explizit zu schätzen, solange Sie dies konsistent über alle Ihre Product-Backlog-Einträge hinweg tun.
Der Grund, warum die meisten Shops dies nicht tun, ist, dass Sie, wenn Sie das Testen getrennt von der Entwicklung berücksichtigen, auch Aufgaben und Schätzungen für alle anderen Elemente der Definition of Done haben sollten. Dies führt im Allgemeinen zu mehr Prozessaufwand, einem falschen Eindruck von Präzision und ist selten genauer als die aggregierte Schätzung für ein Product Backlog Item, die implizit die vollständige Definition of Done enthält.
Scrum sieht vor, dass das gesamte Team gemeinsam an einer einzigen User Story arbeitet, bis sie fertig ist . Zur Definition of Done gehört für mich das Testen und Sicherstellen, dass Akzeptanzkriterien erfüllt werden. Das gesamte Team ist dafür verantwortlich, die User Story fertigzustellen, und wird daher wahrscheinlich Zeit für die User Story aufwenden. Daher sollte der Testaufwand geschätzt werden.
Außerdem gibt es in Scrum keine Rolle als „Tester“ oder „Entwickler“. Alle fallen unter die Kategorie der Teammitglieder. Da ein Teammitglied (hier Tester lesen) an einer User Story arbeiten wird, sollte sein/ihr Aufwand geschätzt und protokolliert werden.
Jeff Lindsey