Agile Softwareentwicklung: So setzen Sie sie erfolgreich um

Wie Ihr Softwareprojekt läuft, entscheidet darüber, wie teuer es später wird, Ihre Meinung zu ändern. Agile Softwareentwicklung hält diesen Preis niedrig. In einem klassischen Waterfall-Plan bedeutet eine neue Anforderung im vierten Monat einen Change Request und eine neue Schätzung. In Agile nimmt das Team sie in den nächsten Zwei-Wochen-Block auf. Ein paar Meetings und ein neuer Sprint-Plan sorgen dafür, dass die nötigen Features oder Projektänderungen schnell umgesetzt werden, mit nur minimalen Störungen.

Agile Softwareentwicklung baut ein Produkt in kurzen Zyklen, üblicherweise ein bis vier Wochen lang. Jeder Zyklus endet mit etwas, das funktioniert und das Sie ansehen können, sodass sich der Plan mit Ihrem Erkenntnisgewinn anpasst. Der Ansatz passt zu Projekten, deren Anforderungen sich bewegen werden, und er passt schlecht, wenn der Scope vom ersten Tag an durch Vertrag oder Regulierung festgelegt ist.

Dieser Leitfaden erklärt in klaren Worten, was Agile bedeutet, wie es sich im Vergleich zu Waterfall verhält und was Scrum und Kanban wirklich sind. Er zeigt außerdem Tag für Tag, wie zwei Wochen Arbeit aussehen. Wir entwickeln Software selbst auf diese Weise, meist mit einem dedizierten Entwicklungsteam, das in den bestehenden Prozess eines Kunden einsteigt. Die Beispiele hier stammen daher aus Projekten, die wir ausgeliefert haben, nicht aus der Theorie.

Was agile Softwareentwicklung tatsächlich bedeutet

Agile Methodik wird auf Dutzende verschiedene Arten erklärt. Unter allen Frameworks und der Terminologie läuft es auf eine sich wiederholende Gewohnheit hinaus. Das Team baut ein kleines Stück des Produkts, zeigt es den Menschen, die es nutzen werden, und lässt deren Reaktion bestimmen, was als Nächstes kommt. Diese Schleife läuft weiter, bis die Software fertig ist.

Drei Dinge halten diese Gewohnheit zusammen:

• Kurze Zyklen, damit ein Fehlweg zwei Wochen kostet statt ein Jahr
• Etwas Funktionierendes am Ende jedes Zyklus, kein Statusbericht
• Ein Plan, der offen und bewusst aktualisiert wird, mit Ihnen im Raum

Ein Mythos gehört ausgeräumt, bevor wir weitergehen. Agile entfernt das Planen nicht, sondern greift es alle paar Wochen erneut auf, gemessen an dem, was der letzte Zyklus allen gezeigt hat. Teams, die diesen Schritt ganz überspringen, sind nicht agil, sondern einfach unorganisiert, und der Unterschied zeigt sich im dritten Monat.

Was Agile nicht ist:

• Eine Regel, dass Dokumentation optional ist
• Die Erlaubnis, mit dem Bauen zu beginnen, bevor Einigkeit darüber besteht, wie Erfolg aussieht
• Ein Versprechen, dass Deadlines sich verschieben, wann es dem Team passt

Strukturiertes Scoping steht in den meisten unserer Projekte weiterhin am Anfang. Eine Discovery-Phase legt das Ziel, die Nutzer, die Rahmenbedingungen und die grobe Form der Arbeit fest. Agile entscheidet dann, wie diese Form ausgefüllt wird, und akzeptiert, dass sich einige Ihrer frühen Annahmen als falsch erweisen werden.

Was Kunden am meisten schätzen, ist, dass wir keine fertige Spezifikation brauchen, um produktiv zu sein. Viele Unternehmen, die zu uns kommen, wissen genau, welches Ergebnis sie wollen. Die Software, die es liefert, ist die offene Frage, deshalb erarbeiten wir sie gemeinsam im Projektverlauf. Niemand muss Antworten erfinden, nur um ein Dokument zu füllen.

Agile vs. Waterfall: Wann welcher Ansatz sinnvoll ist

