Fertig und unfertig

Von Ken Schwaber und David Starr, Scrum.org.

Januar 2012

Die Bereitstellung eines fertigen Inkrements ist ausschlaggebend für erfolgreiche, agile Softwareentwicklung. Anhand realen und theoretischen Beispielen veranschaulichen die Autoren den Unterschied zwischen der Vorstellung von "Fertig" und der Verwendung von "Fertig" und den Einfluss dieses Unterschieds auf den Erfolg eines Projekts. Die Autoren präsentieren anhand der Beispiele anschließend Tools und Strategien, die Teams bei der Entwicklung einer für sie sinnvollen Definition von "Fertig" unterstützen, sowie Methoden zur Kommunikation der Abhängigkeiten, des Status und der Bedeutung von "Fertig".

Betrifft

Application Lifecycle Management; Team Foundation Server

In diesem Artikel:

• Einführung

• Nicht vorhandene Transparenz in Annas Unternehmen

  • Was vermutet wurde

  • Was tatsächlich geschah

  • Die Lektion

• Technische Schulden bei Nanomedtronics AZ

  • Was vermutet wurde

  • Was tatsächlich geschah

  • Die Lektion

• Verstärkung der technischen Schulden durch mehrere Teams

• Der Freigabeplan der Datum Corporation

  • Was vermutet wurde

  • Was tatsächlich geschah

  • Die Lektion

• Umfangreiche Techniken für die Erreichung von "Fertig"

  • Scrum of Scrums

  • Fortlaufende Integration

• Schlussfolgerung

Scrum ist ein iteratives, inkrementelles agiles Framework. Teams verwenden dieses Framework, um Produkt-Inkremente ("Fertig") oder potenziell nutzbare Softwarefunktionen innerhalb eines Zyklus, auch Sprint genannt, schnell iterativ zu erstellen.

"Fertig" ist ein einfaches, jedoch häufig fehlinterpretiertes Wort. Für die Autoren bedeutet es "beendet", "abgeschlossen" und "zum Abschluss gebracht". Wenn etwas "fertig" ist, stehen keine Arbeitsschritte mehr aus. "Fertig" lässt sich einfach definieren. Ein fertiges Inkrement bereitzustellen gehört jedoch weiterhin zu den grundlegenden und schwer fassbaren Anforderungen von Scrum und Agilität.

Agilität erfordert das Bereitstellen von fertigen, einsatzbereiten Inkrementen funktionsfähiger Software in jedem Sprint. Trotzdem generieren die meisten Scrum- und agilen Teams nur teilweise fertige, unvollständige Inkremente. Wenn ein Scrum-Team gefragt wird, warum Produktrückstandsanforderungen nicht vollständig in einem Sprint fertig gestellt wurden, lautet die Antwort häufig "Uns fehlte die Zeit".

In diesem Dokument werden Fragen in Bezug auf fertige Inkremente anhand von Beispielen echter Fallstudien aus der Scrum-Anfangszeit behandelt. Die Namen und Orte der Beteiligten wurden geändert, die entsprechenden Personen werden sich und ihren unermüdlichen Einsatz jedoch sicher erkennen. Alle in diesem Artikel genannten Sprints sind iterative Zyklen von einem Monat, sofern nicht anders angegeben.

Nicht vorhandene Transparenz in Annas Unternehmen

In Annas Abteilung musste der Eingang der Änderungen von Grundeigentumstiteln automatisiert werden. Das Unternehmen, in dem Anna arbeitete, baute und betrieb Gaspipelines in fast ganz Nordamerika. Annas Abteilung war für die Verarbeitung und Auszahlung von Lizenzgebühren an die Grundeigentümer zuständig, durch deren Land die Pipeline verlegt wurde. Die Titelinformationen gingen in Form von Ausdrucken oder Eigentumswechselanzeigen in Annas Abteilung ein. Da das Volumen immer mehr anstieg, beabsichtigte Anna, die Feeds und den Zahlungsprozess für die Lizenzgebühren zu automatisieren.

