[Tutorial] Eine Einführung in Scrum – Teil 1 / 2

In diesem Artikel will ich euch eine kleine Einführung in Scrum geben. Immer wieder wird man in der Softwareentwicklung auf Schlagwörter wie “agil”, “agile Softwarentwicklung” und “Scrum” stoßen. Sicherlich habt auch ihr schon mal davon gehört – aber wisst ihr auch, was Scrum überhaupt ist?

Hier will ich euch zeigen, was Scrum ist und wie es eure Softwareentwicklung deutlich verbessern kann.

Scrum Process

Scrum Process

Was ist Scrum überhaupt?

Es gibt in der Softwareentwicklung viele verschiedene Vorgehensmodelle, wie man eine Software entwickeln kann, eine davon nennt sich Scrum.

Bevor ich euch aber erklären kann, was Scrum so einzigartig & besonders macht, müssen wir uns zuerst die “älteren” Modelle anschauen, um den Unterschied besser verstehen zu können.

 

Das Wasserfall-Modell & seine Probleme

Die wohl bekanntesten Modelle sind das klassische V-Modell oder das Wasserfall-Modell, welche noch heute in vielen Unternehmen & im öffentlichen Bereich vertreten ist.

Da sich das Wasserfall-Model nur im geringem Ausmaß vom V-Modell unterscheidet, werde ich hier nur kurz auf das Wasserfall-Modell eingehen:

Wasserfall-Modell in der Softwareentwicklung

Das Wasserfall-Modell besteht aus 5 Phasen:

  1. Anforderungsanalyse – hier werden alle “Kundenwünsche” gesammelt –> Pflichtenheft
  2. Entwurf (Software Architektur & Design)
  3. Implementation (die Programmierung der Software)
  4. Überprüfung der Software (“Tut die Software das, was sie tun soll?”)
  5. Wartung (Bugfixes, Patches, Updates)

 

Jede Phase wird nacheinander durchlaufen. Gehen wir doch einmal ein Beispiel durch:

“Herr Bauer benötigt für sein Strick-Unternehmen einen Onlineshop, um seine Produkte auch international verkaufen zu können.

Leider sagt ihm keiner der bestehenden Onlineshops auf dem Markt zu und er entscheidet sich für eine Neuentwicklung. Dazu geht er zur Firma SoftX, eine kleine Softwareschmiede, welche ihm diesen Onlineshop programmieren soll. Zuallererst wird er gefragt, wie man ihm denn überhaupt helfen kann. Ein Onlineshop ist leider gar nicht so viel aussagend, wie die meisten denken. Der Mitarbeiter von SoftX fragt Herrn Bauer dazu ausgiebig nach seinen Kundenwünschen aus (Anforderungsanalyse), was die Software am Ende alles können soll. Herr Bauer antwortet, dass man Produkte aussuchen, in den Warenkorb legen und dann bestellen können soll. Der Mitarbeiter stellt noch weitaus genauere Fragen, über die Herr Bauer teilweise länger nachdenken muss und hat notiert sich alle Details. Dieser Prozess dauert sogar teilweise mehrere Tage.

Nun ist der Anforderungsanalyst der Meinung, die Kundenwünsche so genau wie möglich zu kennen und übergibt diese den Software Architekten & Entwicklern, welche daraus die Software Architektur & Software Design kreiieren (Entwurf). Nach diesem Entwurf können die Programmierer endlich loslegen und programmieren die Software, bis sie ihrer Meinung nach fertig ist (Implementation).

Danach wird Herr Bauer wieder dazu gebeten, er überprüft die Funktionalität (Überprüfung) und stellt mit Bedauern fest, dass man zwar ein Produkt in den Warenkorb legen kann – aber nicht mehrere gleichzeitig. Er wünscht sich ein Auswahlfeld von 1 – 10, damit die Kunden gleich mehrere Produkte des selben Artikels in den Warenkorb legen kann (Änderungswunsch). Die Programmierer (sowie evtl. auch die Software Architekten usw.) müssen jetzt noch einmal ran und dieses ungeplante Feature implementieren, was zusätzlich Zeit & Geld kostet, da es von vornherein nicht mit bedacht wurde. Am Ende ist Herr Bauer zufrieden mit der Arbeit und die Software wird nur noch auf Anfrage ab und zu gewartet (wenn neue Features benötigt werden).”

 

