Der Projektmanagement-Blueprint Teil 1: Ein umfassender Vergleich von Agile, Scrum, Kanban und Lean

Überblick

Heutzutage werden viele Methoden in der Softwareentwicklung verwendet. Vielleicht haben Sie schon Schlagworte wie Waterfall, Agile, Scrum, Kanban, Lean, Extreme Programming usw. gehört.

In diesem Artikel werde ich diese Begriffe definieren, erörtern, wie sie miteinander verwandt sind und wie sie sich voneinander unterscheiden. Viele der oben genannten Schlagworte basieren auf Konzepten aus dem Lean Manufacturing, das ursprünglich auf dem Toyota Manufacturing System (TPS) basierte, daher werden wir zuerst darauf eingehen.

Lean-Methodik

Ursprünge von Lean und Lean Manufacturing

Der Begriff „Lean“ hat seinen Ursprung in der Fertigung, wo er geprägt wurde, um ein Fertigungsmodell zu beschreiben, das auf dem Toyota Production System (TPS) basiert, das ursprünglich von Sakichi Toyoda, Kiichiro Toyoda und Taiichi Ohno entwickelt wurde, die ursprünglich von Henry Ford inspiriert wurden. TPS konzentrierte sich auf die Philosophie der „vollständigen Eliminierung jeglicher Verschwendung“ und revolutionierte die Fertigung in den 1950er bis 1970er Jahren. TPS wurde 1990 als „Lean Manufacturing“ bekannt, als „The Machine That Changed the World“ veröffentlicht wurde.

TPS hat bei Toyota drei große Arten von Verschwendung identifiziert:

• Muda: übersetzt als „Verschwendung“. Bei Toyota wurden sieben Muda-Typen identifiziert, und ein achter wurde später hinzugefügt. Diese sind:
  • Mängel: Aufwand für das Auffinden und Beheben von Mängeln
  • Überproduktion: Produktion vor der Nachfrage
  • Warten: Warten auf den nächsten Produktionsschritt, Unterbrechungen etc.
  • Nicht genutztes Talent: unzureichend genutzte Fähigkeiten, unzureichende Ausbildung usw
  • Transport: Bewegliche Teile oder Produkte, die nicht für die Verarbeitung benötigt werden
  • Vorräte: abgeschlossene Vorräte und unfertige Erzeugnisse
  • Bewegung: sich mehr bewegen oder gehen, als für die Verarbeitung erforderlich ist

  • Übermäßige Verarbeitung: durch schlechte Werkzeuge oder Produktdesign

• Muri: übersetzt als „Abraum“. Muri resultiert normalerweise aus Mura, kann aber aus Muda resultieren. Muri äußert sich in Pannen, Fehlzeiten, Sicherheitsproblemen usw.
• Mura: übersetzt als „Unebenheit“. Mura kann in Schwankungen der Kundennachfrage, Prozesszeiten pro Produkt oder Schwankungen der Zykluszeiten für verschiedene Bediener gefunden werden. Wenn Mura nicht reduziert wird, erhöht man die Wahrscheinlichkeit für Muri und damit für Muda. Mura kann reduziert werden, indem Offenheit in der Lieferkette geschaffen, das Produktdesign geändert und Standardarbeit für alle Bediener erstellt wird.

TPS arbeitete daran, Verschwendung zu vermeiden, indem es diese beiden Kernkonzepte anwandte:

• Jidoka: frei übersetzt „Automatisierung mit menschlicher Note“ schreibt vor, dass „Qualität während des Herstellungsprozesses eingebaut werden muss!“ Das heißt, wenn ein Problem auftritt, stoppt die Anlage sofort, wodurch die Produktion fehlerhafter Produkte verhindert wird.
• Just-in-Time: Nur „das herstellen, was benötigt wird, wann es benötigt wird und in der benötigten Menge“.

Als sich TPS weiterentwickelte, bauten diese Grundpfeiler und Werte auf den Konzepten von Jidoka und JIT auf und wurden verankert:

• Ständige Verbesserung:
  • Herausforderung: Eine langfristige Vision entwickeln und Herausforderungen mit Mut und Kreativität begegnen, um Träume zu verwirklichen
  • Kaizen: Kontinuierliche Verbesserung der Geschäftsabläufe, ständiges Streben nach Innovation und Weiterentwicklung, Eliminierung eines Muda nach dem anderen
  • Genchi Genbutsu: Genchi Genbutsu praktizieren, zur Quelle gehen, um die Fakten zu finden, um richtige Entscheidungen zu treffen, Konsens zu erzielen und Ziele in unserer besten Geschwindigkeit zu erreichen
• Respekt vor Menschen:
  • Respekt: ​​Andere respektieren und sich bemühen, einander zu verstehen, Verantwortung übernehmen und unser Bestes tun, um gegenseitiges Vertrauen aufzubauen
  • Teamarbeit: Stimulierung des persönlichen und beruflichen Wachstums, Austausch von Entwicklungsmöglichkeiten und Maximierung der Einzel- und Teamleistung
• Andon: ein visueller Status- oder Problemindikator
• Heijunka: bedeutet Leveln oder Produktionsleveln
• Hansei: bedeutet Selbstreflexion. Um die Effizienz zu verbessern, sollten Mitarbeiter Annahmen hinter aktuellen Prozessen hinterfragen, um bessere zu finden.
• Kanban: ein Schild, das als visuelles Instrument zur Steuerung der Produktion verwendet wird
• Poka-Yoke: Auch als Error Proofing oder Error Proofing bezeichnet
• Pull-System: Material wird genau so in eine Arbeitsstation gezogen, wie es benötigt wird
• Seiri: ist das Prinzip, das Verschwendung widerspiegelt. Seiri diktiert, dass das, was unnötig ist, entfernt werden sollte. Dies umfasst alle der ursprünglichen sieben Verschwendungen von TPS
• Standardisierung: organisiert alle Jobs rund um die menschliche Bewegung und schafft einen effizienten Produktionsablauf ohne Muda. Dies trägt zu Qualität, einem konstanten Tempo und einer kontinuierlichen Verbesserung bei.