Unser Entwicklungsteam schlug vor, das Lizenzgebührensystem für Anna mit Scrum zu entwickeln. So wurde sichergestellt, dass sie jeden Monat eine verwendbare Software begutachten konnte. Außerdem hatte sie das Recht, jeden Monat neu zu entscheiden, welche Schritte das Team als Nächstes ausführen würde.

Am Ende des dritten Sprints hatten wir einen Feed von einer der Provinzen im System und in älteren Daten integriert. Zur Demonstration verwendeten wir eine einfache SQL-Projektmappe. Anna war begeistert, da der Produktrückstand ihrer Mitarbeiter größtenteils von dieser Provinz stammte.

Sie bat uns, ihre Mitarbeiter in SQL zu schulen, damit diese die vom Entwicklungsteam bereitgestellte Software sofort nutzen konnten.

Was meinte sie damit, sie wolle die Software sofort nutzen? Sie hatte den Abschluss eines Sprints als Fertigstellung der Software fehlinterpretiert.

Wir klärten Anna möglichst behutsam auf. Sie reagierte ungehalten. "Was meinen Sie damit, sie ist nicht fertig? Ich habe das erste Inkrement begutachtet, dann das zweite, und jetzt möchte ich die Software einsetzen. Stellen Sie sie bereit, und schulen Sie uns in SQL, damit wir sie verwenden können."

Uns wurde mulmig. Wir erklärten Anna, dass zwar das Softwareinkrement, nicht aber die Software selbst fertig war. Die Software war soweit fertig, um sie Anna zu präsentieren, doch mussten noch einige Probleme behoben werden, bevor sie eingesetzt werden konnte:

• Einige eingehende Datensätze konnte nicht verarbeitet werden. Wir benötigten eine Möglichkeit, um sie zu speichern und zu verwalten, statt sie zu verwerfen.

• Einige Felder in den eingehenden Datensätzen schienen für andere als die dokumentierten Zwecke verwendet worden zu sein. Wie sollten wir mit diesen Feldern verfahren?

• Felder in der vorhandenen Datenbank enthielten Zeiger oder Informationen, die wie Referenzinformationen aussahen. Dieses Phänomen zog sich durch die gesamte Datenbank.

• Beim Ausführen der eingehenden Feeds und anschließender Abfrage der Datenbank stürzte das System mehrmals ab. Anscheinend waren Daten während dieser Abstürze beschädigt worden.

Anna fragte uns, wie lange es dauern würde, bis die Software in ihrem Sinne "fertig" und einsatzbereit wäre. Unserer Einschätzung nach würde es noch zwei Sprints erfordern, bis die Inkremente einsatzbereit wären. Sie gab uns grünes Licht, um die Software für den Einsatz in ihrer Abteilung fertigzustellen. Anschließend bat sie uns um eine Besprechung am nächsten Morgen.

Am nächsten Morgen fanden sich Anna, ihr Vorgesetzter und der Entwicklungsleiter zu der Besprechung ein. Sie brachten ihre Enttäuschung darüber zum Ausdruck, dass die Transparenz, die von uns angekündigt wurde, nicht vorhanden wäre. Ihrer Meinung nach hätten die ungelösten Probleme von uns anders behandelt werden sollen, als nur als Programmfehler erfasst zu werden. Anna und ihre Kollegen waren verunsichert, da der Fortschritt, der aus den an alle Beteiligten ausgegeben Burndownberichten hervorging, falsch war.

Nach der Besprechung lagen folgende Aufgaben vor uns:

1. Die vier Fehler analysieren und beheben.

2. Die ersten drei Inkremente beenden und bereitstellen, sodass sie von Annas Abteilung verwendet werden konnten.

3. Unsere technischen Fähigkeiten verbessern und die Automatisierung testen, sodass das, was wir unter "fertig" verstanden, Annas Definition von "fertig", nämlich sofort vom Unternehmen nutzbar, entsprach.

