Agile, Scrum und Kanban: Was zum Teufel bedeuten diese Wörter wirklich?

Wenn ein Softwareentwickler Neuigkeiten über ein „neues JavaScript-Framework“ oder eine „neue IDE“ hört, muss er nicht weiter nachfragen, um zu klären, worum es geht. Aber wenn er von einem „neuen agilen Framework“ hört, wird er wahrscheinlich wie Homer-Simpson nicken und so tun, als wüsste er, worum es geht, aber er wird eine, und nur eine, Frage haben: Was zum Teufel bedeutet „agile Framework“? bedeuten?

Im modernen Softwareentwicklungsumfeld hören wir immer häufiger Wörter wie „Agile“, „Scrum“ und „Kanban“, und sie werden oft falsch verwendet. In diesem Artikel werde ich versuchen, einige dieser Begriffe zu erklären und zu klären.

Agil

Wenn Sie der Klugscheißer der Masse sein wollen, sollten Sie das Wort „agil“ in jedem zweiten Satz verwenden, wenn Sie über den Arbeitsprozess sprechen. Es ist ziemlich breit gefächert, verpflichtet nicht dazu, viel über das Thema zu wissen, und es ist ein wirklich schönes Adjektiv oder Adverb: „agil denken“, „agiles Vorgehen“, „nach agilen Prinzipien“. Aber was bedeutet „agil“ wirklich?

„Agile“ bezieht sich auf „agile Softwareentwicklung“, den Entwicklungsansatz, der agilen Prinzipien folgt. Aber was zum Teufel sind „agile Prinzipien“? Werfen Sie einen Blick auf das Agile Manifesto und auf die 12 Agile-Prinzipien, die die Grundlagen der agilen Entwicklung bilden. Aus dem Manifest:

Agile Prinzipien fördern die kontinuierliche Bereitstellung funktionierender Software, eine enge Kommunikation zwischen den Teams und eine hohe Anpassungsfähigkeit an sich ändernde Anforderungen. Wenn Sie diese Werte und Prinzipien in Ihrer Arbeit befolgen, können Sie sagen, dass Sie in einem agilen Umfeld arbeiten. Agile Softwareentwicklung ist also keine Methodik, sondern nur eine Reihe verschiedener Methoden, Frameworks und Techniken, die denselben Prinzipien folgen. Man kann sagen, dass „agil“ ein Rahmen zum Denken und Treffen von Entscheidungen ist.

Aber warum ist es so wichtig, diese Prinzipien in unserer Arbeit zu befolgen?

Das Manifest und die Prinzipien sind das Ergebnis der Suche nach den besten Lösungen, die sich im Laufe der Jahrzehnte als Antwort auf die Herausforderungen der Softwareentwicklung entwickelt haben. In den 70er, 80er und 90er Jahren experimentierten verschiedene Entwickler und Teams auf der ganzen Welt mit Arbeitsmethoden und Ansätzen zur Problemlösung, erfanden verschiedene Frameworks und Techniken (wie Scrum und Extreme Programming) und kamen sogar auf dasselbe Ideen parallel. Schließlich kamen im Februar 2001 siebzehn Entwickler zusammen und fanden den gemeinsamen Nenner für all diese unterschiedlichen Ideen und Erfahrungen. So entstand das Manifest.

Gedränge

Wenn Sie über „agile“ Methoden sprechen, ohne zu wissen, was sie bedeuten, können Sie Fehler machen und Dinge sagen, die Sie vor dem Gesprächspartner aufdecken, der sich mit dem Thema auskennt: „Scrum und andere agile Methoden“.

Scrum ist keine Methodik, obwohl wir alle schon häufiger davon gehört haben als die Zahl der Morde in Game of Thrones . Scrum wird nicht auf jede Frage eine Antwort geben, und es wird Ihnen nicht das genaue Verfahren zur Verfügung stellen, um auf jede Situation zu reagieren, mit der Sie konfrontiert sind. Und wahrscheinlich aufgrund dieser falschen Interpretation sind die meisten Scrum-Implementierungen auch falsch: Teams erhalten keinen Wert. Daraus ergibt sich die wohl dümmste Aussage über Scrum: „Scrum funktioniert nicht.“

