Agile Methoden

Agile Methoden

Agile Entwicklung durch Scrum & Co.

Das Wort „agil“ ist aktuell in den meisten Softwareprojekten ein Thema. Scrum als Methode zählt inzwischen zu einer akzeptierten Standardmethode. Warum ist das so? Wie geht es weiter?

Klassisches Wasserfallmodell

Softwareentwicklung ist nach wie vor noch ein junges technisches Gebiet der Informatik. Ständig gibt es technische Neuerungen, neue Hardware, neue Programmiersprachen und eben auch neue Entwicklungsmethoden. Das Ganze zu industrialisieren ist ein Ziel, welches viele Unternehmen verfolgen. Auch im universitären Bereich wird an diesem Ziel gearbeitet. Die agilen Modelle sind aus den immer wieder zu erkennenden Problemen des klassischen Wasserfallmodells entstanden. Hier gab es in den 1970er Jahren sogar den Begriff der „Softwarekrise“.

Projekte dauerten viel länger als geplant und das Ergebnis entsprach nicht den Erwartungen des Auftraggebers. Der langwierige Planungsprozess im Wasserfallvorgehen war in sich zwar logisch – die Trennung der Phasen akzeptiert – trotzdem entsprach die daraus resultierende Software oft nicht den Erwartungen. Jeder, der das Wasserfallmodell schon mal praktiziert hat, weiß, dass es eben oft „Rücksprünge“ in die vorhergehenden Phasen geben musste. Diese waren notwendig aber so vom Verfahren nicht vorgesehen und verursachten Probleme im Ablauf. Man entwickelte immer neue Methoden, wie z.B. UML, um die Softwareentwicklung zu formalisieren. Man legte viel Wert auf Modellierung, Darstellung und Formalisierung. Es entstanden immer umfangreichere Spezifikationsdokumente. Das Wasserfallmodell hier steht stellvertretend auch für alle weiteren Phasenmodelle wie das V-Modell oder das erweiterte Wasserfallmodell. Alle diese Methoden und Planungen verbesserten die Lage und waren auch sinnvoll – lösten aber nicht die Kernprobleme:

  • Die Softwareentwicklung dauert immer länger als geplant.
  • Die entwickelte Software im Ergebnis ist nicht das, was man ursprünglich wollte.

Warum war das so? Die ganzen Modelle waren Abstraktionen der Wirklichkeit und mussten auf beiden Seiten – Auftragnehmer und Auftraggeber - verstanden werden. Dies war oft nur schwer möglich. In der Praxis zeigten sich dann Probleme, die man in der Planung so nicht bedacht hatte.

Es gab immer mehr Vorgehensweisen, die versuchten, das Modell so nah wie an der Wirklichkeit zu bauen. Daraus entstanden Softwareentwicklungsmodelle wie das „Rapid Prototyping“ - der Beginn der agilen Entwicklung. Der kleinste gemeinsame Nenner aller agilen Vorgehensmodelle – und damit auch von Scrum – ist das Agile Manifest. Eine der zentralen Erkenntnisse des „Manifest für Agile Softwareentwicklung“ ist „Menschen und Interaktionen sind wichtiger als Prozesse und Werkzeuge“.

Agiles Manifest

  • Feedback: Kunden müssen zur Steuerung des Prozesses implementierte Features bewerten und auf dieser Basis neue Features priorisieren und planen. Um diese Art der Steuerung zu ermöglichen, werden die Aufgaben in Iterationen aufgeteilt.
  • Transparenz: Der aktuelle Stand der Implementierung und der dafür bisher investierte Aufwand sind für alle jederzeit erkennbar. Der Projektfortschritt ist also unmittelbar nachvollziehbar.
  • Vertrauen: Transparenz schafft Vertrauen, weil es weniger Geheimnisse und daher weniger Misstrauen gibt. Gleichzeitig kann Transparenz nur dann funktionieren, wenn sich alle Beteiligten vertrauen. Hierzu gehört, dass Vereinbarungen und Absprachen (z.B. in Meetings) eingehalten werden.

Agile Werte lassen sich nicht nur auf Softwareentwicklung anwenden sondern auch auf andere Projekte und Produktionsprozesse. Die Parallelen von Scrum zur schlanken Produktion (lean production) sind nicht zufällig. Vorgehensmodelle strukturieren Projekte zeitlich und methodisch: Wer macht was, zu welcher Zeit, und wie soll das Ergebnis aussehen? Ob man einen festen Plan nach dem klassischen Wasserfallmodell oder dem V-Modell XT nutzt oder auf Selbstorganisation agiler Methoden setzt, hängt von den Anforderungen des Projekts ab.

Agile Prozesse werden oftmals als Gegenentwurf zum Wasserfallmodell (sequenzielle, phasenorientierte Entwicklung von Software) abgegrenzt. Aber stimmt diese gängige Überzeugung auch? Die Antwort lautet: Nein! Wenn man den Wasserfall richtig verwendet, kann man mit ihm ebenso effizient wie mit agilen Methoden arbeiten. Bei Applikationen mit zwingend notwendigen, kritischen Systemeigenschaften hat er sogar deutliche Vorzüge. Je nach Kundenanforderungen deckt die committance AG auch diese Methodik ab.

