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.

-- HelmutLeitner

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

Ich denke mal, die Codebasis ist nicht das groesste Problem dieser Firma ...

Wie sieht denn das Umfeld aus ? Gibt es Teamgeist; wie sind die Prozesse - anpassbar oder starr; schafft es das Management, für die Mitarbeiter eine produktive Umgebung zu schaffen ? -- mj

Michael spricht da einen wichtigen Punkt an: No matter how it looks at first, it's always a people problem. (GeraldWeinberg)

Das Problem, das die Firma hat ist nicht der schlechte Code, sonder die Mechanismen in der Firma, die zu dem schlechten Code geführt haben. Wenn sie jetzt einfach nur anfangen, Teile des Systems neu zu entwickeln und stückweise alte Teile zu ersetzen, was sollte sie daran hindern, wieder genau die gleichen Probleme in den neuen Code einzubauen? -- IljaPreuß

[hl] Ich versuche das zu beantworten (mit meinen derzeit unvollständigen Informationen):

Teamgeist: Es ist ein gutes Team, mit einem größeren Anteil erfahrener, langjähriger Mitarbeiter

Management: erfolgreich und kraftvoll, aber ohne Know How, die Prozesse selbst zu ändern

Prozesse: können sicher geändert werden (der Wille ist da), aber sicher nicht in einem ruckartigen Umstellungsprozess

Ilja, "Was sollte sie daran hindert": Ich denke, dass es darum geht Überzeugungsarbeit zu leisten, dass die vorhandenen Prozesse erneuert werden müssen und dass die Umstellung der Prozesse durch entsprechende Projektleitung, positive Erfahrungen, Schulungen, Standards, Kontrollmechanismen etc. abgesichert werden könnte.

Konkret kann das z.B. heissen: In der Firma wird die Regel eingeführt "Jedes Jahr gibt es ein Projekt, das anders durchgeführt wird!"

Soll heissen, es gibt von da an einen Prozess, der neues einführt.

• Zuerst wird das neue getestet, das Gute aus dem Test kann dann übernommen werden.
• Neues Einführen ist ein kontinuierlicher Prozess.

Wir sollten, glaub ich, ein Buch darüber schreiben und sehr reich werden :-)) -- mj

Alternativen:

• IterationsRetrospektiven
• JedesProjektEinPilotprojekt

Deshalb mein Tipp: So inkrementell wie möglich vorgehen, und wo immer möglich alten Code refaktorisieren statt durch neuen ersetzen. -- IljaPreuß