Was ist Scrum? Der Scrum Guide definiert Scrum als:

Es ist also ein Framework , und wie jedes andere Framework kann es falsch verwendet werden und wird es auch regelmäßig. Die effektive Nutzung von Scrum erfordert nicht nur die Übernahme der durch Scrum festgelegten Struktur, sondern auch ein tiefes Verständnis und Wertschätzung für agile Prinzipien im gesamten Team.

Scrum besteht aus folgenden Rollen: Product Owner, Scrum Master, Entwicklungsteam.

Außerdem gibt es vier Scrum-Zeremonien: Planning Meeting, Daily Scrum, Sprint Review, Sprint Retrospective

Und die drei Artefakte: Product Backlog, Sprint Backlog, Product Increment.

Scrum-Projekte sind in regelmäßigen Zeitrahmen organisiert, die wir Sprints nennen. Sie dauern in der Regel zwei Wochen.

Ein Product Owner ist dafür verantwortlich, die Richtung des Projekts zu lenken. Wenn neue Aufgaben und Features festgelegt werden, fügt der Product Owner sie einem Product Backlog hinzu. Ein Sprint beginnt mit einem Planungsmeeting, bei dem das Entwicklungsteam die zu bearbeitenden Aufgaben aus dem Backlog auswählt und plant, wie sie umgesetzt werden. Darauf folgt die Entwicklung, während der das Entwicklungsteam den Rückstand nutzt, um den Fortschritt zu verfolgen, und sich zum täglichen Meeting trifft, um die Aktivitäten zu synchronisieren und den Plan bei Bedarf anzupassen. Das Ergebnis der Entwicklung sollte ein Produktinkrement sein, etwas, das auf das Produkt angewendet und sofort veröffentlicht werden kann. Am Ende des Sprints wird das Produktinkrement dem Product Owner beim Sprint Review präsentiert, wo das Product Backlog erweitert wird, falls weitere Änderungen erforderlich sind. Anschließend nimmt das gesamte Team an der Sprint-Retrospektive teil, wo sie über den Arbeitsprozess sprechen und wie er verbessert werden kann.

Scrum ist leicht zu erlernen und zu verstehen, aber schwer umzusetzen. Es gibt viele Gründe, warum dieses Framework für ein Projekt geeignet sein kann oder nicht. Es erfordert oft viele Veränderungen, nicht nur in der alltäglichen Entwicklung, sondern auch kulturell. Scrum passt am besten zur Entwicklung komplexer Produkte, die lange halten und verschiedene Arten von Spezialisten einbeziehen.

Warum ist Scrum so beliebt und warum hat es einen Vorteil gegenüber dem traditionellen Wasserfallmodell? Einfach ausgedrückt, weil es einem Produkt und Kunden mehr Wert bietet. Bei „Schwergewicht“-Methoden wie Wasserfall häufen sich Schauergeschichten, in denen monatelang niemand etwas von dem Projekt mitbekommt. Mit Scrum ist das nicht möglich.

Bei Scrum dreht sich alles um den Wert , der Endbenutzern geboten wird. Wenn Sie Scrum wirklich nutzen, müssen Sie in jedem Sprint etwas Wertvolles liefern. Der Wert kann gemessen werden, und das Team ist auch gezwungen, Hindernisse zu untersuchen und sich anzupassen, mit dem Ziel, in der nächsten Iteration mehr Wert zu liefern.

Bei den meisten Softwareentwicklungen bauen wir keinen Wolkenkratzer; Wir müssen nicht den ganzen Plan fertig haben, bevor wir anfangen, und uns bis zum Ende an diesen Plan halten. Wir entwickeln Software und haben die Fähigkeit, uns an unterschiedliche Situationen anzupassen und die Produktanforderungen während der Entwicklung zu ändern. Viele Entwickler sahen darin lange Zeit die achte Todsünde, aber aus Produktsicht ist es ein enormer Vorteil, um die Planbarkeit zu optimieren und das Risiko zu kontrollieren. Scrum wurde um diese Fähigkeit herum entwickelt, und seine Implementierung bietet einen zuverlässigen und effizienten Weg, um mit notwendigen Änderungen umzugehen.