4. Unsere Methode zur Erfassung von Fehlern ändern, sodass die Anforderung erst als "fertig" betrachtet werden würde, wenn die Fehler korrigiert worden sind.

   Uns wurde gesagt, dass sich hier eine ausgezeichnete Chance böte, unser Wissen zu erweitern, wenn wir alle unsere Lektionen lernten.

Was vermutet wurde

Der Baseline-Plan, den wir für das System entwickelten, repräsentierte das, wovon die Beteiligten und Anna ausgingen. Das Entwicklungsteam berichtete von den Fortschritten, die den Eindruck erweckten, als verliefe die Freigabe nach Plan, und die beteiligten Personen vertrauten diesem Bericht.

Das Entwicklungsteam ging eigentlich davon aus, dass es richtig sei, zu zeigen, dass die Arbeiten planmäßig voranschritten.

Was tatsächlich geschah

Die Geschwindigkeit ist das Maß und der historische Datensatz für die Produktivität eines Entwicklungsteams pro Sprint. Die Geschwindigkeit wird pro Sprint gemessen und zum Herstellen von Produktivitätsmustern verwendet.

Unser Entwicklungsteam benötigte eine nachhaltige Geschwindigkeit von 8 abgeschlossenen Arbeitseinheiten pro Sprint, um den Zeitplan einzuhalten. Wenn unsere Geschwindigkeit durch irgendeinen Umstand auf unter 8 zu verlangsamen drohte, schlossen wir nicht alle Arbeiten an diesen Einheiten ab.

Wir haben Funktionen bereitgestellt, die zufriedenstellend arbeiteten, jedoch noch nicht ausgereift waren, um verwendet zu werden oder darauf aufzubauen. Sie sollten später verbessert werden. Als wir in der Retrospektive die unerledigte Arbeit einschätzten, kamen weitere 14 Arbeitseinheiten hinzu.

Angesichts der Schwierigkeit der anfänglichen Titelfeeds haben wir den gesamten Plan überarbeitet und einen Zeitplan von etwa 20 Monaten veranschlagt. Von Annas Abteilung wurden etwa alle zwei Monate Inkremente freigegeben und so neue Feeds ermöglicht. Durch die neuen automatisierten Feeds konnte der manuelle Gesamtaufwand so deutlich reduziert werden, dass es einem Antiklimax gleichkam, als das System 22 Monate nach dem Beginn der Arbeiten in Betrieb genommen wurde.

Die Lektion

Bei echter Transparenz muss jeder, der das Inkrement vorliegen hat, dieselben Fakten erkennen und auf gleiche Weise interpretieren. Mithilfe einer transparenten Begutachtung des Inkrements hätte Anna Risiken abwägen und die Prognostizierbarkeit steigern können. Da das Inkrement jedoch nicht transparent war, konnte sie nicht effektiv planen.

Zu Beginn des Projekts legte Anna ein Freigabeziel fest. Nach dem ersten Sprint prüfte sie die Fortschritte im Hinblick auf das Ziel, indem sie ein Inkrement begutachtete, das sie für einsatzbereit hielt. Sie traf eine Entscheidung über die im zweiten Sprint auszuführenden Aktivitäten auf Basis des inkrementellen Fortschritts im Hinblick auf das Ziel. Wenn sie unseren Fortschritt für unzureichend gehalten hätte, hätte sie das Projekt abbrechen können.

Am Ende des dritten Sprints glaubte Anna, dass 3/10 der Gesamtentwicklung ausgeführt waren, was offensichtlich falsch war.

Leider hatte wir jedes Inkrement nur soweit bearbeitet, wie erforderlich war, um seine Verwendung zu demonstrieren. Durch die nicht ausgeführten Arbeiten waren die Inkremente für Annas Abteilung unbrauchbar und für die Begutachtung nicht transparent.

