Was ist Scrum?

Scrum ist ein Teil der Agilen Methodik. Es ist das beliebteste Framework für agile Entwicklung und ein einfaches Prozess-Framework.

Ein "Prozessrahmen" ist eine Reihe von Regeln, die ein Prozess befolgen muss, damit er mit dem Rahmen übereinstimmt. (Das Scrum-Prozessframework sieht beispielsweise Entwicklungszyklen vor, die Sprints genannt werden, während das XP-Framework Pair Programming vorschreibt usw.)

"Leichtgewichtig" bedeutet, dass der Prozess so wenig zusätzliche Schritte wie möglich enthält, damit so viel Zeit wie möglich für die Erledigung nützlicher Aufgaben genutzt werden kann. Ein Scrum-Prozess unterscheidet sich von anderen agilen Prozessen, weil er bestimmte Ideen und Methoden verwendet, die in drei Gruppen eingeteilt werden können: Rollen, Artefakte und Time Boxes.

Scrum wird meist verwendet, um die Entwicklung komplexer Software und Produkte mit Hilfe iterativer und inkrementeller Methoden zu steuern. Im Vergleich zu traditionellen "Wasserfall"-Prozessen macht Scrum einen großen Unterschied darin, wie viel Arbeit erledigt wird und wie lange es dauert, bis Ergebnisse sichtbar werden. Mit Scrum-Prozessen können sich Unternehmen leicht an sich schnell ändernde Anforderungen anpassen und Produkte herstellen, die den sich ändernden Geschäftszielen entsprechen. Ein agiler Scrum-Prozess hilft dem Unternehmen, weil er es ihm ermöglicht:

• Verbesserung der Qualität der Produkte;
• Besser mit Veränderungen umgehen (und diese erwarten);
• Die Kostenvoranschläge sind genauer und benötigen weniger Zeit;
• Mehr Verantwortung für den Zeitplan und den Stand des Projekts zu übernehmen.

Was sind die Voraussetzungen für Scrum?

Scrum schreibt nicht genau vor, wie die Anforderungen aussehen sollen. Stattdessen heißt es nur, dass sie in das Product Backlog kommen und "Product Backlog Items" oder kurz "PBIs" genannt werden. Da ein Sprint eine bestimmte Zeitspanne umfasst, können wir auch davon ausgehen, dass die Umsetzung eines jeden Anforderungssatzes viel weniger Zeit in Anspruch nehmen sollte als der Sprint selbst. Die meisten Scrum-Projekte verwenden die "Extreme Programming"-Methode (XP), bei der eine Feature-Anfrage als "User Story" bezeichnet wird, aber eine kleine Anzahl von Projekten verwendet noch den älteren Begriff "Use Case". In diesem Blog-Beitrag werden wir dem folgen, was die meisten Leute denken, und über drei ziemlich standardmäßige Anforderungsartefakte sprechen, die in Product Backlogs zu finden sind.

• Anwenderbericht

  Eine "User Story" beschreibt in Form einer Geschichte die gewünschte Funktion (funktionale Anforderung). User Stories werden in der Regel vom Product Owner geschrieben, der auch für sie verantwortlich ist. Das Format ist nicht standardisiert, aber es enthält in der Regel einen Namen, einen beschreibenden Text, Links zu externen Dokumenten (z. B. Screenshots) und Informationen darüber, wie die Implementierung getestet werden soll.

• Geschichte

  Nicht alle Anforderungen für Neuentwicklungen sind benutzerorientiert, aber sie alle bedeuten, dass eine Menge Arbeit geleistet werden muss. Meistens, aber nicht immer, handelt es sich bei diesen Anforderungen um Arbeiten, die erledigt werden müssen, um Funktionen zu unterstützen, die die Endbenutzer sehen. Wir nennen diese Anforderungen, die nichts mit der Funktion zu tun haben, "Technical Stories". Technical Stories haben die gleichen Bestandteile wie User Stories, aber sie müssen nicht als Stories geschrieben werden, wenn es nicht hilfreich ist. Meistens schreiben die Teammitglieder die technischen Stories, die dann dem Product Backlog hinzugefügt werden. Der Product Owner muss diese Stories kennen und wissen, wie sie mit den User Stories zusammenhängen, damit er sie in die richtige Reihenfolge bringen kann, damit sie gebaut werden können.

• Fehler

  Ein Defekt, auch Fehlerbericht genannt, ist eine Beschreibung, wie das Produkt nicht so funktioniert, wie es sollte. Fehler werden in einem System zur Verfolgung von Fehlern aufbewahrt, das das gleiche System sein kann, in dem auch das Product Backlog gespeichert ist. Wenn dies nicht der Fall ist, muss die QA (in der Regel der Product Owner) jeden Fehler zum Product Backlog hinzufügen, damit er eingeplant und in die richtige Reihenfolge gebracht werden kann.

Schlussfolgerung

Im heutigen wettbewerbsintensiven globalen Umfeld hat sich die Zeit, die benötigt wird, um neue Softwareprodukte auf den Markt zu bringen, um das Zehnfache verkürzt. Der Produktlebenszyklus oder Systementwicklungsprozess beginnt mit der Marktforschung zu einem Konzept oder den Bedürfnissen eines Kunden und setzt sich bis zur Bereitstellung und zum Betrieb des Systems fort. Das Scrum-Manifest ist erforderlich, um ein System schnell zu entwickeln und auch noch spät in der Entwicklungsphase auf vom Kunden initiierte Änderungen der Anforderungen einzugehen. Dies ist auf den globalen Wettbewerb und die veränderten Kundenbedürfnisse zurückzuführen, die zum Scrum Manifest führten. Scrum erfreut sich immer größerer Beliebtheit, und dieser Trend wird wahrscheinlich noch viele Jahre anhalten.