Agentur für agile Softwareentwicklung

Die GSWE GmbH nutzt für die Entwicklung von Software in der Regel die agile Softwareentwicklung mit Scum. Mit agiler Software-Entwicklung entwickelt unsere Software-Agentur maßgeschneiderte Software, die es den Kunden unser Agentur ermöglicht, Veränderungen in Ihren Geschäftsprozessen und -zielen zeitnah in Ihrer Unternehmenssoftware abzubilden.

agentur agile softwareentwicklung
Agile Softwareentwicklung, agentur agile softwareentwicklung

Grundlage dafür sind die drei einfachen Prinzipien auf die Scrum basiert: sichtbarer Fortschritt, ständige Überprüfung und Anpassung. Mit Scrum verwenden wir in der agilen Softwareentwicklung eine erprobte Methode, um uns an veränderte Anforderungen und Prioritäten anzupassen. Unser Ziel in der Software-Entwicklung mit Scrum ist es, unseren Auftraggebern in regelmäßigen Abständen funktionierende Software bereitzustellen.

Nachfolgenden möchten wir einen Überblick über die verschiedenen Rollen innerhalb eines Projekts geben, den Lebenszyklus von Projekten veranschaulichen und die wichtigsten Praktiken beschreiben. Erfahren Sie, warum die Methode für Softwareprojekte funktioniert und erhalten Sie einige praktische Ratschläge für die Implementierung.

Scrum als Methode für den Prozess in der agilen Softwareentwicklung

Die Methode Scrum ist ein agiler Prozess zur Steuerung von Projekten, dass oft in der Softwareentwicklung eingesetzt wird. Scrum definiert nicht die Implementierung der Software selbst, sondern ist ein leichtgewichtiges Framework, das auf einigen Richtlinien für das Management von Projekten basiert. Scrum folgt einer Prozesskontrolle, bei der sich das Team auf der Grundlage von Erfahrungen anpasst, anstatt einer strengen Reihe von Schritten oder einem sehr detaillierten Plan zu folgen. Das Wort Scrum selbst kommt aus dem Rugby und bezieht sich auf eine Möglichkeit, das Spiel neu zu starten.

Die Methode Scrum, wie wir sie heute kennen, ist das Ergebnis der Zusammenarbeit von Jeff Sutherland und Ken Schwaber. 2001 schrieben sie das Buch Agile Software Development with Scrum, das die Praktiken einem breiteren Publikum zugänglich machte und dazu beitrug, Scrum über die Jahre zu einem Mainstream-Softwareentwicklungsprozess werden zu lassen.

Die meisten Projektmitglieder (Scrum-Team) sind üblicherweise auch in traditionellen Entwicklungsteams zu finden. Es gibt jedoch in einem Scrum-Team einige Unterschiede bei den Verantwortlichkeiten, die es wert sind, nachfolgend zuerst genauer beschrieben zu werden.

  • Scrum-Team
  • In der Scrum-Methode gibt es drei Rollen, die für die Besetzung eines Scrum-Team in jedem Fall benötigt werden:
  • ScrumMaster
  • Product Owner
  • Entwicklungsteam
  • ScrumMasters

Die Rolle des ScrumMasters ähnelt einem Projektmanager in der traditionellen Softwareentwicklung. In Scrum erhält er jedoch bewusst einen anderen Namen, um die Unterschiedlichkeit deutlich zu machen.

Obwohl der ScrumMaster dafür verantwortlich ist, dass sich das Team so schnell wie möglich bewegt, ist diese Rolle eher ein Moderator und Coach als eine, die Kontrolle ausübt und Entscheidungen trifft. Der ScrumMaster hilft dem Team, die Scrum-Prinzipien zu befolgen (z. B. sicherstellen, dass Iterationen zeitlich begrenzt sind, Hindernisse beseitigen, die Zusammenarbeit zwischen Teammitgliedern fördern usw.) Im Gegensatz zu traditionellen Projektmanagerrollen weist der ScrumMaster den Entwicklern oder der QA keine einzelnen Aufgaben zu, sondern Vielmehr organisiert sich das Entwicklungsteam bei jeder Iteration selbst und bestimmt, wer welche Aufgabe übernimmt. Der ScrumMaster muss jederzeit verfügbar sein, um Hindernisse zu beseitigen und sicherzustellen, dass das Team über alle erforderlichen Ressourcen für den Job verfügt.

