Agile Softwareentwicklung – Scrum

Dieser Post ist der Start einer kleinen Reihe von Artikeln, in denen wir kurz und knapp das vielleicht wichtigste Instrument der agilen Softwareentwicklung vorstellen wollen – Scrum. Zielgruppe dieser Artikel sind all diejenigen, die sich auf die Prüfung zum Professional Scrum Master oder Professional Scrum Product Owner vorbereiten wollen. Wer sich nicht sicher ist, wo er sich zertifizieren soll, findet in unserem Blog einen Vergleich der Scrum Alliance und scrum.org Zertifikate.

Standards


Wir haben zur Lernkontrolle exemplarische Prüfungsfragen verlinkt, die zur Vorbereitung auf die Zertifizierung dienen sollen. Ganz wichtig ist in diesem Zusammenhang auch der offzielle Scrum Guide, den ihr auf scrum.org bzw. scrumguide.org finden könnt.

Viel Spaß beim Lernen und viel Erfolg bei der Zertifizierung :)

Einführung in Scrum

itemis Scrum

Scrum kennen viele als eine Methode aus der agilen Entwicklung. Viele Menschen verbinden mit diesem Begriff aber zunächst etwas anderes.

Für sie ist Scrum hauptsächlich eine Standardsituation im Rugby. Diese findet statt, um das Spiel nach kleineren Regelverstößen, einem unerlaubten Vorwärtsspielen des Balles oder nach einem Aus neuzustarten. Wörtlich übersetzt bedeutet Scrum bei Rugby "Gedränge".

Als Methode in der agilen Softwareentwicklung bildet Scrum ein Gesamtsystem aus Meetings, Artefakten, Rollen und Werten. Es stellt ein einfaches Prozessmodell für die Entwicklung von Produkten dar und basiert auf den Grundsätzen der agilen Softwareentwicklung. Scrum setzt sehr stark auf die Selbstorganisation der Teammitglieder. Ein Projektmanager mit umfangreicher Autorität im klassischen Sinne existiert in Scrum nicht.

Der Anfang von Scrum

Scrum wurde von Ken Schwaber und Jeff Sutherland am Anfang der 1990er Jahre entwicklet. Schwaber legte 2003 ein Zertifizierungsprogramm zum Certified Scrum Master vor. Dieses entwickelte er seit 2009 weiter zu zwei Professionalisierungstufen, den Professional Scrum Master I und Professional Scrum Master II.

Ein Beweggrund dabei ist es, die Grundsätze des agilen Softwareengineerings und das Framework Scrum von seinem semiprofessionellen Stigma zu befreien. Scrum ist heute in der Softwareentwicklung als Methode weit verbreitet und etabliert wird aber auch in anderen Branchen mehr und mehr eingesetzt.

Rollen im Scrum-Prozess

Scrum besteht aus nur wenigen Rollen, Meetings und Artefakten, die im Folgenden näher erläutert werden.

Product Owner

Der Product Owner maximiert den Wert des Produktes. Er kennt seine Kunden, verwaltet und priorisiert die Anforderungen und steuert dadurch die Entwicklung. Das wichtigste Artefakt für seine tägliche Arbeit ist das sogenannte Product Backlog – eine geordnete Auflistung der Anforderungen an das Produkt.

Dies umfasst Features, Funktionalitäten, Verbesserungen und Fehlerbehebungen. Der Product Owner kümmert sich darum, dass die Product Backlog Einträge klar formuliert sind und dass das Entwicklungsteam die Einträge im erforderlichen Maße versteht.

Als Repräsentant des Kunden bestimmt er die Reihenfolge der Product Backlog Einträge unter Gesichtspunkten wie wirtschaftlicher Nutzen, Risiko und Notwendigkeit. Er muss sicherstellen, dass das Product Backlog sichtbar ist und für jeden klar ist, woran das Scrum Team als nächstes arbeiten wird.