Viele Techniken werden in Verbindung mit Scrum verwendet: Planungspoker, Paarprogrammierung, testgetriebene Entwicklung (TDD), verhaltensgetriebene Entwicklung (BDD) und andere. Sie sind nicht wirklich ein Teil von Scrum, sondern eher kompatible Techniken. Eine Methode, die oft gleichzeitig mit Scrum erwähnt wird, ist Kanban, und es herrscht große Verwirrung darüber, was diese beiden Dinge im Verhältnis zueinander bedeuten.

Kanban

Wenn Sie über Scrum und Kanban sprechen, lautet eine häufig gestellte Frage der Menge: „Was ist besser, Scrum oder Kanban?“ Und Sie werden nicht wissen, was Sie antworten sollen, denn es ist, als würde man Äpfel mit Birnen vergleichen oder fragen: „Was ist besser, Pfannkuchen oder Bier?“ Beides ist besser.

Kanban ist eine einfache Methode, die auf Just-in-Time-Lieferung abzielt, ohne die Teammitglieder zu überlasten. Es ähnelt Scrum dahingehend, dass das Ziel darin besteht, am Ende den maximalen Wert zu liefern, aber es ist viel flexibler als Scrum.

Kanban wurde nicht von der Softwareentwickler-Community erfunden. Tatsächlich hat es seinen Ursprung in den Herstellungsprozessen bei Toyota und findet in anderen Bereichen breite Anwendung. Es gibt keine strengen Verfahren, die Sie befolgen sollten, und keine strenge Art und Weise, wie Sie Kanban implementieren und verwenden sollten. Es handelt sich vielmehr um eine Reihe von Prinzipien und Praktiken, und Sie können aus diesen Praktiken auswählen, um Ihren Bedürfnissen gerecht zu werden. Aber es gibt eine am häufigsten verwendete Implementierung von Kanban in der Softwareentwicklung, die die Verwendung eines Kanban-Boards beinhaltet, das aus Spalten besteht, die Arbeitsschritte und Aufgaben darstellen.

Spalten repräsentieren den Status einer Aufgabe im Entwicklungsprozess. Das einfachste Beispiel besteht aus drei Spalten: „To Do“, „In Progress“ und „Done“. Aufgaben werden also zu „Zu erledigen“ hinzugefügt, zu „In Bearbeitung“ verschoben, wenn die Entwicklung beginnt, und als „erledigt“ betrachtet, wenn sie in die letzte Spalte verschoben werden. Aber natürlich könnte es komplexer sein:

Backlog → Defining Specification → Ready for Development → Development → Code Review → Testing → Deployed (→ Niemand verwendet es wirklich → Completely Removed).

Jede Spalte kann Unterspalten haben; Beispielsweise kann „Entwicklung“ in „Planung“ und „Codierung“ unterteilt werden; „Testing“ kann in „Unit Testing“ und „Integration Testing“ usw. unterteilt werden. Gegebenenfalls können Spalten Spezialisten gewidmet werden. Das Team definiert die Spalten und Stufen nach seinen Bedürfnissen. Gemäß der „Pull“-Philosophie sollten Aufgaben nur dann in den Workflow aufgenommen werden, wenn die Nachfrage nach ihnen unmittelbar besteht.

Der Zweck dieses Boards besteht darin , den Workflow zu visualisieren , der die erste Schlüsselpraxis in Kanban ist. Kanban geht sogar ganz ohne Tafel! Es könnte eine einfache Liste von Aufgaben in einem Google-Blatt mit unterschiedlichen Hintergrundfarben sein, die den Status der Aufgabe anzeigen, oder es können Gantt-Diagramme, Diagramme, Tabellen sein … Es könnte sogar eine Reihe von Eimern in Ihrem Büro sein, wo jeder einzelne repräsentiert den Status der Aufgabe und wo Bälle als Aufgaben verwendet werden. Visualisieren Sie einfach den Workflow und sorgen Sie für Transparenz im gesamten Prozess.