Das klingt doch bis jetzt ganz gut, oder? Leider hat das Wasserfall-Modell in der Praxis so einige Probleme, weshalb es mittlerweile aus immer mehr Unternehmen verschwindet, z.B.:

  1. Änderungswünsche – Der Kunde kennt nie all seine Anforderungen (“Kundenwünsche”), was immer dazu führen wird, dass der Kunde nachträglich etwas geändert haben will (“Änderungswünsche)”, am besten noch auf Kosten des Unternehmens, weil dieses ihm seinen Aussagen nach die “falsche” Software geliefert hat. Entweder ist das Unternehmen jetzt so kulant und ändert es einfach, oder es muss diese zusätzlichen Kosten (die nicht im Kostenvoranschlag aufgetaucht sind, da sie unbekannt waren) dem Kunden in Rechnung stellen, was den Kunden nicht unbedingt zufriedener macht. Jede nachträgliche Änderung kostet richtig Geld!
  2. Außerdem werden diese “Fehler” (also falsch implementierte Features), die nur nicht richtig kommuniziert wurden, erst entdeckt, nachdem das Produkt fertig programmiert wurde –> spätes Feedback vom Kunden / Fehler werden sehr spät erkannt
  3. Es ist fast unmöglich, zu Projektbeginn wirklich alle Kundenwünsche sorgfältig zusammen zu tragen, da meist der Kunde selbst noch nicht weiß, was er eig. genau will bzw. braucht.

 

Das Hauptproblem liegt in der Vorstellung vieler Kunden, man könnte eine Software gleich von vorn herein komplett durchplanen, was leider ein Irrglaube ist.

Was hier noch recht harmlos klingt, kann im schlimmsten Fall dafür sorgen, dass die Software nie eingesetzt wird und das Unternehmen kein Geld bekommt, nur weil ein paar Features fehlen und kein Budget mehr dafür da ist. Die Standish Group liefert dazu jährlich einen Chaos Report, in welchem sie festgestellt haben, dass 2015 nur 29% der IT Projekte erfolgreich ohne Komplikationen abgeschlossen wurden. 52% haben es gerade so geschafft, das Projekt noch zu veröffentlichen, allerdings mit sehr vielen Problemen. Und 19% der Software Projekte wurden nie beendet, sondern irgendwann (aufgrund der Probleme) aufs Eis gelegt.

 

Und wie ist jetzt Scrum entstanden?

Eine Gruppe aus 17 Softwareentwicklern hat sich zusammengefunden, genau diese Probleme entdeckt & analysiert.

Daraus ist dann das sog. “Agile Manifest” entstanden, wo 4 Punkte hervorgehoben wurden:

  • Individuen und Interaktionen sind wichtiger, als fest definierte Prozesse & Werkzeuge (wenn man mit Kommunikation ein Problem schnell lösen kann, ist es irrelevant, welchen Workflow das Unternehmen dafür besitzt. Beispiel: Ein Support Mitarbeiter muss normalerweise alle technischen Anfragen an den technischen Support weiterleiten. Da er aber weiß, dass dieses sowieso schon überfordert ist und er auch selbst weiß, wie man das Problem beheben kann, hilft er einfach selbst dem Kunden)
  • Funktionierende Software ist wichtiger als Dokumentation
  • Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen (–> frühzeitiges Feedback)
  • Reagieren auf Veränderung (Änderungswünsche) ist wichtiger, als das Verfolgen eines Plans (Flexibilität, Agilität)

 

Wichtig!:

Die Autoren sagen nicht, dass die anderen genannten Punkte auf der rechten Seite vollkommen irrelevant bzw. unwichtig sind! Nur finden sie die linken Punkte weitaus wichtiger, als die Punkte auf der rechten Seite.

 

Aus diesem Manifest hervorgehend haben sich 2 Personen, Jeff Sutherland & Ken Schwaber Gedanken gemacht und das Projektmanagement-Rahmenwerk “Scrum” entwickelt. Ziele bei der Entwicklung von Scrum waren u.a.:

  • Ständiges Kundenfeedback
  • Überschaubarere Zeiträume (keine komplette Planung bis Ende)
  • Effektive Kommunikation
  • Regelmäßige Teilergebnisse liefern (“Inkremente”)
  • Änderungen ermöglichen
  • Transparenz

Siehe auch Was ist Scrum?

 

Scrum ist nicht nur wesentlich flexibler & agiler, sondern liefert auch eine höhere Qualität. Außerdem werden mehr Scrum Projekte erfolgreich abgeschlossen, als herkömmliche Projekte, die auf das Wasserfall-Modell setzen.

Ein Irrglaube ist es allerdings, dass Scrum die Arbeitszeit an einem Produkt verkürzt oder Planung völlig überflüssig wird!

 

Rollen in Scrum

Bevor wir aber mehr auf den Entwicklungsprozess innerhalb eines Sprints eingehen, sollten wir uns zuerst mit den Rollen innerhalb eines Sprints vertraut machen.

