:Michael spricht da einen wichtigen Punkt an: No matter how it looks at first, it's always a people problem. (GeraldMWeinberg?) |
:Michael spricht da einen wichtigen Punkt an: No matter how it looks at first, it's always a people problem. (GeraldWeinberg) |
:::*Zuerst wird das neue getestet, das Gute aus dem Test kann dann übernommen werden. :::*Neues Einführen ist ein kontinuierlicher Prozess. |
****Zuerst wird das neue getestet, das Gute aus dem Test kann dann übernommen werden. ****Neues Einführen ist ein kontinuierlicher Prozess. |
:::Alternativen: ****IterationsRetrospektiven ****JedesProjektEinPilotprojekt Um aber auf den technischen Aspekt zurückzukommen: Ich habe mit der Strategie "Komponente neu entwickeln und dann gegen alte eintauschen" eher negative Erfahrungen gemacht. Das Problem ist, dass im Allgemeinen halt doch auch immer noch an der alten Komponente weiterentwickelt werden muss, was zu doppeltem Aufwand führt und sehr unbefriedigend ist. Außerdem stellt sich dann nachher meist heraus, dass das Austauschen halt doch nicht so einfach ist, weil irgendwelche kritischen Eigenschaften des alten Moduls nicht hundertprozentig nachgebaut wurden. Deshalb mein Tipp: So inkrementell wie möglich vorgehen, und wo immer möglich alten Code refaktorisieren statt durch neuen ersetzen. -- IljaPreuß |
Situation:
Eine Softwarefirma mit etwa 50 Entwicklern arbeitet seit Jahren erfolgreich in einer Nische als Marktführer. Dabei werden gestützt auf ein Standardprodukt zunehmend kundenspezifische Anpassungen und - in kleinerer Zahl - größere Projekte durchgeführt, die auch auf das Standardprodukt aufsetzen, wobei dieser Kern aber nur 10-30% dieser Projekte ausmacht.
Probleme:
Stetig ansteigende Wartungsaufwendungen, welche die freien Entwicklungskapazitäten auffressen. Unbefriedigende Situation bei den Adaptierungen, die teilweise nicht kostendeckend gemacht werden können und zu Aufblähungen des Standards und Inkonsistenzen führen. Schlechte Ergebnisse bei den pauschaliert durchgeführten Großprojekten (Probleme in der Schätzung, Schwächen in der Spezifikation und Nachverhandlung bei Änderungen mit den Großkunden).
Fragestellung:
Wie lässt sich so eine Firma schrittweise "agilisieren" ? Es geht mir darum ein Gesamtkonzept zu entwickeln, das quasi auf Firmenebene einen Prozess in Gang setzt, die wie XP auf Projektebene, priorisiert, schrittweise und immer kontrollierbar, adaptierbar und transparent, zu einer neuen Struktur der Entwicklung führt.
Rohkonzept:
Meine momentaner Denkansatz ist, dass die erwartbaren Schwächen in der Codestruktur, der Modularisierung und der Qualitätskontrolle durch einen längerfristige Refaktorierungsprozess beseitig werden müssen. Ziel: Eine deutlichen Steigerung der Codequalität und eine Senkung von Redundanzen und Inkonsistenzen. Das wird nur durch - teilweise nachträglichen - Aufbau von Testsuiten gehen (a la C3-Projekt), welche das Risiko so weit wie möglich aus der Refaktorierung herausnehmen. Dabei würde diese "Entwicklungswelt" in zwei Teile geteilt, den alten Teil, der nach Möglichkeit nicht mehr groß ausgedehnt wird und einen neuen Kern (Module, Libraries, neue Projekte), der nach neuen ProgrammierStandards, einer eventuell neuen, konsistenten "Sprache" und neuen organisatorischen Regeln (XP oder Versatzstücke davon) entwickelt wird. Die beiden Teile leben aber nicht getrennt, sondern Trennlinie geht zunehmend durch den gesamten Entwicklungsbereich (natürlich mit dem Ziel diese Trennlinie möglichst rasch wieder loszuwerden). Schritt für Schritt sollte der Übergang von der alten in die neue Welt erfolgen, wobei das Management und die Entwickler selbst alle Prozesse immer mitgestalten und steuern. Dabei könnte auch die interne Projektarbeit und das externe Feedback über ein WikiCluster? unterstützt werden.
Scheint Euch so ein Konzept durchführbar? Habt Ihr Tipps, Erfahrungen, Anregungen, die Ihr teilen wollt? -- hl
Deshalb mein Tipp: So inkrementell wie möglich vorgehen, und wo immer möglich alten Code refaktorisieren statt durch neuen ersetzen. -- IljaPreuß