This post originated from an RSS feed registered with .NET Buzz
by -.
Original Post: Einfache Verbesserungen für kleine Teams
Feed Title: Norbert Eder - Living .NET
Feed URL: http://feeds.feedburner.com/NorbertEder-Livingnet
Feed Description: Copyright (c)2005, 2006 by Norbert Eder
Immer wieder, wenn ich mit kleinen Entwickler-Teams zu tun habe, sehe ich, dass dieselben Probleme vorhanden sind. Meist dreht es sich um die folgenden Punkte:
Das Projekt wurde nicht ausreichend spezifiziert. Der Auslöser für das Projekt kennt die genauen Anforderungen, brachte diese jedoch nie vollständig in ein Dokument. Sollte ein Dokument vorhanden sein, findet dieses oft nicht den Weg zum Entwickler. Daher erhält dieser oft unzureichende Informationen, um das Projekt erfolgreich durch zu führen.
Keine Arbeitspakete. Soll ein Projekt durchgeführt werden, muss eine Analysephase durchlaufen werden. Im Zuge dieser Phase sind Arbeitspakete zu definieren. Diese erleichtern zum Einen die Abgrenzung zu anderen ToDo's und ermöglichen eine Kontrolle. Zeitschätzungen dafür werden sehr oft ebenfalls nicht angegeben. Deswegen gestaltet sich eine Kontrolle schwierig.
"Drauf-los-Entwicklung". Die Vorgaben sind bekannt und es wird einfach einmal entwickelt. Zukünftige Anforderungen werden nicht in Betracht gezogen, auch wird erst bei der Integration der einzelnen Teile in Erfahrung gebracht, ob diese überhaupt miteinander harmonieren. In den meisten Fällen sind größere Änderungen notwendig.
Kontrolle. Zum Thema Kontrolle gibt es zwei Wege die hauptsächlich durchschritten werden: Entweder findet keine Kontrolle statt (oder erst ca. 2 Wochen vor Auslieferung) oder es wird versucht das ultimative Kontrollsystem einzuführen. Oft wird hierbei jedoch auf notwendige Vorarbeiten vergessen, wodurch eine Kontrolle gar nicht durchgeführt werden kann (Arbeitspakete in Kombination mit Zeitschätzungen als Beispiel).
Ressourcen-Planung. Ressourcen müssen geplant werden. Freie Kapazitäten sollten vor Annahme eines Projektes bekannt sein. Ebenso sollte bekannt sein, dass eventuell zwischenzeitlich Ressourcen für andere Projekte abgestellt werden müssen - und zu welchem Umfang. Viele Teams werden von plötzlicher Ressourcen-Knappheit überrascht, da plötzlich Entwickler zu anderen Projekten abgezogen werden müssen. Es gilt daher eine saubere Ressourcen-Planung durch zu führen und - wenn notwendig - frühzeitig für Ausgleich zu sorgen.
Der fehlende Architekt. Nicht jeder Softwareentwickler ist zum Architekten geboren. Großes Wissen und viel Erfahrung ist notwendig, um zukunftssichere Grundgerüste zu entwickeln. Gerade kleine Teams haben oft keinen "gelernten" Architekten zur Verfügung. In diesem Fall kommt es für die meisten Projekte billiger, sich zumindest für das Grundgerüst eine entsprechende Person zu zu kaufen.
Dies sind einige Punkte, auf die ich immer wieder in der Praxis stoße. Die einen Teams leben dabei nach dem Motto "Es wird schon irgendwie gehen", wobei die anderen definitiv nach Verbesserung streben. Ich persönlich kann nur jedem Team bzw. jedem kleinen Softwareunternehmen raten, sich zumindest für ein paar Stunden einen Spezialisten zu zu kaufen. Sind bisherige Abläufe bekannt (grobe Abläufe lassen sich in kurzer Zeit ohne Weiteres feststellen), können selbst kleine Änderungen große positive Auswirkungen auslösen.
Will ein Unternehmen dafür kein Geld an externe Personen vergeben, dann sollten zumindest meine aufgeführten Punkte mit der eigenen Vorgehensweise reflektiert werden. Alleine daraus lassen sich einige Verbesserungsmaßnahmen ableiten.
Previous Topic
