nicht angemeldet
Hi,
Das kann man so allgemein nicht sagen, dafür müßte man wissen, wer die 16 sind, welche Art Software produziert werden soll und wer der Kunde ist. Patentrezepte gibt es nicht.
Software rund ums Leasing.
Eigentlich waren das alles rethorische Fragen, die mußt Du Dir erst selber beantworten bevor das andere tun können.
Webanwendungen, SOAP Services, rich clients, "OLTP"- und "OLAP"-Anwendungen ...
Bitte keine Buzzwords, die sind hier vollkommen überflüssig und ich reagiere außerdem allergisch darauf.
Wer entscheidet über die Entwicklungsrichtung der Software? Der Kunde oder der Entwickler oder der eigentliche Bedarf des Kunden?
Was ist eine Entwicklungsrichtung?
Welche Basis, welche Features, welche Bugs sind bedrohlich, welche verzeihlich usw.
---
Beispielshaft aber doch mal etwas kommentiert:
Wie wird mit alter Software verfahren; wie mit Fehlentwicklungen?
Alte Software wird ausser Betrieb genommen, wenn es erforderlich ist.
Was machst Du mit Kunden, die die alte Software benutzen? _Müssen_ die updaten? Können die evt den Code käuflich erwerben? Können die das auch schon vorher (Code mag dabei treuhänderisch verwaltet werden, die kaufen also nur das Recht im Pleitefall o.ä. den Code zu erhalten)?
Fehlentwicklungen werden nicht in Betrieb genommen, d.h. das Scheitern von Projekten wird akzeptiert.
Und was wird aus dem Material? Schmeißt ihr das weg? Keine gute Idee, kann ich Dir sofort sagen. Ist auch die einzige Empfehlung, die ich hier geben kann.
Schreib doch mal ein paar Saetze zur ins Auge gefassten Aufstellung des Teams.
Kam nicht klar genug raus, das das keiner kann ohne genauen Einblick in alle Details?
Werden solche Strukturen erfolgreich gefahren?
Es ist durchaus möglich, das die von Dir beschrieben Struktur funktionieren kann. Wenn die Mitarbeiter mitspielen, der Kunde, die Art der Software, der Kapitalgeber, der Gewinnnehmer, das Wetter ...
Ein kleines Beispiel:
Beim XP wird empfohlen zwei Programmierer auf einen Platz zu setzen, damit die gegenseitig befruchten/über die Schulter schauen. Damit das funktioniert müssen beide auch zusammenpassen, denn es kann alles passieren: "verstehen sich blendend" -> "neutral" -> "bringen sich gegenseitig um" wobei noch die Ziet berücksichtgt erden muß, da nicht bekannt ist, ob die sich nicht nach der Hälfte des Projektes derartig auf den Sackgehen, das sie sich regelmäßig nach dem Frühstück prügeln. Oder umgekehrt: es rauft sich zusammen. Selbst wenn die sich blendend verstehen, muß es nicht unbedingt die Qualität des Codes erhöhen oder den Durchsatz. Es kann auch sein, das die beiden trotz regelmäßiger Prügelei den besten Code der Firma auswerfen und auch noch pünktlich fertig sind.
so short
Christoph Zurnieden