Aus meiner Sicht ist die Softwareentwicklung mit rapid prototyping der richtige Weg, um möglichst früh auf Missverständnisse und falsch verstandene Kundenwünsche aufmerksam zu werden. Wie es der Name schon sagt, versucht man schnell ein Prototyp zu erstellen, den man dem Kunden schon frühzeitig präsentieren kann. Dann bekommt der Kunde früh ein Gefühl für die Software und die eingeschlagene Richtung.
Nach einem solchen Meeting entwickelt man den Prototyp weiter, pflegt die besprochenen Änderungen ein und dreht eine neue Runde mit dem Kunden.
Mit dem rapid prototyping einher, geht für mich die Programmierung eines technischen Durchstiches. Hier wird versucht, durch alle Schichten der Software alle Schwierigkeiten zu testen, um früh Stolpersteine und Fallstricke zu erkennen. Der technische Durchstich muss noch nicht sauber bis ins kleinste Detail programmiert sein. Es können auch mal hartkodierte Werte im Code stehen oder andere Dinge statisch vorgenommen werden. Wenn der technische Durchstich dann läuft kann man daran gehen, Dinge generisch zu lösen.
In einem aktuellen Kundenprojekt sollen eine Vielzahl von Seriendokumenten erstellt werden. Für den technischen Durchstich erfolgte die Erstellung und Sammlung der Daten noch statisch. Das ist für wenige Seriendokumente noch praktikabel, entwickelt sich bei 20 und mehr unterschiedlichen Dokumenten aber schnell zur zeitraubenden Tipparbeit. Da macht es Sinn, ein bisschen mehr Grips in eine generische Lösung zu stecken und die Seriendokumente beispielsweise über eine XML-Datei zu konfigurieren und den Aufbau in der Software generisch vorzunehmen. An dieser Stelle stehe ich gerade und werde die kommenden Entwicklungsstunden dazu nutzen eine tragfähige, generische Lösung zu finden.
Dabei sollte man keine Angst haben, etwas zu übersehen. Man sollte zunächst schon eine Vielzahl der Fälle abdecken, die Lösung sollte aber immer so umgesetzt sein, dass sie auf einfache Art und Weise angepasst werden kann.