Product Owner

Der Product Owner ist ein Vertreter der Business-Seite, der die Prioritäten der zu entwickelnden Items festlegt. Der Product Owner muss entweder vor Ort oder für das Team jederzeit hoch verfügbar sein, um Fragen zu beantworten und unklare Anforderungen zu klären. Sie sollte beispielsweise auf E-Mails und Rückrufe umgehend antworten und an Demos der laufenden Arbeiten teilnehmen, um zu überprüfen, ob das Team auf dem richtigen Weg ist. Im Gegensatz zu anderen Entwicklungsprozessen ist der Product Owner in Scrum während seiner gesamten Laufzeit aktiv am Projekt beteiligt, nicht nur am Anfang oder am Ende.

Das Entwicklungsteam in Scrum kann aus Entwicklern, QA und Business-Analysten bestehen. In einem Scrum-Team erstellt das Entwicklungsteam Schätzungen und erledigt die Arbeit. Das Entwicklungsteam wählt jedoch nicht aus, welche Funktionen entwickelt werden sollen – das ist die Aufgabe des Product Owners. Sobald eine Iteration beginnt, organisiert sich das Entwicklungsteam selbst und entscheidet, wer die einzelnen Elemente erledigt und wie es am besten vorgeht. Während jeder Iteration arbeiten Entwickler, QA und Business-Analysten täglich sehr eng zusammen, um sicherzustellen, dass die Arbeit richtig entworfen, codiert, getestet, repariert und am Ende der Iteration möglicherweise auslieferbar ist.

Teamzusammenarbeit und Selbstorganisation sind Schlüsselpraktiken in Scrum-Teams, da sie es den Menschen ermöglichen, die die Arbeit erledigen, zu entscheiden, was der beste Ansatz ist, um die Arbeit zu erledigen und sie auszuführen. Es ist erstaunlich, wie sehr sich die Produktivität verbessert, wenn Mitglieder eines funktionsübergreifenden Teams täglich zusammenarbeiten. Diese Synergie zwischen den Teammitgliedern in einem Scrum-Team ist einer der größten Vorteile von Scrum und macht meiner Erfahrung nach einen großen Teil des Erfolgs von Scrum-Teams aus.

Prozesse in der agilen Software-Entwicklung

Scrum-Projekte werden in kurzen Iterationen (Sprints) verwaltet, in denen das Team an den wichtigsten Elementen des Projekts arbeitet, wie vom Product Owner definiert, und am Ende jeder Iteration potenziell auslieferbaren Code liefert. Alles in Scrum dreht sich um Sprints. Abbildung 1 zeigt das Grundgerüst des Scrum-Prozesses mit Schlüsselkomponenten wie dem Product Backlog, dem Sprint Backlog, dem Sprint und dem Daily Meeting. In den folgenden Abschnitten beschreibe ich in chronologischer Reihenfolge, was im Lebenszyklus eines Projekts mit Scrum passiert. 

Sprint-Planung

Bevor ein Sprint beginnt, überprüft der Product Owner (mit Hilfe des ScrumMasters) die Liste aller neuen Funktionen, Verbesserungen, Änderungsanfragen und Fehlerberichte, die sich im Laufe der Zeit angesammelt haben, um zu entscheiden, welche zu diesem Zeitpunkt am wichtigsten sind. Wenn es sich um ein neues Projekt handelt, enthält die Liste die Funktionen, die das neue System bereitstellen muss. Die gesamte Liste der Elemente wird als Product Backlog bezeichnet und jedes Element muss eine Beschreibung der Anforderung, die Priorität für das Unternehmen und grundlegende Schätzungen enthalten. Es ist die Aufgabe des Product Owners sicherzustellen, dass diese Liste immer auf dem neuesten Stand ist.

Scrum gibt dem Product Owner während der Laufzeit eines Projekts ein hohes Maß an Kontrolle, da es ihm ermöglicht, die Prioritäten in jedem Planungsmeeting nach Belieben zu ändern (dh alle zwei Wochen oder alle 30 Tage, je nach Größe Ihres Sprints). Auch wenn das Product Backlog zuvor priorisiert wurde, kann der Product Owner Elemente in jedem Planungsmeeting neu priorisieren.

