Kategorie: Scrum

Das Product Backlog listet alle Features, Funktionen, Anforderungen, Erweiterungen und Korrekturen auf, die für die Produktversionen erforderlich sind. Product Backlog-Projekte haben die Attribute Beschreibung (angemessen detailliert), Story Points (Schätzungen) und Aufträge (priorisiert). Sie müssen im Backlog kontinuierlich hinzugefügt, gelöscht und aktualisiert werden (Emergent) und das Verständnis des Team-Backlogs zeitnah und angemessen widerspiegeln.

Die agile Entwicklung ist eine auf den Menschen ausgerichtete, iterative und schrittweise Entwicklungsmethode. Bei der agilen Entwicklung wird der Aufbau eines Softwareprojekts in mehrere Teilprojekte unterteilt, und die Ergebnisse jedes Teilprojekts wurden getestet und haben die Merkmale der Integration und des Betriebs. Mit anderen Worten: Ein großes Projekt wird in mehrere kleine Projekte aufgeteilt, die miteinander verbunden sind, aber auch unabhängig voneinander durchgeführt und abgeschlossen werden können. Während dieses Prozesses befindet sich die Software immer in einem brauchbaren Zustand.

LeSS ist ein leichtgewichtiges, agiles Framework für die Skalierung von Scrum auf mehr als ein Team. Ab 2005 entwickelten Bas Vodde und Craig Larman das LeSS-Framework, nachdem sie die Scrum-Prinzipien und -Regeln bei Großprojekten angewendet hatten. Ihr Ziel war es, große Projekte erfolgreich zu entwickeln und dabei die Beschränkungen von Scrum einzuhalten.

Die meisten Agile- und Scrum-Schulungen beziehen sich auf die 7 +/- 2-Regel, d. h. agile oder Scrum-Teams sollten aus 5 bis 9 Mitgliedern bestehen. Scrum-Enthusiasten erinnern sich vielleicht daran, dass der Scrum-Leitfaden besagt, dass Scrum-Teams nicht kleiner als 3 und nicht größer als 9 sein sollten. Woher kommt diese Faustregel und warum?

LeSS wurde von Bas Vodde und Craig Larman aus praktischen Erfahrungen bei der Skalierung von Scrum entwickelt und 2014 als LeSS Company gegründet. Das Prinzip “More with LeSS” ist das Herzstück von LeSS (Large Scale Scrum). Komplexe Produktentwicklung erfordert keine komplexen Lösungen. Sie erfordert ein tiefes Verständnis für die Essenz der Probleme, die dann mit einfacheren Lösungen gelöst werden können.

In der Softwareentwicklung stoßen wir immer wieder auf diese Begriffe. Manchmal bezeichnen die Leute ein Software-Feature, eine Anforderung, einen Anwendungsfall, ein Backlog-Element …. Was ist die Konvention der Softwareentwickler für die Verwendung dieses oder jenes Begriffs?

In der Software-Entwicklung beinhaltet die übliche “Schätzung” eine quantitative Bewertung des für eine bestimmte Entwicklungsaufgabe erforderlichen Aufwands; dieser wird in der Regel in Form von Dauer (Stunde/Tag) oder geschätzter Einheit (Story Point) ausgedrückt. Der Zweck besteht darin, eine Reihe solcher Einzelschätzungen zu konsolidieren, um einen Hinweis auf die Gesamtdauer, den Arbeitsaufwand oder die Kosten des Softwareprojekts zu erhalten.