Das folgende Diagramm zeigt, wie die Kernkonzepte und Kernwerte zueinander in Beziehung stehen.

Schlankes Management

Das Toyota-Produktsystem und Lean Manufacturing haben sich im Laufe der Zeit weiterentwickelt und wurden in einer Reihe von Bereichen einschließlich des Managements angewendet.

Lean Management wendete die Grundwerte der kontinuierlichen Verbesserung und des Respekts für die Menschen an und destillierte sie in eine Reihe von fünf präskriptiven Lean-Prinzipien, die mehrmals wiederholt werden sollten, um sich kontinuierlich zu verbessern und Verschwendung zu eliminieren:

1. Wert identifizieren: Geben Sie einen Wert aus Sicht des Endkunden nach Produktfamilie an.
2. Wertstrom abbilden: Identifizieren Sie alle Schritte im Wertstrom für jede Produktfamilie und eliminieren Sie nach Möglichkeit die Schritte, die keinen Wert schaffen.
3. Schaffen Sie Fluss: Sorgen Sie dafür, dass die wertschöpfenden Schritte in enger Abfolge erfolgen, damit das Produkt reibungslos zum Kunden fließt.
4. Pull etablieren: Wenn der Flow eingeführt wird, lassen Sie die Kunden Wert aus der nächsten Upstream-Aktivität ziehen.
5. Streben Sie nach Perfektion: Wenn der Wert spezifiziert ist, Wertströme identifiziert, verschwendete Schritte entfernt und Flow und Pull eingeführt werden, beginnen Sie den Prozess erneut und setzen Sie ihn fort, bis ein Zustand der Perfektion erreicht ist, in dem perfekter Wert ohne Verschwendung geschaffen wird.

Diese Prinzipien und andere Aspekte des Lean Managements wurden formalisiert, als Womack & Jones 1996 „Lean Thinking“ veröffentlichten.

Lean-Software-Entwicklung

Lean wurde seitdem auf Management, Softwareentwicklung und andere Bereiche angewendet.

In den 1980er und 1990er Jahren näherte sich die Softwareentwicklungsbranche einer Krise, da Projekte, die mit traditionellen Wasserfallmethoden ausgeführt wurden, immer länger dauerten. Dies führte häufig zu einer großen Verzögerung zwischen der Identifizierung eines Geschäftsbedarfs und der Bereitstellung einer Softwarelösung. Manchmal wurde diese Verzögerung in mehreren Jahren oder sogar in Jahrzehnten in bestimmten Branchen mit spezifischen Anforderungen wie der Luft- und Raumfahrtindustrie gemessen.

Während dieser mehrjährigen Zeiträume änderten sich Anforderungen, Systeme oder sogar ganze Unternehmen. Oft wurden Projekte auf halbem Weg abgebrochen oder ihr Umfang abgeschlossen, nur um herauszufinden, dass das, was sie geliefert haben, nicht mehr den Geschäftsanforderungen entspricht, die zu Beginn des Projekts identifiziert wurden.

Die Wasserfallmethode belohnte Stakeholder dafür, dass sie an alles gedacht hatten, da sie gezwungen waren, einen Vertrag zu schreiben, obwohl sie sich wahrscheinlich nicht sicher waren, was sie brauchten. Die Wasserfall-Methodik erzwang Entscheidungen während der Anforderungs- oder Entwurfsphase, und diese Entscheidungen waren sehr schwer zu ändern, ohne den Vertrag zu ändern und dem Projekt zusätzliche Kosten zuzufügen. Ein hoher Prozentsatz von Softwareprojekten scheiterte vollständig, wurde verspätet und über dem Budget geliefert oder lieferte nicht das, was benötigt wurde.

Diese allgemeine Frustration führte dazu, dass verschiedene Vordenker versuchten, Waterfall zu verbessern. Zu den frühen Beispielen gehört Rapid Application Development (RAD), das sich auf die Reduzierung von Verschwendung konzentrierte, indem es die Anforderungs- und Entwurfsphasen verkürzte, indem es schnell einen Prototyp entwickelte und mit Unternehmen zusammenarbeitete, um die Anforderung weiterzuentwickeln. Es gab auch einen Trend zur iterativen Entwicklung, bei der ein kleines Projekt abgeschlossen wurde und Funktionen in kontinuierlichen Iterationen hinzugefügt wurden. Obwohl diese Methoden hilfreich waren, lösten sie nicht die Kernprobleme im Zusammenhang mit Waterfall.

In den 1990er und frühen 2000er Jahren veröffentlichten mehrere Autoren Bücher über die Anwendung von Lean-Prinzipien auf die Softwareentwicklung. Dr. Robert Charette veröffentlichte 1993 „Lean Software Development“ und 2003 „12 Principles of Lean Software Development“.

Tom und Mary Poppendieck veröffentlichten „Lean Software Development: An Agile Toolkit“ im Jahr 2003. Dieses Buch beschreibt sieben Prinzipien der schlanken Entwicklung, die direkt mit den sieben Formen der Verschwendung in der schlanken Fertigung korrelieren. Die Ähnlichkeiten und Unterschiede zwischen den beiden verschiedenen Lean-Publikationen und Agile (wird im nächsten Abschnitt besprochen) sind im folgenden Diagramm dargestellt.

