Keep it agile but not simpler
Veröffentlicht auf 26. Oktober 2009
Agile Methoden wie Scrum haben sich inzwischen viele Softwareentwicklungsabteilungen zu eigen gemacht und arbeiten entsprechend dem agilen Manifest:
* Individuen und Interaktionen haben Vorrang vor Prozessen und Werkzeugen.
* Funktionsfähige Produkte haben Vorrang vor ausgedehnter Dokumentation.
* Zusammenarbeit mit dem Kunden hat Vorrang vor Vertragsverhandlungen.
* Das Eingehen auf Änderungen hat Vorrang vor strikter Planverfolgung.
Diese 4 Vorgaben sind meines Erachtens durchaus sinnvoll und ich persönlich ziehe es auch vor in agilen Projekten zu arbeiten. Nicht Prozesse oder irgendwelche teuren Werkzeuge sind für den Erfolg von Projekten verantwortlich, sondern die Menschen dahinter. Ein Produkt muss seinen vordefinierten Zweck erfüllen, dies ist viel wichtiger einzuordnen als eine vollständige Entwicklungsdokumentation. Der gute zum Kunden und direkte Gespräche sind viel wichtiger für den Projekterfolg, wie Streitereien über Vertragsdetails. Das Produkt muss einsatzfähig sein, Änderungen zu akzeptieren ist daher wichtiger als stur Meilensteine zu verteidigen.
Dennoch werden diese 4 Punkte auch gerne misinterpretiert und als Ausreden für "schlampiges" Arbeiten genommen.
Wenn viele Menschen zusammen arbeiten, muss eine gewissen Grundordnung herrschen und der nächste Schritt muss allen klar sein, dazu braucht man Prozesse. Werkzeuge können die Arbeit vereinfachen, ohne Werkzeuge zu arbeiten bedeutet aber auch fahrlässig wichtige Ressourcen zu verschenken.
Gänzlich ohne Dokumentation funktionieren auch die meisten agile Projekte nicht. Es werden nur direkte Gespräche bevorzugt, diese sollten jedoch in persönlichen Notizen der Mitarbeiter festgehalten werden, um sich später ggf. darauf beziehen zu können. Entwickler können ohne definierte Anforderungen nicht zielgerichtet arbeiten und Tester können ohne konkrete Vorgaben nur raten und nicht unterscheiden was gewollt und was wirklich fehlerhaft ist.
Wer sich nicht spätestens, wenn es um Geld geht auf vertragliches stützen kann, dürfte diesen Fehler nur einmal machen. Das offene, klärende Gespräch und der gute Kontakt sind zwar ausdrücklich gewünscht, aber die eigene Absicherung darf dadurch nicht vernachlässigt werden.
Zusätzlich darf das Ende eines Projektes nicht aus denn Augen verloren werden vor lauter Änderungen am Produkt. Wer nie zum Ziel kommt, kann nicht abschließen und auch nichts neue beginnen.
Mehr zum agilen Manifest:
http://scrum-master.de/content/view/62/25/
* Funktionsfähige Produkte haben Vorrang vor ausgedehnter Dokumentation.
* Zusammenarbeit mit dem Kunden hat Vorrang vor Vertragsverhandlungen.
* Das Eingehen auf Änderungen hat Vorrang vor strikter Planverfolgung.
Diese 4 Vorgaben sind meines Erachtens durchaus sinnvoll und ich persönlich ziehe es auch vor in agilen Projekten zu arbeiten. Nicht Prozesse oder irgendwelche teuren Werkzeuge sind für den Erfolg von Projekten verantwortlich, sondern die Menschen dahinter. Ein Produkt muss seinen vordefinierten Zweck erfüllen, dies ist viel wichtiger einzuordnen als eine vollständige Entwicklungsdokumentation. Der gute zum Kunden und direkte Gespräche sind viel wichtiger für den Projekterfolg, wie Streitereien über Vertragsdetails. Das Produkt muss einsatzfähig sein, Änderungen zu akzeptieren ist daher wichtiger als stur Meilensteine zu verteidigen.
Dennoch werden diese 4 Punkte auch gerne misinterpretiert und als Ausreden für "schlampiges" Arbeiten genommen.
Wenn viele Menschen zusammen arbeiten, muss eine gewissen Grundordnung herrschen und der nächste Schritt muss allen klar sein, dazu braucht man Prozesse. Werkzeuge können die Arbeit vereinfachen, ohne Werkzeuge zu arbeiten bedeutet aber auch fahrlässig wichtige Ressourcen zu verschenken.
Gänzlich ohne Dokumentation funktionieren auch die meisten agile Projekte nicht. Es werden nur direkte Gespräche bevorzugt, diese sollten jedoch in persönlichen Notizen der Mitarbeiter festgehalten werden, um sich später ggf. darauf beziehen zu können. Entwickler können ohne definierte Anforderungen nicht zielgerichtet arbeiten und Tester können ohne konkrete Vorgaben nur raten und nicht unterscheiden was gewollt und was wirklich fehlerhaft ist.
Wer sich nicht spätestens, wenn es um Geld geht auf vertragliches stützen kann, dürfte diesen Fehler nur einmal machen. Das offene, klärende Gespräch und der gute Kontakt sind zwar ausdrücklich gewünscht, aber die eigene Absicherung darf dadurch nicht vernachlässigt werden.
Zusätzlich darf das Ende eines Projektes nicht aus denn Augen verloren werden vor lauter Änderungen am Produkt. Wer nie zum Ziel kommt, kann nicht abschließen und auch nichts neue beginnen.
Mehr zum agilen Manifest:
http://scrum-master.de/