Fehlende Transparenz bei der Begutachtung eines Inkrements lässt sich mit einem Thermostat vergleichen, der mit einem kalten, nassen Waschlappen bedeckt wird. Der Thermostat kann die tatsächliche Raumtemperatur nicht erkennen und würde den Heizvorgang fälschlicherweise einleiten, obwohl er eigentlich kühlen sollte.

Ohne transparente Inkremente fehlt den Beteiligten das richtige Verständnis für das, was tatsächlich geschieht, und so führen sie fälschlicherweise Aktionen aus, die nicht sinnvoll sind.

Kurz gesagt, ohne vollständige Transparenz besteht für die Teams keine Möglichkeit mehr zur effektiven Überprüfung und Anpassung.

Technische Schulden bei Nanomedtronics AZ

Technische Schulden bezeichnen die zurückgestellte Arbeit, die ausgeführt werden muss, bevor Software als "fertig" angesehen werden kann. Technische Schulden können viele verschiedene Formen annehmen und können beispielsweise aus einem schlechten Entwurf, Codeduplikaten und ungeprüften Funktionen bestehen. Im folgenden Beispiel werden Ursache und Auswirkungen der technischen Schulden als zurückgestellte Arbeit im Verlauf eines Projekts veranschaulicht.

Nanomedtronics AZ war ein kleines aufstrebendes Softwareunternehmen. In diesem Unternehmen arbeitete ein Scrum-Team an einer neuen Version seines lebenswichtigen Produkts. Es handelte sich um Software für Nano-Roboter zur Reinigung der verstopften Arterien von Patienten, die unter Bluthochdruck leiden.

Was vermutet wurde

Am Anfang seiner Tätigkeit wurde das Team mit der Aufgabe betraut, Produktrückstandselemente auszuwählen, um diese in einem Sprint von einem Monat in fertige Komponenten zu verwandeln (keine Restarbeiten, einsatzbereit, potenziell auslieferbar). Das Entwicklungsteam verfügte über alle notwendigen Fähigkeiten, um die Anforderungen vollständig zu einem fertigen Inkrement zu entwickeln.

Als das Scrum-Team den ersten Sprint begann, kam es zu dem Schluss, dass 80 Arbeitseinheiten innerhalb von 10 Monaten abgeschlossen werden mussten. Entsprechend wählte das Entwicklungsteam pflichtgemäß 8 Arbeitseinheiten pro Sprint aus. Mit lediglich 8 Einheiten pro Sprint wären sie in den vom Unternehmen angesetzten 10 Monaten mit der Arbeit fertig.

Das Entwicklungsteam präsentierte am Ende jedes Sprints ein funktionierendes Inkrement. Allem Anschein nach funktionierte die Scrum-Methode, und Nanomedtronics AZ befand sich im Zeitplan, um sein Produkt wie geplant bereitzustellen.

Was tatsächlich geschah

Doch nur dem Entwicklungsteam war klar, dass jedes bereitgestellte Inkrement tatsächlich einige schlechte Implementierungen, unkritische Fehler, wiederholte Logik und im Allgemeinen unübersichtlichen Code enthielt. Darüber hinaus waren die Inkremente nicht vollständig getestet worden, da das Entwicklungsteam die Tests einstellte, wenn es innerhalb eines Sprints unter Zeitdruck geriet. Das Entwicklungsteam hatte sich verpflichtet, den Zeitplan einzuhalten, und dies ließ sich häufig nur auf Kosten der Qualität erreichen.

Das Team arbeitete hart und entwickelte das Produkt im Laufe der geplanten zehn Monate. Der Kunde war begeistert und darauf vorbereitet, die Software zu implementieren und zu verwenden. Das Entwicklungsteam hatte jedoch 48 Einheiten mit unerledigten Arbeiten angesammelt, die in der folgenden Abbildung als neue technische Schulden dargestellt sind.

