Wir arbeiten chaotisch

... und dabei immer in Ihrem Sinne

Veröffentlicht am: 02. August 2021

Chaotisch arbeiten? Das behauptet doch keiner von sich! Doch, denn wir bezeichnen unsere Art des Arbeitens ganz bewusst auch mal als „chaotisch“- Doch nicht ganz im Sinne der Definition des Dudens „verworren, ungeordnet; nicht willens oder nicht fähig, Ordnung zu halten“.

Vielmehr geben wir unserer täglichen Arbeit Raum für Chaos. Die meiste Zeit und Energie verwenden wir für die geplanten Dinge, die unmittelbar auf unser Projektziel einzahlen. Doch da wir wissen, dass wir keine Maschinen sind, dass Dinge einfach mal passieren und dass es etwas Chaos braucht, um Dinge auszuprobieren und auf diesem Wege Neues zu entdecken, lassen wir unserer Arbeit einen Freiraum für eben dieses Chaos. So fördern wir neue Ideen, neue Ansätze und neue Lösungswege.

Gleichzeitig arbeiten wir agil und kundenindividuell, aber nicht nach einem festgelegtem Schema F, in das wir jeden Kunden und jedes Projekt reinpressen. Vielmehr sind es Ideen, Ansätze und Auszüge verschiedener Modelle aus denen wir uns bedienen: Ob klassisch nach Wasserfall oder dem V-Modell oder agil nach Extreme Programming, Scrum oder Kanban – je nach Ihren Strukturen, Vorlieben und Anforderungen setzen wir Ihr Projekt zielgerichtet mit der passenden Methodik um.

Vorgehensmodelle in der Softwareentwicklung

Beginnen wir mit der theoretischen Basis unserer Arbeit und den Vorgehensmodellen in der Softwareentwicklung. Vorgehensmodelle organisieren Prozesse in festgelegte und strukturierte Abschnitte und zugehörige Aktivitäten. Man unterscheidet hierbei zwei Arten von Methoden: die klassischen und die agilen. Die klassischen Methoden sind sequenziell aufgebaut. Ein Projekt wird in mehrere Sequenzen aufgeteilt, in denen bestimmte Ergebnisse erbracht werden müssen. Ist eine Sequenz abgeschlossen, kann die nächste bearbeitet werden. Die agilen Methoden dagegen richten sich nicht nach vorab definierten Abschnitten. Bei der agilen Arbeit kann man kurzfristig auf Änderungen reagieren. Das Ziel agiler Methoden ist ein flexibler und schlanker Entwicklungsprozess. Gerade in der Softwareentwicklung ist die Arbeit nach agilen Methoden von Vorteil, denn der Auftraggebende erlangt bereits während der Entwicklung erste Blicke auf die Software und kann dabei genauer formulieren, wie das Ergebnis aussehen soll.

In diesem Beitrag gehen wir auf fünf unterschiedliche Vorgehensmodelle, die häufig in der Softwareentwicklung angewendet werden, ein. Wir starten mit dem sehr strikt geregelten Wasserfall-Modell als Extrembeispiel der klassischen Methoden. Darauf folgt das etwas weniger strenge V-Modell. Im Anschluss beleuchten wir die Mutter der agilen Methoden: das Extreme Programming (XP). Darauf folgt die Scrum Methode und zum Abschluss bieten wir einen Überblick über Kanban.

Das Wasserfall-Modell

Die Wasserfall-Methode ist eine klassische Methode und zeichnet sich durch ein lineares Vorgehen aus. Hierbei werden zu Beginn des Projektes alle Anforderungen an die Software formuliert. Das gesamte Projekt wird anschließend auf Basis der Anforderungen in einzelne aufeinander aufbauende Phasen eingeteilt. Jede Phase muss abgeschlossen sein, damit die nächste Phase gestartet werden kann. Bei einer Änderung, die sich während des Projektes ergibt, muss in eine vorherige Phase gewechselt werden, um diese Änderung durchzuführen. Je später eine Anforderung an das Projekt geändert werden muss und je gravierender die Änderung ausfällt, desto höher werden die Kosten für diese Änderung.

Da bei dem Wasserfall-Modell der Auftraggebende erst sehr spät einen Einblick in die Software bekommt, ist es hierbei besonders wichtig, zu Beginn des Projektes alle Anforderungen schriftlich zu dokumentieren und ausführliche Richtlinien zu erstellen.

Das Wasserfall-Modell eignet sich für Projekte, in denen sich Anforderungen, Leistungen und Abläufe bereits in der Planungsphase präzise beschreiben lassen und die sich auch im Laufe der Entwicklung möglichst nicht ändern.

Das V-Modell

Ähnlich wie das Wasserfall-Modell wird nach dem V-Modell der Prozess der Softwareentwicklung in aufeinander aufbauenden Phasen organisiert. Hierbei wird mit einer funktionalen Spezifikation begonnen, die immer detaillierter zur technischen Spezifikation und anschließend zur Implementierungsgrundlage ausgebaut wird. Dieser Teil bildet die linke Seite eines Vs ab und ist nahezu gleich wie bei dem Wasserfall-Modell. Die Spitze des Vs beschreibt die Implementierung der Software. Anschließend wird die implementierte Software gegen die vorher definierten Spezifikationen getestet. Der Teil des Testens bildet die rechte Seite des Vs ab. Jeder Spezifikationsphase steht eine entsprechende Testphase gegenüber, wodurch sich die namensgebende V-Form ergibt.

