Seite 2: LDM-Prinzipien

Inhaltsverzeichnis

1. Liefere so schnell wie möglich

Beim Modell ersetzt die agile Priorisierung eines Backlogs die klassische, detaillierte Planung für alle Ressourcen. Die Aufgaben werden nicht im Voraus durch den Projektleiter zugewiesen, sondern durch das Team selbstständig in den nächsten Workflow-Schritt gezogen (Pull statt Push) (Abb. 2). Das Hauptaugenmerk liegt dabei auf der Maximierung des Durchsatzes.

Die Limitierung von Arbeitspaketen in den Workflow-Schritten verhindert, dass in frühen Schritten mehr Zwischenprodukte erzeugt werden, als sich in späteren verarbeiten lassen. Angefangene Aufgaben, die Tickets, sind erst fertigzustellen, bevor neue begonnen werden, und jedes Teammitglied ist dafür verantwortlich, dass die Bearbeitung nicht ins Stocken gerät. Für die zu optimierende Cycle Time gibt es keine Pause oder Unterbrechung. Wenn ein Ticket zum Beispiel durch Warten auf Kunden-Feedback blockiert ist, läuft die Zeit trotzdem weiter. Ändert ein Entwickler die Codebasis, ist er so lange für das Ticket verantwortlich, bis die Änderung erfolgreich durch die Continuous-Integration-Tool-Kette validiert wurde. Bis der Fehler behoben ist, dürfen keine weiteren Änderungen gemacht werden.

Diese Vorgehensweise erlaubt eine tägliche Lieferung an den Kunden früh im Entwicklungsprozess. Eine ausgewählte Version der Software wird durch einen Smoke-Test validiert und mit dem Testergebnis ausgeliefert. Der Zustand der Software ist für den Kunden so immer sowohl transparent als auch greifbar und ermöglicht es ihm, Feedback zu geben, um Spezifikationen und Implementierung kontinuierlich zu verbessern.

2. Qualität inklusive

Die Definition of Done (DoD) ist entscheidend für die Qualitätssicherung und wird vom Team zu Beginn des Entwicklungsprozesses festgelegt. Sie legt fest, welche Schritte zur Implementierung einer User Story gehören, beispielsweise bei der Einarbeitung von Änderungen. Letztere sind ganzheitlich durchzuführen, zu dokumentieren und durch Reviews abzusichern. Bei der Übergabe einer Änderung ans Testteam muss neu erstellter und geänderter Code eine Vielzahl von Unit-Tests absolviert haben, die der Entwickler zu erstellen hat. Die Erwartung dabei ist, dass eine Änderung bei Übergabe keine Fehler mehr aufweist.

Das soll sicherstellen, dass Fehler so früh wie möglich aufgedeckt werden. Je höher der Automatisierungsgrad, desto schneller sollten sich Fehler und Regressionen finden lassen. Die Tests werden je nach Phase des Projekts und Art der Lieferung skaliert:

• tägliche Smoke-Tests für die Tages-Lieferung,
• fokussiertes Testen für Engineering Drops,
• Integrationstests für wichtige Meilenstein-Lieferungen,
• langlaufende Validierungstests für den Produktionsstart und
• kontinuierliche Unit-Tests als Teil von Continuous Integration.

Die Automatisierung wird durch das Continuous-Integration-Tool Jenkins gesteuert. Angebundene Test-Frameworks erlauben es, Interaktionen zu simulieren und die Ergebnisse dem Tester und Entwickler aufzubereiten. Der Entwickler bekommt direkte Rückmeldung zu statischer Codeanalyse und Unit-Tests sowie Testabdeckung. Die Auswertung durch SonarQube ist für den Architekten, Projektleiter und Testmanager eine wertvolle Unterstützung. Metriken zu Lint-Warnungen, Duplizierung und Komplexität sowie das SIG-Maintenance-Modell helfen, den Gesamtüberblick zu bewahren.

Die Weichen für erfolgreiches Testen werden bereits am Anfang gestellt. Die Beachtung von Design For Testability (DFT) und Test Driven Devlopment (TDD) mit Refactoring führen zu besserem Design und stabiler Architektur.

3. Just-in-time-Entscheidungen

