nach \cite{Bleek2008}

• priorisierte Anforderungen sind die Grundlage der Entwicklung
  • Fokus auf nutzenbringende Features (und nicht auf Standardfunktionen wie z.B. Stammdatenverwaltung)
• Kommunikation mit dem Kunden
  • z.B. Sprint Planning zusammen mit dem Kunden
  • Kunde entscheidet über Prioritäten (neue Features, Bugfixing etc.)
  • zusätzliche Anforderungen können leicht und schnell integriert werden
• das Team soll ständig dazulernen
  • Retrospektiven sind äußerst wichtig für die Entwicklung des Teams und des Prozesses
  • kontinuierliche Verbesserung des Schätzverfahrens für Tasks → z.B. Planning Poker
  • Collective Code Ownership → jeglicher Code darf von jedem Entwickler geändert werden
• lauffähige Software abliefern
• die verfügbare Arbeitszeit muss realistisch verplant werden
  • überschaubare Länge der Tasks/Aufgaben der Entwickler (max. 1 Woche)
  • z.B. 70% produktive Zeit wegen Urlaub, unvorhergesehenen Aufgaben etc.
  • Zeit für Bugfixing, Retrospektiven etc. muss eingeplant werden
  • Timeboxing → Termine stehen fest, Funktionen werden ggfs. reduziert
• einfache Regeln → keine Zeitverschwendung durch lange Lernzeiten für Prozessmodell
• viel Freiheit für die Entwickler → dennoch sollten die wenigen Regeln strikt eingehalten werden
• wenig Dokumentation

nach \cite[S. 10ff.]{Bleek2008}

• Kommunikation
  • direkt: von Person zu Person und möglichst kurzfristig bei Bedarf
  • offen und ehrlich: alles wird angesprochen auch unangenehme Dinge
• Einfachheit
  • technisch: nur das bauen, was benötigt wird
  • organisatotisch: Entwickler organisieren sich weitestgehend selbst
  • methodisch: keine überbordenden Prozesse, sondern einfach umzusetzendes Vorgehen
• Rückkopplung
  • insbesondere: Retrospektiven
• Mut
  • neue Wege ausprobieren
  • sich gegen Widerstände durchsetzen
  • wichtig für offene Kommunikation bei schwierigen Themen
• Respekt
  • Voraussetzung für offene und ehrliche Kommunikation

Das Original: Manifesto for Agile Software Development

• Individuen und Interaktionen vor Prozessen und Werkzeugen
• laufende Software vor ausgedehnter Dokumentation
• Zusammenarbeit mit dem Kunden vor Vertragsverhandlungen
• Reaktion auf Veränderungen vor Planverfolgung

nach \cite[S. 159ff.]{Bleek2008}

• Contra aufgrund des Kunden
  • kein SMARTes Projektziel
  • Prozess ist fest vorgegeben (z.B. bei Behörden)
  • Nice-to-have-Projekt → es gibt keinen Kunden, der Anforderungen definiert
  • lange Entscheidungswege beim Kunden → mangelhafte Rückkopplung
  • langwierige Change-Request-Verfahren → langer Stillstand im Projekt
  • kein Anwenderkontakt möglich → keine Rückkopplung möglich
  • Kundenrolle nicht oder zeitlich zu knapp besetzt → lange Entscheidungswege, keine klare Vision des Kunden vorhanden
  • Erstellung von lebenskritischer Software → wichtige Vorgaben zu Tests, Dokumentation etc.
  • Angst und organisierte Unverantwortlichkeit → niemand übernimmt Verantwortung
  • Kunde steht nicht hinter dem Vorgehen → Kunde nimmt seine Rolle nicht ernst oder fürchtet Mehrarbeit
  • keine Arbeit vor Ort möglich → mangelhafte Rückkopplung
  • Festpreisprojekte → Erkenntnisse können/dürfen nicht in den laufenden Prozess eingearbeitet werden
  • Kunde ist eine Behörde → meist treffen mehrere der obigen Punkte zu
