Lösungen für Entwicklung – 100% zielgerichtet

Entwicklung nach dem V-Modell

Ursprünglich für die Software-Entwicklung konzipiert, ähnelt das V-Modell dem Wasserfallmodell in Bezug auf Phasen, die gebildet werden. Das V-Modell definiert darüber hinaus zu den Entwicklungsphasen noch Testphasen, die eine Qualitätssicherung darstellen, da sie den einzelnen Entwicklungsphasen entsprechende Testprozesse gegenüberstellen. In der Regel wird auf der linken Seite mit einer fachlichen bzw. funktionalen Spezifikation angefangen, die dann im Verlauf immer weiter detailliert und technischer spezifiziert wird. Unten angekommen, wird die Implementierung gestartet, so dass im Anschluss auf der rechten Seite des V mit den entsprechenden Tests jede Entwicklungsebene abgeschlossen werden kann. Somit sind in V-Form Entwicklungsphasen direkt Testphasen gegenübergestellt. Eines der größten Einsatzgebiete des V-Modells ist nach wie vor die Automobilindustrie.

Agile Methoden: Kanban

Kanban (‚Signalkarte‘ [kan ‚Signal‘, ban ‚Karte‘]) ist eine der agilen Entwicklungsmethoden, die neben den bekannten Karten folgende Kernpraktiken vereint:

• Visualisierung des Workflows
  Nötige Prozessschritte werden auf einem (Kanban-)Board dargestellt. Genauer wird die Kette der Wertschöpfung bzw. der Fluss der Arbeit als Spalten innerhalb des Boards repräsentiert. Auf (Kartei-)Karten wiederum – oft auch als Klebezettel – werden vereinzelte Aufgaben festgehalten und in den Spalten zu Arbeitspaketen organisiert. Die Aufgaben (im Kontext von Kanban auch Tickets genannt) wandern im Laufe der Zeit von links nach rechts durch die Spalten bzw. Prozessschritte auf dem Kanban-Board.
• Begrenzung der angefangenen Arbeit
  Innerhalb einer Spalte ist die Anzahl der Tickets (die in gleichzeitig in Arbeit sind) limitiert. So wird die angefangene Arbeit (im Kontext von Kanban WiP – also work in progress) begrenzt. Dieses System hat zwei Vorteile: erstens entsteht ein “Pull-Prinzip”, so dass jede Station sich die Arbeit von der Vorigen abholen muss. Zweitens wird durch dieses Vorgehen verhindert, dass nachfolgende Stationen überschüttet werden mit Arbeit. Auch können so eventuelle Bottlenecks festgestellt werden.
• Messung und Steuerung des Workflows
  Für die Identifizierung von Bottlenecks (Engpässe) werden Key Performance Indicators (KPI) festgelegt. Als Beispiel zum Messen der Längen von Warteschlangen, Zykluszeit oder Durchsatz, um festzustellen, wie gut die Arbeit organisiert ist. So wird festgestellt, wo der Fluss der Arbeit Schwächen vorweist, wo man noch etwas verbessern kann und welche Versprechen man an die Partner geben kann, für die man arbeitet. Neben der Verlässlichkeit wird so auch die Planungssicherheit verbessert.
• Mache Explizität der Regeln für Prozesse
  Es müssen für alle Beteiligten die Rahmenbedingungen eines Kanban-Boards klar definiert werden. Beispielsweise, wann eine Aufgabe “fertig” ist, was die einzelnen Spalten repräsentieren und unter welchen Bedingungen man sich das nächste Ticket selektiert.
• Implementation von Feedbackzyklen
  In vorher definierten Terminen wird das Team zu Feedback Runden zusammengeholt. Hierzu zählen folgende Varianten:
  • Operation-Reviews:
    Es findet eine objektive Betrachtung der Aktivitäten statt.
  • Retrospektiven:
    Die Zusammenarbeit wird rückblickend betrachten – auch zwischenmenschlich.
  • Standup-Meetings:
    Es erfolgt eine kurze Besprechung bzgl. bevorstehender Aufgaben oder Blockaden.
• Verwendung von Modellen
  Ein Modell ist die Vereinfachung von etwas Realem und erlaubt im Kontext von Kanban das Erkennen von Potentialen zur Verbesserung. Modelle stammen aus verschiedenen Theorien und können beispielsweise mit abgeleiteten Praxisversuchen helfen ein besseres Prozessverständnis zu erlangen und mehr Effektivität und Effizienz zu erreichen.

Agile Methoden: Scrum

Scrum verkörpert die Werte der agilen Software-Entwicklung, die im agilen Manifest von Ken Schwaber, Jeff Sutherland und anderen formuliert wurden:

1. Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.
2. Funktionierende Software ist wichtiger als umfassende Dokumentation.
3. Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen.
4. Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans.

Im Unterschied zu Kanban ist der Scrum Prozess in der Regel zyklusbasiert mit festgelegten Zyklen. Hierbei wird am Anfang eines Zyklus der Arbeitsvorrat (Backlog) durch den Product Owner zu einem Sprint (Zyklus) zusammengestellt. Im nächsten Schritt werden diese Stories nun durch die Entwickler bewertet und qualifiziert. In der Folge werden so viele Stories für den Sprint geplant, wie theoretisch umsetzbar sind durch das Team. Nach dem formalen Sprintstart ist es im Scrum oft verpönt, Änderungen am Sprintumfang vorzunehmen. Am Sprintende stehen neben Retrospektive zur Verbesserung des Prozesses auch das fertige (erweiterte) Produkt, welches das Ziel hat lauffähig zu sein.

Es gibt nun unzählige Erweiterungen und Abwandlungen des ursprünglichen Scrum Prozesses, wobei die Grundregeln meistens unangetastet bleiben. In großen Software-Entwicklungsteams beobachtet man häufig auch Gamification (siehe Videos links), um sich besser mit Produkt und der Entwicklung identifizieren zu können.