Agile Softwareentwicklung
Agile Softwareentwicklung zeichnet sich aus durch
• I. eine kurze Zeitspanne bis zur Lieferung des ersten Releases
• II. kurze Zyklen (wenige Wochen) zwischen den Lieferungen weiterer Releases
• III. die Lieferung von eventuell unvollständigen, aber immer funktionsfähigen Releases
• IV. die Möglichkeit, zu "späten" Zeitpunkten Änderungen zu berücksichtigen
• V. eine konstante, langfristig aufrechtzuerhaltende Entwicklungsgeschwindigkeit
• VI. die Strukturierung eines (Teil-)Projekts um motivierte Einzelne
• VII. selbstorganisierende Teams
• VIII. effiziente Kommunikation von Angesicht zu Angesicht
• IX. das Anstreben von möglichst einfachen, aber herausragenden technische Lösungen
• X. eine gute System- und Software-Architektur
• XI. einen ständigen Verbesserungsprozess
Im Vergleich zu klassischen Vorgehensmodellen ergeben sich einige Unterschiede:
Wegen I. und IV. ist die Erstellung umfangreicher Dokumentation (z.B. Lasten- oder Pflichtenhefte) im Rahmen agiler Prozesse kontraproduktiv. Es bietet sich an, auch Dokumentation agil zu erstellen und zu pflegen, z.B. mit einem Wiki.
Wegen IV. ist die im Falle der Vergabe der Realisierung an einen externen Dienstleister in der Regel nur eine Abrechnung nach Time and Material möglich. Festpreisprojekte (d.h. fester Preis, fester Leistungsumfang, fester Endtermin) erfordern eine möglichst exakte Vereinbarung des Leistungsumfangs, was dazu führt, dass die Änderung der Anforderungen (Creeping Requirements) während der Projektdurchführung auf große Widerstände stößt.
Wegen VIII. sollten die Realisierer und Auftraggeber möglichst in räumlicher Nähe voneinander arbeiten. Das stellt bei externer Projektvergabe höhere Anforderungen an die Reisebereitschaft der Realisierer. Auch an den Auftraggeber werden höhere Anforderungen gestellt, intensivere Kommunikation erfordert während der Projektlaufzeit einen höheren Zeitaufwand.
Quelle
http://agilemanifesto.org/principles.html
• I. eine kurze Zeitspanne bis zur Lieferung des ersten Releases
• II. kurze Zyklen (wenige Wochen) zwischen den Lieferungen weiterer Releases
• III. die Lieferung von eventuell unvollständigen, aber immer funktionsfähigen Releases
• IV. die Möglichkeit, zu "späten" Zeitpunkten Änderungen zu berücksichtigen
• V. eine konstante, langfristig aufrechtzuerhaltende Entwicklungsgeschwindigkeit
• VI. die Strukturierung eines (Teil-)Projekts um motivierte Einzelne
• VII. selbstorganisierende Teams
• VIII. effiziente Kommunikation von Angesicht zu Angesicht
• IX. das Anstreben von möglichst einfachen, aber herausragenden technische Lösungen
• X. eine gute System- und Software-Architektur
• XI. einen ständigen Verbesserungsprozess
Im Vergleich zu klassischen Vorgehensmodellen ergeben sich einige Unterschiede:
Wegen I. und IV. ist die Erstellung umfangreicher Dokumentation (z.B. Lasten- oder Pflichtenhefte) im Rahmen agiler Prozesse kontraproduktiv. Es bietet sich an, auch Dokumentation agil zu erstellen und zu pflegen, z.B. mit einem Wiki.
Wegen IV. ist die im Falle der Vergabe der Realisierung an einen externen Dienstleister in der Regel nur eine Abrechnung nach Time and Material möglich. Festpreisprojekte (d.h. fester Preis, fester Leistungsumfang, fester Endtermin) erfordern eine möglichst exakte Vereinbarung des Leistungsumfangs, was dazu führt, dass die Änderung der Anforderungen (Creeping Requirements) während der Projektdurchführung auf große Widerstände stößt.
Wegen VIII. sollten die Realisierer und Auftraggeber möglichst in räumlicher Nähe voneinander arbeiten. Das stellt bei externer Projektvergabe höhere Anforderungen an die Reisebereitschaft der Realisierer. Auch an den Auftraggeber werden höhere Anforderungen gestellt, intensivere Kommunikation erfordert während der Projektlaufzeit einen höheren Zeitaufwand.
Quelle
http://agilemanifesto.org/principles.html