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?
Diese Artikel könnten Sie noch interessieren:
- Zielvereinbarungen funktionieren nicht …zumindest nicht in der Software-Entwicklung. Eine oft gehörte Beschwerde, und...
- iLife-Applikationen nicht verschieben! Bei mir auf dem Mac habe ich im Programme-Ordner einen...
- Schlanke Zeiten [OOP 2010] Ein paar Gedanken zum Zeitbegriff in agilen Verfahren. In allen...
Berater, Coach und Trainer für effektive Produktentwicklung
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
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
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?
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
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
Wenn man agil entwickelt, braucht man eine vernünftige Testabdeckung. Kann gut sein, dass man beim Durchrechnen feststellt, dass die Kosten die möglichen Einsparungen weit übertreffen (z. B. bei altem Code, wenn die Programmiersprache kaum Unterstützung für Tests bietet, …)
Oder wenn die Entwickler teures Spezialwissen benötigen, das aufzubauen mehrere Jahre braucht.
Dann wird es eben schwierig mit dem kollektiven Code-Eigentum. Das bedeutet dann, wenn ein Spezialist in Verzug kommt, ist auch der Sprint im Verzug.
Ich denke, auch wenn man eine sehr unerfahrene Truppe hat, wird das Ergebnis besser, wenn die vielen Anfänger von einer erfahrenen Führungskraft angeleitet und kontrolliert werden.
Falls es beim Kunden gar kein Interesse an monatlichen Releases gibt, und man einen Vierteljahreszeitraum recht gut planen kann, wird das Ergebnis mit agiler Entwicklung schlechter sein als mit einem schlanken geplanten Prozess mit Dreimonatsiterationen. Die vielen Meetings kosten eben Zeit und Geld.
Wie sieht es den bei Software Projekten aus, bei denen die Software als Medizinprodukt endet? Und wir die Normierung der 62304 anwenden müssen. Ist da ein agiles Arbeiten überhaupt machbar?