Extreme Programming (XP)

Extreme Programming (XP) ist eine sehr agile Methode, eignet sich für Projekte mit wagen oder sich häufig ändernden Anforderungen und stellt die Menschen (Entwickler-Team und Kunden) in den Vordergrund. Da sich häufig zu Beginn eines Projektes noch nicht sämtliche Anforderungen präzise benennen lassen, setzt diese Methode auf das ständige Anpassen der Anforderungen im laufenden Projekt und auf eine ständige Kommunikation zwischen Entwickler, Management und Kunden.

Das Prinzip von XP setzt auf klar kommunizierte Werte, Prinzipien und Techniken. Die Werte lauten Einfachheit (eine einfache Lösung ist vorzuziehen), offene Kommunikation, ehrliches Feedback, respektvoller Umgang und Mut, denn es müssen auch unangenehme Dinge umgehend angesprochen werden. Dazu kommen die 14 Prinzipien Menschlichkeit, Wirtschaftlichkeit, beidseitiger Vorteil, Selbstgleichheit, Verbesserungen, Vielfältigkeit, Reflexion, Fluss, Fehlschläge hinnehmen, Gelegenheiten wahrnehmen, Qualität, Redundanzen vermeiden, kleine Schritte, akzeptierte Verantwortung. Zu den Techniken zählen stetige Reviews, fortwährendes Testen, kontinuierliches Design und Redesign, ein nachhaltiges Tempo sowie stetiges Feedback, kurze Releasezyklen, die fortlaufende Integration und die starke Einbeziehung des Auftraggebenden.

Zum Vorgehen: Die Kundenanforderungen werden in Form von User Storys auf Story Cards festgehalten. Wann was umgesetzt wird, wird in den vor einer Iteration (Entwicklungsphase) stattfindenden Planungstreffen festgelegt. Innerhalb einer Iteration stimmt sich das Entwicklungsteam in täglichen Meetings ab. Die entstehende Software wird ständig getestet, um Fehler aufzudecken und auf diese reagieren zu können. So können sich Inhalt und Ziel einer Iteration jederzeit ändern.

Nach dem Abschluss einer Entwicklungsphase schauen sich Vertreter des Managements und des Auftraggebenden die Software in ihrem aktuellen Entwicklungsstatus an und geben Feedback. Nun können auch neue Prioritäten gesetzt oder weitere Anforderungen definiert werden.

Scrum

Scrum ist ebenfalls eine agile Methode und legt den Fokus auf die Selbstorganisation aller Teammitglieder. Dabei wird die Software iterativ und inkrementell entwickelt. Es gibt einen Scrum-Master, der während des Projektes auf die Einhaltung der Scrum-Regeln achtet, etwaige Hindernisse beseitigt und das Team zur Außenwelt hin vertritt, einen Product Owner, der die Anforderungen des Kunden an die Entwicklung verwaltet und während des Projektes als Ansprechpartner für den Kunden fungiert, und das Team, bestehend aus drei bis neun Personen, welches das Projekt umsetzt.

Ein Projekt nach Scrum startet mit der Projektplanung, in der die Rahmenbedingungen definiert werden. Das Projekt selbst wird in mehrere Sprints unterteilt. Ein Sprint dauert eine bis vier Wochen. Alle Sprints innerhalb eines Projektes sind dabei gleich lang.

Das Projektziel wird in kleinere Items (Aufgaben) geteilt, im Product-Backlog gesammelt und mit einer Priorisierung versehen. Zu Beginn eines Sprints findet ein Planungsmeeting mit dem Product Owner, dem Scrum Master und dem Team statt, in dem für die höchsten priorisierten Items der jeweilige Aufwand geschätzt wird und die Items gemäß Priorisierung in den Sprint-Backlog gezogen werden. Während des Sprints gibt es ein tägliches Meeting von maximal 15 Minuten. Hierbei beantwortet jedes Teammitglied die drei Fragen „Was habe ich gestern getan, um das Ziel des Sprints zu erreichen?“, „Was werde ich heute tun, um das Ziel des Sprints zu erreichen?“ und „Sehe ich ein Hindernis, was mich oder das Team davon abhält, das Ziel des Sprints zu erreichen?“. Der Sprint endet mit einer Retrospektive, in der das Team die Ergebnisse dem Product Owner und allen weiteren Stakeholdern präsentiert. Anschließend geben alle Anwesenden Feedback zu dem Ergebnis. Jede dabei gefundene Verbesserung fließt wiederum in das Planungsmeeting des nächsten Sprints ein.

Mit jedem neuen Sprint nähert sich die Software dem Ziel an. Am Ende entscheidet der Auftraggebende, wann sie in seinen Augen fertig und das Projekt somit abgeschlossen ist. Bis dahin kann er Änderungswünsche äußern und trägt so zur Weiterentwicklung des Produktes bei.