Unterschiede zwischen Lean und Agile

Laut Dr. Charette besteht einer der Hauptunterschiede zwischen Lean und Agile darin, dass Agile von unten nach oben und Lean von oben nach unten erfolgt.

Agiles Framework

Ursprünge von Agile und das Agile Manifest

Ungefähr zur gleichen Zeit, als Charette und die Poppendiecks ihre Bücher veröffentlichten, wurde das Agile Framework entwickelt, um bei der Lösung derselben Probleme zu helfen. Im Februar 2001 traf sich eine Gruppe von Agile-Pionieren auf dem berüchtigten Snowbird-Treffen in Snowbird, Utah, um zu versuchen, eine Lösung zu finden.

Das Ergebnis war das Agile Manifesto, das eine Reihe von Werten und Prinzipien für eine Methodik festlegte, die versucht, sich an sich ändernde Anforderungen und Kundenbedürfnisse anzupassen, Verschwendung zu reduzieren und mithilfe eines inkrementellen, iterativen Ansatzes schneller Vorteile zu erzielen.

Das Agile Manifest lautet wie folgt:

„Wir entdecken bessere Möglichkeiten, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Arbeit haben wir zu schätzen gelernt:

• Individuen und Interaktionen über Prozesse und Tools
• Funktionierende Software über umfassende Dokumentation
• Kundenzusammenarbeit über Vertragsverhandlungen
• Auf Veränderungen reagieren, anstatt einem Plan zu folgen

Das heißt, während die Elemente auf der rechten Seite einen Wert haben, schätzen wir die Elemente auf der linken Seite mehr.“

An den Werten des Manifests ausgerichtet sind die 12 Prinzipien hinter dem Agilen Manifest:

„Wir folgen diesen Grundsätzen:

1. Unsere höchste Priorität ist es, den Kunden durch frühzeitige und kontinuierliche Lieferung wertvoller Software zufrieden zu stellen.
2. Begrüßen Sie sich ändernde Anforderungen, auch spät in der Entwicklung. Agile Prozesse nutzen den Wandel zum Wettbewerbsvorteil des Kunden.
3. Stellen Sie häufig funktionierende Software bereit, von ein paar Wochen bis zu ein paar Monaten, wobei Sie kürzere Zeiträume bevorzugen.
4. Geschäftsleute und Entwickler müssen während des gesamten Projekts täglich zusammenarbeiten.
5. Bauen Sie Projekte um motivierte Personen auf. Geben Sie ihnen das Umfeld und die Unterstützung, die sie brauchen, und vertrauen Sie darauf, dass sie ihre Arbeit erledigen.
6. Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist das persönliche Gespräch.
7. Funktionierende Software ist das primäre Maß für den Fortschritt. Agile Prozesse fördern eine nachhaltige Entwicklung.
8. Die Sponsoren, Entwickler und Benutzer sollten in der Lage sein, ein konstantes Tempo auf unbestimmte Zeit beizubehalten.
9. Kontinuierliche Aufmerksamkeit für technische Exzellenz und gutes Design verbessert die Agilität.
10. Einfachheit – die Kunst, die Menge an nicht erledigter Arbeit zu maximieren – ist entscheidend.
11. Die besten Architekturen, Anforderungen und Designs entstehen aus sich selbst organisierenden Teams.
12. In regelmäßigen Abständen überlegt das Team, wie es effektiver werden kann, und passt sein Verhalten dann entsprechend an.“

Die oben genannten Werte und Prinzipien sind Anwendungen von Lean-Prinzipien wie Jidoka, JIT, Genchi Genbutsu, Kaizen, Hansei, Heijunka und Reduzierung von Verschwendung.

Agile Prinzipien in der Softwareentwicklung

Agile ist ein übergeordnetes Framework, das für jeden Prozess gilt, der die agilen Werte und Prinzipien anwendet.

Einige Beispiele sind:

• Extremes Programmieren
• Gedränge
• Kanban

Gedränge

Kurze Geschichte des Abschaums

Scrum ist ein Framework, das agile Prinzipien anwendet, das von mehreren Personen separat erfunden wurde, von denen einige das Agile Manifest unterzeichnet haben:

• Hirotaka Takeuchi und Ikujiro Nonaka führten den Begriff „Scrum“ in ihrem Whitepaper „The New Product Development Game“ erstmals im Fertigungskontext ein. 1986 in der Harvard Business Review veröffentlicht.
• Jeff Sutherland, John Scumniotales und Jeff McKenna implementierten Scrum 1993 bei der Easel Corporation.
• Ken Schwaber verwendete in seinem Unternehmen Advanced Development Methods in den 1990er Jahren das, was später Scrum werden sollte.

Schwaber und Sutherland arbeiteten in den 1990er Jahren zusammen, um das Framework im Kontext der Softwareentwicklung zu entwickeln und zu verfeinern, und sprachen auf verschiedenen Konferenzen. Schwaber arbeitete 2001 mit Mike Beedle zusammen, um die Methode in dem Buch „Agile Software Development with Scrum“ zu beschreiben.

Schwaber fuhr fort, die beiden wichtigsten Scrum-Zertifizierungsstellen zu schaffen:

• Scrum Alliance: 2001 gegründet. Einrichtung der Certified Scrum -Akkreditierungsreihe.
• Scrum.org: wurde 2009 gegründet, nachdem Schwaber die Scrum Alliance verlassen hatte. Richten Sie die parallele Professional Scrum -Akkreditierungsserie ein.