Waterfall führt ein Projekt in einer langen Linie durch. Sie stimmen den vollen Scope ab, entwerfen ihn, bauen ihn, testen ihn und veröffentlichen ihn. Jede Phase endet, bevor die nächste beginnt, weshalb Sie funktionierende Software meist erst gegen Ende sehen.

Dieser Ansatz ist nicht unsinnig, und er ist nicht ausgestorben. Öffentliche Festpreis-Ausschreibungen, Sicherheitszertifizierungen und Hardware-Launch-Termine belohnen es alle, die gesamte Antwort im Voraus zu kennen. Was Waterfall schlecht bewältigt, ist Erkenntnisgewinn. Probleme beginnen, wenn etwas, das Sie spät in der Umsetzung lernen, einer Entscheidung vom Anfang widerspricht. Das rückgängig zu machen bedeutet mehr Papierarbeit, einen überarbeiteten Preis und ein unangenehmes Gespräch.

Die Wahl zwischen agiler Softwareentwicklung und Waterfall hängt selten davon ab, welche Methode moderner klingt. Es kommt auf eine Frage an: Wie viel von diesem Produkt kennen Sie wirklich schon? Wenn die ehrliche Antwort fast alles ist, wird Waterfall Ihnen nicht schaden. Wenn die Antwort etwa die Hälfte ist, sparen kurze Zyklen Ihnen Geld.

Werden Sie um eine vollständige Spezifikation gebeten, bevor jemand ein Angebot abgibt? Unser Leitfaden zu Spezifikationen und Projektschätzung zeigt, was dieses Dokument leisten kann und was nicht, und woher die Zahlen darin kommen.

Scrum vs. Kanban: Die zwei Frameworks, von denen Sie hören werden

Agile ist die Idee. Scrum und Kanban sind zwei verbreitete Wege, sie in die Praxis zu bringen, und der größte Teil des Jargons, dem Sie begegnen, gehört zu einem von beiden.

Scrum organisiert Arbeit in festen Zyklen, den Sprints, üblicherweise zwei Wochen lang. Das Team verpflichtet sich am Anfang auf eine Menge von Elementen, prüft das Ergebnis am Ende und wiederholt das Ganze. Es benennt außerdem einige Verantwortlichkeiten, darunter jemanden, der die Prioritäten verantwortet, und jemanden, der den Prozess ehrlich hält. Der offizielle Scrum Guide umfasst etwa ein Dutzend Seiten, was zeigt, wie leichtgewichtig das Framework unter der darauf aufgebauten Industrie wirklich ist.

Kanban lässt den festen Zyklus weg. Die Arbeit liegt auf einem sichtbaren Board, wandert von links nach rechts, während sie fortschreitet, und ein neues Element startet erst, wenn das Team Kapazität dafür hat. Der Kanban Guide ist noch kürzer. Seine zentrale Regel ist eine Obergrenze dafür, wie viele Dinge gleichzeitig in Arbeit sein dürfen, und das ist die Disziplin, die den meisten Teams am schwersten fällt.

Viele Teams fahren eine Mischung aus beidem, und daran ist nichts falsch. Wir nutzen Sprints tendenziell, während ein Produkt gebaut wird, weil ein Zwei-Wochen-Rhythmus allen einen vorhersehbaren Moment gibt, hinzusehen, zu entscheiden und zu korrigieren. Für langlaufende Wartungsarbeit, bei der Tickets eintreffen, wann sie eintreffen, passt ein flussbasiertes Board besser zur Realität.

Wie ein zweiwöchiger Sprint tatsächlich aussieht

Das Wort Sprint klingt nach Hetze, ist es aber nicht. Ein Sprint ist einfach ein festes Zeitfenster mit einem abgestimmten Ziel, und zwei Wochen sind die Länge, auf die sich die meisten Teams einigen. Das bedeutet 10 Arbeitstage, und sie laufen so ab:

• Tag 1 ist Planung. Das Team und die Person, die die Prioritäten verantwortet, vereinbaren, was bis Tag 10 geliefert wird, und schreiben auf, was fertig für jedes Element bedeutet. Alles, was zu vage ist, um es zu testen, wird aufgeteilt oder zurückgegeben.
• Tag 1 bis 10 beginnen alle mit einem kurzen Check-in. Er dauert 15 Minuten, und jede Person beantwortet drei Fragen: was hat sich gestern bewegt, woran arbeite ich heute, was blockiert mich. Das ist kein Statusmeeting für Manager, sondern ein Weg, ein Hindernis am Tag seines Auftretens sichtbar zu machen statt eine Woche später.
• Tag 2 bis 9 sind die Arbeit selbst. Entwickler und Tester arbeiten gleichzeitig statt hintereinander, sodass nichts als fertig gilt, bevor es geprüft wurde. Diese eine Regel verhindert den Stapel ungeprüften Codes, der den letzten Monat eines Waterfall-Projekts in eine Krise verwandelt.
• Tag 10 hält zwei Gespräche. Zuerst zeigt das Team, was tatsächlich funktioniert, auf dem Bildschirm, mit echten Daten. Dann blickt es zurück auf den Prozess und wählt eine Sache aus, die geändert wird.

Teams, die dieses zweite Gespräch überspringen, behalten die Meetings, werden aber nicht besser und betreiben agile Softwareentwicklung damit nur dem Namen nach.

Was ein Sprint von Ihrer Seite braucht

Agile ist kein Weg, Software zu kaufen, ohne aufzupassen. Es braucht ein paar Stunden pro Woche von jemandem auf Ihrer Seite, der Fragen beantworten und Entscheidungen treffen kann. Diese Person muss außerdem jede Demo verfolgen. Geben Sie einem Team einen abwesenden Stakeholder, und der Zyklus dreht sich weiter, während das Produkt abdriftet.

Der Nutzen ist, dass nichts lange verborgen bleibt. Sie sehen alle zwei Wochen Fortschritt und können zu Beginn jedes Zyklus die Richtung ändern. Ein rutschender Zeitplan kündigt sich ebenfalls rechtzeitig an, um darauf zu reagieren. Dieses Feedback wird schärfer, wenn die Arbeit echte Menschen erreicht, und unser Beitrag zum frühen Einbeziehen von Endnutzern beschreibt die praktischen Wege dorthin.

Dieser Rhythmus skaliert weiter, als man erwartet. Im Projekt Justin Alexander haben wir vier separate Websites zu einer Multibrand-Plattform für ein Brautmodenunternehmen zusammengeführt, das über mehr als 1.500 autorisierte Händler verkauft. Zehn Entwickler, drei Projektmanager und vier QA-Engineers arbeiteten in genau diesem Rhythmus auf einem Python- und Django-Stack. Die Website bedient heute über 30.000 Besucher pro Monat.

Agile und MVPs: Die kleinste Version bauen, die Ihnen etwas beibringt

Ein MVP, also ein Minimum Viable Product, ist die kleinste Version Ihrer Idee, mit der echte Nutzer tatsächlich etwas tun können. Kein Prototyp, kein Foliensatz, sondern funktionierende Software mit der einen Aufgabe, für die sie existiert. Ihr Zweck ist, Ihnen zu zeigen, ob Ihre Annahmen stimmen, bevor Sie das restliche Budget binden.

Agile und ein MVP passen natürlich zusammen, weil beide Ihre Vermutungen als etwas behandeln, das zu prüfen ist, nicht als Fakten. Bauen Sie den Kern, geben Sie ihn Nutzern, und lassen Sie deren Verhalten die Reihenfolge des Nächsten bestimmen. Die meisten Listen von Vorteilen agiler Softwareentwicklung beginnen an derselben Stelle, mit Geld, das nicht für Features ausgegeben wurde, die niemand genutzt hat.

Unsere MVP-Entwicklungsservices liefern einen Launch in 12 Wochen, kurz genug, um den Scope ehrlich zu halten. Zu entscheiden, was in diese erste Version gehört, ist der schwierige Teil, und dort findet die meiste Diskussion statt. Unser Leitfaden dazu, wie man ein MVP baut, zeigt, wie Sie eine Wunschliste auf etwas kürzen, das Sie ausliefern und aus dem Sie lernen können.