Für Scrum wird ein Scrum Team benötigt. Dieses besteht aus 3 Rollen:

  • Product Owner
  • Scrum Master
  • Entwicklungsteam

 

Der Product Owner vertritt den Kunden, erstellt die Liste der Anforderungen (“Product Backlog”), priorisiert die Aufgaben und erklärt dem Team bei Bedarf die Anforderungen. Bei Unklarheiten fragt er den Kunden. Außerdem nimmt er die Ergebnisse eines jeden Sprints ab. Dazu aber später mehr.

Der Scrum Master erklärt dem Team, wie Scrum funktioniert (“Mentor”), fördert die Zusammenarbeit und beseitigt Hindernisse. Kurzum: Er sorgt dafür, dass das Team ungestört arbeiten kann.

Und das Entwicklungsteam selbst implementiert (und entscheidet dabei über die technischen Details), schätzt die Aufwände und liefert letzendlich das Ergebnis. Dazu aber später mehr. Das Entwicklungsteam besteht im Optimalfall aus 7 +/- 2 Personen (Product Owner & Scrum Master nicht mit eingerechnet).

 

Wie funktioniert Scrum?

Es gibt in Scrum 3 Artefakte:

  • Product Backlog
  • Sprint Backlog
  • Inkrement (“fertiges Stück Software”)

 

Zuerst einmal wird vom Product Owner ein sog. Product Backlog entwickelt.

Das Product Backlog stellt eine Liste aller Anforderungen des Kunden dar. Wichtig ist, dass diese Liste priorisiert ist.

Der Product Backlog muss nicht zwingend nur die Anforderungen für den aktuellen Sprint beinhalten, sondern kann auch schon Dinge für die nächsten Sprints oder ganze Produktversionen vorausplanen. Der Product Owner erweitert es regelmäßig.

Während das Product Backlog also alle Kunden Anforderungen beinhaltet, gibt es noch ein sog. Sprint Backlog.

Dieses beinhaltet die Arbeitsanweisungen für das Team inkl. aller technischer Details (Wie soll etwas umgesetzt werden?) und stellt quasi eine Teilmenge des Product Backlogs dar. Die Tasks im Sprint Backlog sind möglichst detailiert. Das Sprint Backlog beinhaltet immer nur die Arbeitspakete für den aktuellen Sprint! Im Gegensatz zum Product Backlog ist nicht der Product Owner für den Sprint Backlog verantwortlich, sondern das Entwicklungsteam. Dieser Sprint Backlog wird beim Sprint Planning gebildet, dazu später mehr.

 

In Scrum wird ein Produkt sog. “Sprints” entwickelt.

Ein Sprint ist eine Iteration, ein Zeitraum, in welchem eine Teilmenge der Funktionalität des Produktes entwickelt wird.

Ein Sprint dauert in der Regel 1 – 4 Wochen. In diesen 1 – 4 Wochen entwickelt das Team also gewisse Features und zeigt diese nach dem Sprint dann dem Kunden / Product Owner (“Regelmäßige Teilergebnisse”), damit dieser die Ergebnisse direkt bewerten kann (“Ständiges Kundenfeedback”). Je länger ein Sprint andauert, umso unplanbarer gestaltet es sich (–> Risikoreich). Wenn ein Sprint allerdings zu kurz ist (< 1 Woche), ist es nahezu unmöglich, etwas ansprechendes auf die Beine zu stellen. Hier muss also die richtige Balance gefunden werden. Während eines Sprints darf die Priorität innerhalb des Product Backlogs nicht angepasst werden. Während des Sprints arbeitet das Entwicklungsteam möglichst alle Tasks aus dem Sprint Backlog ab.

Scrum Process

 

Ausblick

Jetzt weißt du grundlegend, wie Scrum funktioniert. Sicherlich sind aber noch einige Unklarheiten geblieben, z.B.:

  • Wie & wann wird jetzt der Sprint Backlog gebildet?
  • Wie funktioniert die Entwicklung innerhalb eines Sprints?
  • Wie & Wann schaut sich der Kunde das fertige Teilprodukt nach einem jeden Sprint an?
  • Kann dieses Vorgehen verbessert werden?

 

All diese Fragen werde ich in einem 2. Blog Beitrag beantworten, in welchem ich näher & tiefer auf Scrum eingehen werde. Dieser 1. Teil sollte erstmal einen Überblick verschaffen. Für Kritik, Anregungen & Feedback bin ich wie immer jederzeit offen und freue mich sogar darüber! 😀
Nur Kritik hilft mir, meine Beiträge & Tutorials zu verbessern! 😀

 

Weiterführende Literatur & Quellen

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.