TOP TOC 
Agile . since Jun 23 . Index . DOCs TOP TOC
Eine Gemeinsamkeit der verschiedenen agilen Entwicklungsmethoden ist, dass das zu entwickelnde System in vielen Iterationen (oder „Sprints“) entsteht. Iterationen dauern üblicherweise ein bis vier Wochen. Am Ende jeder Iteration steht ein getestetes und lauffähiges System („potentially shippable code“) mit neu dazu gekommener Funktionalität. Agile Entwicklungsmethoden bedienen sich in unterschiedlichem Ausmaß weiterer agiler Praktiken wie Test-Driven Development (TDD), Refactoring etc. Im Gegensatz zu Wasserfall-Projekten kann in agilen Projekten auf sich ändernde Anforderungen oder Prioritäten schnell reagiert werden. Es gibt einen sehr frühen Return on Investment, weil der Kunde schon nach der ersten Iteration ein lauffähiges System hat, das er produktiv einsetzen kann. Ein komplettes Scheitern des Projekts (kein lauffähiger Code), wie es bei Wasserfall-Projekten immer wieder vorkommt, ist wenig wahrscheinlich.
Agile . since Jun 23 . Index . DOCs TOP TOC
Pair Programming
Pair Programming ist Teil der agilen Entwicklungsmethode XP (Extreme Programming), kann aber auch in anderen Entwicklungsmethoden eingesetzt werden. Zwei Entwickler arbeiten gemeinsam am Bildschirm. Der „Pilot“ („Driver“) schreibt den Code. Der „Navigator“ („Observer“) prüft den Code und denkt über Verbesserungen am Design nach. Wenn nötig, wird sofort diskutiert. Die Rollen werden oft gewechselt, z.B. alle paar Minuten. Die Paarzusammensetzungen im Projektteam werden ebenso gewechselt, beispielsweise zweimal am Tag. Der Vorteil von Pair Programming ist die höhere Qualität der Software (je nach Studie 15 % bis 50 % weniger Fehler). Viele Fehler können sofort am Bildschirm entdeckt werden und ein besseres Design kann gefunden werden. In Projekten, die Pair Programming einsetzen, kennen sich mit jedem Teil des Codes mindestens zwei Entwickler sehr gut aus. Damit ist das Projekt weniger stark gefährdet, wenn einzelne Projektmitarbeiter zum Beispiel durch Krankheit oder Kündigung ausfallen. Der Aufwand für Pair Programming ist nicht, wie man vielleicht annehmen könnte, 100 % mehr als bei Einzelprogrammierung, sondern (je nach Studie) 15 % bis 85 % mehr. Diesem Mehraufwand stehen durch die verbesserte Qualität Einsparungen später im Projekt gegenüber.
Design- und Code-Reviews in FDD (Feature Driven Development)
In der agilen Entwicklungsmethode FDD gibt es für jedes zu entwickelnde Feature auch die Meilensteine „Design Inspection“ und „Code Inspection“. In der Design-Inspektion werden das Design und Abnahmetests geprüft. In der Code-Inspektion werden der Code und Abnahmetests geprüft. Der Chef-Programmierer als Leiter des Projektteams bestimmt den Grad der Formalität der jeweiligen Inspektion. Im Gegensatz zu Reviews in Wasserfall-Projekten ist bei den Inspektionen in FDD die Gefahr von psychologischen Problemen geringer, weil der Owner des zu prüfenden Artefakts nicht eine Einzelperson ist, sondern das gesamte Feature-Team. Der Einsatz von Inspektionen in FDD wird mit wissenschaftlichen Untersuchungen begründet, die zeigen, dass Code-Inspektionen Fehler mit weniger Aufwand beseitigen können als Tests. Im Gegensatz zur Entwicklungsmethode XP mit seinem Pair Pogramming vertraut FDD voll auf klassische Inspektionen. Das ist einer der Gründe, warum FDD unter den agilen Entwicklungsmethoden als diejenige angesehen wird, die den klassischen Vorgehensmethoden am nächsten steht.
Sprint Review Meetings in Scrum
In der agilen Entwicklungsmethode Scrum erfolgt nach einem Sprint ein informelles Review durch Team, Product Owner und Stakeholder. Dazu wird das Ergebnis des Sprints durch das Team vorgeführt. Product Owner und Stakeholder geben Feedback, das in die weitere Arbeit mit einfließt. Im Sprint Review Meeting werden keine Folien gezeigt, auch kein Quell-Code, sondern es wird die laufende Software vorgeführt. Das Sprint Review Meeting ist also kein Review im Sinne einer Inspektion, welche Fehler auf Artefakt-Ebene finden will. Das Sprint Review Meeting trägt vielmehr einige Merkmale eines Abnahmetests. Reines Scrum hat erstmal keine „reviewartigen“ Mechanismen im Sinne von Inspektionen. Daher ist es empfehlenswert, in Scrum-Projekten zusätzlich (mindestens) die Praktiken Pair Programming oder Inspektionen einzusetzen.