Sowas kenn ich in der Juristerei gar nicht. Wenn hier etwas ansteht, dann spricht man sich kurz ab und zieht die Aufgaben durch. Wenn jeder motiviert und intelligent ist, dann braucht man keine seltsamen Methoden und Sprints.
Das liegt daran, dass in der Juristerei nicht 1000 Einflussvektoren existieren, sondern "nur" evtl. 100.
Je nach Größenordnung von so einigen IT-Projekten müsste man alle Juristen einer Stadt mit dem kompletten Fall beschäftigen. Das wäre dann einer, der alle Teilgebiete der Juristerei betrifft.
Bei riesigen Fällen spricht man sich auch nicht nur mal kurz ab und geht los. Da macht man auch Sprints, nur nennt man die nicht so.
IT ist mehr als ein paar Server, die irgendwie laufen, ein paar Switche, die irgendwie laufen, ein paar Windowse, die irgendwie laufen und ein paar Applikationen, die irgendwie laufen.
Das Problem bei IT-Projekten ist, dass idR. die gesamten Geschäftsprozesse daran hängen.
Während eine Anwaltskanzlei evtl. noch mit einem DokumenteServer, 20 PCs, einem Fax und eine VoIP-TK-Anlage auskommt, läuft in anderen Firmen jeder furz über IT-Systeme. Steht die IT, können die MAs am Ende noch Wasser für den Kaffee machen und das war es dann.
Um so wichtiger ist eine saubere IT und damit deren Systeme.
Das Problem bei IT-Projekten ist, dass das klassische Wasserfallmodell, V-Modell, what ever, schnell an seine Grenzen kommt, weil das Gesamtsystem so komplex ist, dass klassisches Requirementengineering an seine Grenze kommt oder man während dessen eigentlich schon das Projekt umsetzt, während man eigentlich noch die Vorarbeit machen sollte.
Und daher haben sich agilere Methoden angeboten. Ob das immer besser ist, steht auf einem anderen Blatt.
(Man muss die Entwicklung eines Excel-Formblattes nicht mit Scrum machen,.)
Es ist ja nicht so, dass das alles irgendwelche "Versuch macht Klug"-Strategien sind.
Das Ganze wird dadurch umso wichtiger, als dass IT-Projekte im Regelfall keine historische Komponente haben.
Sowas ist oftmals was neues, weil es eben irgendwie immer eine spezifische Lösung ist.
Und wer sagt denn, dass die IT nicht mit dem Kunden/Fachbereich/what ever spricht?
Versuchst du hier etwa, aufgrund eines geschilderten, also nicht selbst erlebten, Falls eine Verallgemeinerung?
Arbeitet man so als Jurist? Ist das die Interpretation von "so lange unschuldig bis das Gegenteil bewiesen ist"?
Gilt auch, dass wenn ein Golf-Fahrer, der bei Rot über die Ampel gefahren ist, dass alle Golf-Fahrer bei Rot über die Ampel fahren?
Lernt man das im Jura-Studium?
Darf ich daher annehmen, dass alle Juristen derart unreflektiert sind? Gut!
Scheinbar hat das Auswendiglernen so einige andere Synapsen verdrängt.
In der klassischen Wissenschaft verallgemeinert man nur dann, wenn die Statistik einen hinreichenden Anhaltspunkt liefert.
Scheinbar wird sowas im Jurastudium nicht vermittelt. Schade, das würde so einiges auf solidere Füße stellen.
Es gibt natürlich auch in der IT Projekte, die schief gehen.
Warum sollte "die IT" frei von Fehlern sein?
Und auch gibt es in der IT eben Persönlichkeiten, die "speziell" sind. Nur gibt es diese Persönlichkeiten auch überall. Es gibt auch Architekten, mit denen willst du nichts zu tun haben, oder Zahnärzte, oder Einzelhandelsfachangestellte, oder Fleischer, oder Schornsteinfeger oder oder oder.
Charaktere gibt es überall.
Oftmals beruhen Missverständnisse aber auf mangelndem Verständnis bezüglich der Komplexität von Sachverhalten.
Nur weil der Rohrleger Kalle schon 100 PCs für sich und sein Umfeld zusammengebaut hat, ist er noch lange nicht in der Lage ein Netzwerk (inkl. aller relevanten Sachen) eine Serverlandschaft oder eine neue Software aufzubauen.
Da gehört schon viel mehr dazu. Und das ist in der Regel so viel, dass selbst der krasseste Ober-ITler-Marc-The-Sacker-Sackerbörg das nicht alles in einer Person abhandeln kann. Und daher sind IT-Projekte manchmal so "aufgebläht".
Denn ein Fehler by Design kann enorme Auswirkungen haben. Genauso wie es beim Brückenbau ungünstig ist, wenn der Typ, der nur Stahlseile macht, plötzlich die Gründung des 200m hohen Brückenpfeiler machen soll.
@Ashampoo
Es gibt überall Anforderungsmanagement. Nur funktioniert das eine so und das andere anders und das eine ist da besser und das andere dort. Rest siehe oben.
Auch im Scrum gibt es RE, nur ist das eben agiler, wie eben auch die Entwicklung etwas agiler ist, ohne dabei ständig alles über den Haufen zu werfen, wobei letzteres in extremen Ausnahmefällen auch geht und gehen muss, auch wenn uncool.
............ 
