Inhaltsverzeichnis
Agile Softwareentwicklung
"Obwohl [das Wasserfallmodell] im Laufe der Zeit z.B. in Form vom erweiterten Wasserfallmodell und Spiralmodell weiterentwickelt wurde, hat es in der IT-Branche heute nur noch eine geringe Bedeutung. In den letzten Jahren haben immer mehr Unternehmen zu agilen Methoden gewechselt. Diese verringern den bürokratischen Aufwand, unterstützen eine kontinuierlichen Interaktion mit dem Kunden sowie eine iterative Softwareentwicklung mit hoher Flexibilität bei der Festlegung der nächsten Schritte" (siehe die Lecture Notes zu agiler Softwareentwicklung von P. Brichzin).
Agiles Manifest
Agile Methoden zur Softwareentwicklung (z.B. Extreme Programming oder Scrum wurden Anfang der 1990'er Jahre entwickelt. Die Vertreter dieser Ansätze formulierten 2001 bei einem Treffen in Utah ihre gemeinsamen Überzeugungen als "Agiles Manifest":
„Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:
- Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge
- Funktionierende Software ist wichtiger als umfassende Dokumentationen
- Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen
- Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans
Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.“
Agile Prinzipien (nicht auswendiglernen!)
Aus dem agilien Manifest ergeben sich folgende 12 Prinzipien für die Projektarbeit:
- Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen.
- Heisse Anforderungsänderungen sind selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.
- Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.
- Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.
- Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.
- Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.
- Funktionierende Software ist das wichtigste Fortschrittsmaß.
- Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.
- Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.
- Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell. (KISS-Principle)
- Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.
- In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.
(Quelle: Wikipedia)
Aus diesen Prinzipien kann man zwischen den Zeilen sehr gut herauslesen, welche Probleme traditioneller Vorgehensmodelle durch die agile Herangehensweise behoben werden sollen 
.
In unseren Projekten am Ende des Schuljahres wollen wir vor allem die sechs kursiv gesetzten Prinzipien beherzigen.
Agile Methoden
Die nachfolgend beschriebenen agilen Methoden (siehe Paper von P. Brichzin) orientieren sich an Scrum, jedoch wurde die Anzahl der Methoden, Rollen und Ereignisse deutlich reduziert und leicht adaptiert.
Iterativ inkrementelle Softwareentwicklung ("Prototyping")
Regelmäßiger Meilenstein (iterativer Prozess) ist ein lauffähiger und getesteter Prototyp, der mehr Funktionalitäten bietet, als der vorhergehende Prototyp
(inkrementell). Jedes Inkrement umfasst dabei alle Schichten (siehe Abb. rechts). Durch die Entwicklung "von Prototyp zu Prototyp" sehen wir nicht nur schrittweise unsere Software wachsen, sondern halten die Produktausrichtung und Reihenfolge der umzusetzenden Funktionalitäten flexibel. Weiterhin werden ungenaue Schnittstellenabsprachen zwischen Teilgruppen des Teams frühzeitig erkannt und können korrigiert werden.
Sprint
Das Zeitintervall, in dem ein Prototyp erstellt wird, wird Sprint genannt. Der Sprint beginnt mit einer Planung, hat eine Implementierungsphase und schließt mit Tests ab. Ein Sprint soll sich sich in unseren Projekten über ca. 2 Wochen erstrecken.
Retrospektive
Nach jedem Sprint treffen sich die Entwickler im Team zu einer 1 - 2-stündigen Besprechung, der Retrospektive. Sie reflektieren den Arbeitsprozess und haben Zeit, um außerhalb der täglichen Routine über vergangene Ereignisse und Verhaltensweisen nachzudenken. Das Team stellt sich beispielsweise folgende Fragen:
- Was hat gut geklappt?
- Was hat nicht gut geklappt?
- Was wollen wir von nun an anders machen?
User Story
Die Anforderungen an unser Projekt beschreiben wir in Form von User Stories. Jede User Story beschreibt eine Funktionalität der Software aus der Sicht des Endanwenders. Sie ist aufgeteilt in Titel und Beschreibung und so kurz formuliert, dass sie auf eine Karteikarte passt. Bei der Formulierung achten wir darauf,
- keine Fachausdrücke der Informatik zu verwenden,
- keine Implementierungsdetails zu nennen und
- die Formulierung so zu wählen, dass später getestet werden kann, ob die User-Story im Programm erfolgreich umgesetzt wurde.
User Stories werden im Rahmen von Teambesprechungen priorisiert und getestet.
Modeling Story
Bei zunehmender Prototyp-Größe wird es nötig sein, auch das "Große Ganze" abzustimmen und die Implementierungsdetails in Form von Klassendiagrammen, Sequenzdiagrammen usw. zu modellieren. Diese Modelle werden in "Modeling Stories" festgehalten und in Teambesprechungen gemeinsam festgelegt.
Task
Tasks sind elementare Aufgaben aus der Sicht der Entwicklerin/des Entwicklers, die durch die Unterteilung einer User Story entstehen. Tasks sind aufgeteilt in Titel und Beschreibung. Sie sind so kurz formuliert, dass sie auf ein „Post it“ passen. Sie sind Ergebnis einer Teambesprechung, testbar und in der Bearbeitung einem Paar zugeordnet.
Project Board
Die gesamte Planung erfolgt über ein im Computerraum aufgehängtes Project Board(s. Abb. rechts). Es dokumentiert über die Spalten „to do“, „in progress“, „in test“ und „done“ zu Erledigendes und bereits Abgeschlossenes, sowie wer aktuell an welchen Arbeitspaketen arbeitet. Auch ist das Sprintende als nächster Meilenstein deutlich vermerkt. Bei den Arbeitspaketen, deren Reihenfolge durch die Priorisierung bestimmt wird, gibt es zwei unterschiedliche Granularitäten: User Stories und Tasks. Niedrig priorisierte müssen nicht von Anfang an als Tasks ausgearbeitet werden.
Pair programming
Entwickelt wird paarweise, wobei folgende zwei Rollen mindestens einmal pro Unterrichtsstunde gewechselt werden: Der Driver verwendet Tastatur und Maus und verfasst den Quelltext. Entscheidungen und Absichten werden dem Partner mündlich mitgeteilt. Der Navigator hinterfragt Quelltext, spricht mögliche Fehler an, und sucht elegantere Lösungen. Er hat die Aufgabe das große Ganze im Auge zu behalten.
Standup-Meeting
Jede Woche findet eine Besprechung im Stehen vor dem Taskboard statt. Dazu äußert sich jedes Teammitglied bzw. jedes Paar knapp und präzise, welche Aufgaben es bearbeitet hat. Gegebenenfalls gibt es kurze Hinweise zum Lösungsweg (insbesondere wenn Schnittstellen betroffen sind) und zu aufgetretenen Problemen. Weiterhin nennt jeder den Task, den er als nächstes bearbeiten wird. Die maximale Dauer des Standup-Meetings beträgt 10 Minuten.
Das Standup-Meeting am Ende eines Sprints wird erweitert um die Planung des nächsten Prototyps. Dazu gehört gegebenenfalls eine neue Priorisierung der User Stories, Ergänzung von Tasks und die Aufteilung der Tasks an die Paare.
Hinweis: Bei den Profis findet dieses Meeting täglich statt (Daily), bei uns wöchentlich.
Nicht-verwendete Scrum-Methoden
Da wir nicht so viel Zeit für unsere Projekte zur Verfügung haben wie die Profis in den Unternehmen und da unser Projekt nicht mit Kosten verbunden ist, verzichten wir auf folgende Methoden:
Schätzen (Planungspoker - Burn Down Chart)
In realen Softwareentwicklungsprojekten schätzt die Softwarefirma ausgehend vom Pflichtenheft den Aufwand für einen Auftrag und erstellt aufbauend auf diese Schätzung ein Angebot, das natürlich auch noch einen Gewinn einkalkuliert. Dieses Angebot wird dann vom Auftraggeber angenommen oder abgelehnt. Ist die Schätzung der Softwarefirma zu niedrig angesetzt, so wird sie mit dem Projekt Verlust machen. Ist sie zu hoch angesetzt, so wird eine andere Firma den Zuschlag für das Projekt erhalten. Eine möglichst realistische Aufwandsschätzung ist daher essenziell.
Beim Planungspoker schreibt jeder Beteiligte seine Aufwandsvermutung verdeckt auf Papier (oder verwendet – wie der Name nahelegt – Spielkarten mit vorgefertigten Aufdrucken). Gibt es beim anschließenden Aufdecken starke Abweichungen (nach oben oder nach unten), so offenbaren diejenigen ihre Gründe für Ihre abweichende Vermutung. Diese Methode stellt somit Schwierigkeiten in den Vordergrund, die eine Mehrheit evtl. übersehen hat, genauso wie besonders effiziente Lösungsmöglichkeiten, die nur einzelnen aufgefallen sind.
Burn Down Chart: siehe Wikipedia