Gleich einem Lebewesen hat auch jedes Softwareprodukt seinen Lebenszyklus. Der Software-Lebenszyklus ist eine Reihe von Phasen, die ein Produkt während seiner gesamten Lebensdauer durchlaufen muss. Er beginnt mit einer Geschäftsidee, die in Code umgesetzt werden soll, und endet mit der Wartung einer fertigen Softwarelösung nach der Bereitstellung.
Es gibt eine ziemlich standardisierte Liste der Lebenszyklusphasen, die unter Softwareentwicklern weithin akzeptiert ist. Die Technologie der Computercodierung selbst bestimmt diese Liste. Aber sowohl die Reihenfolge der Phasen als auch die Methodik des Projektmanagements können von Fall zu Fall variieren. Ausserdem entwickeln sich die Methoden zur Entwicklung von Softwareprodukten ständig weiter. Und wie bei jeder Evolution müssen verschiedene Entwicklungsmethoden darum kämpfen, von Softwareentwicklern angenommen zu werden.
Jede Produktentwicklungsmethodik hat ihre besonderen Vor- und Nachteile. Und das ist ein ziemlich heikler Punkt, denn bestimmte Vorteile und mögliche Nachteile lassen sich wohl kaum ein für alle Mal festlegen. Was für das eine Projekt ein Vorteil ist, kann für ein anderes Projekt leicht ein Nachteil sein. Nichtsdestotrotz lohnt es sich, die Vor- und Nachteile der gängigsten Softwareentwicklungsmethoden zu prüfen, um herauszufinden, welche Methode am besten zu Ihrem Entwicklungsprozess passt.
Trotz der vielen allgemeinen Informationen über die wichtigsten Softwareentwicklungsmethoden, die im Internet verfügbar sind, möchten wir auf einige besondere Aspekte eingehen, denn der Teufel steckt im Detail.
Lebenszyklus-Phasen & Projektmanagement-Paradigmen
Die folgenden Phasen des Lebenszyklus eines Softwareprodukts gelten in der gesamten Softwareentwicklungsbranche als üblich. Sie können sich von Projekt zu Projekt leicht unterscheiden, aber der Unterschied liegt in den Begriffen, nicht in der Bedeutung. Sie spiegeln in der Regel wider, was die Entwickler tun müssen, damit das Produkt das Licht der Welt erblickt.
- Analyse der Idee. Jede Geschäftsidee eines Kunden in Bezug auf eine neue Software sollte vom Entwicklerteam analysiert werden, um zu verstehen, welche technischen Anforderungen auf das künftige Produkt anwendbar sein könnten.
- Entwerfen und Planen. Wenn die Produktanforderungen klar sind, bieten die Designer und Softwareingenieure Technologien und Werkzeuge an, mit denen das zukünftige Produkt die Anforderungen erfüllen kann. Dabei geht es sowohl um die Funktionen des Produkts als auch um die Mittel, mit denen die Funktionen verwirklicht werden können. Der gesamte Arbeitsplan wird in der Regel in dieser Phase ausgearbeitet.
- Programmierung. Dies ist die längste Phase, die zahlreiche Unterphasen umfassen kann. Sie alle führen dazu, dass aus einer Idee ein echtes Produkt wird, das man anfassen und testen kann.
- Testen und Fehlerbehebung. Diese Phase hilft den Entwicklern zu erkennen, ob das fertige Produkt tatsächlich fertig ist. Je gründlicher das Testen und die Fehlerbehebung durchgeführt werden, desto weniger Probleme treten bei der Unterstützung nach der Bereitstellung auf.
- Einführung und Wartung. Wenn ein neues Softwareprodukt auf den Verbrauchermärkten auftaucht, kann das Entwicklerteam nur selten zur Seite treten und das Produkt einfach laufen lassen. Support und Wartung sind entscheidend, damit das Produkt überlebt und den gewünschten Geschäftseffekt bringt. Diese Phase kann Jahre, wenn nicht Jahrzehnte dauern.
Der Lebenszyklus zeigt, was mit einem neuen Softwareprodukt im Laufe seiner Entwicklung geschieht. Aber er erklärt nicht, wie das geschieht. Um die Frage nach dem "Wie" zu beantworten, kommen verschiedene Methoden der Produktentwicklung ins Spiel. Hier geht es um Projektmanagement-Paradigmen, die dafür sorgen, dass sich jeder einzelne Entwicklungsprozess oft von den anderen unterscheidet.
Im Allgemeinen gibt es zwei grundlegende Paradigmen: ein lineares, das durch die Wasserfall-Methode repräsentiert wird, und ein agiles Paradigma, das sich aus einigen spezifischen Produktentwicklungsmethoden wie Scrum, Kanban, Lean und dergleichen zusammensetzt. Das lineare Paradigma ist einfach zu verstehen, da es sich im Kern um einen geradlinigen, schrittweisen Entwicklungsprozess handelt. Das agile Paradigma hingegen ist weniger leicht zu verstehen, da sich die Komplexität aller zusammengesetzten Softwareentwicklungsmethoden in vielen entscheidenden Aspekten unterscheidet.
Werfen wir einen Blick auf die beiden beliebten agilen Methoden der Produktentwicklung Kanban und Scrum, um zu verstehen, wie das agile Paradigma sowohl den Entwicklern als auch ihren Kunden Vorteile bringt.
Kanban-Methodik
Das Wort Kanban bedeutet in Japan "Zeichen" oder "Notiz". Das Kanban-System hat seine Wurzeln in den Autofabriken von Toyota. Die japanischen Manager setzten Tafeln mit Notizen ein, um einen speziellen Ansatz zu visualisieren, mit dem sie ihr betriebliches Inventarsystem verbessern wollten. Das Hauptziel war es, sowohl Verschwendung als auch Ausfallzeiten zu reduzieren. Im Laufe der Zeit hat der erfolgreiche Ansatz zahlreiche Anwendungen in verschiedenen Branchen gefunden.
In der Softwarebranche ist Kanban als Methode zur Verbesserung der Entwicklungsprozesse anerkannt. Sie ist eines der Elemente der agilen Philosophie, die das sogenannte Manifest für agile Softwareentwicklung im Hintergrund hat. Die im Manifest genannten Werte sind auf fast alle agilen Softwareentwicklungsmethoden anwendbar, natürlich auch auf Kanban.
Wie Kanban aussieht
So trivial es auch klingen mag, das einzige Endziel von Kanban ist die rechtzeitige Freigabe eines hochwertigen Endprodukts. Kanban beginnt mit einer Tafel mit Notizen, um alle Prozesse für das gesamte Team visuell fassbar zu machen. Sowohl eine reale (materielle) Tafel als auch deren virtuelle Entsprechungen (wie z.B. Trello) können geeignet sein. Jedes Teammitglied kann auf die Tafel zugreifen, um jederzeit den aktuellen Status der einen oder anderen Aufgabe zu sehen.
Jedes Projekt hat seinen eigenen Arbeitsplan, der aus bestimmten Phasen besteht. Die Etappen sollten in Spalten auf der Tafel angegeben werden. Die Anzahl der Etappen kann von Projekt zu Projekt variieren, und auch die Namen der Etappen können beliebig gewählt werden. Das Wichtigste ist, dass die Reihenfolge der Phasen unverändert bleibt. Eine solche Abfolge wird in Kanban als Flow bezeichnet. Der Fluss eines typischen IT-Projekts könnte die folgende Abfolge haben:
"ausstehend - zugewiesen - im Prototyping - in Entwicklung - im Test - fertig - in Wartung".
Die Kanban-Notizen, die bestimmte Aufgaben enthalten, sollten sich über die Durchlaufphasen bewegen. Die Kanban-Tafel ermöglicht es Entwicklern, mehrere Projekte gleichzeitig zu bearbeiten. Verschiedenfarbige Notizen können verschiedene Projekte widerspiegeln. Eine Tafel mit Notizen allein reicht jedoch nicht aus, damit Kanban funktioniert. Die Teammitglieder sollten wissen, wie man das Spiel spielt.
Kanban-Prinzipien
Kanban setzt voraus, dass alle Teamkollegen an einem Strang ziehen. Wenn jemand nicht Schritt hält, leidet das gesamte Projekt. Da der gesamte Arbeitsablauf auf der Tafel visualisiert wird, können alle Teamkollegen ihren eigenen Beitrag zum Wert des Projekts einschätzen. Die agile Philosophie, die Kanban zugrunde liegt, hat keine festen Regeln. Stattdessen gibt es einige grundlegende Kanban-Prinzipien, mit denen Sie rechnen müssen.
- Schätzen und nutzen Sie, was Sie hier und jetzt haben: die verfügbaren Ressourcen, Fähigkeiten und Verantwortlichkeiten
- Optimieren und verbessern Sie Ihren Entwicklungsprozess und vermeiden Sie allzu abrupte Änderungen
- Fördern Sie Führungsqualitäten in Ihrem Team
Mit der Kanban-Methode lassen sich grossartige Ergebnisse erzielen, wenn das Arbeitspensum des Teams richtig gepflegt wird. Es ist wichtig, die Aufgaben zu quantifizieren, die Ihr Team innerhalb eines bestimmten Zeitrahmens tatsächlich bewältigen kann. Die Kanban-Visualisierung ist dabei eine grosse Hilfe. Sie stellt ein ganzheitliches Bild des Projekts dar, das es ermöglicht zu erkennen, wie die einzelnen Elemente verbessert werden können.
Wann lohnt sich der Einsatz von Kanban
Einige Experten betrachten Kanban zu Recht als eine Übergangsmethode beim Übergang vom linearen Wasserfall zu einer sehr ausgeprägten agilen Methode wie Scrum. Obwohl sowohl Kanban als auch Scrum zu den agilen Softwareentwicklungsmethoden gehören, ist Kanban in vielerlei Hinsicht etwas weicher: Es werden keine Meetings abgehalten, funktionsübergreifende Teams sind nie obligatorisch, es gibt keine Rolleneinteilung in einem Team, es sind keine grundlegenden Änderungen der Arbeitsabläufe erforderlich usw.
Wenn Entwickler nach der traditionellen Wasserfall-Methode arbeiten, kann viel Zeit für die Dokumentation vergeudet werden, wenn im letzten Moment ein Fehler entdeckt wird. Nehmen wir an, das Team stellt fest, dass es an der Zeit ist, zu Agile überzugehen. Warum nicht Scrum, wenn es heute so beliebt ist? Aber gleichzeitig sind gewisse Ängste ganz natürlich: Was ist, wenn eine so radikale Umstellung scheitert?
Das ist genau der Moment, in dem Kanban eine gute Wahl wäre. Wenn ein Team erfolgreich mit Kanban vorankommt, ist ein weiterer Übergang zu Scrum einen Versuch wert. Aber in vielen Fällen scheinen die mit Kanban erzielten Fortschritte ausreichend zu sein. Zu den Vorteilen von Kanban gehört also unter anderem ein reibungsloser Übergang zur agilen Software-Produktentwicklung.
Scrum-Methodik
Wenn wir von Scrum sprechen, ist eine agile Methodik der Softwareentwicklung gemeint. Aber das ist nicht ganz richtig. Um genau zu sein, kann eine agile Softwareentwicklungsmethodik auf Scrum-Praktiken aufgebaut sein. Deshalb kann mein Scrum ganz anders aussehen als Ihr Scrum. Scrum ist also so etwas wie eine agile Methodik im Quadrat: Es bietet einen agilen Ansatz für ein sehr agiles Paradigma. Aber das Wichtigste zuerst.
Besonderheiten von Scrum
Im Gegensatz zu Kanban beginnt Scrum mit spezifischen Rollen, die einigen verantwortlichen Teammitgliedern zugewiesen werden. Sie müssen die Rollen auf eine sehr eindeutige Weise spielen. Der Verantwortungsbereich der Rollen ist wahrscheinlich die einzige feste Regel in Scrum. Was danach geschieht, ist der Flexibilität und Kreativität Ihrer Teamkollegen überlassen. Die grundlegenden Scrum-Rollen implizieren Folgendes:
- Produkteigentümer (PO). Ein Teammitglied, das diese Rolle spielt, fungiert als Bindeglied zwischen dem Team und dem Kunden. Die Hauptaufgabe eines Product Owner besteht darin, alles zu tun, um den Wert sowohl des entwickelten Produkts als auch der Arbeit des Teams zu erhöhen. Ein zentrales Werkzeug des PO ist das sogenannte Product Backlog, das alle Arbeitsaufgaben in der Reihenfolge ihrer Priorität enthält.
- Scrum Master (SM). Er ist eine dienende Führungspersönlichkeit, deren Aufgabe es ist, den Teammitgliedern zu helfen, ihre Arbeitseffizienz zu maximieren, indem er verschiedene auftretende Hindernisse beseitigt. Der SM unterstützt den PO, indem er das Team ausbildet und motiviert.
- Entwicklungsteam (DT). Das DT besteht nur aus den Specs, die direkt an der Produktentwicklung beteiligt sind. Laut dem offiziellen Scrum Guide sollte das DT die folgenden Eigenschaften besitzen:
- Selbstorganisiert sein. Niemand (auch nicht PO und SM) kann den Teammitgliedern vorschreiben, wie sie das Product Backlog in ein tatsächlich funktionierendes Produkt umwandeln sollen.
- Multifunktional zu sein. DT soll alle notwendigen Spezifikationen enthalten, um ein tatsächlich funktionierendes Produkt zu erstellen.
- Die volle Verantwortung tragen. Nicht einzelne Personen, sondern das Team als Ganzes trägt die Verantwortung für die Endergebnisse.
- Die empfohlene Anzahl der DT-Mitglieder beträgt 7 +/- 2 Personen. Grössere Teams erfordern übermässige Ressourcen für die Kommunikation, während kleinere Teams das Risiko erhöhen, dass das Projekt aufgrund unzureichender Fachkenntnisse scheitert.
Scrum-Prozess
Scrum geht mit speziellen Entwicklungsperioden einher, die Sprints genannt werden (in der Regel jeweils 2 - 4 Wochen). Jeder Sprint hat einen bestimmten Zweck. Im Idealfall endet jeder Sprint mit einer neuen Version des entwickelten Produkts.
Bevor ein Sprint beginnt, findet eine gemeinsame Sprintplanung statt, um zu überlegen, welche Aufgabe aus dem Product Backlog in ein bestimmtes Sprint Backlog passen könnte. Das Ziel eines jeden Sprints dient dabei als Motivator. Das Schema ist einfach: Die Erfüllung der in den Sprint Backlogs angegebenen Sprint-Aufgaben führt zum Erreichen der Sprint-Ziele.
Jeden Tag hält das gesamte Team ein spezielles Treffen ab, das Daily Scrum genannt wird und bei dem alle Teammitglieder ihre Pläne, Erfolge und Hürden austauschen, denen sie gegenüberstehen. Ziel der Treffen ist es, den Status und den Fortschritt jedes Sprints zu ermitteln.
Wenn ein Sprint vorbei ist, finden zwei weitere Treffen statt: Sprint Review und Sprint Retrospective. Sie helfen den Teammitgliedern, ihre Effizienz im abgeschlossenen Sprint zu bewerten und die wünschenswerte Effizienz in den zukünftigen Sprints zu prognostizieren.
Vorteile von Scrum
Scrum ist kundenorientiert. Kunden können ihre Anforderungen jederzeit ändern. Auch wenn Scrum keine Garantie für die Erfüllung der Anforderungen bietet, so ist doch gerade die Möglichkeit, während des Prozesses Änderungen vorzunehmen, für viele Kunden sehr attraktiv.
Scrum ermöglicht eine Zeitersparnis durch den Ausschluss von unkritischen Aktivitäten. Diese Softwareentwicklungsmethode bietet am Ende eines jeden Sprints ein potenziell lebensfähiges Produkt.
Scrum konzentriert sich auf autarke Teams, die ihre Aufgaben ohne übermässige Koordination bewältigen können. Dies ist vor allem für kleine Unternehmen und Startups interessant, da kein spezielles Managementpersonal eingestellt werden muss.
Mängel von Scrum
Gelegentlich steht die sehr kundenorientierte Ausrichtung von Scrum im Widerspruch zu den Scrum-Prinzipien. Kunden interessieren sich nicht für die internen Regeln des Teams und sollten dies auch nicht tun. Vor allem, wenn die Regeln die Wünsche der Kunden irgendwie einschränken. Scrum gehört zur agilen Philosophie, die weder Kommunikationspläne noch Strategien zur Reaktion auf Risiken vorsieht. Daher ist kein formeller Widerstand gegen Verstösse gegen die Scrum-Regeln möglich.
Ein weiterer Nachteil von Scrum liegt in der multifunktionalen Struktur der Teams. Die geringeren Koordinationskosten können die kompliziertere und teurere Personalbeschaffung oft nicht ausgleichen. Darüber hinaus können zusätzliche Ressourcen für die Schulung und Motivation des Teams erforderlich sein. Unter bestimmten Umständen scheint es auf dem Arbeitsmarkt unmöglich zu sein, ein vollwertiges Scrum-Team zu beschäftigen.
Abschluss
Was auch immer in der Softwareentwicklung getan wird, es dient der besseren Effizienz. Die Methoden zur Entwicklung von Softwareprodukten sind da keine Ausnahme. Die traditionelle lineare Methodik (Wasserfall) ist nach wie vor für grosse Projekte mit unbegrenztem Zeitrahmen geeignet. Aber die Schönheit der agilen Methoden beschäftigt immer mehr kleine und mittelgrosse Softwareteams.
Sowohl Kanban als auch Scrum spiegeln die oben beschriebene agile Philosophie im Hinblick auf innovative und effiziente Arbeitsabläufe wider, die zur Entwicklung von Softwareprodukten beitragen. Kanban ist einfacher zu übernehmen, während Scrum revolutionärer ist. Kanban ist weniger radikal, um den Übergang von einem linearen Paradigma zu einem agilen Paradigma zu ermöglichen. Scrum bietet eine äusserst kundenorientierte Vision des Entwicklungsprozesses, bei dem sich recht kompakte Entwicklungsteams von Sprint zu Sprint bewegen.
Beide oben genannten Methoden zur Entwicklung von Softwareprodukten haben ihre spezifischen Vor- und Nachteile, aber die agile Philosophie, die im Hintergrund steht, ermöglicht es Softwareentwicklungsunternehmen und ihren Kunden, von den verbesserten Arbeitsabläufen stark zu profitieren. Dies ist für die kundenspezifischen Softwareentwicklungsdienste, die von modernen Softwareanbietern angeboten werden, von entscheidender Bedeutung.
Kontaktieren Sie uns noch heute, damit Ihr Projekt den besten agilen Praktiken von heute entspricht. Unsere professionellen Projektmanager können Ihren Entwicklungsprozess durch die individuell gewählte agile Methodik etablieren, die am besten zu Ihrem Projekt passt.
