Zitat Zitat von derBenny Beitrag anzeigen
Oder man macht es wie die Japaner. Wenn die merken, dass die Zeit nicht reicht, dann fragen sie nicht nach einer Verschiebung der Frist, sondern arbeiten eben die Nächte durch ...
Oder man macht es wie Redmond und verschiebt zweimal den Termin, dann entfernt man einfach so lange Features und kürzt die QA-Phase, bis es hinkommt. Den "Nächte durcharbeiten"-Kram macht man parallel. Außerdem stellt man erst noch 1000 Entwickler ein.


Es gibt wirklich keine optimale Lösung. Man kann zwar nach ISO-Standard arbeiten und Kram wie Ist- und Sollanalysen machen, Gantt-Diagramme und Risikotabellen erstellen etc., aber das macht wirklich nur bei größeren kommerziellen Projekten Sinn. Wenn man nur mit zehn Leuten an einer kleinen Anwendung rumbastelt wird der Aufwand für die korrekte Abarbeitung der Vorschriften fast schon größer als der der eigentlichen Entwicklung.

Idealerweise sollte man einfach so viele Informationen erarbeiten, wie jeder Mitarbeiter braucht, um jederzeit über den aktuellen Status und die noch ausstehenden Sachen im Bild zu sein. Außerdem sollte man sich ein Entwicklungsmodell suchen und dementsprechend arbeiten - wenn man agil entwickelt ist der ISO-Standard teilweise eher hinderlich als nützlich, während er bei einem traditionellen Wasserfallmodell praktisch unabdingbar ist.

Absolut extrem wichtig ist die Kommunikation zwischen den Entwicklern. Jeder muß jederzeit im Bild sein, wie es um das Projekt steht und wo noch was getan werden muß. Wenn man einen Spezialisten für ein Thema hat so sollte er den anderen genug davon vermitteln, daß im Notfall jemand für ihn einspringen kann. Und die Leute sollten erreichbar sein. Wenn die Reaktionsgeschwindigkeit des Teams davon beschränkt wird, daß ein Mitglied nur alle drei Tage in die Mailbox schaut dann hat das deutliche Auswirkungen auf die Qualität des Endproduktes.


Die Organisation von Softwareentwicklung ist ein Thema für sich und als solches nicht gerade trivial. Außerdem ist eine der wichtigsten Komponenten Erfahrung - denn ohne selbige kann man bei einigen wichtigen Entscheidungen nur raten (beispielsweise dabei, wie lang die QA-Phase im Vergleich zum Rest der Entwicklung sein sollte).