Wo Agile an Grenzen stößt und was Sie dagegen tun können

Agile passt nicht zu jedem Projekt, und jeder Anbieter, der Ihnen etwas anderes erzählt, verkauft Ihnen etwas. Drei Situationen machen es tatsächlich schwerer, und jede hat einen sinnvollen Umgang:

• Ein Festpreisvertrag fixiert den Scope. Wie der Lieferprozess auch genannt wird, alles im Voraus zu vereinbaren ist ein Waterfall-Deal. Sie können darin weiterhin in Zyklen arbeiten, haben aber die Freiheit aufgegeben, die Richtung zu ändern. Wo Kunden beides wollen, vereinbaren wir Ziel und Budget, halten die Details offen und prüfen sie alle paar Wochen gemeinsam.
• Regulierte Arbeit verlangt einen Audit-Trail. Ein laxer Prozess liefert keinen, was kurze Zyklen aber nicht ausschließt. Behörden betreiben agile Softwareentwicklung im großen Maßstab, und der GAO Agile Assessment Guide existiert, um US-Bundesprüfern die Bewertung zu erleichtern. Wir haben an Current mit der Change & Innovation Agency gearbeitet. Es ist eine Web-App, die Anträge von Bürgern für staatlich verwaltete Programme verarbeitet, gebaut auf Angular, ASP.NET Core und Azure. Die Geschäftslogik von Current entwickelte sich in Zyklen weiter, während die Dokumentationspflichten parallel erfüllt wurden.
• Niemand auf Ihrer Seite kann die Arbeit prüfen. Ein Team ohne Gegenüber für die Demo entscheidet selbst, und einige Entscheidungen werden falsch sein. Wenn Ihre Organisation keinen Entscheider für ein paar Stunden pro Woche freistellen kann, sagen Sie das, bevor das Projekt beginnt. Die ehrliche Antwort kann ein kürzeres Engagement sein, ein Business Analyst auf unserer Seite oder eine Verzögerung, bis jemand die Verantwortung übernehmen kann.

Wie Redwerk agile Delivery umsetzt

Unser Standardmodell ist ein dediziertes Team, das in zweiwöchigen Sprints arbeitet, mit einer Demo, an der Sie am Ende jedes Sprints teilnehmen, und direktem Zugang zu den Entwicklern dazwischen. Kunden sagen uns, dass ihnen die Kommunikation zuerst auffällt, und das ist Absicht. Keine wöchentliche Zusammenfassung, geschrieben von jemandem, der nicht im Code war.

Der größere Unterschied liegt darin, wo wir bereit sind zu starten. Viele Projekte, die zu uns kommen, haben keine vollständige Spezifikation, und einige treffen als halbfertige Codebasis ein, die jemand anderes aufgegeben hat. Beides hält uns nicht auf, denn ein erster Sprint kann genauso gut eine Bewertung des Bestehenden liefern wie einen funktionierenden Teil neuer Software. Unsere Arbeit im Software-Development-Consulting beginnt oft genau dort, mit einem klaren Blick auf den Boden, bevor sich jemand auf einen Plan festlegt.

Agile funktioniert, weil es davon ausgeht, dass Sie an Tag eins nicht jede Antwort haben. Zwanzig Jahre Produktentwicklung haben uns gelehrt, genau dafür zu planen. Ein Prozess, der sich mit Ihrem Erkenntnisgewinn verbessert, schlägt einen, der bricht, wenn sich Anforderungen ändern. Kurze Zyklen helfen nur, wenn Sie das Ergebnis ansehen und danach handeln. Um zu besprechen, welche Arbeitsweise zu Ihrem nächsten Projekt passt, erzählen Sie uns, was Sie bauen.

FAQ

Erfahren Sie, wie wir AWE Learning dabei geholfen haben, von einer lokalen Lösung in die Cloud zu migrieren und durch die Implementierung einer skalierbaren SaaS-Lösung Benutzer außerhalb der USA zu erreichen.

Bitte geben Sie Ihre Geschäfts-E-Mail-Adresse ein ist keine Geschäfts-E-Mail

Fallstudie anfordern