Kanban

Kanban beschreibt eine Art des Arbeitsmanagements nach der Pull-Methode und orientiert sich an vier Grundprinzipien und sechs Kernpraktiken. Die Grundprinzipien lauten: Beginne mit dem, was Du gerade tust. Verfolge inkrementelle, evolutionäre Veränderung. Berücksichtige bestehende Prozesse, Rollen und Verantwortlichkeiten. Ermutige zu Führungsverantwortung auf jeder Organisationsebene.

Die Kernpraktiken sind: Visualisiere den Workflow. Begrenze die Menge laufender Arbeit. Miss und steuere den Workflow. Formuliere explizite Prozess-Regeln. Implementiere Feedbackschleifen. Nutze Modelle für die Verbesserung der Zusammenarbeit.

Kanban heißt wörtlich übersetzt „visuelles Signal“. Dieses Signal erschafft man sich durch ein Kanban-Board mit den drei Spalten „To Do“, „In Bearbeitung“ und „Erledigt“. Je nach Struktur können Spalten wie „Feedback“ und „Diese Woche“ hinzukommen. Auf dem Kanban-Board kann jedes Teammitglied rechtzeitig sehen, ob Engpässe aufkommen, und sorgt so gemeinsam für einen reibungslosen Projektablauf. Jedes Aufgabenelement wird in Form einer Karte dargestellt, einer zuständigen Person zugewiesen und kann bei Bedarf mit einem Fälligkeitsdatum versehen werden. Die Größe der Aufgabe, die auf einer Karte festgehalten wird, sollte nicht zu groß, aber auch nicht zu klein sein. Die Teammitglieder nehmen sich selbstständig ihre Aufgaben aus der To-Do-Spalte und ziehen sie zur Bearbeitung in die In-Bearbeitung-Spalte. So ist jederzeit ersichtlich, was gerade bearbeitet wird.

Im Gegensatz zu Scrum setzt Kanban weder auf feste Rollen (diese bleiben bestehen, wie sie bisher waren) noch auf immer gleiche zeitlich begrenzte Iterationen. Beide Methoden setzen auf ein limitierten Work in Progress, transparente Prozesse und die möglichst schnelle Auslieferung sogenannter Minimal viable Products (MVP).

Unsere 5 Grundsätze, nach denen wir arbeiten:

Die Grundsätze unserer Arbeit basieren auf unseren kommunizierten und gelebten Werten Zuverlässigkeit, Offenheit, Transparenz, Selbstständigkeit, Kreativität, Weiterbildung und Nachhaltigkeit.

Wir arbeiten chaotisch und nicht nach Schema F. Warum? Weil wir flexibel auf Ihre Anfragen und Anforderungen reagieren und uns an Sie, Ihre Arbeit und Ziele anpassen. Unserer Meinung nach gibt es kein Projekt, was ist, wie ein vorheriges – wir sehen genau hin und packen unsere Kompetenzen, Erfahrungen und unser Wissen für Sie in ein stimmiges Gesamtpaket.
Wir arbeiten in Ihrem Sinne. Die grundlegende Strategie und Planung entstehen in Zusammenarbeit mit Ihnen. So definieren wir zum Beispiel im Rahmen unseres Starterpakets das große Projektziel, kleinere Zwischenziele und die Art, wie wir das Ziel erreichen wollen. Anschließend arbeiten wir lösungsorientiert und kreativ an Ihrem Projekt.
Wir arbeiten im Team und nehmen Sie gerne dafür als Teil unseres Teams auf, damit Sie verstehen, was wir tun, und an der Entstehung Ihrer Lösung teilhaben können. Denn wir teilen jederzeit unser Wissen mit Ihnen. Wir bieten Ihnen einen festen Ansprechpartner auf unserer Seite und stehen in regelmäßigen Austausch mit Ihnen.
Wir setzen auf Transparenz, Ehrlichkeit und Offenheit. Dazu gehört, dass wir unsere Arbeit Ihnen gegenüber jederzeit transparent gestalten und Ihnen nicht nach dem Mund reden, sondern unsere langjährige Erfahrung in die Bewertung Ihrer Situation einfließen lassen.
Unser Ziel ist eine nachhaltige Lösung. Sie profitieren also jederzeit von unserer langjährigen Erfahrung und davon, dass wir immer am Puls der Zeit bleiben. Denn wir vereinen tiefgehendes Wissen mit neuen Anforderungen, moderner Technik und Trends, die wir vorher hinterfragen. Sie können sich auf uns verlassen.

Lernen Sie uns kennen!

Sie möchten das papierlose Büro umsetzen, die Einführung eines ECM im Kopf oder möchten erstmal Ihre Papierdokumente digitalisieren? Dann vereinbaren Sie für ein erstes Kennenlernen einen Termin mit uns. Wir unterhalten uns im ersten Schritt unverbindlich mit Ihnen über Ihre Anforderungen und machen uns ein Bild davon. Alles weitere werden wir im Anschluss daran mit Ihnen besprechen – sofern Sie Ihr Projekt mit uns umsetzen möchten.