Agile Schule (E-Book). Ralf Romeike

Чтение книги онлайн.

      Agile Methoden einzusetzen bedeutet auch zu verstehen, wo sie herkommen, welche Werte mit ihnen verbunden sind und wie diese in der Praxis zum Tragen kommen. In diesem Kapitel werden zunächst die wichtigsten Entwicklungsschritte und Vorgehensmodelle agiler Methoden beschrieben. Anschließend werden Agile Werte als ideelles Fundament und ihre Bedeutung für Unterrichtsprojekte dargestellt. Unterschiedliche Beweggründe und Erfahrungen bei der Einführung agiler Methoden werden schließlich durch Schilderungen aus der Praxis dreier Unternehmen skizziert.

2.1 Geschichte und Entwicklung

      Softwareentwicklung wird Teamarbeit

      Allein entwickelte Software ist typischerweise nicht sehr komplex, wird von wenigen genutzt oder hat eine kurze Lebenszeit. Anders ist es mit großen Softwaresystemen: Sie werden von vielen für viele geschrieben und meist über Jahrzehnte genutzt und weiterentwickelt.

      Die Entwicklung solcher Softwaresysteme begann Mitte des letzten Jahrhunderts mit Steuerelementen für Raumfahrt und militärische Streitkräfte. Anfangs wurde im Großen ebenso «intuitiv» wie im Kleinen entwickelt. In den folgenden Jahrzehnten beauftragten Banken, Telefon- und Transportgesellschaften, Unternehmen für Medizintechnik und viele weitere Branchen zunehmend umfangreichere Softwarelösungen, die nur noch von Teams entwickelt werden konnten. Rasch wurde klar: Das Risiko zu scheitern war ohne ein strukturiertes Vorgehen groß. Dass es damals, als sich die Informatik als Wissenschaft erst entwickelte, noch kaum systematisch ausgebildete Informatiker, aber viele Ingenieure in der Softwareentwicklung gab, mag erklären, weshalb man in den 1960er-Jahren bewährte Vorgehensweisen aus Bau- und Produktionsprozessen übernahm und sie für die Softwareentwicklung anpasste. So entstand ein wasserfallähnlicher Verlauf in Phasen, der einen Schwerpunkt auf die sehr präzise Analyse und Definition der Anforderungen legte, um dadurch, analog zum Bauwesen, teure oder gar unmögliche spätere Änderungen zu vermeiden. Anschließend wurde gemäß den Anforderungen ein detaillierter Plan ausgearbeitet und im Folgenden genau umgesetzt. Kommuniziert wurde dabei im Wesentlichen durch das Weiterreichen der umfangreichen Dokumentation. Diese heute als klassisch bezeichneten Vorgehensweisen brachten Struktur in den Prozess, aber auch neue Probleme. Planungsfehler wurden beispielsweise oft erst am Ende des Projekts erkannt und waren zu diesem Zeitpunkt nur mit erheblichem Zusatzaufwand meist in Form von Überstunden behebbar. Außerdem beschrieben die verschriftlichten Wünsche des Kunden aufgrund von Kommunikationsschwierigkeiten oder unzureichender Kenntnisse oft nicht das, was eigentlich gebraucht wurde, sodass die Arbeit von Monaten oder Jahren «umsonst» war. Nach Abschluss einer klassischen Planung eingebrachte Wünsche durften nicht mehr berücksichtigt werden, auch wenn eine Planänderung aus Sicht des Entwicklerteams möglich und sinnvoll gewesen wäre. Die Praxis der Softwareentwicklung zeigte Ende des 20. Jahrhunderts immer deutlicher, dass langfristige Pläne oft nur für kurze Zeit gute Pläne sind, insbesondere in einer Welt, deren Anforderungen und Einsatzszenarien immer volatiler, komplexer, unsicherer und mehrdeutiger werden.

      Abbildung 2.1: Probleme bei klassischem Vorgehen: Was der Kunde beschreibt, was er anfangs bräuchte, was umgesetzt wird, was noch gerettet werden kann und was er am Ende tatsächlich gebraucht hätte

      Auf dem Weg zu mehr Flexibilität

      Vor dem Hintergrund dieser auch für die Softwareentwickler oftmals frustrierenden Erfahrungen diskutierten in den 1990er-Jahren immer mehr Informatikerinnen und Informatiker darüber, welche neuen Wege beschritten werden könnten, um Software für alle Beteiligten besser zu entwickeln. Hierbei entstanden Vorgehensmodelle wie Extreme Programming, Scrum und Feature Driven Development, die zunächst unter das Prädikat «leichtgewichtig» fielen. Die Ideen für Veränderungen waren nun da, aber noch fehlte eine positive charakteristische Bezeichnung, die, vergleichbar mit einem Siegel, die verknüpften Werte bündelte, ihnen eine unverkennbare Identität gab und beim Kunden Neugier und Vertrauen für das damit verbundene Versprechen, besser zu sein, weckte.

      Das änderte sich, als 17 erfahrene Softwareentwickler mit sehr unterschiedlichem Hintergrund im Jahr 2001 in den schneebedeckten Rocky Mountains zusammenkamen, um eine gemeinsame Basis und einen Begriff für die neuen Herangehensweisen zu finden. Nachdem ein Teilnehmer vorgeschlagen hatte, das, was man in der praktischen Arbeit mehr schätzen gelernt hat, dem gegenüberzustellen, was traditionell wichtig war, ging es sehr schnell. Dann standen vier Sätze, aus denen das Agile Manifest wurde, an der Wandtafel.

      Abbildung 2.2: Das 2001 formulierte Manifest für Agile Softwareentwicklung

      Der Moment wird von Teilnehmern später als überwältigend beschrieben. Es gab keine Gegenargumente, es bedurfte keiner Abstimmung. Alle sahen die Sätze und sagten: «Ja, das ist es!» Am zweiten Tag wählte die Gruppe das Wort «agil», das mit «beweglich», «flink» oder «wendig» ins Deutsche übersetzt СКАЧАТЬ