HEC Blog: Technik & Methoden
Verfasst von Annekathrin Gut am 26. Oktober 2021
Komplexe Aufgaben erfolgreich lösen

Software mit Scrum entwickeln

Scrum hilft, komplexe Aufga­­ben zu lösen. Projekte in der Soft­wa­re­ent­wick­­lung gehö­ren eindeu­tig dazu, denn sie müssen nicht nur zahl­rei­che indi­vi­­du­elle Anfor­­de­run­­gen berü­ck­­sich­ti­­gen, sondern sich auch häufig ändern­­den Rahmen­­­be­­din­­gun­­gen anpas­­sen. Scrum bietet einen Rahmen, um den Entwick­­lungs­­pro­­zess ausrei­chend koor­­di­­niert und dennoch flexi­­bel und lern­­fä­hig genug zu gesta­l­ten.

In der HEC setzen wir Soft­wa­re­ent­wick­­lungs­­pro­jekte deshalb meis­tens nach Scrum um. Großer Vorteil ist das itera­tive und inkre­­men­telle Vorge­hen: Es werden Schritt für Schritt kleine Lösun­­gen erzeugt, die auspro­­biert und konti­­nu­ier­­lich verbes­­sert werden und sich auf diese Weise itera­tiv dem gewün­sch­ten Erge­b­­nis nähern. Alle Lösun­­gen sind inkre­­men­tell, bauen also aufein­an­­der auf. Bei diesem Vorge­hen steht der Endzu­­stand in der Regel nicht von vorne­he­r­ein fest. Das Projekt wächst orga­­nisch.

Wie funktioniert Scrum?

Scrum umfasst feste Rollen in einem Team, Ereig­­nisse inner­halb bestim­m­ter Zeit­­span­­nen und Arte­fakte.

Rollen im Scrum Team

Die zentrale Rolle über­­­nimmt das Scrum Team. Es besteht aus Product Owner, Scrum Master und Entwicklungsteam.

Der Product Owner (PO) wird in unse­ren Projek­ten meist vom Unter­­neh­­men gestellt, das den Auftrag vergibt. Er – oder sie – trägt die Verant­wor­tung für den Produk­ter­­folg, ist also dafür verant­wor­t­­lich, dass die fertig­­ge­­stellte Soft­­ware einen Beitrag zur Wert­­ma­­xi­­mie­rung leis­tet. Seine Aufga­­ben beste­hen darin, zusam­­men mit den Stake­hol­­dern ein Zukunfts­­­bild für das Produkt zu entwi­­ckeln und für ein gemein­sa­­mes Verstän­d­­nis zu sorgen. Hierzu beschäf­tigt er sich mit den Anfor­­de­run­­gen an das Produkt und bringt diese in eine Reihen­­­folge (Prio­ri­­sie­rung), so dass Risi­ken früh­­zei­tig ange­­gan­­gen und der Nutzen des Produk­tes maxi­­miert wird.

Der Scrum Master fördert die Zusam­­me­n­a­r­­beit des Scrum Teams (Wert­strom­­ma­­xi­­mie­rung). Er soll unter ande­rem das Lernen und die Entwick­­lungs­­­ge­schwin­­dig­keit erhö­hen.

Das Entwick­­lungs­­team ist cross-funk­ti­o­nal. Es enthält alle Kompe­ten­­zen, die es zur Umset­­zung der Aufgabe benö­tigt. In der HEC gehö­ren dazu übli­cher­­weise Soft­wa­re­ent­wick­­ler:innen, Tester:innen und Anfor­­de­rungs­­­ma­na­­ger:innen sowie UX-Desi­g­­ner:innen.

Ereignisse

Das Herz von Scrum ist der Sprint: Inner­halb eines Zeit­­fens­ters (time-box) von maxi­­mal einem Monat wird ein ferti­­ges, nutz­­ba­res und poten­­zi­ell auslie­­fer­­ba­res – oder noch besser: ein ausge­­lie­­fer­tes – Produkt-Inkre­­ment herge­­stellt.