• Contra aufgrund der Entwickler
  • keine Erfahrung mit agilen Projekten und kein Coach vorhanden
  • Lernunfähigkeit oder -unwillen → agile Entwicklung bedeutet Lernen
  • Kultur von Befehl und Gehorsam → agile Entwicklung bedeutet Eigenverantwortung, Fehler machen dürfen etc.
  • Entwickler scheuen Anwenderkontakt → keine Rückkopplung möglich
  • hohe Mitarbeiterfluktuation → Team kann sich nicht einspielen
  • keine Arbeit vor Ort gewünscht → Rückkopplung wird behindert
  • kein Management-Commitment auf agile Methoden → Erlaubnis, Fehler machen zu dürfen ist sehr wichtig
• Contra aufgrund der Technologien
  • lange Build-Zeiten
• Pro aufgrund des Kunden
  • Start-ups → müssen schnell Ergebnisse liefern
  • innovative Projekte → brauchen Lernerfolge, haben Commitment der Teilnehmer
  • neue Anwendungsbereiche → schnelle Lernerfolge
  • schnelle Auslieferung notwendig (Time-to-Market)
  • nutzenorientierte Perspektive des Kunden (anstatt kostenorientiert)
  • Transparenz des Projektfortschritts → Risikominimierung
• Pro aufgrund der Entwickler
  • neugierige Entwickler → wollen Kunden verstehen, wollen Neues ausprobieren, sind risikobereit, wollen sich einbringen
  • Arbeit vor Ort ist sowieso gegeben
  • konkrete (Team-)Probleme sind bekannt → agile Entwicklung kann durch Rückkopplungen gezielt Probleme lösen
• Pro aufgrund von Technologien
  • inkrementelle Compiler → schnelle Rückkopplung beim Entwickler
  • interpretierte Scriptsprachen
  • Refactoring-Browser vorhanden → leichte Änderbarkeit des Quelltextes
  • Test-Frameworks vorhanden oder bekannt

nach \cite{Coldewey2008}

• Agiles Arbeiten ist ingenieursmäßiges Arbeiten
  • es muss wissenschaftlich-theoretisch fundiert sein
    • Quellen sind die Psychologie von Gruppen und Organisationen, die Theorie komplexer Systeme und die Managementtheorie
    • bis auf Systemtheorie eher "weiche" Wissenschaften, aber trotzdem als theoretische Grundlage verwendbar
  • es muss empirisch sein
    • reale Projekte werden selten für Studien geöffnet (Angst, durch Veröffetnlichung von Interna das Geschäft zu schädigen)
    • Zweifel, ob Empirie in der Informatik überhaupt sinnvoll ist (kurzlebige Theorien, häufige und schnelle Änderungen der Methoden und Werkzeuge)
    • Methoden für empirische Studien in der Informatik fehlen allgemein
  • es muss systematisch erlernbar und anwendbar sein
    • für viele Praktiken und Methoden der agilen Entwicklung gibt es gute Literatur (z.B. Retrospektiven, contiuous integration etc.)
    • agile Praktiken werden seit Jahren an amerikanischen Hochschulen gelehrt
• Agiles Arbeiten hat die gleichen Wurzeln wie traditionelle Prozesse
  • bereits auf der Software-Engineering-Konferenz in Garmisch 1968 sagte Andy Kinslow, dass er Design als Prozess versteht aus Entwurf in Form von Flussdiagrammen, Programmieren nach diesen Diagrammen und zurückgehen, wenn man feststellt, dass das Diagramm falsch ist → iterative Entwicklung
  • auf derselben Konferenz wurde das Vorgehen, erst alles detailliert zu spezifizieren und dann erst zu implementieren als "das tödlichste in der Softwareentwicklung" bezeichnet (Douglas Ross)
  • viele Unterzeichner des agilen Manifests waren vorher in der Pattern-Bewegung aktiv
  • viele Methoden der traditionellen Verfahren werden auch bei agiler Entwicklung benutzt: Testautomatisierung, Versionskontrolle, Kapselung, Schichtentrennung etc.
• Agiles Arbeiten verfolgt die Linie der betriebswirtschaftlichen Ausrichtung
  • die Erfahrung zeigt, dass es wesentlich wirtschaftlicher sein kann, die Anforderungen möglichst lange änderbar zu halten, als von Anfang an, alles haarklein zu spezifizieren
  • die detaillierte Spezifikation kostet viel und kann zum Scheitern von Projekten führen
  • Entwickler und Kunde verhandeln bei agiler Entwicklung gemeinsam, sodass bessere Ergebnisse (→ Fachbereich und Entwickler arbeiten zusammen) dabei herauskommen