Im Laufe der Zeit wurden mehrere Frameworks/Zertifizierungsstellen geschaffen, um die Skalierung des Scrum-Frameworks auf größere Teams und Projekte zu adressieren, da Scrum ursprünglich für kleine Teams (7 plus oder minus 2 Mitglieder) konzipiert war:

• SAFe: Skaliertes agiles Framework
• LeSS: Großes Scrum
• Scrum@scale: Scrum at Scale, erstellt von Jeff Sutherland

Scrum-Werte

Laut der Scrum Alliance:

Scrum ist eine einfache, aber unglaublich leistungsstarke Reihe von Prinzipien und Praktiken, die Teams dabei helfen, Produkte in kurzen Zyklen zu liefern und schnelles Feedback, kontinuierliche Verbesserung und schnelle Anpassung an Veränderungen zu ermöglichen.

Scrum ist ein vorgeschriebenes, inkrementelles und iteratives Framework für die Entwicklung von Software, die agile Prinzipien anwendet. Die Scrum-Werte und -Prinzipien sind in den folgenden Diagrammen skizziert und stimmen stark mit den Lean- und Agile-Werten und -Prinzipien überein.

Scrum-Übersicht

Die Arbeit wird in kurze zeitlich begrenzte Iterationen, sogenannte Sprints, aufgeteilt, die normalerweise 1-3 Wochen dauern. Dies steht in krassem Gegensatz zur detaillierten Planung von Waterfall. Die für den aktuellen Sprint geplante Arbeit wird aus einem priorisierten Rückstand von Arbeitselementen ausgewählt, der als Product Backlog bezeichnet wird (Pull-System, Heijunka), und sie wird festgelegt, sobald der Sprint beginnt. Ziel ist es, am Ende eines jeden Sprints eine funktionierende Software zu haben, die ein schnelles Feedback ermöglicht.

Am Ende des Sprints trifft sich das Team, um die erledigte Arbeit zu überprüfen, wie der Sprint gelaufen ist und um den nächsten Sprint zu planen. Die Sprintlänge sowie die Sprintrituale und die Trittfrequenz werden für jeden Sprint festgelegt.

Sprints werden von funktionsübergreifenden Teams ausgeführt, die über alle erforderlichen Fähigkeiten verfügen, um die Arbeit im Sprint abzuschließen. Die tägliche Planung und Verfolgung des Fortschritts erfolgt mithilfe von visuellen Artefakten wie dem Scrum Board und Sprint-Burndown-Diagrammen.

Die Arbeit in einem Sprint wird aus einem priorisierten Backlog gezogen. Die Befolgung dieser Methoden ermöglicht sich ändernde Anforderungen im Laufe der Zeit und fördert ständiges Feedback von den Endbenutzern.

Das folgende Mindmap-Diagramm skizziert einige der Hauptkonzepte von Scum, die in den nächsten Abschnitten besprochen werden.

Scrum-Rollen

Scrum hat drei Rollen:

• Scrum Master : Der Scrum Master ist ein dienender Leiter des Scrum-Teams. Sie sind der Coach des Teams, der hilft, die Zusammenarbeit zu erleichtern, Hindernisse zu beseitigen, den Scrum-Prozess durchzusetzen und zu schützen und das Team zu schützen. Dies bedeutet in der Regel, dass sie die Sprint-Rituale organisieren und moderieren, sicherstellen, dass der Product Owner über ein ordnungsgemäß priorisiertes und gepflegtes Backlog verfügt, sicherstellen, dass das Team nicht unter Druck gesetzt wird, sich zu sehr auf einen Sprint einzulassen, und sicherstellen, dass der Umfang nicht zu einem hinzugefügt wird Sprint, stellt sicher, dass die Definition of Done eingehalten wird. Sie weisen Teammitgliedern (Genchi Genbutsu) keine Aufgaben zu und sind nicht für die Durchführung eines Projekts verantwortlich
• Product Owner : Der Product Owner ist „der einzige umwringbare Hals“, der für die Lieferung des Produkts verantwortlich ist. Der Product Owner definiert die Vision dessen, was er aufbauen möchte, und übermittelt diese Vision an das Team und die Organisation. Der Product Owner besitzt die Geschäfts- und Marktanforderungen und priorisiert alle Arbeiten, die durch die Erstellung und Verwaltung des Product Backlogs erledigt werden müssen. Sie entscheiden, welche Funktionen wann ausgeliefert werden. Sie arbeiten mit dem Team und anderen Stakeholdern zusammen, um sicherzustellen, dass jeder die Elemente im Product Backlog versteht. Sie akzeptieren oder lehnen Arbeit ab, die in einem Sprint bei der Sprint-Demo abgeschlossen wurde.
• Teammitglied : Das Scrum-Team ist ein sich selbst organisierendes, funktionsübergreifendes Team, das typischerweise aus fünf bis sieben Mitgliedern besteht. Alle im Projekt arbeiten zusammen und helfen sich gegenseitig und sind nicht unbedingt an bestimmte Rollen wie Architekt, Programmierer, Designer oder Tester gebunden. Alle erledigen die Arbeit gemeinsam. Das Scrum-Team plant, wie viel Arbeit es für jeden Sprint erledigen kann, und besitzt den Plan (Genchi Genbutsu).

Scrum Flow, Aktivitäten und Zeremonien

Wie oben besprochen, hat Scrum einen definierten Ablauf und eine Reihe von Ritualen und Aktivitäten. Der Ablauf eines Sprints ist wie folgt.

Sprint-Planung:

Bevor ein Sprint beginnt, moderiert der Scrum Master ein Meeting mit dem Scrum-Team und dem Product Owner, das sogenannte Sprint-Planungsmeeting, bei dem der Product Owner die Ziele des bevorstehenden Sprints identifiziert und das Team dann seine Arbeit entsprechend den Zielen plant.

Dies geschieht normalerweise mit den folgenden Aktivitäten:

• Sprint-Kapazität: Das Team bestimmt die Kapazität für den Sprint unter Berücksichtigung der Anzahl der Tage, der Anzahl der Teammitglieder, der Feiertage usw.
• Sprintziele: Der Product Owner legt die Ziele für den Sprint fest. Entscheidend ist, dass das Product Backlog nach den Zielen priorisiert (also die relevanten Stories ganz oben stehen) und gepflegt wird.
• Arbeitsauswahl: Stories oder Aufgaben werden von der Spitze des Backlogs in den Sprint gezogen, bis die geschätzte Kapazität erreicht ist. Wenn Stories eingezogen werden, erklärt der Product Owner die Story und beantwortet Fragen des Teams, wobei er die Story nach Bedarf aktualisiert, bis der Product Owner und das Scrum-Team ein gutes, gemeinsames Verständnis der Story haben. Sobald diese Aktivität abgeschlossen ist, hat das Team einen Vorschlag für den anfänglichen Sprintumfang.
• Aufgabenaufschlüsselung: Das Scrum-Team bespricht jede Story im Detail, wobei der Schwerpunkt auf der Planung liegt, wie sie die Story vervollständigen und alle Akzeptanzkriterien und die DoD ansprechen werden. Sie werden eine Liste der Teilaufgaben erstellen, die zur Vervollständigung der Geschichte erforderlich sind. Sobald die Liste der Teilaufgaben vollständig ist, wird die Schätzung der Geschichte überprüft und bei Bedarf aktualisiert.
• Sprint-Verpflichtung: Sobald alle Storys aufgeschlüsselt und die Schätzungen aktualisiert sind, wird der vorgeschlagene anfängliche Sprint-Umfang überprüft. Storys können aus dem Sprint entfernt und wieder in das Backlog aufgenommen werden und/oder es können zusätzliche Storys hinzugefügt werden. Sobald dies erledigt ist, verpflichtet sich NUR das Scrum-Team (und nicht der Scrum Master oder Product Owner), die Arbeit im Sprint abzuschließen, und der Sprint wird gestartet.

Die Gesamtmenge an Arbeit oder Umfang, die für den Sprint zugesagt wird, wird in Story Points gemessen.

Sprint-Ausführung

Während des Sprints ziehen Teammitglieder Arbeitselemente (User Storys, Aufgaben usw.) von der Spitze der Sprint-To-Do-Liste, um sie zu bearbeiten. Verschiedene Teammitglieder werden an den verschiedenen Workitems bzw. deren Teilaufgaben arbeiten. Sie aktualisieren den Status eines Elements bei Bedarf, indem sie es von einer Spalte in die nächste verschieben (normalerweise To Do > In Progress > Testing > Done oder eine Variation davon) auf dem Scrum Board, bis es erledigt ist.

Der Fortschritt wird mithilfe eines Burndown-Diagramms verfolgt, das den Umfang der abgeschlossenen und verbleibenden Arbeit, gemessen in Story Points, anzeigt. Verbleibende Story Points werden auf der Y-Achse und die verbleibende Zeit auf der X-Achse angezeigt. Das Burndown-Diagramm wird aktualisiert, wenn Stories fertig sind.

Täglich konzentriert sich der Scrum Master auf:

• Erleichtert das tägliche Standup-Meeting, um den Tag zu planen und den Fortschritt zu überprüfen (siehe unten)
• Stellt sicher, dass das Team einen Plan für den Tag hat
• Entfernt Straßensperren
• Schützt den Sprint Scope und das Team vor Ablenkungen
• Hilft dem Team, sein Burndown-Diagramm und andere Scrum-Statistiken zu pflegen

Tägliches Aufstehen

Zu Beginn jedes Tages im Sprint moderiert der Scrum Master ein kurzes, 15-minütiges Meeting mit dem Scrum-Team und dem Product Owner, um den Tag zu planen und den Sprint-Fortschritt zu überprüfen. Dies ist ein kurzes Meeting, bei dem alle vor dem Scrum Board stehen und jede Person im Meeting die folgenden Fragen in 2 Minuten oder weniger beantwortet und sich auf bestimmte Punkte auf dem Sprint Board bezieht:

• Was hast du gestern gemacht?
• Was hast du heute vor?
• Gibt es Hindernisse, die Sie daran hindern, Ihre Arbeit zu erledigen?

Dadurch kann jeder sehen, woran jeder arbeitet, welche Fortschritte erzielt oder nicht erzielt werden, und Hindernisse und/oder benötigte Hilfe identifizieren.

Sprint-Abschluss

Der Scrum Master führt zwei Zeremonien zum Abschluss des Sprints durch, bevor er den nächsten Sprint plant.

Sprint-Demo

Am Ende des Sprints moderiert der Scrum Master ein Sprint-Demo-Meeting, bei dem dem Product Owner und dem Rest des Teams jede abgeschlossene Story an der funktionierenden Software demonstriert wird. Der Product Owner akzeptiert die Story entweder, wenn alle Akzeptanzkriterien erfüllt sind, oder er lehnt die Story ab. Wenn eine Story abgelehnt wird, werden die Defizite identifiziert und die Story wird in ihrer Prioritätsreihenfolge wieder in das Product Backlog aufgenommen, um zu einem späteren Zeitpunkt oder gar nicht abgeschlossen zu werden. Oft werden die Teile einer Story, die der Product Owner nicht akzeptiert, in eine oder mehrere separate Story(s) aufgeteilt und die ursprüngliche Story geschlossen.