Das Team bei Nanomedtronics AZ hatte nicht alle Aktivitäten und Arbeiten berücksichtigt, die wirklich erforderlich gewesen wären, um ein fertiges Produkt zu entwickeln. In der folgenden Liste sind nur einige Punkte aufgeführt, die das Team nicht berücksichtigte. Es gibt noch zahlreiche andere Punkte, die in diese Liste gehören.

• Analyse

• Entwurf

• Abhängigkeitsanalyse

• Leistungstests

• Stabilitätstests

• Umgestaltung

• Immunologische Antworttests

• Integration in die Arbeit anderer Teams, die an einem Produkt arbeiten

• Integrationstests im Hinblick auf die Arbeit anderer Teams, sodass das Inkrement die Gesamtheit aller Ergebnisse des Teams darstellt

• Anmerkungen zu dieser Version

• Internationalisierung im Hinblick auf die sechs Kulturen, in die das Produkt verkauft wird

• Benutzerakzeptanztests

• Regressionstests

• Codeüberprüfungen

Die oben aufgeführten Arbeiten müssen ausgeführt und fertig sein, um bis zum Ende des Sprints ein vollständiges, integriertes Inkrement zu erstellen. Die meisten Entwicklungsteams schließen jedoch nicht alle der oben aufgeführten Arbeiten ab. Sie stellen bei jedem Sprint Arbeiten zurück, die unerledigt bleiben. Dadurch werden Inkremente erstellt, die einen schlechten Entwurf, duplizierten Code, übermäßig komplexe Logik und ungeprüfte Funktionen aufweisen oder in anderer Beziehung nicht fertig sind. So häufen Teams technische Schulden in der Softwareentwicklung an.

Nanomedtronics AZ erfuhr, dass das Produkt zwar alle Funktionen enthielt, die für die Auslieferung an die Kunden erforderlich waren, es jedoch noch mit vielen Fehlern behaftet war und die Verpackungs- und Endbearbeitung fehlte, die für eine tatsächliche Markteinführung erforderlich war. Das Entwicklungsteam hatte versehentlich einen zusätzlichen Arbeitsrückstand geschaffen, dessen Aufholung weitere sechs Monate dauern würde, indem es von einer falschen Geschwindigkeit von 8 Einheiten pro Sprint ausgegangen war.

Für die Unternehmensleitung war eine Wartezeit von sechs Monaten bis zur Auslieferung des Produkts nicht akzeptabel. Daher wurde es mit nicht ausgeführten Restarbeiten nach nur drei Monaten ausgeliefert. Das verlorene Potenzial bestand nicht nur in der dreimonatigen Verzögerung bei der Auslieferung des Produkts, sondern darin, dass neue Funktionen nur zögerlich hinzugefügt werden konnten, da das Entwicklungsteam in künftigen Sprints mit technische Schulden zu kämpfen hatte.

Die Lektion

Technische Schulden verdecken den wahren Fortschritt und verschleiern die Transparenz, die erforderlich ist, damit Produktbesitzer und Projektbeteiligte eine Entscheidung auf empirischer Basis treffen können. Technische Schulden werden getilgt, und zwar entweder in Form eines bewussten Zeitaufwands für die Korrektur technischer Probleme oder in Form von Verlusten aufgrund verzögerter Auslieferung oder Auslieferung mit mangelnder Qualität.

In den meisten Fällen stehen bei der Freigabe von Produkten 50 % unerledigte Arbeiten aus. Entsprechend werden unerledigte Arbeiten als fortlaufende Schulden institutionalisiert. Technische Schulden führen zu Produktzerbrechlichkeit und können den Unternehmen letztendlich negative Entscheidungen aufzwingen, wie die Software neu zu schreiben oder ein Produkt aufzugeben.

Verstärkung der technischen Schulden durch mehrere Teams