In jedem langlaufenden Softwareprojekt wird der anfängliche Plan durch veränderte Anforderungen und Rahmenbedingungen schnell obsolet. Er ist daher über die gesamte Laufzeit fortwährend anzupassen. Zu Anfang einer Iteration müssen alle Anforderungen für den Inhalt abgestimmt sein, damit die Story-Teams die Feinplanung vornehmen können. Details zu Anforderungen zukünftiger Iterationen können noch unscharf sein, um flexibel auf Änderungen reagieren zu können. Annahmen, speziell die zu Beginn des Projekts getroffenen, sind oft zu korrigieren. Festlegungen zu Architektur und Design sollten möglichst nur soweit getroffen werden, wie es für die nächsten Schritte notwendig ist. Ziel ist es, teure Sackgassen zu vermeiden und sich Möglichkeiten offen zu halten, um das System anzupassen, wenn gesicherte Informationen verfügbar sind. Optimierungen erfolgen so spät wie möglich. Die Softwarearchitektur und Testabdeckung müssen regelmäßiges Refactoring unterstützen.

Nicht alle Zulieferer arbeiten iterativ. Werden ihre aktualisierten Komponenten integriert, muss eine Stabilisierungsphase erfolgen. Hierfür werden alle Tickets priorisiert, aber nicht nach Stufen, sondern in einer eindeutigen Rangordnung – dem Ticket-Backlog. Die geplante Grenze zur nächsten Iteration, und damit die Anzahl der abzuarbeitenden Tickets, ermittelt man anhand von Metriken wie der Cycle Time und dem Inflow neuer Tickets. Ein Ticket höherer Priorität kann es erfordern, den Inhalt einer Iteration anzupassen.

4. Verschwendung eliminieren

Um die Ressourcen des Teams so sinnvoll wie möglich einzusetzen, konzentriert sich das Team stets auf das aktuell benötigte Feature-Set. Work-in-Progress-Limits (WiP) für jedes Teammitglied und die Workflow-Schritte verhindern, dass an zu vielen Dingen gleichzeitig gearbeitet wird. Wechselzeiten, Verluste durch Übergaben und die Fehlerquote werden reduziert. Auch halbfertige Funktionalitäten, die zum Zeitpunkt der Lieferung als Verschwendung anzusehen sind, werden so vermieden.

Ganz vermeiden lassen sich Fehler jedoch nie. Daher ist der Arbeitsprozess dahingehend angepasst, Fehler so früh wie möglich zu identifizieren, um die Entwicklung fehlerhafter Funktionen und die dabei verlorene Zeit zu minimieren. Ebenso wichtig ist es, sich von nicht mehr benötigten Features zu trennen. Over-Engineering und vorauseilende, auf Annahmen basierende Implementierung sind zu vermeiden. Das verkürzt nicht nur die Entwicklungszeit, sondern reduziert auch Wartungs- und Testaufwand.

5. Das Team stärken

Basis der Teamarbeit sind Selbstbestimmung, Motivation und Ausrichtung auf ein gemeinsames Ziel. Der Mensch mit seinen Fähigkeiten steht im Vordergrund, die Ressource Arbeitskraft tritt in den Hintergrund. Das Team gestaltet den Entwicklungsprozess durch gemeinsame Retrospektiven weitgehend selbst.

Die Teamkommunikation wird durch die Visualisierung des Workflows auf einem magnetischen Board an der Wand unterstützt (Abb. 5).

Um auch standortübergreifend arbeiten zu können, werden die lokalen Boards mit einer elektronischen Übersicht synchronisiert. Die Projektmanager stellen priorisierte Arbeitspakete in der To-do-Spalte zur Verfügung. Der nächste freie Mitarbeiter eines Story-Teams zieht sich das Ticket (Pull) und kennzeichnet es mit einem seiner zwei Magneten (persönliches WiP-Limit). Ist kein Magnet mehr frei, sind Tickets zuerst abzuschließen oder an einen Kollegen zu übergeben (Abb. 6).

Die lokalen Teams behalten die Übersicht am physikalischen Board. Bei offenen Fragen oder sogenannten Findings wird das Ticket eigenverantwortlich mit einem "Talk about me"-Magneten versehen. Während des Daily-Standup-Meetings spricht das Team die markierten Tickets an, detaillierte Besprechungen erfolgen im Anschluss in kleinerem Kreis.

In der Feature-Entwicklung formieren sich dynamisch die Story-Teams, die sich um die Abarbeitung aller Tasks zu einer User Story kümmern. Die aus dem Scrum entlehnten Stories helfen dem Team, auch in Kanban den Überblick zu behalten. Das Team ist interdisziplinär besetzt mit Softwarearchitekten, Testern und Entwicklern. Im Daily-Standup-Meeting berichtet abwechselnd eines der Teammitglieder über den aktuellen Stand der Story. Auf diese Weise werden alle Teammitglieder gleichermaßen eingebunden.