nicht angemeldet
Hi Lude,
wenn Du eine gute Ausbildung genossen hast, hat man Dich die Essays aus "The mythical man-month" von Fred Brooks lesen lassen. Wenn Du gut bist (im Sinne der Ingenieur-Wissenschaften), hat diese Lektüre Deine Haltung zu Konzepten des Software-Engineerings so grundlegend beeinflußt, daß Du diesen Thread nicht eröffnet haben würdest [1]. Denn dann wäre Dir deutlich geworden, daß einige Visionäre sich bereits Mitte der 70er Jahre des vergangenen Jahrhunderts keiner Illusion mehr hinsichtlich des garantierten Scheiterns Deiner Typen I,II und III hingaben (IV scheint mir kein spezifischer Typ zu sein, sondern eine Selbstverständlichkeit für jeden Entwickler).
Aus Deinen Fragestellungen zu diesem Thema hallt die winselnde Hilflosigkeit der Auftraggeber und Manager von Softwareentwicklern unserer Zeit; diese lähmende und permanent Fehlentscheidungen erzeugende Unfähigkeit, die angesichts der unüberwindbar komplexen und weitgespannten Anforderungen der Softwareentwicklung nach einem Strohhalm in Form eines approbierten, genormten Verfahrens zu greifen sucht. Im Grunde ein spezialisierte Form von Lebensunfähigkeit, die ihre Ursache in der Pest der unserer Zeit hat: die BWL (Himmel - es wird emotional, tu einfach so, als hättest Du den letzten Satz nicht gelesen; dieses Thema läßt sich nur an langen Abenden mit Wein vor dem Kaminfeuer diskutieren, niemals online...).
Aktuell läßt sich diese Schauspiel am Beispiel "Extreme Programming" beobachten: jeder spricht davon, daß soll was tolles sein, weniger Entwicklungszeit, wesentlich höhere Erfolgsquote, blah blah blah. Aber es setzt sich nur quälend langsam durch; denn die Entscheider blicken nicht durch, ihre Phantasie versagt völlig bei der Vorstellung, zwei Entwickler gemeinsam an einem Terminal arbeiten zu lassen und auch sonst alle approbierten und zertifizierten Methoden über Bord zu werfen (und was noch viel bedeutender ist: sie haben keine persönliche Erfahrung mit dieser Methode gemacht und werden sie nie machen, denn sie sind BWLer und keine Ingenieure; was bedeutet, daß sie es niemals richtig beurteilen können werden).
Aus meiner eigenen Erfahrung würde ich die Sache so sehen, wie ich es bei Stephen Black gelernt habe: "Surgical Team im chaotischen Raum".
1. Ein oder mehrere Teams sind aufgebaut wie ein chirurgisches Team im OP: _ein_ Entwickler (vielleicht nach Extreme-Programming-Manier zwei, die wie einer arbeiten, die Erfahrung habe ich nur einmal gemacht und das ist schon so lange her), der über eine Gruppe von Leuten verfügt, die ihm zuarbeiten (Tester, Werkzeugmacher, Dokumentierer, Rechercheur, Kommunikator, ...)
2. Zerhacken der unklaren und wechselnden Anforderungen in nach Prioritäten geordnete Häppchen, die drängendsten werden zuerst abgearbeitet, die unbedeutenden verschwinden über die Laufzeit von selbst, permanentes Briefing hält das Moving Target im Fadenkreuz
Ergo muß Softwareentwicklung meiner Meinung nach im Rambo-Stil ablaufen: Entwickler wird nachts im Sturm über unbekanntem Dschungelgebiet mit dem Fallschirm abgeworfen und muß sich taktisch lavierend mit viel Erfahrung und Agilität durchkämpfen. Das bedeutet für den Auftraggeber und das Management, auf solche Rambos Zugriff haben zu müssen - und die gibt es so häufig wie schwarze Perlen im Ozean; das bedeutet, solchen Rambos vertrauen zu müssen, ohne genau zu wissen, wo es hingeht; das bedeutet, nur sehr schwer solche Projekte pauschal kalkulieren zu können; das bedeutet, das große Projekte (von denen wir hier sprechen) keine singulären Ereignisse sind, sondern einen permanenten, nie endenden Strom darstellen. Wir haben es also vorwiegend mit Problemen zu tun, die gegen die Natur des BWLers sprechen und somit heutzutage kaum lösbar sind...
hth Robert
[1] Da ich diesen Disclaimer in Diskursen mit Dir wohl immer wieder anbringen muß: ich möchte Dich nicht offensiv oder aggressiv angehen; meine Aussagen ergeben sich ganz natürlich und emotionslos aus den gegebenen Umständen.