Ein weiteres wichtiges Prinzip besteht darin , die Batchgröße Ihrer Bemühungen zu reduzieren . Vereinfacht bedeutet dies, Multitasking zu vermeiden. Das kann bedeuten, das Volumen der Aufgaben zu reduzieren, an denen Sie gleichzeitig arbeiten. Wenn Sie drei Designer in einem Team haben, kann das Team die maximale Anzahl von Aufgaben in der Spalte „Design“ auf drei festlegen.

Wie Scrum sieht auch Kanban das Team als wichtigste Figur im Prozess. Aber es schlägt keine Rollen vor wie Scrum, und Sie können die vorhandenen Rollen beibehalten, um Änderungen an Ihrem vorhandenen Prozess zu vermeiden. Dasselbe steht für kontinuierliche Verbesserung: Kanban ermutigt Sie im Allgemeinen, kontinuierlich zu lernen und sich zu verbessern, schreibt jedoch kein bestimmtes Ereignis nur für diesen Prozess vor, wie dies bei Scrums Sprint-Retrospektive der Fall ist.

Welche sollte ich verwenden?

Scrum und Kanban schließen sich nicht aus und sind nicht wirklich vergleichbar. In Scrum gibt es definierte Rollen, während Kanban sagt: „Was zum Teufel, behalten Sie Ihre aktuellen Rollen und Verantwortlichkeiten bei.“ Scrum wird Sie dazu zwingen, Ihre Arbeitsweise zu ändern; Mit Kanban können Sie mit Ihrem bestehenden Prozess beginnen. Bei Scrum wird durch das Framework ein klarer Ablaufplan für Events vorgegeben; In Kanban gibt es keine Ereignisse. Dennoch haben sie viele Gemeinsamkeiten: Beide sind wertezentriert, Teammitglieder werden als „Chefs“ des Systems respektiert und haben im Wesentlichen die gleiche Mission: Kontinuierlich Verschwendung zu beseitigen und Hindernisse zu beseitigen.

Aber die Frage: „Was soll ich in meinem speziellen Projekt und mit meinem speziellen Team verwenden?“ macht viel mehr Sinn. Kanban erfordert nicht so viele Prozess- und Kulturänderungen und ist in den meisten Fällen einfacher einzuführen als Scrum. Scrum hingegen bietet deutlich mehr Struktur, um den Prozess zu steuern, was viel Overhead eliminieren kann, solange alle auf derselben Seite sind.

Aber das Schöne an beiden ist, dass es sich bei beiden nicht um ein strenges Regelwerk handelt. Nichts hindert Sie daran, die besten Scrum-Elemente für Sie auszuwählen, wie z. B. ein tägliches Meeting oder eine Überprüfung. Und es gibt keinen Grund, warum Sie ein Kanban-Board nicht in Scrum integrieren können.

Scrum hat sich als äußerst effektives Framework erwiesen, wenn es vom gesamten Team gut verstanden wird. Meiner Erfahrung nach finde ich es jedoch schwierig, mit einigen Kunden im Scrum zu arbeiten. Der Prozess und die kulturellen Veränderungen, die für eine ordnungsgemäße Scrum-Implementierung erforderlich sind, können zu viel sein (insbesondere wenn man es mit jemandem zu tun hat, der glaubt, dass er ein neues Google macht!). Andererseits ist Kanban flexibler und zwingt die Menschen nicht, sich zu ändern. Einige Autoren sagen auch, dass Kanban ein guter Weg zur Agilität ist und eine einfachere Implementierung von Scrum bietet. Andere sagen, dass die Verwendung von Scrum am Ende zu Kanban führen sollte.

Die Wahrheit ist, dass jedes Projekt anders ist und es keine Einheitslösung gibt. Als Projektmanager liegt es an Ihnen, zu bestimmen, was für Ihr Team am besten funktioniert.