Sobald die Software-Entwicklung über das Programmieren „im Kleinen“ hinaus geht ist besonders sinnvoll, systematisch zu arbeiten und einen geeigneten Entwicklungsprozess einzuführen.
Das Wasserfall-Modell gehört zu den ersten, klassischen Entwicklungsmodellen, die einem z.B. im Studium begegnen. Im Wasserfall-Modell durchläuft das Projekt jeweils vollständig einzelne Phasen. Mehr Informationen zum Wasserfall-Modell gibt es von Sebastian auf dem ideenschmiede-Blog. Andere Prozesse bauen auf dem Wasserfall-Modell auf, bspw. das V-Modell.
Einige der Modelle haben u.a. Schwierigkeiten mit Änderungen an den Anforderungen. Um diesen Schwachpunkt zu umgehen gibt es einmal die Möglichkeit, das Produkt inkrementell bzw. evolutionär (d.h. Feedback durch Anwendung und Benutzer einfließen lassen) zu entwickeln. Eine Alternative ist es, die einzelnen Phasen nicht Projekt übergreifend zu bearbeiten, sondern die Phasen jeweils auf einzelne Anforderungen „herunter zu brechen“.
Scrum und Kanban gehören zu den neueren Entwicklungsprozessen, die mittlerweile sehr beliebt in der Entwicklung von Webprojekten sind.
Nachdem ein anderes Team vorher bereits besonders gute Erfahrungen mit Kanban gemacht hat, steigen wir in den nächsten Tagen ebenfalls um. Für den Vergleich der beiden Methoden hatte ich Notizen zusammen getragen. Im Nachfolgenden möchte ich einige Eigenschaften der beiden Modelle vorstellen:
Kanban
- Kanban-Board enthält den aktuellen Entwicklungsfortschritt des Projektes und offene Aufgaben
- FIFO, optional mit Priorisierung über Kanban-Board
- neue Anforderungen (Tickets) können übernommen werden, sobald Kapazitäten frei sind
- Möglicher “Stau” in einer Kanban-Board-Spalte muss optimiert werden
- keine „Rollen“, aber feste Stationen, visualisiert über das Kanban-Board
- Anwendungsbereiche: häufige Releases, flexibler mit Anforderungen umgehen, Wartung/Support
- eher für unkomplizierte Projekte/Produkte, kleine Teams
- (möglichst) keine gleichzeitigen Aufgaben pro Mitarbeiter
- gleichmäßige Arbeitsbelastung (Auslastung ohne Überlastung)
- mehr Änderungsmanagement als Entwicklungs-Lebenszyklus-Methode
- Quellen: Wikipedia, t3n
Scrum
- feste Iterationen (Sprint) ( = “Lieferungen”)
- Produkt sollte nach jeder Time Box auslieferungsfähig sein (bestmögliches Produkt unter Berücksichtigung von Kosten, Funktionalität, Zeit, Qualität)
- Aufgaben werden zu Beginn verpflichtend festgelegt und zugeordnet
- Rollen: Product Owner, Team, Scrum Master = Scrum Team, sowie Management, Customer, User
- Flexible Anpassung an mittlerweile geänderte Anforderungen (normalerweise zu Beginn des nächsten Sprints)
- User Storys anstelle von Pflichtenheft
- Mitarbeiter stehen im Mittelpunkt – Eigenverantwortung, Qualifizierung wichtig
- Verschiedene regelmäßige Meetings: Daily Scrum (täglicher Fortschritt, aufgetretene Probleme und Hindernisse, die zu lösen sind, aktuelle Arbeit), Sprint Planning (Planung des nächsten Sprints durch das Scrum Team), Spring Review (i.W. Präsentation der Ergebnisse), Retrospektive (Reflektion der Erfahrungen, Suche nach Optimierung bzw. Ausräumen von Hindernissen)
- Product Backlog, Sprint Backlog
- Quellen: Wikipedia, t3n
Zusätzliche Quellen: Weitere Artikel zum Vergleich von Kanban und Scrum gibt es z.B. auf heise.de und auf microtool.de.
In beiden Entwicklungsmodellen werden Aufgaben erfasst und der Fortschritt visualisiert. Es gibt einige Software, die die Zusammenarbeit unterstützen kann und darüber hinaus auch das örtlich getrennte Arbeiten ermöglicht.
Für einige bedeutet der Wechsel des Entwicklungsprozesses eine große Umstellung. Es erfordert u.U. eine gewisse Einarbeitungszeit, bis die Vorteile erkennbar sind. Sowohl Scrum als auch Kanban sehen vor, den aktuellen Prozess zu reflektieren und auf Probleme, Aufgabenstau und sonstigen Hindernissen zu reagieren und den Ablauf zu optimieren.
Es ist sinnvoll, den Prozess zu etablieren, mit dem das Team am effizientesten arbeiten kann. Das kann bedeuten, dass man auf ein paar “Regeln” verzichtet, dafür andere ergänzende Regeln einführt.
Hi Benny,
schöne Zusammenfassung 🙂 Der allerwichtigste Unterschied zwischen den beiden Modellen ist allerdings der folgende: Kanban ist kein Prozessframework, im Gegensatz zu Scrum. Kanban für sich kennt nur 3 Prinzipien: Visualisierung, Limitierung und kontinuierliche Verbesserung.
Und der entscheidende Unterschied tritt bei deinem letzten Satz zu Tage: “Das kann bedeuten, dass man auf ein paar “Regeln” verzichtet, dafür andere ergänzende Regeln einführt.”
Genau das ist der Unterschied: Kanban ist ein evolutionäres Vorgehen. Man arbeitet damit und passt es Schritt für Schritt an. Kanban hat keine feste Regeln, man formt mit Kanban keinen Wunschprozess, sondern alles was Kanban verlangt, ist es ganz exakt genau das abzubilden, wie man gerade arbeitet. Das kann auch ein Wasserfallmodell sein, das ist Kanban egal. Kanban macht keine Vorgaben wie ich arbeite.
Scrum ist ein revolutionärer Ansatz, für den dein Satz nicht zutrifft: wenn ich das Framework einsetze, werden Probleme transparent und ICH bzw. mein Team oder Unternehmen müssen sich entsprechend ändern und anpassen, eine Revolution eben. Mache ich das nicht, und fange direkt anfangs an Regeln zu verändern, wird Scrum nicht (!) funktionieren. Überall wo Scrum nicht ganz passt und man meint “wir sind anders, da müssen wir an Scrum schrauben”, legt Scrum ein Problem offen. Erforsche es, statt die Regel dafür zu ändern.
Das macht Scrum so schmerzlich und das unterscheidet Scrum von Kanban.
Die besten Scrum Prozesse holen sich übrigens Kanban-relevante Punkte mit ins Boot, wie etwa die Einführung eines WIP, die auch bei Scrum hilfreich ist, sich auf das wesentliche zu konzentrieren, Multitasking zu verringern und die Produktivität zu steigern.
Ich meinte im letzten Absatz natürlich ein WIP-Limit… 😉
Übrigens: die große Schwierigkeit an Scrum ist es, wirklich alle Regeln zu leben. Scrum unterscheidet sehr fein zwischen “Tools” im Framework, die man benutzen kann, aber nicht muss und eben festen Regeln, die nicht geändert werden dürfen. Der Nutzen dieser Regeln ist meistens nicht von Anfang an offensichtlich, lasst sie dafür aber nicht weg.
Ein kleines Beispiel: Timeboxes. Man sagt sich “naja, wenn wir in der Sprint Planung jetzt die Timebox nicht erreichen, der Sprint aber noch nicht voll ist, können wir ja nicht einfach aufhören”.
Doch, kann man. Diese Schuld, muss man dann im Sprint “ausbaden” und beim nächsten Mal, werden alle Beteiligten plötzlich eher die Verantwortung übernehmen, das Ziel der Sprint Planung zu erreichen, als wenn ich einfach sage, “alles klar, dann machen wir eben 1-2 Stunden länger”. Ist damit also ein Werkzeug die Selbstorganisation anzutreiben.
Hi Seb,
vielen Dank für die ausführlichen Ergänzungen und Klarstellungen.