Wie kann man generisch und wiederverwendbar entwickeln, wenn man in kurzen Zeitabschnitten liefern soll?

Meine bisherigen Erfahrungen stammen hauptsächlich aus der firmeninternen Webentwicklung. In meinem letzten Team war das so, dass sie dem PO manchmal 2 verschiedene Story Point Schätzungen präsentiert hatten: eine für die generische, wiederverwendbare Lösung und eine für die normalerweise kostengünstigere funktionsorientierte Umsetzung. Normalerweise kam dann noch die Bemerkung des Teams dazu, dass die kostengünstigere Umsetzung zum Zusatzaufwand bei der Umsetzung einer bestimmten User Story aus dem Product Backlog führen wird. Der PO musste also entscheiden, welche Umsetzung er bereit ist in Kauf zu nehmen. Dadurch dass wir jeden Sprint nach dem Review eine neue Version des Produktes online genommen haben, war die Entscheidung des POs vom Fall zu Fall unterschiedlich. Mal hat er sich für die momentan kostengünstigere Version entschieden, um z.B. auszutesten, ob diese Funktionalität beim Benutzter überhaupt gut ankommt oder nicht."

Das mag im Webumfeld so sein. Diese Diskussionen kenne ich auch noch sehr gut aus diversen Coaching-Einsätzen. Prinzipiell sollte das Team aber einen gewissen Qualitätsstandard gemeinsam mit dem Product Owner definieren und hochhalten. So steht zum Beispiel das kontinuierliche Refactoring niemals zur Debatte. Eine Aufsplittung in generische Komponenten und funktionale Implementierungen hat stets einen nicht-agilen Beigeschmack. Diesen Kunstgriff würde ich mir nur vorbehalten, wenn die generische Komponente selbst einen hohen Wert darstellt - zum Beispiel ein bestimmtes Risiko angreift oder die Basis für eine Vielzahl von darauf aufbauenden Funktionalitäten darstellt.

Wiederverwendbarkeit, konzeptionelle Integrität, und andere nicht-funktionale Anforderungen sind zu klärende Qualitätsmerkmale (Constraints oder Abnahmekriterien), so wie viele andere auch. Ein gutes Team arbeitet diese Anforderungen durch wiederholtes und konsequentes Refactoring innerhalb ihres testgetriebenen Entwicklungszyklus immer wieder in den Code ein. Dabei sind neben KISS und YAGNI natürlich auch schon bekannte Faktoren zu berücksichtigen, wenn sie sich nicht später ohne größeren Aufwand wieder umbauen lassen. Die Erstellung von Qualität bedingt immer auch die konstante Verbesserung der Codebasis. In einem klassischen Ansatz betrachtet man vielleicht einmal geschriebenen Code als "fertig" - der o.a. Kern steht einmal, erfüllt seine Aufgaben perfekt und muss nicht mehr angepasst werden. Bei der iterativen und inkrementellen Entwicklung entsteht im ersten Sprint nur so viel vom Kern, dass man eine bestimmte einfache Funktionalität über alle Schichten realisieren kann. Dabei wird der Kern im 2. Sprint angepasst, vielleicht werden auch Funktionalitäten aus anderen Modulen in den Kern umgezogen, weil sie dort mehr Sinn machen. Dafür braucht es keinen langen initialen "Architektursprint." Zu viel Generik lenkt dabei von den User Stories ab, zu wenig Refactoring und eine fehlende Architekturvision führen hingegen zu unwartbarem Code. Die Aufgabe des Architekten ist es, die Balance zwischen funktionsgetriebener Entwicklung und solider Architektur in den Teams zu begleiten, erleichtern und moderieren.