Sonstiges > Offtopic

Projektmanagement: Lastenheft, Pflichtenheft, Statusreport etc.

<< < (2/2)

flaite:
Wasserfall hab ich in verschiedenen Ausprägungen erlebt. Es gibt eine Art, in der Leute, die das "fachliche" Modell erstellen, sehr viel Zeit eingeräumt wird und den Programmierern nur noch sehr wenig Zeit bleibt. Obwohl bei den Proggern Interesse besteht, mit sowas wie Junit-Tests zu arbeiten, wird argumentiert, dass dies nicht gebraucht wird. Und es würde helfen.
Politisch sieht es dann so aus, dass ein fachliches Modell niemals eine Error-Meldung erzeugt, Programmcode aber schon.
D.h.: auch wenn der Fehler im Lastenheft liegt, sind letztlich die Programmierer für die Ausbügelung des Fehlers verantwortlich, da dem oberen Management die Verfolgung eines Fehlers auf das Lastenheft zu abstrakt ist.

--- Zitat ---Ein erschreckender Eindruck, den ich habe, ist, dass diese Probleme zum Teil bewusst in Kauf genommen werden -  vielleicht aus Gewohnheit.

--- Ende Zitat ---
Es ist zumindest gut, dass die (aus Erfahrung) die grundsätzlichen Probleme des Prozesses kennen. Ich habe mit unerfahrenen Projekt-Managern zusammengearbeitet, denen das nicht klar war, und das ist definitiv schwerer zu ertragen.
Die Alternative besteht darin, praktisch ganz ohne Prozess zu arbeiten. Das ist oft in Projekten so, die keine besondere Priorität (mehr) haben. Sprich: Maintainance-Programmierung. Da wird oft auf Zuruf gearbeitet, ohne dass sich die Zeit genommen wird, die Auswirkungen von Änderungen auf das Gesamtsystem zu analysieren.
Oder Programmierer haben so viel Macht, dass sie jederzeit ungestraft die "in dem Programm ist es aber so"-Karte spielen können. Und sie glauben ihren Teil des Vertrags - also eine bestimmte Funktionalität in einer gegebenen Zeit zu liefern - jederzeit brechen zu können.

Nur ist dieser Ausstoß an letztlich unnötigen Dokumenten und Unflexibilität etwas, dass in der Betriebswirtschaft bekämpft wurde. Das ist der Kern von sowas wie Just in time Produktion und Total Quality Management. Ich hab deshalb Interesse an agilen Prozessen, weil ich mir ernsthaft die Frage stelle, wie lange das eigentlich noch so gut geht.

Ich hab genug traditionelle Projekte erlebt, in denen früh klar wurde, dass das Ergebnis etwas sein wird, dass nicht den Anforderungen entsprechen wird. Also gab es Nachverhandlungen. Man kann also auch nicht sagen, dass mit einem Wasserfallmodell gewährleistet ist, dass der Gesamtpreis früh quantifizierbar wäre.
Prozessinnovationen haben sich in anderen Branchen auch nicht sehr schnell durchgesetzt. Ich hab aber für mich beschlossen, mich damit zu beschäftigen.
In diesem Land wird genug in andere Länder outgesourced. Ich kann über die "bösen" Manager schimpfen, die im Grunde nur Agenten der Angleichung von Lebensverhältnissen unter den Bedingungen von

--- Zitat ---The global economic playing field is being leveled.

--- Ende Zitat ---
sind.
... oder ich kann schauen, ob es nicht vielleicht doch bessere Wege gibt. Unser komparativer Vorteil besteht hauptsächlich in der Nähe zum Kunden. Für agile Prozesse ist das ein bedeutenderer Vorteil als im Wasserfallmodell. 
Wenn man mit traditionellen Prozessen arbeitet, sollte man zumindest die Schwachstellen gut kennen. Das war die Intention meines vorangegangenen Postings.

Gruß Axel

Bruce Willis:
Hallo,

danke an alle Beteiligten!

Gruß
Leo

Navigation

[0] Themen-Index

[*] Vorherige Sete