Die Gesamtzahl der abgeschlossenen Story Points pro Sprint (Velocity) wird berechnet und der Sprint abgeschlossen. Die Geschwindigkeit wird verwendet, um das Leistungsniveau des Teams zu verfolgen, und wird verwendet, um abzuschätzen, wann Features oder Veröffentlichungen abgeschlossen sein werden.

Sprint-Retrospektive

Nach der Sprint-Demo, aber vor dem nächsten Sprint-Planungsmeeting, moderiert der Scrum Master eine Sprint-Retrospektive, bei der das Team über den gerade abgeschlossenen Sprint nachdenkt und bespricht, was gut und was nicht gut gelaufen ist, damit sie den Prozess kontinuierlich und schrittweise verbessern können und Qualität im Laufe der Zeit (Kaizen, Hansei). Es gibt eine Fülle von retrospektiven Formaten oder Übungen, die verwendet werden können, um dem Team zu helfen, Diskussionen anzuregen.

Es wird eine Liste mit Aktionspunkten zur Verbesserung erstellt, die manchmal dazu führen, dass Artikel zum Produkt-Backlog hinzugefügt werden, Änderungen am DoD oder an der Team-Charta vorgenommen werden usw.

Product-Backlog-Management

Product-Backlog-Erstellung

Bevor ein Sprint geplant oder ausgeführt werden kann, muss der Product Owner ein Product Backlog of Work erstellen. Das Backlog beginnt in der Regel mit Feature-Entwicklungselementen, sogenannten Stories, die vom Product Owner geschrieben wurden, und wird im Laufe der Zeit auch mit Entwicklungs- oder QA-Aufgaben, Spitzen und Fehlern usw. gefüllt, die möglicherweise von jedem Mitglied des Teams erstellt werden. Alle Elemente im Rückstand sind nach Priorität geordnet.

Rückstandspflege

Sobald das anfängliche Produkt-Backlog erstellt und priorisiert ist, übernimmt der laufende Backlog-Grooming-Prozess. Das Ziel ist es, immer mindestens genug der Top-Items im Backlog gepflegt und geschätzt zu haben, damit sie bereit sind, während eines Sprint-Planungsmeetings in einen Sprint gezogen zu werden. Dies geschieht in der Regel durch regelmäßige Backlog-Grooming-Meetings mit dem Produktmanager und dem Team, die vom Scrum Master moderiert werden.

Vor dem Treffen wird eine Liste mit Geschichten an das Team gesendet, damit sie das Grooming-Meeting überprüfen und sich darauf vorbereiten können. Beim Grooming-Meeting wird jeder Punkt in Bezug auf Akzeptanzkriterien, Komplexität, Risiko, Größe, Implementierungsstrategie usw. besprochen. Die Akzeptanzkriterien und andere Details der Geschichte werden überprüft und überarbeitet, bis das Team, der Product Owner und der Scrum Master haben ein gemeinsames Verständnis der Geschichte. An diesem Punkt wird die Story mithilfe einer Technik namens Planungspoker in Story Points geschätzt.

Story Point-Schätzung

Story Points sind eine Arbeitseinheit, die eine relative Dimensionierung verwendet, bei der Geschichten mit früheren, bekannten und gut verstandenen Arbeiten verglichen werden. Sie stellen sich immer die Frage „Ist diese Geschichte größer, kleiner oder ungefähr gleich groß“ wie ein anderes Werk?

Die Fibonacci-Skala (1, 2, 3, 5, 8, 13, 21 …) ist die am häufigsten verwendete Skala, bei der jedes Inkrement ungefähr doppelt so groß ist wie das vorherige (dh eine Fünf-Punkte-Geschichte ist mehr oder weniger doppelt so groß). groß wie eine Drei-Punkte-Geschichte). Manchmal werden andere Skalen wie T-Shirt-Größen (XS, S, M, L, XL) oder sogar Fische (Elritze, Goldfisch, Forelle, Thunfisch, Wal usw.) verwendet. Jede Skala, mit der Sie die Größe von etwas relativ zu einem anderen vergleichen können, funktioniert.

Story Points stellen die gesamte Anstrengung des Teams dar, eine Story zu implementieren, einschließlich Entwicklung, Tests, Design und anderer verschiedener Aufgaben, die für die Definition of Done erforderlich sind. Die Schätzung berücksichtigt den Arbeitsaufwand, die Komplexität und das Risiko. Sobald die relative Größe des Stockwerks bestimmt ist, wird eine Größe auf der Skala als Schätzung zugewiesen.

Die Teams bereiten sich auf den Story-Point-Schätzungsprozess vor, indem sie zunächst eine Basislinie für die Schätzung festlegen, indem sie eine „mittelgroße“ Story auswählen, die das gesamte Team als Referenzstory versteht. Einige zusätzliche Referenzgeschichten, die größer und kleiner sind, werden ebenfalls ausgewählt.

Die Schätzung der Story Points erfolgt während Grooming-Meetings und manchmal während der Sprint-Planung mit Planning Poker:

1. Jedes Teammitglied/Schätzer hat einen Kartensatz.
2. Backlog-Items werden wie oben beschrieben einzeln besprochen.
3. Sobald der Artikel vollständig besprochen wurde, wählt jeder Schätzer privat eine Karte aus, die seine Schätzung darstellt.
4. Wenn alle Schätzer ihre Schätzungen abgegeben haben, decken sie gleichzeitig ihre Karten auf.
   • Wenn alle Schätzungen übereinstimmen, wählen die Schätzer ein anderes Backlog-Element aus und wiederholen denselben Vorgang.
   • Wenn sich die Schätzungen unterscheiden, diskutieren die Schätzer das Problem, um einen Konsens zu erzielen.

