Dies scheint ein Streitpunkt zu sein, wo ich arbeite. Einige beschweren sich über den Mangel an Verifikationsstrukturen in Scrum-Projekten, während Scrum-Puristen sagen, dass Scrum nicht darum geht. Beide Seiten bringen große Punkte, aber ich würde gerne sehen, was Leute außerhalb meines Kreises über das Thema sagen. Was sind deine Gedanken? Warum?In einem Scrum-Projekt sollten Tests und Peer-Reviews in jedem Sprint als einzelne Aufgaben bearbeitet werden?
In einem Scrum-Projekt sollte alles, was getan werden muss, als Aufgabe eingegeben werden.
Einer der Schlüsselpunkte von Scrum ist es, genau vorhersagen zu können, was ein Team in einem Sprint erreichen kann. Um dies zu tun, müssen Sie alles berücksichtigen, was die Zeit eines Entwicklers in Anspruch nehmen wird.
Dies bedeutet, dass Dinge wie Dokumentation, Tests und Peer-Reviews alle als Aufgaben berücksichtigt werden müssen.
Bearbeiten: Basierend auf Mendels Beitrag, werde ich die Dinge ein wenig klären.
Von Wikipedia:
Product Backlog: Das Product Backlog ist ein High-Level-Dokument für das gesamte Projekt. Es enthält umfassende Beschreibungen aller erforderlichen Funktionen, Wunschlisten, etc. Es ist das "Was", das gebaut wird. Es ist offen und editierbar für jedermann. Es enthält grobe Schätzungen, in der Regel in Tagen. Diese Schätzung hilft dem Product Owner, die Zeitachse und in begrenztem Umfang die Priorität zu bewerten (z. B. wenn die Funktion "Add spellcheck" auf 3 Tage gegenüber 3 Monaten geschätzt wird, was den Wunsch des Product Owners beeinträchtigen könnte).
Sprint Backlog: Das Sprint Backlog ist ein sehr detailliertes Dokument, das Informationen darüber enthält, wie das Team die Anforderungen für den kommenden Sprint implementieren wird. Aufgaben sind in Stunden unterteilt, wobei die Aufgabe nicht länger als 16 Stunden dauert. Wenn eine Aufgabe länger als 16 Stunden dauert, sollte sie weiter unterteilt werden. Aufgaben im Sprint-Backlog werden niemals zugewiesen, sondern Aufgaben werden von den Teammitgliedern nach Belieben angemeldet.
Artikel auf dem Product Backlog nicht Dinge wie Dokumentation oder Tests zeigen, aber die Aufgaben auf dem Sprint Backlog sicherlich sollte.
Ich gebe ein Beispiel. Angenommen, im Produkt-Backlog gibt es ein "Feature A", dessen geschätzte Zeit 1 Woche beträgt. Auf dem Sprint Backlog, wird das könnte in folgenden Aufgaben unterteilt:
Initial design document: 4 hours Development of subset 1 of Feature A: 8 hours Peer review of subset 1 of Feature A: 2 hours Testing of subset 1 of Feature A: 6 hours Development of subset 2 of Feature A: 8 hours Peer review of subset 2 of Feature A: 2 hours Testing of subset 2 of Feature A: 6 hours User Documentation for Feature A: 4 hours --------------------------------------------- Total time 40 hours
Edit # 2: Die Idee hinter dem Sprint Backlog ist spezifisch wie nur irgend möglich sein, genau zu, wo Sie Ihre Zeit zu verbringen, . Aus diesem Grund können Aufgaben nicht länger als 16 Stunden sein und Sie erreichen einen Punkt, an dem Sie sehr zuverlässig in Ihren Zeitplanvorhersagen sein können.
Wenn Sie die Sprint Backlog Richtlinien religiös befolgen und sicherstellen, alles enthalten, dass Sie Entwicklungszeit auf dann verbringen, werden Sie angenehm überrascht sein, wie genau Ihre Planung nach ein paar Sprints der Praxis sein kann.
stimme ich mit ganzem Herzen zu. – Kilhoffer
Ich stimme jetzt zu. Meine Antwort basierte nur auf dem, was Sie in den Produktstau eingetragen haben. Habe meine (verwirrende) Antwort entfernt und deine klarere Antwort aufgefrischt :-) – Mendelt
Ist diese Detailtiefe immer notwendig? Zum Beispiel scheint es in einer Kultur, in der Code vor einem Commit überprüft wird, nicht notwendig zu sein, dies als ein separates Objekt zu erfassen. Ich sehe es als notwendig an, mit einem neuen Team, in dem die Kultur um Ihre Engineering-Praxis noch nicht so weit entwickelt ist. Wenn TDD und automatische Peer-Review tief verwurzelt ist, scheint die Erfassung ohne zusätzlichen Grund wie ein zusätzlicher Aufwand. – mch
Es sollte, denn wenn Sie sie nicht explizit als Aufgaben eingeben, werden sie möglicherweise nicht ausgeführt. So einfach ist das.
Denken Sie in vertikalen statt horizontalen Schichten.
Wenn Sie Design, Programmierung und Unit-Tests prüfen, Prüfung, usw. als Schichten in einem Entwicklung Kuchen, ich denke, man könnte die Eigenschaften (Geschichten) sehen Sie als Kuchenscheiben liefern, die jeweils aus einem kleines Stückchen Design, Code, Test, Performance, etc. Das ist irgendwie wie bei den "Tracing Bullets" von Pragmatic Programmer.
Vor scrum, wir folgten dem Paradigma der Wasserfallentwicklung, das Code-Reviews enthielt, bevor irgendetwas zur Versionskontrolle übergeben wurde. Seit dem Wechsel zu Scrum vergeben wir keine separaten Aufgaben für die Code-Überprüfung, da dies in Entwicklungsgeschichten implizit enthalten ist.
Eine der Schlüsselverifikationsstrukturen, die in Scrum integriert ist, besteht darin, dass der Product Owner für das Akzeptieren der Stories verantwortlich ist. Das Team erhält nur die Geschwindigkeit, die auf der Bereitstellung des Geschäftswerts basiert.
Ein gängiges Tool für Scrum-Teams ist die Definition von Abnahmetests für Produkt-Backlog-Elemente (diese Backlog-Elemente kommen oft in Form von User Stories vor).
Im Rahmen der Zusammenarbeit als Scrum-Team müssen Sie die Frage beantworten, welche technischen Praktiken das Team verwenden wird, um ein qualitativ hochwertiges Produkt zu liefern. Scrum selbst ist ruhig in diesen Praktiken (ich denke absichtlich, um diese Praktiken im Laufe der Zeit zu entwickeln, wie wir lernen, Dinge besser zu machen).
Diese Praktiken können Dinge wie Komponententests, Paarprogrammierung, Peer-Review usw. sein. Oft werden diese Teil der Definition des Teams, was es bedeutet, etwas zu tun. Wenn ein Team mit Schätzungen zu kämpfen hat oder es zu Ende geht, kann es hilfreich sein, sie als Aufgaben im Sprint-Backlog auszugeben. Meine Empfehlung ist es, den Prozess leicht zu halten - Sie müssen nicht jede Kleinigkeit herausrufen (aber Sie müssen die Zeit berücksichtigen, die benötigt wird, um Routineartikel in den Schätzungen zu verwenden).
Ich stimme zu, diese Frage als Off-Topic zu schließen, weil es nicht um Programmierung geht. –