Die Praktiken und Richtlinien von Scrum funktionieren, weil sie die wichtigste Komponente der Softwareentwicklung ansprechen: Menschen und ihre Interaktionen.

Da Product Owner das Unternehmen repräsentieren, haben sie normalerweise eine Vorstellung davon, was die Kunden wollen und was zuerst geliefert werden muss. Ausgestattet mit diesem Wissen und vorläufigen Schätzungen wählt der Product Owner eine Teilmenge von Elementen aus dem Product Backlog zur Berücksichtigung im Sprint-Planungsmeeting aus.

Das Sprint-Planungsmeeting besteht aus zwei Teilen. Während der ersten Hälfte des Meetings (die ersten 2-4 Stunden) beschreibt der Product Owner dem Scrum-Team die Funktionen, die sie in der nächsten Iteration gerne implementiert sehen möchte. Entwickler und QA stellen dem Product Owner Fragen, um für jeden Artikel „ausreichende“ Schätzungen zu erstellen. Dies ist kein Design-Meeting. Die Tatsache, dass dies ein kurzes Meeting ist, zwingt das Team, nicht zu viel Zeit damit zu verbringen, jeden Punkt zu überanalysieren. Der ScrumMaster hilft, dieses Meeting fokussiert und innerhalb der vereinbarten Zeit zu halten.

Nachdem das Team Schätzungen vorgelegt hat und mehr Arbeit veranschlagt ist als im Sprint verfügbare Zeit, ist es die Aufgabe des Product Owners zu entscheiden, welche Product Backlog-Elemente aus dem Sprint entfernt und welche beibehalten werden. Es ist sehr wichtig, nur so viele Elemente aufzubewahren, von denen die Entwickler glauben, dass sie sie abschließen können. Es ist auch wichtig, den Product Owner (und nicht die Entwickler) entscheiden zu lassen, welche im Sprint behalten werden sollen. Kurzum: Das Entwicklungsteam schätzt, aber der Product Owner priorisiert.

So verlockend es auch sein mag, die Dauer eines Sprints „nur noch ein paar Tage“ zu verlängern, um Platz zu schaffen und ein paar weitere Items hineinzuquetschen, Scrum-Praktiker empfehlen, die Sprintgröße konstant zu halten. Der ScrumMaster setzt diese Praxis während des Planungsmeetings durch. Timeboxing zwingt den Product Owner, Entscheidungen zu treffen und sich auf Elemente mit hoher Priorität zu konzentrieren, anstatt zu versuchen, alle möglichen Funktionen in einer Iteration aufzunehmen. Denken Sie daran, dass Scrum iterativ ist; es wird weitere Iterationen geben. Wenn die ausgelassenen Punkte dennoch sehr wichtig sind, kommen sie beim nächsten Sprint-Planungsmeeting ganz oben auf die Liste.

Die Elemente, die im Sprint aufbewahrt werden, werden als Sprint Backlog bezeichnet. Diese Punkte werden für die Dauer des Sprints im Fokus des Teams stehen. Während der zweiten Hälfte des Sprint-Planungsmeetings (die letzten 2-4 Stunden) erstellt das Team einen Plan zur Ausführung der Punkte des Sprint-Backlogs. Zum Beispiel kann das Team einige der Elemente in kleinere Blöcke aufteilen, damit mehrere Entwickler daran arbeiten können, entscheiden, wie die Funktionen getestet werden, welche Funktionen voneinander abhängen und welche zuerst behandelt werden sollten Sprint.

Sprint

Ein Sprint ist eine Iteration, in der das Entwicklungsteam (Entwickler und QA) am Sprint Backlog arbeitet. Während dieser Zeit muss der Product Owner zur Verfügung stehen, um Fragen zu beantworten und Feedback zu Features zu geben, wenn diese sich entwickeln. Am Ende des Sprints ist das Entwicklungsteam dafür verantwortlich, potenziell auslieferbaren Code bereitzustellen. Potenziell auslieferbarer Code bedeutet, dass er codiert, getestet und produktionsbereit ist, auch wenn er nicht sofort produktiv gehen wird. Scrum empfiehlt, dass das Team am Ende des Sprints dem Product Owner die Software mit den neuen Funktionen vorführt.

