Stellen Sie sich das vor: Feste Agile

Von Eelco Rustenburg und Maarten Winkels Stellen Sie sich Folgendes vor: Sie betreten einen Raum und finden an einem Konferenztisch zwei mürrisch dreinblickende Männer vor, die mit verschränkten Armen zu Ihnen sprechen: "Wir wollen einen festen Preis, einen festen Termin und eine feste Funktionalität!" Stellen Sie sich nun vor, Sie wären der Manager eines Softwareentwicklungsunternehmens, das sich für Agile einsetzt, was würden Sie tun? Der Konflikt ist leicht zu erkennen: Agile schreibt vor, den Wandel zu begrüßen und auf eine strenge Planung zu verzichten. Wie könnten Sie mit diesem Unterschied umgehen? Es braucht einen besonderen Menschen, um einen eckigen Pflock in ein rundes Loch zu stecken. Ausgangspunkt Bevor Sie sagen, dass sie völlig verrückt sind, weil sie das Unmögliche verlangen, beschließen Sie, sich die Anfrage genauer anzusehen und zu fragen, warum sie glauben, dass es machbar und sogar erwünscht ist, es auf diese Weise anzugehen. Sie sagen Ihnen, dass es sich um ein relativ kleines Projekt handelt, vielleicht zwei Monate, und dass sie bereits ähnliche Projekte durchgeführt haben, also wissen, worauf sie sich einlassen. Sie wollen "so viel" in "dieser Zeit" für "diesen Preis". Sie wollen sicher sein, dass alle Entwicklungsrisiken abgedeckt sind, und es macht ihnen nichts aus, dafür etwas mehr zu bezahlen. Sie versuchen, ihre Situation zu klären und ihnen zu zeigen, wie Sie ihnen helfen können, und ehe Sie sich versehen, skizzieren Sie ein einfaches Bild auf der weißen Tafel. "Das ist es, was Sie hier sehen", sagen Sie ihnen. "Die horizontale Achse ist die Zeit, die vertikale Achse ist die Funktionalität. Sie wissen, was Sie erreichen wollen und wann Sie es erreichen wollen." Sie zeichnen die dreieckige Form und erklären ihnen die Geschwindigkeit. "Mit Ihrem Wissen über den Problembereich und meinem technischen Know-how können wir ein Team unserer Mitarbeiter befähigen, genau das zu erreichen." Aber das ist nicht genug. Sie wollen sie von den Vorteilen eines agilen Ansatzes überzeugen. Iterationen "Wir entwickeln Software gerne iterativ und evolutionär", beginnen Sie zu erklären. "Wir werden Ihnen am Ende jeder Iteration eine funktionierende Software zeigen, die es Ihnen ermöglicht, zu Zwischenzeitpunkten zu steuern." Sie unterteilen die Zeitleiste in vier gleiche Teile und beginnen, einen Pfeil zu zeichnen, der vom optimalen Geschwindigkeitspfad leicht nach oben zeigt. "Sehen Sie", fahren Sie fort, "wenn unser Team aus irgendeinem Grund nicht so gut abschneidet wie geplant, wird die noch zu liefernde Funktionalität am Ende einer Iteration größer sein als geplant. An einem solchen Punkt können wir Ihnen helfen, die Frist für das Projekt einzuhalten, indem wir zum Beispiel einige unserer Qualitätsstandards fallen lassen oder die Komplexität einiger Anforderungen reduzieren." Vom Endpunkt des letzten Pfeils aus zeichnen Sie einen Pfeil, der nach unten zum Punkt der Deadline führt. "Auf diese Weise stellen wir sicher, dass Sie zum Abgabetermin über eine funktionierende Software verfügen, auch wenn sie nicht ganz unseren Qualitätsstandards entspricht oder nicht alle Funktionen enthält, die Sie haben sollten." Sie verlängern den ersten Pfeil, um den Zeitplan zu erreichen. "Nach Ablauf der Frist kann unser Team weiter an den offenen Fragen arbeiten, um das Projekt abzuschließen und die erforderliche Qualität zu erreichen. Gemäß unserem Festpreisvertrag haben Sie natürlich Anspruch auf eine Vertragsstrafe für die verspätete Lieferung." Priorisiertes Backlog Einer der Männer auf der anderen Seite des Tisches beginnt, sich für Ihre Ideen zu erwärmen. Seine Erfahrung mit Festpreisprojekten ist, dass er nach der Anfangsphase keinen Einfluss mehr auf das Projektgeschehen hat und die Fortschrittsberichte der Entwicklung minimal sind. Mit dem Modell, das Sie ihm vorstellen, hat er zu jedem Zeitpunkt Einblick in das Geschehen und kann seine eigenen Prognosen anstellen. "Was müssen wir also Ihrem Team zur Verfügung stellen, um all das zu erreichen?", fragt er. "Nun, natürlich müssen Sie uns sagen, was Sie wollen", beginnen Sie, "aber was wir eigentlich brauchen, ist ein priorisiertes Backlog." Sie erklären ihm, dass die benötigte Funktionalität in "mundgerechte, SMARTe Stücke" aufgeteilt werden muss, um die Entwicklung planen zu können. Diese UserStories sind das Kommunikationsmittel zwischen dem Kunden und dem Entwickler. Jede UserStory sollte einen Teil der erforderlichen Funktionalität enthalten und in sich abgeschlossen sein, so dass der Kunde und der Entwickler sich darauf einigen können, wann sie fertig ist. Um dies zu erreichen, sollte sie spezifisch, messbar, erreichbar, relevant und zeitgebunden sein. "Nachdem wir uns auf die ursprüngliche Liste geeinigt haben", fahren Sie fort, "müssen Sie sie zunächst in die Reihenfolge der wichtigsten Geschichten bringen. Für jede Iteration oder jeden Sprint nimmt unser Team die obersten Storys der Liste und verpflichtet sich, sie innerhalb des Sprints fertigzustellen. Für jede Story wird geschätzt, wie viel Zeit für ihre Fertigstellung benötigt wird. Diese Storys werden dann im Sprint Backlog festgehalten. Nach jeder Iteration zeigt Ihnen das Team, was erreicht wurde, und Sie können sich den Rest des Product Backlogs ansehen." Request For Change Der andere Mann ist immer noch nicht überzeugt. Er ist schon sein ganzes Leben lang Projektmanager und hat schon viele neue Projektmanagementansätze kommen und gehen sehen. "Und wie gehen Sie mit Änderungen um?", fragt er. "Wir wissen bereits, dass sich einige der Anforderungen unserer Kunden während des Projekts ändern werden." Sie verzichten darauf, ihnen zu sagen, dass diese Aussage den gesamten Niedergang des Festpreisansatzes zugunsten des agilen Ansatzes zusammenfasst und kommen auf das Bild zurück, das Sie gezeichnet haben. "Alle Änderungen können während der Entwicklung zum Product Backlog hinzugefügt werden. Sie können entscheiden, wie hoch die relative Priorität im Verhältnis zu anderen Backlog-Elementen ist. Mit jedem neuen Sprint werden neue Elemente aus dem Product Backlog in das neue Sprint Backlog übertragen. In diesem Sinne sind Änderungen nur normale Anforderungen, die noch nicht umgesetzt wurden." Unter der Horizontalen zeichnen Sie einen rechteckigen Bereich, der vom Ursprung ausgeht und dessen eine Kante der Linie der perfekten Geschwindigkeit folgt. "Die Menge an Arbeit, die im Laufe des Projekts hinzugefügt wird, kann so im Modell nachverfolgt werden", erklären Sie. "Das Hinzufügen von Arbeit verlangsamt das Team nicht, so dass die Geschwindigkeit gleich bleibt, aber es beeinflusst die Gesamtzeit, die für den Abschluss des Projekts benötigt wird. Dies lässt sich nachverfolgen, indem Sie die geforderten Änderungen zur negativen Achse der erforderlichen Funktionalität hinzufügen. Fazit "Wir müssen also nur eine nach Prioritäten geordnete Liste aller erforderlichen Funktionen erstellen und den Fortschritt verfolgen, indem wir am Ende eines jeden Sprints an den Demonstrationen teilnehmen?", fasst der erste Mann Ihre Erklärung zusammen. Sie sagen ihm, dass Sie mehrtägige Schulungen anbieten, in denen genau das erklärt wird, und dass er wahrscheinlich der erste ist, der das Wesentliche in so kurzer Zeit begreift. Zufrieden damit, dass Sie heute sowohl etwas gelernt als auch etwas erreicht haben, verlassen Sie das Meeting, . Auf dem Rückweg wird Ihnen klar, dass Agile im Grunde ein ganz natürliches Paradigma ist und dass es nicht mehr als zwei Bilder und eine Handvoll Worte braucht, um seine Kernprinzipien jedem klugen Menschen zu erklären.