Ein Entwicklungsteam muss sorgfältig nur so viel Arbeit auswählen, wie es in einem Sprint erledigen kann. Den Umfang dieser Arbeit kann das Entwicklungsteam durch Erfahrungswerte einschätzen. Dennoch muss ein Team moderne Entwicklungsverfahren wie automatisierte Build- und Regressionstests einsetzen, um möglichst viel zu erreichen. Werden diese Verfahren und Tests nicht eingesetzt, wird das Team beim vierten oder fünften Sprint von manueller Arbeit überrollt.

Angenommen, ein Entwicklungsteam besteht aus drei Programmierern und zwei QA-Spezialisten. Jeden Tag checken die Programmierer Code in das Quellcodesystem ein. Mithilfe von Tests werden Fehler erkannt und an den zuständigen Programmierer weitergeleitet. Zwischen dem Einchecken von Code und dem Erkennen und Melden von Fehlern verstreicht wertvolle Zeit. Während dieser Zeit haben die anderen Programmierer möglicherweise neuen Code in den fehlerhaften Code eingecheckt. Der Aufwand, der erforderlich ist, um das ursprüngliche Problem zu beheben, ist nun größer. Wenn das Entwicklungsteam ein fortlaufendes Build- und Testverfahren implementiert hätte, wäre der Fehler sofort erkannt worden. Die Teammitglieder hätten den Fehler untersuchen, beheben und anschließend mit der Projektarbeit fortfahren können. Zusätzlicher Aufwand und Verluste hätten so vermieden werden können.

Viele Organisationen setzen zur Entwicklung von Software mehr als ein Scrum-Team ein. In diesem Fall wird das im Abschnitt oben beschriebene technische Schuldenproblem deutlich verstärkt. Das Risiko, Code in fehlerhaften Code einzuchecken, ist deutlich höher. Die Kosten für das Korrigieren der zunehmenden Zerbrechlichkeit der Software steigen im Verlauf der Arbeit exponentiell an.

Der Freigabeplan der Datum Corporation

Wir haben kürzlich mit einem anderen Unternehmen, einem Infrastruktursoftwareunternehmen, das wir als Datum Corporation bezeichnen werden, zusammengearbeitet. Die Hauptproduktgruppe beschäftigt über 800 Entwickler, einschließlich 250 Programmierer. Die Entwicklungsinfrastruktur war teilweise automatisiert und teilweise manuell. Durch das Testen wurde die Codierung häufig mehrere Tage verzögert. Zwischen dem Einchecken eines fehlerhaften Codes durch einen Programmierer und der Erkennung und Meldung des Fehlers verstrichen häufig zehn oder mehr Tage.

Um die Komplexität, die so viele Programmierer mit sich bringen, zu minimieren, arbeitete jedes Entwicklungsteam an einer eigenen Codeverzweigung. Die Entwicklungsmanager halfen dabei, die Produktrückstandsanforderungen zu organisieren, um die Abhängigkeiten zu minimieren. Wenn jedes Entwicklungsteam seinen Code jeden Tag in die Hauptcodezeile zusammenführte, ließe sich dadurch der Umfang der möglichen Nacharbeit minimieren.

Das Management war jedoch der Ansicht, dass dieser Ansatz zu viel Zeit in Anspruch nehmen würde. Es beschloss, alle Codeverzweigungen in jedem dritten Sprint in den Stamm zusammenzuführen. Mithilfe von Integrationstests ließen sich alle Fehler finden, die dann behoben werden konnten. Ein Release Candidate wäre am Ende jeden dritten Monats bereit.

Was vermutet wurde

In der folgenden Abbildung wird der geplante Releasezeitplan und -zyklus veranschaulicht.

Der ursprüngliche Plan ging von folgenden Annahmen aus:

• 9 Sprints

• 3 Release Candidates und anschließend eine vollständige Version

• Eine Entwicklungsorganisation bestehend aus 800 Personen

Was tatsächlich geschah