Ein Sprint dauert in der Regel zwei Wochen oder 30 Tage. Frühe Literatur über Scrum empfahl 30 Tage, aber in letzter Zeit habe ich die meisten Teams gesehen, die zweiwöchige Sprints durchgeführt haben. Ich bevorzuge zweiwöchige Sprints aus verschiedenen Gründen. Erstens macht es ein kürzerer Zeitraum für das Team einfacher, zwei Wochen Arbeit zu planen, abzuschätzen und abzuschließen, anstatt vier oder sechs. Ein kürzerer Zeitraum macht Sprint-Planungsmeetings kürzer und führt dazu, dass Schätzungen genauer sind, da der Sprint kleiner ist. Zweitens geben zweiwöchige Sprints dem Product Owner die Freiheit, Prioritäten häufiger zu ändern, was dem Team hilft, sich schnell an den Marktdruck anzupassen.

Welchen Zeitrahmen Sie auch immer für Ihre Sprints gewählt haben, stellen Sie sicher, dass sie zeitlich begrenzt sind. Timeboxing gibt dem Team ein greifbares Ziel (z. B. haben Sie nach zwei Wochen diese vier neuen Funktionen abgeschlossen.) Menschen arbeiten besser, wenn sie wissen, dass sie erfolgreich sein können und wenn ein Ende in Sicht ist. Das Zwingen von Teams, am Ende jedes Sprints potenziell auslieferbaren Code zu haben, verhindert auch, dass Teams in einen dauerhaften „85 % erledigt“-Zustand verfallen, in dem das Team immer kurz davor ist, etwas abzuschließen, aber es nie fertig wird. Timeboxing ermutigt das Team auch, das System stabil zu halten, da es weiß, dass es am Ende des Sprints einen Checkpoint gibt, an dem es eine funktionierende, potenziell auslieferbare Version des Systems demonstrieren muss. Das ist gut für das Entwicklungsteam, den Product Owner und die Kunden.

Die Dauer des Sprints für die Dauer des Projekts konstant zu halten, ist ebenfalls eine gute Praxis, da dies dem Team einen Rhythmus verleiht.

Product Owner können einem Sprint nicht mehr Arbeit hinzufügen, wenn er einmal begonnen hat. Sie müssen neue Anforderungen bis zum nächsten Sprint-Planungsmeeting verschieben. Da Sprints jedoch normalerweise von kurzer Dauer sind und das beinhalten, was der Product Owner für am wichtigsten hielt, sind Product Owner in der Regel empfänglich für die Idee, ein paar Tage bis zum Ende des Sprints zu warten, um die Prioritäten zu ändern. Denken Sie daran, dass sie bei jedem Sprint-Planungsmeeting neue Prioritäten setzen können. Es ist möglich, einen laufenden Sprint zu stoppen und abzubrechen, wenn der Product Owner nicht warten kann und die Prioritäten mitten im Sprint geändert werden müssen. Das passiert meiner Erfahrung nach in Scrum eher selten.

Scrum unterscheidet sich auch dadurch von anderen Softwareentwicklungsprozessen, dass weder der ScrumMaster noch der Product Owner dem Entwicklungsteam bestimmte Aufgaben zuweist. In Scrum-Teams entscheiden die Teammitglieder nach der Definition des Sprint-Backlogs untereinander, wie es umgesetzt wird. Einige Teams ziehen es vor, alle Elemente während des Planungsmeetings vorab untereinander zuzuweisen, während andere nur eine Handvoll Elemente zuordnen und die Mitglieder die restlichen Elemente abholen, wenn sie die ersten erledigen.