In fast allen unse­ren Projek­ten hat sich heraus­­ge­­stellt, dass zwei Wochen die opti­­male Dauer für einen Sprint sind. Der Zeit­raum von 14 Tagen ist lang genug, damit ein Entwick­­lungs­­team neue Funk­ti­o­na­­li­tä­ten mit tatsäch­­li­chem Mehr­wert hers­tel­len kann. Gleich­­zei­tig ist die Spanne kurz genug, um Feed­­back von Auftrag­­ge­­bern, Nutzern und Stake­hol­­dern einzu­ho­len, um Fehl­ent­wick­­lun­­gen zu vermei­­den, die später nur schwer wieder zu korri­­gie­ren wären.

Ein Sprint bein­ha­l­tet das Sprint Planning, die Daily Scrums (die tägliche Abstimmung des Entwicklungsteams), die eigentliche Entwicklungsarbeit, das Sprint Review und die Sprint Retrospektive. Außerdem müssen Zeiten für das Refinement eingeplant werden. Die klar vorgegebenen Ereignisse strukturieren die Entwicklung und ver-dichten die notwendige Kommunikation.

Scrum-Ereignisse Schritt für Schritt

Artefakte

Scrum sieht drei Arte­fakte vor: das Product Back­log, das Sprint Back­log und das Inkre­­ment.

Der PO berei­tet das Product Back­log vor (Refi­ne­ment). Oft ist das Entwick­lungs­team daran betei­ligt. Die erfah­re­nen Scrum Master der HEC oder weitere Expert:innen können bei dieser Aufgabe unter­stüt­zen.

Beim Sprint Plan­­ning legen PO und Entwick­­lungs­­team mit Blick auf das Product Back­log das Sprint­­ziel und die hier­­für umzu­­set­­zen­­den Anfor­­de­run­­gen gemein­­sam fest. Den Umfang bestimmt dabei allein das Entwick­­lungs­­team: Nur sie können realis­tisch einschät­­zen, wieviel in dem gesetz­ten Zeit­raum zu schaf­­fen ist.

Die Anfor­­de­run­­gen wandern in das Sprint Backlog. Schritt für Schritt und nach festgelegter Priorität werden sie abgearbeitet. Der Fortschritt ist jederzeit einsehbar. Bis zum Ende des Sprints soll eine den Anforderungen entsprechende Leistung (Inkrement) entstehen.

Was passiert bei den weiteren Scrum-Ereignissen?

Im Sprint Review werden die während des Sprints umge­­­setz­ten Funk­ti­o­na­­­li­tä­ten live am System präsen­tiert. Die Präsen­ta­tion über­­­­­nimmt idea­le­r­­­weise der PO. Auftrag­­­ge­­­ber, bezie­hungs­­­­­weise dessen Stake­hol­­­der, geben unmit­tel­­­ba­res Feed­­­back auf die Funk­ti­o­na­­­li­tät des Inkre­­­ments.

Alles was noch nicht oder unvoll­­­­­stän­­­dig umge­­­setzt wurde, verbleibt im Product Back­log. Ände­run­­­gen, Ergän­­­zun­­­gen oder Fehler, die im Rahmen des Sprint Reviews erkannt werden, werden in das Product Back­log aufge­nom­­­men. Der PO prio­ri­­­siert die Anfor­­­de­run­­­gen neu. Das Entwick­­­lungs­­­team zieht sich daraus die neuen Aufga­­­ben für den nach­­­fol­­­gen­­­den Sprint.

Das Produk­tin­­­kre­­­ment, das im Sprint erstellt wurde, wird spätes­tens direkt nach Abschluss des Sprints an den Auftrag­­­ge­­­ber über­­­­­ge­­­ben. Nun kann es produk­tiv gesetzt werden, wenn das zu diesem Zeit­­­punkt sinn­voll ist.

Jeder Sprint wird mit einer Retro­­­spek­tive abge­­­schlos­­­sen. Sie bietet dem Scrum Team die Gele­­­gen­heit, sich selbst zu über­­­prü­­­fen und sich konti­­­nu­ier­­­lich zu verbes­­­sern – und das im Zusam­­­men­­­spiel mit dem PO des Kunden. Zum Vergleich: Im Sprint Review soll das Produkt selbst über­­­­­prüft werden. In der Retro­­­spek­tive werden der Prozess und die Zusam­­­me­n­a­r­­­beit im Scrum Team unter­­­sucht. Gemein­­­sam werden Maßnah­­­men zur Verbes­­­se­rung erar­­­bei­tet, die im nächs­ten Sprint umge­­­setzt werden.

Noch Fragen? Dann sprechen Sie mich an:

Beratung / Anforderungs­management