Wann sollte man nicht agil arbeiten? [OOP 2010]
Gestern war ich in einem Gebäude mit Erdgeschoss und 8 anderen Stockwerken. Der Aufzug brachte mich in den 7. Stock, dann konnte ich mir aussuchen, auf einer Treppe oder mit einem anderen(!) Aufzug in den 8. Stock zu kommen, wo ich den Besprechungsraum, mein eigentliches Ziel, finden würde.
Einer der Teilnehmer am Workshop in diesem Raum sagte: “Vielleicht ist das Gebäude agil entwickelt worden, die Anforderung für den 8. Stock kam erst später. Oder vielleicht wurden die Tests eingespart?”
Allgemeines Gelächter in der Gruppe.
Das bringt mich auf die Frage: Wann ist es eigentlich sinnvoll, agil zu entwickeln und bei unvollständigen Informationen trotzdem weiterzumachen? Eigentlich ganz einfach: Agil zu entwickeln ist angebracht, wenn die Kosten für nachträgliche Änderungen geringer sind als die Verschwendung (waste, muda), die durch das Streben nach initialer Perfektion der Anforderungen ausgelöst werden würde.
Wann gilt diese Bedingung? Wahrscheinlich für fast alle “normalen” Softwareprojekte – für nur ganz wenige gilt sie nicht. In diesen Fällen sollte man dann besser nicht agil entwickeln.
Was meinen Sie – wann sollte man besser zuerst perfekt planen, dann umsetzen?
vor 2 Monaten
Agilität ist sicher eine große Chance, gleichzeitig beinhaltet sie auch immer die Gefahr, dass sie als Feigenblatt genutzt wird: Wenn das Team nicht das Standing hat, mit dem Auftraggeber klare Anforderungen zu diskutieren, sonder statt dessen agil beginnt, sind wir wieder da wo wir vor der Agilität schon immer waren: Projektstart ohne geklärte Rahmenbedingungen. Mehr unter http://www.projektmanagementhandbuch.de.
Gruß, Dirk Voigt
vor 2 Monaten
Hallo Herr Voigt,
das ist klar, ohne vernünftig geklärte Anforderungen wird der Projekterfolg nicht mehr messbar und damit unwahrscheinlich.
Meine Frage geht jedoch in eine bestimmte Richtung: Gibt es “Klassen” von Projekten, die ganz normal und absichtlich, aus ihren Grundeigenschaften heraus (nicht wegen Fehlern oder Dysfunktion des Teams) besser nicht agil entwickelt werden sollten?
Kann man überhaupt einfach sagen: Bei einem Projekt mit den Grund-Eigenschaften X, Y oder Z lohnt sich agiles Vorgehen nicht?
Beispiele könnten Systeme sein, deren nachträgliche Änderungskosten so hoch sind, dass sich ein im Vorhinein perfektionierter Plan wirklich effektiv auch lohnt.
Gibt es nach Ihrer Ansicht Systeme, bei denen diese Eigenschaft ganz normal ist und keinen Fehler darstellt?
Gruß, Matthias Bohlen
vor 1 Monat
Jetzt kam schon lange kein Kommentar mehr – heißt das, solche Projekte, die man besser nicht agil abwickeln sollte, gibt es nicht? Oder zumindest: Sie sind sehr selten?
vor 1 Monat
Ich habe selten ein Softwareprojekt gesehen, in dem im Laufe der Entwicklung nicht große Probleme aufgetreten sind.
Denn mit einer Softwareversion lernt man wieder mehr über die Domäne. Dieses Wissen resultiert in Anpassung der Software – man baut also ein Haus und wenn es “fertig” ist, erkennt man, dass 7 Stockwerke nicht aussreichen.
Ist das nun ein Resultat schlechter Planung? Nein, Softwareentwicklung ist ein wissenschaftlicher Prozess. In der Wissenschaft kann man eben nicht wissen, wann etwas erforscht sein wird.
Deshalb bedeutet für mich Agiltät in einem Vorgehensmodell nicht ohne Plan ans Werk zugehen sondern zu planen den Plan neu zu planen.
“Planing is everything, the plan is nothing”
Und das ist für mich in Scrum integriert. Ich plane, lerne aus neuen Softwareversionen und plane erneut.
Gruß,
Peter Quiel
vor 1 Monat
Um auf Ihre Frage wirklich einzugehen.
Mir fallen nur zwei Arten von Projekte ein, bei denen eine agile Vorgehensweise nicht unbedingt notwendigt ist.
1. Eine bestehen Anwedung 1 zu 1 auf eine neue Technologie migrieren.
2. Ein Software – die ich schonmal entwickelt habe – nochmal neu entwickeln.
Aus meine Sicht sind beide Vorhaben nicht sehr sinnvoll, aber dannach wurde ja auch nicht gefragt.
Viele Grüß,
Peter Quiel