Keine Weiterentwicklung solange noch Fehler enthalten sind
Was nicht explizit getestet wurde, gilt als nicht korrekt
| Inhalt | Abbildung | Source | Projektmanagement | |||
| |< | < | > | >| | Generated by CoCoDiL | ||
Das Ziel ist es zu jedem Zeitpunkt dem Kunden ein fehlerfreies Programm übergeben zu können. Deshalb lautet die Grundprinzipien:
| Keine Weiterentwicklung solange noch Fehler enthalten sind |
Fehlerfreiheit bedeudet hier, dass die innere Qualität der Software sehr hoch ist.
| Unbedingt zu verhindern ist es, daß man viele offenen Punkte mit sich schleppt, die immer nur fast fertig sind |
Nach der Broken Window Theorie zieht Schmutz und Zerstörung weitere Verschmutzungen und Zerstörungen an. In einem Versuch in den USA wurde ein Auto mit geöffneter Motorhaube in New York abgestellt. Innerhalb weniger Minuten wurde es geplündert. Ein vergleichbares Auto blieb abgestellt in Palo Alto eine Woche unangerührt. Dann hat man gezielt eine Scheibe des Autos zerstört. Dies kaputte Scheibe zog weitere Beschädigungen nach sich und in kurzer Zeit wurden die anderen Scheiben auch eingeschlagen, die Reifen wurden geklaut etc. In New York werden daher Graffitis sofort entfernt, wenn sie entdeckt werden. Man geht davon aus, dass es Sprayern einfacher fällt, eine Wand mit einem Graffiti zu verschönern, wenn sie nicht die Ersten sind.
(aus dem Buch: Software entwickeln mit XP - Erfahrungen aus der Praxis, Autoren: Martin Lippert, Stefan Roock, Henning Wolf)
| Wer die Qualität eines Projekts nicht misst, kann nie aussagekräftige Prognosen über den Projektfortschritt tätigen. |
In den meisten Projekten verlangt der Projektleiter lediglich Schätzungen der Entwickler wie weit ihre Tätigkeiten fortgeschritten ist. Die Entwickler schätzen meist sehr positiv, da in vielen Unternehmen Zaudern als Schwäche angesehen wird. Ist der Code auf den die Entwickler aufbauen fehlerhaft, haben die Schätzungen keine Chance realistisch zu sein. Viele Entwickler wagen es (zurecht) nicht den existierenden Code zu verbessern, da auch andere Entwickler auf diesen Code aufbauen, und eine Änderungen bei diesen zu Fehlern führt. Statt existierenden Code zu verwenden, implementieren diese Entwickler dann die Funktionalität erneut. So entstehen viele Versionen derselben Funktionalität, jede Version hat hat ihre eigenen Schwächen und ist ausserhalb des eigenen Kontextes schwer verwendbar. Mit fortschreitender Projektdauer hat keiner mehr den Überblick, der Projektzustand lässt sich nicht mehr messen. Änderungen an Anforderungen bewirkten Änderungen an vielen verschiedenen Teilen des Codes. Da die Codeteile voneineinander abhängig und ineinander verwoben sind, ziehen kleine Änderungen grosse Nachbesserungen auf sich.
In einem auswärtigen Projekt an dem ich in der Schlussphase mitgearbeitet haben, hatten die Entwickler einem Monat vor Abgabetermin um eine Aufschiebung um einen Monat gebeten. Als dieser Monat zu Ende war benötigten die Entwickler noch 2 weitere Monate. Danach verdoppelte sich jeweils diese Zeitspanne noch 2 bis 3 mal, bis man das Projekt dann entgültig als gescheitert erklärte. Die notwendige Funktionalität war zwar schon lange implementiert, aber trotz sehr guter Entwickler schaffte man es nicht die Software zu stabilisieren. Das Problem lag in erster Linie im Management. Auf innere Qualität wurde bewusst nicht geachtet. Um schnell Erfolge nachweisen, und den ursprünglich sehr engen Zeitplan einhalten zu können, wurden die Entwickler angehalten statt den existierenden Code zu stabilisieren, möglichst schnell neue Funktionalität hinzuzufügen. Die eigentliche Kunst von Projektmanagement liegt nicht im Erstellen von Gantt-Diagrammen, sondern im Messen des Projektzustands, sowie die Kommunikation zwischen den Projektbeteiligten zu optimieren. Nur eine hohe innere Qualität der Software garantiert, dass die Komplexität von Software nicht mit neuen Anforderungen exponential ansteigt.
| Inhalt | Abbildung | Source | Projektmanagement | |||
| |< | < | > | >| | Generated by CoCoDiL | ||