Die Vorteile der Story-Point-Schätzung sind:

• Schnell: Schätzungen beziehen sich auf bereits abgeschlossene Product-Backlog-Einträge.
• Genau genug: Genau genug, um einen Überblick über den Umfang zu geben, zukünftige Arbeiten zu planen, Prioritäten zu setzen und Erwartungen zu verwalten.
• Umarmt Unsicherheit: Story Points geben einen unbekannten Zeitbereich an. Die Auswahl aus einer bestimmten Fibonacci-ähnlichen Folge von Story Points ermöglicht das Erfassen von Unsicherheiten.
• Teamsport : Beteiligt alle (Entwickler, Designer, QA, Produktmanager). Verwendet mehrere Perspektiven, um die Größe der Arbeit zu bestimmen, aber nur Teammitglieder, die die Arbeit erledigen, können sie schätzen
• Misst die Teamgeschwindigkeit: Misst , wie viel Arbeit ein Team in einem Sprint leistet, im Vergleich zur Zeit, die für die Arbeit aufgewendet wird. Wenn sich das Team verbessert, werden sie Storys der gleichen Größe schneller abschließen, was im Laufe der Zeit zu einer höheren Story-Point-Velocity führt.

Release-Schätzung und -Verfolgung

Die Schätzung von Story Points wird auch im Zusammenhang mit der Release-Planung mithilfe der folgenden Technik verwendet:

1. Listen Sie alle zu dimensionierenden Stockwerke auf
2. Ordnen Sie sie vom kleinsten zum größten
   • Nehmen Sie die erste und zweite User Story.
   • Entscheiden Sie, welches größer ist, und legen Sie das größere darunter
   • Nehmen Sie dann das nächste und entscheiden Sie, wo es relativ zu den anderen beiden passt
   • Wiederholen Sie den Vorgang, bis jetzt alle Geschichten in der Liste sind (in einer Reihenfolge von der kleinsten zur größten).
3. Dimensioniere die Geschichten

Die Story-Schätzungen für alle Storys in einer Veröffentlichung in Kombination mit der Geschwindigkeit des Teams ermöglichen es Ihnen, abzuschätzen, wann eine Veröffentlichung abgeschlossen sein wird, und ihren Fortschritt zu verfolgen. Dies wird oft in einem Release-Burn-Up-Diagramm dargestellt.

Die Scrum-Artefakte und -Terme

• Product Backlog: Eine Backlog-Liste aller Arbeitselemente für ein bestimmtes Produkt, die Funktionen (Storys), technische Aufgaben, Spitzen und Fehler enthalten kann
• Release-Burn-up: Ein grafisches Diagramm, das verwendet wird, um den Fortschritt auf Release-Ebene anzuzeigen und mithilfe von Sprint Velocity vorherzusagen, wann ein Release abgeschlossen sein wird. Abgeschlossene Story Points werden auf der Y-Achse und Sprints auf der X-Achse angezeigt.
• Sprint Backlog: Eine Backlog-Liste aller Arbeitselemente, die in einem bestimmten Sprint abgeschlossen werden müssen. Die Inhalte des Sprint Backlogs werden im Sprint Planning Meeting vereinbart.
• Scrum Board: Ein Board im Tabellenstil, das den Fortschritt der für den Sprint zugesagten Arbeit verfolgt. Status werden oben in vertikalen Spalten angezeigt und Arbeitselemente werden über jeden Status hinweg verschoben, bis sie fertig sind. Das Scrum Board wird während des Sprint-Planungsmeetings gefüllt und am Ende eines Sprints zurückgesetzt.
• Sprint Burndown: Ein grafisches Diagramm, das den Umfang der abgeschlossenen und verbleibenden Arbeit, gemessen in Story Points, über die Länge des Sprints anzeigt. Verbleibende Story Points werden auf der Y-Achse und die verbleibende Zeit auf der X-Achse angezeigt.
• Sprint Velocity: Die Anzahl der Story Points, die ein Scrum-Team in einem Sprint abschließt.
• Impediments Backlog: Eine Liste von Hindernissen, die vom Scrum Master angegangen werden müssen, damit das Team weiterarbeiten kann. Wenn ein Teammitglied blockiert wird, fügt es dem Hindernis-Backlog ein Element hinzu, um dem Team und dem Scrum Master Sichtbarkeit zu verschaffen.
• Epic: Ein Epic ist ein umfangreiches Werk, das aus mehreren verwandten User Stories besteht.
• User Story: Eine User Story ist eine Beschreibung einer Softwarefunktion aus Sicht des Endbenutzers. Die User Story beschreibt den Typ des Benutzers, was er will und warum. Eine User Story hilft dabei, eine vereinfachte Beschreibung einer Anforderung zu erstellen und enthält Akzeptanzkriterien. User Stories werden vom Product Owner erstellt und gepflegt.
• Aufgabe: Eine Aufgabe ist eine Arbeit, die vom Scrum Master oder Teammitglied eingegeben wird und die direkt oder indirekt mit User Stories in Verbindung stehen kann. Sie sind in der Regel technischer Natur und beinhalten Akzeptanzkriterien.
• Spike: Ein Spike ist eine spezielle Art von Aufgabe, die verwendet wird, wenn Sie irgendwann recherchieren, Prototypen erstellen und/oder entwerfen müssen, bevor Sie entscheiden können, wie eine User Story implementiert oder geschätzt werden soll.
• Teilaufgabe: Eine Teilaufgabe ist eine Aufgabe, die als Implementierungsschritt zur Fertigstellung einer User Story oder Aufgabe eingegeben wird. Sie werden normalerweise vom Team während eines Sprint-Planungsmeetings eingegeben.
• Story Point Estimates: Eine relative Größenschätzungsskala, die auf der Fibonacci-Skala basiert (1, 2, 3, 5, 8, 13, 21…)
• Akzeptanzkriterien: Die Liste der storyspezifischen, testbaren Elemente, die in jeder Story enthalten sind und abgeschlossen werden müssen, bevor ein Product Owner eine Story als abgeschlossen akzeptiert.
• Definition of Done (DoD): Eine Liste gängiger Schritte oder Kriterien, die abgeschlossen sein müssen, bevor eine Story als erledigt betrachtet werden kann. Das Team stimmt sich darauf ab und dokumentiert es, damit es nicht in jeder Story aufgeführt werden muss.