Die Hauptaufgabe des ScrumMasters während des Sprints besteht darin, sicherzustellen, dass die Bedürfnisse des Teams erfüllt werden und Hindernisse aus dem Weg geräumt werden. Dazu gehört, dass Entwickler und QS Zugang zu allen notwendigen Ressourcen (Personen, Dokumente, Hardware, Software) haben, Besprechungen mit externen Parteien erleichtern, Ablenkungen reduzieren (z und Entwicklungsteam, wenn Entscheidungen getroffen werden müssen, und sorgen insgesamt dafür, dass Entwickler und QS in der bestmöglichen Umgebung arbeiten können.

Der Product Owner muss während des Sprints leicht erreichbar sein, um Fragen zu Sprint-Backlog-Elementen zu beantworten, die laufende Arbeit mit dem Entwicklungsteam zu überprüfen und sicherzustellen, dass sich die Funktionen in die richtige Richtung bewegen.

Während des Sprints arbeiten Entwickler und QA täglich zusammen. In einigen Teams arbeitet QA Seite an Seite mit Entwicklern, um Funktionen zu entwerfen, zu entwickeln und zu testen, während sie in anderen Funktionen innerhalb weniger Stunden nach der Entwicklung (nicht Wochen später) testen. Diese enge Schleife zwischen Entwicklern und QA ist entscheidend, um am Ende des Sprints potenziell auslieferbaren Code sicherzustellen. Code, der geschrieben, aber nicht getestet wurde, ist sehr unwahrscheinlich, dass er potenziell produktionsbereit ist.

Daily Meeting

Während des Sprints treffen sich die Teammitglieder täglich, um dem Team den Status zu melden. Das Scrum Daily Meeting – oder Daily Scrum – ist eine kurze Besprechungszeit von 15 Minuten, in der jeder Teilnehmer drei Fragen beantwortet:

Was haben Sie seit dem letzten täglichen Treffen gemacht?

Was werden Sie von jetzt an bis zum nächsten täglichen Meeting tun?

Gibt es Straßensperren im Weg?

Obwohl das gesamte Team beim täglichen Meeting anwesend ist, ist es sehr wichtig zu beachten, dass das tägliche Meeting den Teammitgliedern dient, um den Status an ihre Kollegen zu berichten, nicht an den ScrumMaster oder den Product Owner. Dieses Meeting hält das Tempo des Teams täglich für alle Teambeteiligten sichtbar. Ob das Team wie geplant vorankommt, wird sich bei diesen Treffen zeigen. Auch wenn jemand Schwierigkeiten hat, wird dies nicht unbemerkt bleiben. Die regelmäßige Berichterstattung an ihre Kollegen hilft den Teams, sich im Verlauf des Sprints effizient selbst zu organisieren und bietet den Teammitgliedern Rechenschaftspflicht. Es ist wichtig, dass der Product Owner und der ScrumMaster in diesem Meeting anwesend sind, um Hindernisse zu erkennen und so schnell wie möglich darauf zu reagieren.

Als Beispiel könnte ein Entwickler in einem typischen täglichen Meeting berichten, dass er gestern die Middle-Tier-Komponente für ein bestimmtes Modul fertiggestellt hat und heute plant, die Webseite, die es verwenden wird, abzuschließen. Er wird den Product Owner und die QA darüber informieren, dass diese am nächsten Tag einen Blick darauf werfen können. Eine andere Entwicklerin könnte berichten, dass sie Probleme hat, die Wurzel eines Problems im Anmeldeprozess zu finden und könnte Hilfe gebrauchen. Die QA kann melden, dass der Kontaktbildschirm aufgrund eines Fixes in einem anderen Modul defekt zu sein scheint und dass die Entwickler dies beheben müssen, bevor er mit dem Testen anderer Bildschirme auf demselben Modul fortfahren kann.

Um das Meeting kurz zu halten, ist es notwendig, Diskussionen, die nur ein oder zwei Teammitglieder betreffen und die länger als ein paar Minuten dauern können, beiseite zu legen. Es ist üblich, das tägliche Meeting als Stand-Up-Meeting abzuhalten. Dies hilft, das Meeting kurz zu halten, da die Leute normalerweise nicht gerne länger als 15 Minuten stehen, um etwas zu besprechen.

Sprint Retrospectives

Scrum ist ein adaptiver Prozess. Dies erreichen Scrum-Teams unter anderem durch die Durchführung regelmäßiger retrospektiver Meetings, um darüber zu sprechen, was im letzten Sprint erfolgreich war, was im nächsten verbessert werden könnte und wie das Team noch besser werden könnte. Dies sind offene Meetings, an denen das gesamte Team (Product Owner, ScrumMaster, Entwickler und QA) teilnimmt.

Idealerweise hält das Team diese Meetings am Ende jedes Sprints ab. Retrospektive Meetings bieten dem Team ein Forum, um Bedenken zu äußern und sich über Dinge zu rühmen, die gut gelaufen sind. Es ist sehr wichtig, das Meeting mit Erfolgen und Verbesserungspotenzialen auszubalancieren. Um dieses Gleichgewicht zu erreichen, können Sie verlangen, dass jeder Teilnehmer zum Meeting eine Liste mit zwei oder drei Praktiken mitbringt, die dem Team zu einer guten Leistung verholfen haben, und zwei oder drei Bereichen, in denen sich das Team verbessern muss.

Retrospektive Meetings können schwer zu handhaben sein, da sie leicht zu emotionalen Diskussionen werden können. Um dies zu verhindern, ist es sehr wichtig, dass sich das Meeting darauf konzentriert, wie man im Team besser arbeitet und nicht in ein Forum für persönliche Angriffe. Ich habe festgestellt, dass retrospektive Meetings von großem Wert sind, um Teams zu ermöglichen, Dinge, die sie frustrieren, Luft zu machen und Ideen vom gesamten Team zu erhalten, wie diese Probleme angegangen werden können. Wenn die Dinge gut laufen, ist es auch gut für das Team, darüber zu sprechen, was es erfolgreich macht, und sicherzustellen, dass jeder weiß, was das Team aufrechterhalten muss, um die Dynamik aufrechtzuerhalten. Diese Meetings setzen auch das Konzept durch, dass alle Beteiligten (ScrumMaster, Product Owner, Entwickler, QA) als ein Team zusammenarbeiten und miteinander zusammenarbeiten müssen.

Bei einem retrospektiven Meeting könnten Teams Dinge besprechen wie „Wir müssen sicherstellen, dass unsere Unit-Tests auf dem neuesten Stand sind, seit wir sie im letzten Sprint ignoriert haben, Probleme haben sich außerhalb unserer Kontrolle eingeschlichen“ oder „Ich fand es sehr hilfreich, das Neue zu demonstrieren Screens an Jane eher früh als am Ende des Sprints“ oder „wir brauchen eine bessere Kommunikation zwischen Entwicklern und QA, da viele Fehler nicht frühzeitig getestet wurden, weil die Entwickler sie nicht als bereit zum Testen gekennzeichnet haben Zeit."

Es ist wichtig zu verfolgen, was das Team während dieser Treffen vereinbart. Wenn das Team besprochen hat, dass es mit etwas Neuem beginnen möchte, wie z. B. Demo-Arbeiten früher an den Product Owner, muss der ScrumMaster dem Team helfen, sicherzustellen, dass Demos früher durchgeführt werden. Der ScrumMaster muss dieses Thema auch in das nächste retrospektive Meeting zurückbringen, um zu sehen, ob das Team das Gefühl hat, sich in die richtige Richtung zu bewegen.

Nach dem retrospektiven Meeting ist das Team bereit für einen neuen Sprint. Das Team trifft sich zu einem neuen Sprint-Planungsmeeting und wiederholt dann den Zyklus. Da der Code potenziell am Ende jedes Sprints auslieferbar ist, wird der Regressionstestprozess erheblich vereinfacht. Einige Teams haben eine spezielle Art von Sprint namens Release Sprint, bei der sie lediglich das System in der Testumgebung bereitstellen, Regressionstests durchführen, alle während dieses Prozesses gefundenen Probleme beheben und dann die in den Sprints seit dem letzte Ausgabe.

Warum Scrum für Softwareentwicklung in unser Agentur funktioniert

Die Praktiken und Richtlinien von Scrum funktionieren, weil sie die wichtigste Komponente der Softwareentwicklung ansprechen: Menschen und ihre Interaktionen. Scrum bietet dem gesamten Team (Product Owner, ScrumMaster, Entwickler, Qualitätssicherung und Business-Analysten) einen Rahmen für die regelmäßige Zusammenarbeit und Zusammenarbeit.

Das tägliche Meeting hilft beispielsweise dem gesamten Team (nicht nur dem ScrumMaster oder dem Product Owner) dabei, den Fortschritt täglich zu überwachen. Wenn das Team in Rückstand gerät, kann es sich sofort anpassen und sich selbst neu organisieren. Timeboxing im Sprint hilft dem Product Owner, den Fortschritt in bestimmten Intervallen zu überwachen, da am Ende der Iteration die während des Planungsmeetings geplanten Features entweder potenziell auslieferbar sind oder nicht. Das Ziel eines potenziell auslieferbaren Codes leitet alle im Team an, auf dasselbe Ziel hinzuarbeiten. Das Sprint-Retrospektive-Meeting ermöglicht es dem Team, über Erfolge zu reflektieren, über Verbesserungspotenziale zu sprechen und Maßnahmen zur Verbesserung im nächsten Sprint zu ergreifen.

Ein häufiges Missverständnis ist, den Scrum-Prozess als Mini-Wasserfall zu sehen. Nur kurze Iterationen reichen nicht aus, um Scrum zum Laufen zu bringen. Damit Scrum glänzen kann, ist es wichtig, dass alle Teammitglieder während des Sprints zusammenarbeiten, um dasselbe Ziel zu erreichen. Wenn Entwickler eine Reihe von Funktionen codieren, die QA jedoch eine andere Reihe von Funktionen testet, arbeiten sie nicht zusammen. Sie werden am Ende dieses Sprints keinen potenziell auslieferbaren Code haben. Der ScrumMaster muss dieses Kollaborationsmodell fördern, insbesondere bei Teams, die noch nie so eng zusammengearbeitet haben, wie Scrum vorschlägt.

Scrum fördert ein Umfeld, in dem Teams langfristig erfolgreich sein können, indem sie ein konstantes Tempo halten. Durch kurze Iterationen und Selbstinspektion bei jedem Schritt des Prozesses (z. B. tägliche Meetings, Sprints und Retrospektiven) können Scrum-Teams immer den Status des Projekts kennen und sicherstellen, dass sich das Team auf das gleiche Ziel zubewegt. Da Sprints von kurzer Dauer sind und sich das Team immer darauf konzentriert, am Ende der Iteration potenziell auslieferbaren Code zu haben, verhindert Scrum das sogenannte „Studentensyndrom“, bei dem sich Menschen erst im letzten Moment vor einer Deadline einsetzen. Abbildung 2 zeigt den Stresslevel von Teams, die keine kurzen Iterationen und regelmäßige Checkpoints haben. Diese Teams sind zu Beginn oft entspannt und gegen Ende des Projekts gestresst. Die kurzen Iterationen und regelmäßigen Checkpoints von Scrum führen Teams zu einem effizienteren Modell, bei dem die Teammitglieder selbst Abweichungen erkennen und frühzeitig Anpassungen vornehmen, anstatt zu warten, bis es zu spät ist. Der Stresslevel in Scrum-Teams ist tendenziell niedrig, wie in Abbildung 3 dargestellt.

Progress Tracking

Teams, die Scrum verwenden, haben mehrere Möglichkeiten, den Status des Projekts zu verfolgen. Einer ist, dass das Team am Ende des Sprints über potenziell auslieferbaren Code verfügen muss. Teams, die dem Product Owner die neuen Funktionen am Ende des Sprints demonstrieren, sind eine großartige Möglichkeit, dieses Ziel zu fördern. Am Ende des Sprints ist die Software möglicherweise versandbereit oder nicht. Dieser in agilen Entwicklungsprozessen übliche binäre Status ist für Product Owner tendenziell aussagekräftiger als das mehrjährige „Wir sind zu 85 % fertig“.

Eine weitere Möglichkeit, wie Scrum-Teams den Fortschritt messen können, sind Burndown-Charts. Dabei handelt es sich um Diagramme, in denen der verbleibende Arbeitsaufwand eines Sprints täglich aktualisiert und dem gesamten Team zur Verfügung gestellt wird. Wenn zu Beginn des Sprints 200 Arbeitsstunden zu erledigen sind, wird das Diagramm am zweiten Tag aktualisiert, um anzuzeigen, wie viel Arbeit (wie von den Entwicklern, die an jeder Aufgabe arbeiten) noch übrig ist.

Wenn Aufgaben abgeschlossen – kodiert und getestet – werden, verringert sich die Anzahl der noch zu erledigenden Stunden. Wenn keine Aufgaben erledigt werden, bleibt die Stundenzahl von einem Tag zum anderen gleich. Abbildung 4 zeigt ein Beispiel für ein Sprint-Burndown-Diagramm, bei dem alles perfekt lief. An jedem Tag des Sprints absolvierte das Team zwanzig Stunden und beendete alles pünktlich. Andererseits zeigt Abbildung 5 ein Beispiel, bei dem das Team an Tag 3 auf einige Schwierigkeiten stieß (die Anzahl der verbleibenden Stunden blieb fast gleich wie am Vortag) und diese Schwierigkeiten an den Tagen 4 und 5 fortgesetzt wurden Elemente waren schwieriger zu implementieren, als das Team erwartet hatte, oder ein Teamkollege wurde krank. Was auch immer der Grund für die Verlangsamung war, das Team hatte an Tag 6 einige Korrekturmaßnahmen ergriffen (z. B. einige Elemente aus dem Sprint nach einem Gespräch mit dem Product Owner entfernt), um potenziell auslieferbaren Code für das bereitzustellen, was bis Ende des Jahres noch erreichbar war der Sprint.

Scrum ist kein Allheilmittel. Auch beim Einsatz von Scrum ist es immer noch möglich (und wahrscheinlich), dass es hin und wieder anders läuft als geplant. Durch häufige Inspektion und Anpassung erkennt das Team diese Abweichungen jedoch sofort, wenn sie auftreten, und passt sich an die neue Umgebung an. Diese Fähigkeit, sich schnell an eine neue Umgebung anzupassen, ist einer der Hauptunterschiede zwischen empirischen Prozesskontrollen (wie Scrum) und definierten Prozesskontrollen, wie sie von traditionellen nicht agilen Softwareentwicklungsprozessen verwendet werden.

Der vielleicht beste Tracking-Mechanismus, der in Scrum-Teams stattfindet, ist die ständige Feedbackschleife, die Scrum bietet. Durch die Zusammenarbeit des gesamten Teams (Product Owner, Entwickler, Qualitätssicherung und ScrumMaster) während des gesamten Sprints wissen Teams in der Regel besser, wo sie sich befinden, bemerken, wenn sie in Rückstand geraten, und handeln regelmäßig.

Erste Schritte mit Scrum

Im Kern ist Scrum extrem einfach; manche könnten sogar sagen, dass es einfach nur gesunder Menschenverstand ist. Wenn Sie jedoch noch nie ein Projekt mit Scrum gemanagt haben, empfehle ich Ihnen, klein anzufangen. Wie bei den meisten Prozessänderungsinitiativen hängt der Erfolg davon ab, dass die Menschen das neue Paradigma wirklich annehmen. Die ScrumMaster-Coaching-Rolle in der Anfangsphase ist entscheidend für Teams, um sie zu übernehmen und damit erfolgreich zu sein. Ich habe der Seitenleiste einige Ressourcen hinzugefügt, um mehr über Scrum zu erfahren.

Scrum funktioniert sehr gut mit gemeinsamen Teams von fünf bis zehn Mitgliedern, darunter Product Owner, Entwickler, Qualitätssicherung, Analysten und ScrumMaster. Sie können es skalieren, um mit größeren und verteilten Teams zu arbeiten, aber ich schlage vor, dass Sie mit einem kleinen Team beginnen.

Wenn Sie in Ihrem aktuellen Entwicklungsprozess sechsmonatige Iterationen verwenden, wäre das Konzept der zweiwöchigen Sprints möglicherweise ein zu großer Schock für Ihr Unternehmen. Wenn dies der Fall ist, beginnen Sie mit 30-tägigen Sprints, sehen Sie, wie es für Ihr Team für eine Weile funktioniert, und bewerten Sie dann erneut, ob Sie kürzere Iterationen durchführen müssen.

Scrum bietet einen Rahmen für funktionsübergreifende, selbstorganisierte Teams, die gemeinsam auf ein gemeinsames Ziel hinarbeiten. Die Prinzipien des sichtbaren Fortschritts und der ständigen Kontrolle schaffen Transparenz für Teams und ermöglichen ihnen, sich schnell an Veränderungen im Umfeld anzupassen. In der heutigen schnelllebigen Welt neuer Technologien, sich ändernder Anforderungen und des erhöhten Drucks, auf den Markt zu kommen, können die Praktiken von Scrum Ihnen helfen, Ihren Kunden häufiger funktionierende Software mit den richtigen Funktionen bereitzustellen.