Als der Freigabetermin dieser Organisation nach neun Monatssprints anstand, war das Produkt für die Freigabe nicht bereit. Der sechste Release Candidate wies über 5.000 Fehler und mehr als 2.000 Produktrückstandsanforderungen auf, die nicht abgeschlossen waren. Wir fragten uns, wie das passieren konnte. Jeden dritten Monat wurde ein Release Candidate präsentiert. Auf Nachfrage erfuhren wir, dass die Demonstration auf die Codeverzweigung der einzelnen Entwicklungsteams zurückging. Es hatte keine Integration stattgefunden. Es wurden keine Integrationstests durchgeführt.

Um die Geschwindigkeit beizubehalten, die für den Freigabetermin erforderlich war, hatten die Entwicklungsteams alle Integrationsarbeiten aufgeschoben und so technische Schulden in großem Umfang angehäuft. Das Ergebnis war ein achtmonatige Verzug des geplanten Freigabetermins. Die Wörter "Release Candidate" waren ohne Bedeutung.

Die folgende Abbildung zeigt das tatsächliche Projekt sowie die Zeit, die für die Stabilisierung erforderlich war.

Die Release Candidates verfügten teilweise über funktionierende Funktionen von der Codeverzweigung der einzelnen Teams. Vor der Freigabe waren fünf Monate zur "Stabilisierung" des Produkts erforderlich. Ein besonders gravierender Fehler, der die Bereitstellung mehr verzögerte als andere, war "schlechtes Leistungsverhalten." Dieses Problem wurde bereits im ersten Sprint protokolliert.

Die Lektion

Die verschiedenen Teams, die an der gleichen Software arbeiten, führen ihre Arbeit letztendlich zusammen. Die Software zu integrieren, um ihre Funktionsfähigkeit sicherzustellen, reduziert das Risiko der Integrationen. Dieser Vorgang sollte daher regelmäßig ausgeführt werden.

Mit der Zusammenführung der Arbeit mehrerer Teams zu warten ist verlockend, da sich so die Kosten der Zusammenführung hinauszögern lassen. Die endgültigen Kosten für die Verzögerung erklären sich durch die Anzahl von betroffenen Teams und die Anzahl von Verzweigungen, die integriert werden müssen.

Umfangreiche Techniken für die Erreichung von "Fertig"

Den Status "fertig" über mehrere Teams hinweg zu erreichen ist schwer. Es sind zahlreiche Komplexitäten zu berücksichtigen. Zwischen Teams und Codeverzweigungen bestehen Abhängigkeiten. Obwohl diese umfangreiche Komplexität Kosten mit sich bringt, ist sie dennoch erreichbar und bietet enormen Wert, wenn die Bereitstellung durch synchronisierte Teams im Einklang erfolgt.

Es gibt verschiedene Techniken, die nach unserer Erfahrung bei der Zusammenarbeit mehrerer Teams hilfreich sind.

Scrum of Scrums

Wenn viele Scrum-Teams an demselben Projekt arbeiten, benötigen sie eine Technik, um ihre Arbeit zu koordinieren. Wir haben ein "Scrum of Scrums" empfohlen. Hierbei handelt es sich um ein tägliches Ereignis, das unmittelbar nach der täglichen Scrum-Besprechung der einzelnen Teams abgehalten wird. Zur Scrum of Scrums-Besprechung wird von jedem Team ein Teilnehmer entsandt. Jeder Teamvertreter beschreibt, woran sein Team zurzeit arbeitet. Anschließend erläutert er die für den Folgetag geplanten Aktivitäten des Teams. Auf Basis dieser Informationen versuchen die Vertreter, mögliche erforderliche Nacharbeit, entstehende Abhängigkeiten und Arbeit zu identifizieren, die möglicherweise neu terminiert werden muss.

Die Scrum of Scrums-Besprechung hat sich für viele Organisationen als nützlich erwiesen. Allerdings ist sie unzureichend. Abhängigkeiten und Nacharbeit werden nicht immer erfolgreich identifiziert, da die Probleme nicht bekannt sind, sondern antizipiert werden. Unvorhergesehene Abhängigkeiten führten zu Nacharbeit und nicht bestandenen Tests. Einige Teams verbrachten über 50 % jedes Sprints mit der Arbeit und Nacharbeit an Abhängigkeiten.