Typischer Weise möchte der Kunde bzw. Fachbereich über den nächsten Sprint hinaus planen:

  • Bis wann werden welche Features, Erweiterungen und Anpassungen des Produktes umgesetzt?
  • Kann ein bestimmter Termin eingehalten werden?

Um derartige Fragen zu beantworten, muss der Product Owner einerseits für eine Aufwandsbewertung der Product Backlog Einträge sorgen, z.B. indem er eine Schätzklausur organisiert. Anderseits muss er die Entwicklungsgeschwindigkeit (Velocity) bzw. Leistungsfähigkeit seines Teams kennen, um dann in Abstimmung mit dem Kunden/Fachbereich einen Releaseplan zu erstellen.

Die Product Owner-Rolle erfordert also gute Fähigkeiten im Requirements Engineering und Projektmanagement. Gute Kommunikations- und Moderationsskills sind dafür eine wichtige Voraussetzung. Da der Product Owner sehr eng mit dem Development-Team zusammenarbeitet, ist es weiterhin von Vorteil, wenn er ein solides Verständnis für die Technik (Software-Entwicklung) mitbringt.

Der Product Owner kann die oben genannten Arbeiten selbst übernehmen oder sie durch das Entwicklungsteam erledigen lassen. Er bleibt jedoch verantwortlich (accountable). In jedem Fall ist es sehr wichtig, dass die Aufgaben und Verantwortlichkeiten des Product Owners unter den konkreten Randbedingungen klar definiert und ggf. von den Aufgaben anderer Rollen abgegrenzt werden.

Zudem benötigt der Product Owner die volle Unterstützung und Ermächtigung seines Managements, damit er die Rolle erfolgreich ausfüllen kann.

Team

Das Entwicklungsteam besteht im Idealfall mindestens drei aber weniger als zehn Personen. Es organisiert sich selbst und entwickelt eigenverantwortlich die Software in sogenannten Sprints. Dies ist der Begriff für Iterationen in Scrum.Wird bei Scrum vom Scrum-Team gesprochen, so ist die Gesamtheit aus Product Owner, Entwicklungsteam und Scrum Master gemeint.

Werden für eine Entwicklung signifikant mehr als neun Personen benötigt, so sieht Scrum keine Vergrößerung des Teams vor, da dies die Kommunikationsfähigkeit gefährden würde. In so einem Fall soll "Scrum of Scrums" verwendet werden: Es werden mehrere Scrum-Teams gebildet, jeweils ein oder zwei Personen aus jedem dieser Teams bilden ein hierarchisch höher angesiedeltes Team, das ebenso den Scrum-Prozess durchläuft und vorranging koordinierende und integrierende Aufgaben hat.

Dieses Prinzip kann, falls erforderlich, auf weiteren Ebenen fortgesetzt werden und führt zu einer Baumstruktur von Teams.

Scrum Master

Der Scrum Master hat im Prozess die Aufgabe, die Werte und Regeln während des Projektes zu wahren und Hindernisse zu beseitigen. Er ist ebenfalls die Schnittstelle des Teams zur Außenwelt und zuständig für die Kommunikation mit Nichtteammitgliedern, um das Team von dieser Aufgabe zu befreien und als zentrale Anlaufstelle zu fungieren.

Der Scrum Master ist prinzipiell nicht höher gestellt als das Team. Darüber hinaus existieren weitere Rollen, die nicht Teil des eigentlichen Scrum-Prozesses sind, aber auf diesen einwirken. So sollen auch folgende Gruppen die Ergebnisse der Sprints in den »Review Meetings« kommentieren:

  • Benutzer, die das Produkt anwenden sollen und für die das Produkt entwickelt wird.
    Käufer und / oder Verkaufspersonen, die das Produkt kaufen oder verkaufen sollen.
    Höheres Management, welches die Umgebung der Projektentwicklung bereitstellt und dem Projekt grobe Ziele und Anforderungen vorgibt.

Scrum Prozess


  Scrum Master und Product Owner Zertifizierung

  

Diesen Artikel weiterempfehlen

    

Über den Autor

Jens Wagener ist Vorstandsvorsitzender der itemis AG.