Um Scrum, eines der bekanntesten agilen Vorgehensmodelle, geht es in der einhundertzweiundsechzigsten Episode des IT-Berufe-Podcasts.
Podcast: Play in new window | Download (Duration: 1:17:16 — 36.3MB)
Abonnieren: Apple Podcasts | Spotify | RSS
Inhalt
Scrum ist einer der bekanntesten und praxiserprobten agilen Entwicklungsprozesse. Die Bezeichnung „Scrum“ (deutsch: Gedränge) kommt aus dem Rugby und bezeichnet das Aufeinandertreffen verschiedener Spieler „auf einem Haufen“.
Entwickelt wurde Scrum von Ken Schwaber und Jeff Sutherland für die Softwareentwicklung, aber Scrum wird heute in allen möglichen Bereichen eingesetzt.
Scrum ist lediglich ein Framework und definiert z.B. keine konkreten Methoden für die Softwareentwicklung, wie es z.B. bei Extreme Programming der Fall ist (dort gibt es z.B. TDD, Refactoring, 40-Hour-Workweek etc.). Stattdessen verlässt sich Scrum auf selbstorganisierende Teams.
Scrum ist ein agiler, iterativer und inkrementeller Prozess, was bedeutet, dass er sich an die Gegebenheiten in konkreten Projekten anpassen lässt, in mehreren gleich ablaufenden Iterationen zum Ziel gelangt und dieses mit wachsendem Funktionsumfang erstellt wird.
Grundsätzlicher Ablauf von Scrum
- Zunächst werden alle bekannten Anforderungen erfasst und geschätzt.
- Dann werden die Anforderungen für die nächste Iteration identifiziert (z.B. wichtigste, kritischste, einfachste) und geplant.
- Die Iteration ist time boxed. Sie wird nicht unterbrochen und auch nicht verlängert. Die Iteration heißt auch Sprint. Er ist üblicherweise 30 Tage lang.
- Am Ende der Iteration steht dem Kunden ein „fertiges“ Produkt zur Verfügung, das er sich anschauen und zu dem er Feedback geben kann.
- Der Fortschritt der Arbeit wird täglich in einem kurzen Meeting im gesamten Team besprochen.
- Die wichtigste Zahl bei Scrum ist die Drei: Es gibt jeweils drei Rollen, Artefakte und Meetings.
Rollen
Bei Scrum gibt es drei verschiedene Rollen: Team, Product Owner und Scrum Master.
Das Team führt die Arbeit aus und entscheidet wie viele Anforderungen es in einem Sprint umsetzen kann. Seine Arbeitsweise ist völlig frei durch das Team selbst bestimmbar, es gibt keine Vorgaben („selbstorganisierendes Team“).
Der Product Owner repräsentiert die Kundenbedürfnisse. Ihm „gehört“ das Produkt und er trifft die nötigen Entscheidungen (in Abstimmung mit dem Kunden). Er entscheidet, welche Anforderungen für eine Version umgesetzt werden und wann die Software ausgeliefert wird. Er arbeitet eng mit dem Team zusammen und ist weit mehr als ein einfacher Produktmanager oder Projektleiter, hat aber keine Weisungsfunktion.
Der Scrum Master hilft allen Beteiligten, Scrum korrekt anzuwenden und unterstützt das Team, indem er z.B. „Impediments“ (Hindernisse) beseitigt. Der Scrum Master ist kein Projektleiter, sondern sollte eher als „Consultant“ oder „Coach“ verstanden werden, der penibel prüft, ob die Regeln von Scrum eingehalten werden. Er hat daher auch keine Weisungsbefugnis.
Artefakte
Im Rahmen von Scrum werden drei verschiedene Artefakte erzeugt und bearbeitet: Das Product Backlog, die Sprint Backlogs und das (End-)Produkt. Die obige Darstellung zeigt die Zuordnung der einzelnen Artefakte zu den Phasen von Scrum.
Das Product Backlog ist das zentrale Instrument zum Erfassen und Managen von Anforderungen. Aus ihm werden die in den einzelnen Sprints umzusetzenden Aufgaben oder Tasks abgeleitet. Vereinfacht gesagt ist das Product Backlog eine absteigend nach Priorität sortierte Liste aller bereits geschätzten (!) Anforderungen an das Produkt.
Aus dem Poduct Backlog werden im Rahmen des Sprint Plannings die wichtigsten Anforderungen herausgenommen und für den nächsten Sprint in das Sprint Backlog übertragen. Dort werden alle nötigen Aktivitäten zum Erreichen des Sprint-Ziels aufgelistet und detailliert beschrieben. Das Team schwört sich auf das Sprint Backlog ein und verpflichtet sich zur Umsetzung der dort definierten Punkte („commitment“). Das Sprint Backlog wird täglich aktualisiert.
Das Produkt(-inkrement) ist das wichtigste Artefakt, da letztlich nur die erstellte Software dem Kunden einen Mehrwert bietet und kein Product Backlog oder Sprint Backlog. Um den Kundenanforderungen bestmöglich zu entsprechen wird es in Iterationen entwickelt, um sich nicht von den Vorstellungen des Kunden wegzuentwickeln. Das Produkt beinhaltet: Das Programm, die Dokumentation und die nötigen Tests („definition of done“).
Meetings
Bei Scrum werden drei Meetings abgehalten: Das Sprint Planning, der Daily Scrum und der Sprint Review. Die obige Darstellung zeigt auch die Zuordnung der Meetings zu den Phasen von Scrum.
Beim Sprint Planning werden die im nächsten Sprint umzusetzenden Anforderungen vom Team realistisch geschätzt (z.B. muss die verfügbare Entwicklungszeit realistisch definiert werden, etwa mit 2 Tagen/Woche) und das Team legt sich verbindlich auf das Ziel des Sprints fest. Die Aufgaben werden an die Teammitglieder verteilt. Für die Schätzung kann z.B. Planning Poker gespielt werden.
Das Daily Scrum ist ein „time-boxed Standup-Meeting“, das max. 15 Minuten dauern sollte und am besten direkt vor dem Sprint Backlog durchgeführt wird. Ziel ist, das Sprint Backlog auf den neusten Stand zu bringen und drei Fragen durch jedes einzelne Teammitglied beantworten zu lassen:
- Was habe ich seit dem letzten Daily Scrum gemacht?
- Was werde ich bis zum nächsten Daily Scrum tun?
- Was hat mich bei meiner Arbeit behindert? (das sind die Impediments, die der Scrum Master beheben muss)
Beim Sprint Review am Ende eines Sprints wird das Produkt dem Kunden vorgeführt, damit dieser Feedback geben kann. Im besten Fall wird immer eine lauffähige Software präsentiert und keine theoretischen Überlegungen oder UML-Diagramme. Auf Basis des Kundenfeedbacks können im nächsten Sprint dann gezielt die Probleme behoben oder die nächstwichtigen Anforderungen umgesetzt werden.
Sonstiges
Optional wird von Zeit zu Zeit eine Sprint Retrospective am Ende eines Sprints durchgeführt, um sicherzustellen, dass die Arbeit im Projekt regelmäßig verbessert wird. Der Scrum-Prozess soll ständig optimiert werden und somit ein noch besseres Ergebnis geliefert werden.
Die Velocity des Teams sagt aus, wie schnell dieses Aufgaben abarbeiten kann. Sie pendelt sich im Laufe des Projekts auf einen stabilen Wert ein, da zu Beginn des Projekts die Schätzungen häufig ungenauer sind, weil z.B. die Domäne nicht bekannt ist, Technologien evaluiert werden müssen usw.
Auf dem Burndown Chart kann zu jedem Zeitpunkt der aktuelle Fortschritt des Projekts abgelesen werden. Hier werden im Daily Scrum die Schätzungen der aktuellen Aufgaben aktualisiert, wobei sich diese nach unten (erfolgreich bearbeitet) oder oben (Probleme aufgetreten) entwickeln können. Es geht nicht darum, die aufgewendete (vergangene) Arbeitszeit zu protokollieren, sondern darum, die Schätzung der zukünftigen Aufwände an die aktuellen Erkenntnisse anzupassen.
Literaturempfehlungen
In diesem Video erklärt Ken Schaber, einer der „Erfinder“ von Scrum, den Prozess: Scrum et al..
Ein gutes deutsches Buch, das Scrum im Detail erklärt, ist Scrum: Agiles Projektmanagement erfolgreich einsetzen* von Roman Pichler. Ich habe es damals selbst während meines Studiums gelesen.
*
Links
- Permalink zu dieser Podcast-Episode
- RSS-Feed des Podcasts
- Das agile Manifest
- Scrum – Wikipedia
- Das Minimum Viable Product (MVP) (Grafik mit Auto vs. Skateboard/Roller)
- Agile Ausbildung bei DATEV mit Uwe Ritthammer
Eine Bemerkung zu Rugby. Die Spieler stehen da zusammen und STIMMEN dann AB, was der nächste Spielzug werden soll, wie im Scrum Team, wenn es unterschiedliche Ansichten zu einem Thema gibt.
Buchtipp bzw. Hörbuch: Jeff Sutherland „Die Scrum Revolution“.
Hallo Jeff, oh, das wusste ich noch nicht. Danke für die Info!
Es sind ja wirklich gute Informationen und auch wirklich toll erklärt, aber BITTE – dieses Gegendere ist als würde einem jemand konstant ins Ohr rülpsen.
Es ist einfach eine Vergewaltigung der Sprache und stört einfach nur. Ich schätze Ihre Arbeit wirklich, aber ich bin nicht hier um mir politischen Nonsense anzutun. Bezweifle, das dies die Intention ist, dennoch schreckt es genug ab um sich keine weiteren Episoden anzuhörne, was ich sehr schade finde. Der Informationsgehalt ist wirklich toll und Sie bringen es ja auch verständlich rüber. Im Browser gibt es wenigstens Plugins um diesen Unsinn zu entfernen, in einem Podcast hat man die Möglichkeit leider nicht.
Hallo Sebastian,
danke für dein Feedback! Leider kann ich deinem Wunsch nicht nachkommen. Gerade in einer Branche wie unserer, die so stark männlich dominiert ist, müssen wir alles dafür tun, dass wir niemanden ausschließen. Und das beginnt bei der Sprache. Daher werde ich weiterhin versuchen, alle ITler:innen unabhängig von ihrem Geschlecht anzusprechen.
Übrigens: Seit der Neuordnung der IT-Berufe ist Diversität quasi Pflichtprogramm im Ausbildungsrahmenplan.
Wenn du das für „politischen Nonsense“ [sic!] hältst, musst du wohl auf meinen Podcast verzichten.
Viele Grüße!
Stefan
Das ist ein sehr unglücklicher Strohmannversuch. Was auch immer das „ach so schlimme“ Patriachat mit der Berufswahl zutun hat. Zeigt nur den Grad der (hoffentlich schlicht naiven) Verblendung. Noch ist die Berufswahl frei. Und man wird ganz sicherlich nicht benachteiligt, als Frau in der IT, warum auch? Habe wenig Lust jetzt noch auf den Genderpaygap Mythos einzugehen. Erfahrungsgemäß wird man als Frau eher bevorzugt als benachteiligt. Prangere ich ja auch nicht an. Meinetwegen darf das ja auch gerne weiterhin so bleiben.
Warum sollte das Geschlecht denn überhaupt relevant sein im IT Kontext? Kann man den Job denn besser ausführen, je nachdem welches Geschlechtsteil man hat?
Es handelt sich nicht um Körperliche Arbeit, warum sollte sich da also jemand drum schreren ?
Eben genau deshalb sollte man nicht drauf rumreiten. (Und ja, das ist ein eigener Strohmann)
Genau wegen solchem Unsinn lehnt die Mehrheit der Bevölkerung diese unnötige Verzerrung der Realität auch ab. Es existiert schlicht kein Problem. Es wird künstlich eines erzeugt. Dummerweise erkennt die Bevölkerung, diesen Umstand und trinkt das CoolAid nicht.
Sprache funktioniert so nicht. Es wird nicht „von Oben herab“ befohlen, wie man zu reden hat. Und exakt das gibt die Bevölkerung auch als Feedback. Dennoch möchten es irgendwelchen möchtegern Aktivisten auf nem Machttrip anderen VORGESCHRIEBEN. Selbst die Gruppe von Menschen, die es betrifft MÖCHTE das nicht. Es ist einfach absolut lächerlich.
Kontrolliere die Sprache und du kontrollierst das Denken. Das ist alles. Ein schlichtes Machtspielchen.
Da noch den Deckmantel von „Berücksichtigung“ drumzulegen ist absurd. „Gegenseitige Wertschätzung“ und Gendern gehören nicht in die selbe Schublade. Klassische Motte and Bailey Argumentation. Mag vlt. bei einem 12 Jährigen noch funktionieren, aber je erwachsener ein Mensch wird, desto eher durchschaut dieser das. Und exakt das geben auch die Umfragen zu dem Thema wieder.
2 von 3 Menschen lehnen es ab. Ihnen ist es nicht nur egal, nein – sie sind aktiv DAGEGEN. Im Sinne von AKTIV ABLEHNEN.
Die Prozentzahl ist da sogar weit näher bei der 80 als bei der 60. Der letztendliche „Nutzen“ der Unverständlichmachung der eigenen Sprache existiert hierbei jedoch nicht. Kein Mensch fühlt sich dadurch besser. Im Gegenteil. Es produziert lediglich Verwirrung und Spaltung. Einzig leicht formbare Jugendliche lehnen es nicht völlig ab, da ihnen die Konsequenz nicht bewusst ist. Aber selbst bei diesen Jugendlichen ist die Zustimmung irgendwo unterm 40% Bereich, also auch WEIT fern von irgendeiner Mehrheit.
Menschen ab 30+ liegt die Zustimmung irgendwo unter dem 10% und je älter die Leute werden, desto geringer die Zustimming. Selbst denkende, erfahrene Menschen halt.
Selbst das ZDF, was nichts sonderlich subtil zu indoktrinieren versucht und durchaus ein Pferd im Rennen hat, kam da nicht zu schmeichelhaften Zahlen. Möchte dazu anmerken, das die „pro“ Argumente rein auf Emotionaler Ebene beruhen. Man fühlt, das man andere Menschen doch besser behandeln müsse. Schaut man näher hin, erkennt man sehr schnell, das dieser Umstand jedoch nicht der Realität entspricht. Es wird halt krampfhaft versucht die Sprache als politisches Kampfmittel zu missbrauchen.
Jetzt beballert man sich also mit politischen Floskeln, schürt Lagerdenken und feindet sich an. Exakt das ist die Folge vom Gendern.
Was war daran nun Positiv?
Zu „mehr Inklusion“ führt es jedenfalls nicht. Wie Sie selbst gerade eindrucksvoll bewiesen haben, sogar zur Exklusion (such halt nen anderen Podcast). Na ganz toll.
Huch, da habe ich aber wohl in ein Wespennest gestochen. 🙂 Danke für das ausführliche Feedback. Ich bleibe allerdings trotzdem beim Gendern und freue mich, wenn du mir als Hörer erhalten bleibst. Und wenn nicht, ist das natürlich deine freie Entscheidung. Genauso wie es die meine ist, alle Geschlechter bei meiner Ansprache mit einzubeziehen. Weitere Diskussionen möchte ich an dieser Stelle nicht über das Thema führen, da der Fokus auf IT-Inhalten liegen soll.