Fortlaufende Integration

Extreme Programming (XP) erfordert eine fortlaufende Integration und Integrationstests für die Arbeit eines Teams. Warum sollte diese nicht auf alle Teams ausgedehnt werden? Ob zwei oder fünfzig Teams involviert sind, jedes Team muss am Ende jedes Sprints ein integriertes, Integration getestetes Inkrement vorlegen. Um dies zu erreichen, müssen die Teams ihre Arbeit häufig integrieren. Da jede nicht integrierte Arbeit möglicherweise nicht aufgelöste Abhängigkeiten enthält, stellt die fortlaufende Integration die beste Lösung dar.

Die fortlaufende Integration der gesamten Arbeit ist mit den Lean-Production-Methoden vergleichbar. In den Lean-Production-Fertigungslinien wird die Qualität eines Produkts während des Produktionsverfahrens mithilfe von verschiedenen Techniken bewertet. Wenn Abweichungen oder Qualitätsprobleme auftreten, wird die Fertigungslinie angehalten. Die fortlaufende Integration und Integrationstests bieten die gleichen Techniken für die Softwareproduktentwicklung.

Auch wenn es schwierig ist, empfehlen wir, dass jedes Team und jedes Teammitglied die Codierungsarbeit einstellt, sobald ein fortlaufender Build oder ein Test fehlschlägt. Wird die Arbeit fortgesetzt, wird möglicherweise auf Fehlern aufgesetzt, was zu einer sich allmählich ausbreitenden Wirkung der Fehler führt. Bei Verwendung der fortlaufenden Integration arbeiten die Teams eng zusammen, um Integrationsfehler zu vermeiden. Die Arbeitsgewohnheiten werden verbessert, unnötiger Aufwand wird reduziert, und die Qualität nimmt zu.

Die meisten Organisationen, die das Scrum-Konzept übernehmen, beginnen nicht mit allen technischen Fähigkeiten und Tools, die zum Erstellen eines fertigen Inkrements erforderlich sind. Um fertige Inkremente zu erzielen, muss ein straffes Programm gestartet und verfolgt werden. Gruppen mit weniger als fünfzig Teilnehmern können rasch einen Punkt erreichen, an dem sie ein fertiges Inkrement innerhalb des Sprints abschließen. Organisationen von über fünfhundert Entwicklern benötigen häufig mehrere Jahre, um diesen Punkt zu erreichen.

Unfertige Inkremente führen zu Verlusten und verhindern, dass Teams wirkliche Agilität erreichen. Die tatsächlichen Kosten der nicht abgeschlossenen Arbeit sind jedoch weitaus höher als das Fehlen einer Funktion im Inkrement. Die Kosten enthalten den unnötigen Aufwand der erneuten Planung und Nacharbeit, die notwendig sind, wenn ein Inkrement nicht tatsächlich fertig ist, sowie die Kosten einer niedrigeren Prognostizierbarkeit und eines höheren Risikos.

Viele Organisationen, die die Vorteile der Agilität anstreben, setzen dazu Scrum ein. Die Bereitstellung eines fertigen Inkrements ist ausschlaggebend für erfolgreiche, agile Softwareentwicklung. Die Teams sollten zunächst eine Definition von "fertig" festlegen, die für sie sinnvoll ist, und diese Definition dann im Laufe der Zeit bewusst erweitern. Nur so werden sie wirkliche Agilität erreichen.

Siehe auch

Konzepte

Zusammenarbeit [umgeleitet]

Zusammenarbeit (weiter vertiefen) [umgeleitet]

Erstellen Ihres Backlogs

Bereinigen und Schätzen des Backlogs

Ausführen einer Iteration [umgeleitet]

Fertig stellen einer Iteration [umgeleitet]