 |
| | | | | Beschreibung | | Agile Ansätze sind iterativ. Das bedeutet, die Software wird Schritt für Schritt entwickelt, von einer laufenden Version zur nächsten. Zwei Wochen sind beispielsweise in XP-Projekten eine typische Iterationslänge. Nach wenigen Iteration wird ein Release an den Kunden ausgeliefert und von diesem abgenommen. Jedes Release wird so entworfen, dass es für den Kunden nutzbar ist.
Einige agile Ansätze sind zusätzlich evolutionär. Die Systemarchitektur wird zu Beginn eines Projektes nur soweit festgelegt, wie es für die erste Iteration notwendig ist. Von Iteration zu Iteration werden kleinere Designs und die Architektur fortlaufend verbessert, beispielsweise durch Refactoring. Ein rein evolutionäres Vorgehen birgt allerdings das Risiko, große Teile eines Systems überarbeiten zu müssen, wenn sich die Architektur in einem Release deutlich ändern muss.
Agile Prozesse sind leichtgewichtig, sie beschränken sich auf die wesentlichen, unbedingt notwendigen Projektergebnisse, Rollen und Vorgabe. Sie verzichten insbesondere umfangreiche, stark reglementierte Dokumentation. Der Kunde bekommt genau das, wofür er bezahlt. Hinter dem Weglassen bestimmter Kapitel oder ganzer Dokumente steht ein aktiver Entscheidungsprozess, im Projekt wird entschieden, was erforderlich ist und was nicht. Agilität sollte keine Ausrede für mangelnde Dokumentations-Motivation sein. Agile Methoden unterscheiden sich deutlich in den geforderten Dokumentationsumfängen. Während in XP-Projekten praktisch keine Dokumentation gefordert wird, schreibt Crystal-Orange Anforderungs- und Designdokumente vor. Der Dokumentationsumfang wird auch durch Teamgröße und Kritikalität des Projektes bestimmt.
Die Planung ist flexibel und orientiert sich am aktuellen Nutzen für den Kunden. Mit Änderungen wird aktiv umgegangen, diese werden bei Bedarf in das aktuelle oder das nächste Release eingeplant. Der Kunde ist an der Planung des nächsten Releases beteiligt, er bestimmt die Inhalte des Releases, so dass es für ihn den größten Nutzen hat.
Der Kunde wird eng in Projekte eingebunden. Er sollte leicht erreichbar oder sogar vor Ort sein, um sofort Fragen zu beantworten und Entscheidungen zu treffen. Nutzbare und nützliche erste Versionen der Software werden dem Kunden früh, bereits nach wenigen Wochen, zur Verfügung gestellt. Schnelles Feedback wird erzielt und Fehlentwicklungen, die auf Unklarheiten und Missverständnissen beruhen, werden vermieden. Weitere Releases folgen in kurzen Abständen (z.B. im Monatsrhythmus).
Zusammenarbeit und Verantwortung des Einzelnen und des Teams werden aktiv gefördert. Teamgeist, Ehrlichkeit und Offenheit sind zentrale Werte. Die Verantwortung jedes Projektmitglieds für das Ergebnis wird betont, das macht die Leichtgewichtigkeit erst möglich. Häufig vergleichen agile Methoden die Software-Entwicklung mit einem Mannschafts-Spiel, um den Teamarbeitsaspekt und den Spaß zu betonen.
Einige agile Methoden sind adaptiv, sie enthalten einen Mechanismus, mit dem das Vorgehensmodell automatisch an die aktuelle Projektsituation angepasst werden kann. Entwickler überprüfen beispielsweise regelmäßig, ob die verwendeten Methoden effektiv und effizient sind. In der Crystal Methodenfamilie ist diese Praktik unter dem Namen „Methodology-Tuning Technique“ enthalten, in Scrum ist diese Adaption in dem Sprint-Review (s.u.) enthalten.
Umfangreiche Regressionstests werden implementiert, insbesondere UnitTests. Diese stellen sicher, dass bei den kurzen Releasezyklen und häufigen Änderungen die Qualität erhalten bleibt und sich nicht durch Refactoring oder andere Änderungen Fehler einschleichen.
| |
| | | | | | | | | | | | | Zu dieser Seite wurden noch keine Kommentare oder Bewertungen abgegeben. |
|
| | | | | | | | Vorgehen in agilen Projekten | | | | | | Erfahrungen | | | | | | | | | | Weitere Themen | | | | | | | | | | | | | |
|
Glossar 
Forschungsprojekte 
Anbieterverzeichnis 
Datenbanksuche 
Highlights 
Eintrag kommentieren