Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03505.jsonl.gz/1227

Agile Softwareentwicklung: Was hat sie gebracht und wie geht es weiter: Drei Experten, drei Meinungen. Heute äussert sich der "agile Unruhestifter" Dan North.
Wie haben agile Methodologien in den letzten Jahren die Softwareentwicklung verändert, und was hat das gebracht? Was sind die grössten Fehler bei der Anwendung und wie geht es weiter? inside-it.ch hat drei Experten mit diesen Fragen konfrontiert: Scott Ambler
und Dan North.
Last but not least äussert sich heute Dan North. North, der sich selbst als "agiler Unruhestifter" bezeichnet, arbeitet seit 20 Jahren als und für Softwareentwickler. Er hat die agilen Ansätze Behaviour-Driven Development und Deliberate Discovery entwickelt. Sein aktuelles Steckenpferd ist der Accelerated Agile-Ansatz
, über den er an der kommenden Softwarekonferenz GOTO Zurich sprechen wird.
inside-it.ch: Was wurde in den rund fünfzehn Jahren erreicht, seit agile Methodologien erstmals in der Softwareentwicklung angewendet wurden? Sind vergleichbare Projekte heute billiger? Schneller? Risikoärmer?
Dan North: Vor fünfzehn Jahren, in den späten Neunzigern, hatten die Probleme von IT-Projekten vor allem mit ihrer Grösse zu tun. Es war nicht ungewöhlich, dass Projekte mehrere Jahre lang dauerten. Und diese Projekte scheiterten regelmässig - oder produzierten etwas, das nur einem Schatten der ursprünglichen Vorstellung entsprach. Danach wechselten die Leute, die bei einem gescheiterten Projekt dabei gewesen waren, einfach zum nächsten Riesenprojekt.
Teufelszyklus
Das führte zu einem Teufelszyklus, in dem die Abnehmer der Software immer mehr und noch mehr forderten - schlicht, weil die Lieferung so lange dauerte - und die Entwicklungszeit immer länger wurde, weil eben die Anforderungen dauernd ergänzt wurden. Das war der Kontext, der zur Entwicklung der ursprünglichen agilen Methodologien führte: Man versuchte, Riesenprojekte in handhabbare Teile aufzubrechen, um diese Stücke dann schneller liefern und auch schneller auf Feedback aufgrund dieser Lieferungen reagieren zu können.
Die Technologie war damals noch nicht auf kurze Feedback-Zyklen ausgerichtet. Sogar ein einigermassen grosses Stück C++-Code zu kompilieren, konnte mehrere Stunden dauern. Automatisierte Testmöglichkeiten waren selten oder existierten gar nicht. Einige Projekte hatten Scripts für die Zusammenstellung von Softwarebuilds, aber automatisierte Deployments waren selten und die automatisierte Konfiguration von Umgebungen noch fast völlig unbekannt. Softwareprojekte wurde wie grosse Bauprojekte geführt, mit Gantt-Charts
usw.
Durch agile Methoden haben viele erkannt, dass man für Softwareprojekte nicht unbedingt die Regeln von grossen Projekten aus dem Ingenieurswesen anwenden muss. Wir können Teile einer Lösung mit jeweils einer Gruppe von nützlichen Funktionen unabhängig voneinander liefern. Die Reaktionen, die diese Teile auslösen, können dann wiederum die Richtung des ganzen Projekts bestimmen. Die Komplexität von Softwareentwicklung ist dynamisch. Sie wechselt schlicht aufgrund der Tasache, dass ein Projekt im Gang ist. Man kann etwas erfahren, das einen grossen Teil des Projekts viel einfacher oder sogar überflüssig macht. Oder man kann auf etwas stossen, das ein Projekt viel schwieriger oder sogar undurchführbar macht.
Feedback, Reaktion und Werte
Die grösste Errungenschaft der agilen Methoden war es, dass sie es möglich gemacht haben, Feedback einzubeziehen und darauf zu reagieren. All die ursprünglichen "Geschmacksrichtungen" von Agile - Crystal, Extreme Programming (XP), Scrum, Feature Driven Development (FDD), Adaptive usw. - haben dies gemeinsam. Das Agile Manifest
wurde geschrieben, um die grundlegenden Werte, die sie alle teilen, festzuhalten: Menschen und ihre Interaktionen zu respektieren, sich mehr auf das Ergebnis als auf die "Zeremonie" zu konzentrieren, und Feedback zu respektieren und darauf zu reagieren, statt einem fixen Plan zu folgen.
Agile Methoden haben das Potential, die anfangs genannten Vorteile zu bringen, so dass Projekte schneller, billiger und risikoärmer werden können. Ich sage "Potential", weil diese Vorzüge nicht immer realisiert werden. Die Gesamtentwicklung kann billiger und schneller sein, wenn man es vermeiden kann, unnötige oder aufs Geratwohl angeforderte Features zu bauen. Das wiederum kann durch das regelmässige Vorzeigen von Vor- und Teilversionen ("Showcases") und einen klaren Fokus auf das ursprüngliche Ziel ereicht werden. Die durch kurze Zyklen und regelmässiges Feedback sowie die Vorversionen geschaffene Transparenz kann es auch ermöglichen, Risiken viel früher zu erkennen. Aber eben, wenn man die Strukturen nicht hat, um diese Risiken zu erkennen und darauf zu reagieren, dann bringt auch das frühe Feedback nicht viel.
Flaschenhälse erkennen
Was sind die grössten Fehler, die bei der Anwendung von agilen Methodiken gemacht werden?
Organisationen entscheiden sich oft dazu, "agil zu werden", ohne wirklich zu verstehen, was ihre eigentlichen aktuellen Bremsklötze beziehungsweise Flaschenhälse sind. Wenn man zum Beispiel seinen Markt oder sein Produkt nicht versteht, dann wird man auch durch schnelle und flexible Softwareentwicklung nicht erfolgreicher. Wenn Sie neben den Prozessänderungen und den technischen Anforderungen nicht auch gleichzeitig die organisatorischen Änderungen angehen, die agile Methoden erfordern, dann wird Ihr Unternehmen nicht mit agilen Teams interagieren können. Dabei geht es um alles, von der Art, wie Leute bezahlt und belohnt werden über die Kontrollprozesse und Hierarchien bis dahin, wie die Budgetierung und Finanzierung funktioniert.
Agile Methoden wurden entwickelt, um regelmässig und vorhehrsehbar Software abliefern zu können. Wenn die Teams, die danach die Software betreiben und damit umgehen sollen, nicht in der Lage sind, das gelieferte vernünftig zu "verdauen", dann wird man Probleme erhalten, sobald es in die Produktion geht, egal, wie effizient die Softwarentwicklung geworden ist. Das ist es, worauf sich die Methoden DevOps
und Continuous Deployment konzentrieren.
Auf der anderen Seite müssen auch die Abnehmer der Software, die vielleicht noch daran gewöhnt sind, die "grosse Business-Initiative" zu starten und schwergewichtige Anforderungskataloge zu generieren, lernen, "in kleineren Brocken" zu denken. Dies wird ihnen erlauben, iterativ zu denken und mit Ideen zu experimentieren statt vorzugeben, die Zukunft vorhersagen zu können. Darauf fokussiert sich die "Lean Startup"-Bewegung
. Reale Erfahrungen und harte Daten werden immer besser sein, als Spekulation. Aber wenn ihr Unternehmen einmal im Jahr ein in Stein gemeisseltes Budget festsetzt, werden sie Mühe haben, die Vorteile iterativer Techniken auszunützen.
"Reservieren sie ein grosses Reisebudget!"
Ist agile Softwareentwicklung mit Offshoring kompatibel?
Das kann sie auf jeden Fall sein, aber leicht ist das auch nicht. Ich habe erfolgreiche grosse Projekte gesehen, an denen deutlich über hundert Leute aus verschiedenen Kulturen, verteilt auf mehrere Zeitzonen und Kontinente mitarbeiteten. Die wichtigsten Faktoren, die man dabei berücksichtigen muss, sind Kommunikation und Autonomie. Man muss eine klare Vorstellung davon haben, wie das Produkt aussehen soll, und es braucht häufige Synchronisierungen (Reservieren sie ein grosses Reisebudget!) damit die Teams auf das gleiche Ziel hin arbeiten. Offshoring macht dies einfach noch schwieriger.
Jedes Team muss die Kontrolle über seinen Teil des Produkts haben, was bedeutet, dass man Verantwortlichkeiten nach Feature-Gruppen und nicht nach Technologien aufteilen sollte. Wenn zum Beispiel die Datenbankleute an einem und die Backend-Entwickler an einem anderen Ort und die Webentwickler nochmals woanders sitzen, ist das ein Rezept für das Scheitern. Was man braucht sind voll autonome Teams an jedem Standort, die alle relevanten Technologien abdecken. Jedes Team sollte verantwortlich für seinen Teilbereich der Funktionen des Endprodukts sein, eingeschlossen Testing, Deployment und Management.
Wir sind schlecht darin, agile Werte zu vermitteln
Wie wird man Software in zehn Jahren, also im Jahr 2023, entwickeln?
Leider wahrscheinlich ziemlich gleich wie heute. Fachleute für agile Methoden verfechten diese schon seit fünfzehn Jahren, aber viele grosse Organisationen stecken geistig immer noch in den 90ern. Sie betrachten die IT als Kostenfaktor und nicht als einen Partner für die Weiterentwicklung. Die grossen "Verbraucher" agiler Methoden sind mehr auf Zertifikate als auf Resultate fixiert und missachten regelmässig, dass es bei agiler Entwicklung um Feedback und Kommunikation geht. Das deutet aber auch an, dass wir, die agilen Fachleute, ausserordentlich schlecht darin sind, diese Werte zu kommunizieren.
Innovationen in der Technologie - vor allem Virtualisierung und Cloud-Computing - werden die Kosten in einigen Bereichen der Softwareentwicklung weiter senken und das Tempo beschleunigen. Aber die grosse Verschwendung passiert immer noch in den Bereichen Budgetierung und Finanzierung, sowie der Governance und der Weitergabe von Projekten. Eli Goldratt, der Author des bahnbrechenden Buchs "Das Ziel"
, sagt, dass seiner Erfahrung nach der Wechsel vom kostenbasierten Denken zum durchsatzbasierten Denken zwischen fünf und bis zu fünfzehn Jahre lang dauert. Der Wechsel bedingt einen kompletten "Neustart" - einen Paradigmenwechsel - und die Leute tun alles, um eine Änderung ihrer Paradigmen zu verhindern!
Auf dem Weg zu einem "schlanken" organisatorischen Denken und einer durchsatzbasierten Buchhaltung werden wir 2023 noch kaum weiter sein, weil der Aktienkurs und Quartalsresultate immer noch das Verhalten ganz oben in der Hierarchie bestimmen werden. Um das zu ändern, brauchen wir einen grösseren Hebel, als die agile Softwareentwicklung. (Fragen und Übersetzung: Hans Jörg Maron)
Die GOTO-Zurich-Konferenz für Entwickler
findet am 10. und 11. April in Zürich statt. Wer als inside-it.ch-Leser bei der Registrierung den Promocode "insideit" erwähnt, erhält hundert Franken Leserrabatt.
(Interessenbindung: inside-it.ch ist Medienpartner der GOTO Zürich)