Scrum, innerhalb dessen Menschen komplexe, adaptive Aufgabenstellungen angehen können, ist ein agiles Rahmenwerk. Hier stehen Interaktionen zwischen den Individuen im Mittelpunkt, die zum Ergebnis führen. Darüber hinaus gibt es Ansätze, die eher technisch orientierte Praktiken zur Softwareentwicklung beitragen, wie die testgetriebene Entwicklung aus Extreme Programming (XP). Scrum sorgt für Transparenz zwischen Produktmanager und dem Entwicklungsvorgehen. Hierdurch können sich beide Seiten überprüfen, verbessern und anpassen („Inspect and adapt“).

Prinzipien des agilen Projektmanagements
  • Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.
  • Motivierte Individuen benötigen ein Projektumfeld und die notwendige Kundenunterstützung für die Erledigung der Aufgabe. Dazu gehört auch das Vertrauen in sie!
  • Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklerteam zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.
  • Die Gesamtlösung und die dazugehörigen Schritte (die besten Architekturen, die Anforderungen und die Entwürfe) entstehen durch selbstorganisierte Teams.
  • In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten an.

Ein typisches Projektbeispiel für einen agilen Scrum-Prozess mit uns als Partner kann wie folgt aussehen (vgl. u.a. Scrum Glossar):

  • Im Product Backlog wird alles aufgenommen, was für das zu entwickelte Produkt relevant ist. Dazu zählen Features oder auch nicht funktionale Anforderungen.
  • Aus dem Product Backlog werden die Elemente in das Sprint Backlog übernommen, die im nächsten Sprint bearbeitet werden sollen.
  • Ein solcher Sprint dauert typischerweise zwei bis vier Wochen. In dieser Zeit wird das Sprint Backlog bearbeitet.
  • Während des Sprints werden in täglichen Scrum-Meetings die aktuellen Aufgaben und Herausforderungen besprochen.
  • Am Ende des Sprints wird ein auslieferbares Produktinkrement geliefert. Die Software oder Lösungen können also produktiv genutzt werden. Oft werden sie dem Kunden in einem Review vorgestellt.
Scrum Glossar
  • Product Backlog: Das Product Backlog enthält alle bekannten Anforderungen und Arbeitsergebnisse, die für das Erreichen des Projektziels umgesetzt oder erbracht werden müssen. Seine Einträge sind priorisiert.
  • Scrum Master: Der Scrum Master ist eine Scrum-Rolle. Er hilft, Scrum richtig anzuwenden. Er unterstützt das Team und stellt die direkte Zusammenarbeit von Product Owner und Team sicher. Zudem beseitigt er Hindernisse und hilft dem Team, seine Produktivität kontinuierlich zu steigern.
  • Product Owner: Der Product Owner ist ebenfalls eine Scrum-Rolle und verantwortlich für den Erfolg des Projekts. Er beschreibt die Anforderungen, verwaltet das Product Backlog und erstellt den Release-Plan sowie die Release-Berichte. Er managt die Interessenvertreter und arbeitet eng mit dem Team während der gesamten Projektlaufzeit zusammen.
  • Transition Product Backlog: Das Transition Product Backlog enthält alle notwendigen Maßnahmen, um Scrum erfolgreich unternehmensweit einzuführen.
  • Sprint: Ein Sprint ist ein Arbeitszyklus, der Anforderungen aus dem Product Backlog in ein Produktinkrement umsetzt. Er dauert maximal 30 Tage.

Wir denken, wer agile Softwareentwicklung erfolgreich betreiben will, muss das Kernstück dieses Vorgehens einführen – die kontinuierliche Abnahme von Teilergebnissen durch den Kunden. Nur dann lassen sich die Früchte der Agilität ernten. Das schrittweise Ausliefern hält den Anteil der Anwendung, der noch zu testen ist, noch nicht abgenommen wurde oder zu dem noch Feedback fehlt, stets überschaubar. Kritik muss der Abnehmer jeweils am Ende einer Iteration abgeben. Dadurch hält sich der Änderungsaufwand in Grenzen und die Kosten laufen nicht aus dem Ruder.

Iterativ zu arbeiten, anstatt sehr viel Zeit und Aufwand auf Analyse und Design zu verwenden, ist ein Service-Gedanke von uns. Damit ist innerhalb der agilen Transition – der Umwandlung in ein agiles (Beratungs-)Unternehmen – auch das Verschlanken der Hierarchien ein weiteres Kernelement der committance AG.

Deshalb wenden wir gemäß dem agilen Ansatz das Prinzip der Spezialisierung nicht nur innerhalb unseres Unternehmens sondern auch bei Bedarf bei unseren Kunden konsequent an: während die Qualität und Lieferfähigkeit Sache des Beraters (Entwickler oder Business Consultant) ist, gibt es bei Führungsaufgaben (Management oder Projektleitung) die folgenden Rollen: zum einen, die des Verantwortlichen für den Kundennutzen und zum anderen die des Verantwortlichen für die Produktivität.

Mit abstrakten Anforderungen im Stil von „wir wollen besser werden“ ist es bei der committance AG nicht getan! Wir wollen ganz im Sinne des Agilen Manifests „den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software“ (oder Beratung) zufrieden stellen.


Quellenangaben