Vor- und Nachteile von Scrum

Der Hauptvorteil von Scrum ist die Anwendung agiler Werte und Prinzipien sowie Lean-Konzepte wie Seiri, Jidoka, Just-in-Time, Kaizen, Genchi Genbutsu, Heijunka, Pull-System und Iterationen. Applying these principles allow project teams to receive continuous feedback, quickly adapt to changing requirements and uncertainty, reduce waste, increase visibility and transparency, and strive for continuous improvement. By always focusing on the most important items in the product backlog and only working in short iterations that always produce working software, Scrum is more customer focused and allows customers to see what they like (and don't like) and make changes as needed. The overhead cost in terms of process and management is smaller, thus leading to quicker, cheaper results.

Scrum is a great methodology for projects with requirements that are not clearly known and/or expected to change. This applies to most projects. Scrum is also great for experienced, motivated teams as it allows teams to organize the work themselves and it provides visibility, transparency, and accountability for both progress and problems. All of this will result in teams improving and becoming more productive over time.

Scrum does have some disadvantages and is not the best methodology in some situations:

• Transparency: Scrum increases transparency and accountability which is both an advantage and disadvantage as problems and poor performance within and outside the team and are exposed. This can be uncomfortable and can lead to resistance if not handled properly within the Scrum framework of continuous improvement.
• Team Experience and Commitment: Inexperienced and/or uncommitted Scrum teams or Scrum Masters can cause serious problems through misapplying the Scrum methodology. There are no defined roles in the Scrum team as everyone does everything, so it requires committed team members with technical experience to follow the Scrum process and improve over time. It can also be very detrimental if other parts of the organization are resistant to Scrum.
• Scope Creep: There is a risk of scope creep, especially if there isn't a defined end date as stakeholders are allowed to add to the scope. Being able to change scope and priorities is one of the main advantages of Scrum, but it can also be a disadvantage if discipline isn't used.
• Poorly defined work: Poorly defined and understood user stories or tasks can lead to rework, inaccurate estimates, and scope creep. Although Scrum is focused on working software over documentation, the product owner needs to be clear on what they want and be able to clearly communicate that in conversations and in the user stories.
• Scaling: Adopting the Scrum framework in large teams is challenging as Scrum is meant for smaller teams.

Kanban

What Is Kanban?

Kanban is a lighter weight process that applies many of the Lean and Agile values as well as a subset of the Scrum values and principles but there are also some fundamental differences. Kanban focuses on visualization, flow, and limiting work in progress.

Kanban is Japanese for “signboard” or “billboard.” Toyota line-workers used a kanban (ie, an actual board) to signal extra capacity in various steps in their manufacturing process. In software, this is done with a Kanban board, which is very similar to the Scrum board. There is a prioritized backlog of To Do items and vertical columns for each status that a work item can have. Like Scrum, work items are moved from one status to another; however, in Kanban, the amount of work in progress is strictly limited to a maximum number of items in each status based on team capacity. New work cannot be pulled in until existing work is moved to the next step in the process. In Scrum, work in progress in indirectly limited by controlling the amount of work planned for a sprint.

In Kanban, there are no fixed iterations or sprints, just a constant flow where work items are pulled from one stage to the next. This means that the Kanban board is never reset. It also means that many of the Scrum rituals not used. Kanban teams often have daily standup meetings but they are not prescribed. There are no regularly planned sprint planning meetings, sprint demos or sprint retrospectives, so the process is more lightweight. Some of the activities in those rituals may or may not be performed at an informal level. Continuous improvement is accomplished by tracking and analyzing the flow of items from one state to another and making constant incremental improvements based on what issues are uncovered.

Kanban also doesn't prescribe the roles that Scrum does. The only role needed is the team member role, however, there is often a project manager that manages the team and the backlog. Often a single Kanban board can serve multiple function based roles and/or teams that only work on items in a certain status. For example, a development team might pull items from To Do to In Progress and move them to Testing, and the test team might test items in Testing and move them to Done.

Many of the backlog management activities for prioritizing and grooming of work items still need to be done to ensure that a given work item is well understood and ready to be worked on, however, estimating the work items is prescribed as optional.

Kanban vs. Scrum

The following table compares Scrum and Agile:

Summary: The End of Part 1

In this part, we reviewed a few of the most popular methodologies used for Software Development. By now you should have a good understanding of Lean, Agile, Scrum, and Kanban and their historical roots in Lean Manufacturing and TPS. In the next part of the series, we will continue reviewing and comparing other Software Development methodologies such as Waterfall, JTBD, and SAFe (and other scaling frameworks), as well as hybrid methodologies, so you have all of them conveniently explained in one place.