Kommentare zu: Wann sollte man nicht agil arbeiten? [OOP 2010]

Von: Julian

Julian — Fri, 02 Jul 2010 08:41:52 +0000

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?

Von: Charly

Charly — Mon, 10 May 2010 21:30:17 +0000

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.

Von: Peter Quiel

Peter Quiel — Wed, 20 Jan 2010 16:34:51 +0000

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

Von: Peter Quiel

Peter Quiel — Wed, 20 Jan 2010 16:29:58 +0000

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

Von: Matthias Bohlen

Matthias Bohlen — Fri, 15 Jan 2010 09:24:16 +0000

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?

Von: Matthias Bohlen

Matthias Bohlen — Sun, 10 Jan 2010 12:57:45 +0000

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

Von: Dirk Voigt

Dirk Voigt — Sun, 10 Jan 2010 10:47:15 +0000

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