Zu viel technische Schuld: Die Anforderung kann nicht umgesetzt werden

Photo of author
Sebastian Neus

Das Development Team ist bei Scrum für die Source Code Qualität und die im System vorhandene technische Schuld verantwortlich. Guter Source Code ist wartbar. Bedeutet, dass er Veränderungen ermöglicht.

Einleitung

Das Development Team ist bei Scrum für die Source Code Qualität und die im System vorhandene technische Schuld verantwortlich. Guter Source Code ist wartbar. Bedeutet, dass er Veränderungen ermöglicht.

Product Owner haben in Software Entwicklungsprojekten selten persönliche Software-Entwicklungserfahrung und können daher nur schwer einschätzen, welche ihrer Entscheidungen dazu beitragen, dass die Software-Qualität sich verschlechtert.

In Scrum leben wir Zusammenarbeit und Transparenz. Einer der wesentlichen Werte in Scrum ist Mut. Ein Development Team muss zwar vom Product Owner behandelt werden wie ein Stakeholder, aber auch den Mut haben, auf technische Erfordernisse und sich anbahnende Probleme aktiv hinzuweisen.

Aufwand für die Entwicklung

Die folgende Grafik zeigt, wie sich der Aufwand für die Umsetzung einer neuen Anforderung erhöht, wenn die technische Schuld eines Systems steigt.

Zum Zeitpunkt „t1“ sind Änderungen mit vertretbarem Aufwand praktisch nicht mehr möglich.

Die folgenden Entscheidungen/Situationen führen zur Verschlechterung der Source-Code-Qualität:

  • Dauerhafter Feature-Druck
  • Keine Zeit für Refactorings
  • Keine Zeit für technische Audits
  • Fehlende Code-Reviews durch Teammitglieder
  • Wenig Zeit für Diskussionen zur technischen Umsetzung

Nur wer regelmässig „aufräumt“ hat dauerhaft gute Source-Code-Qualität und ist damit in der Lage, kurzfristig neue Anforderungen umzusetzen!

Schreibe einen Kommentar

Das könnte Dich auch noch interessieren

Warum Sie beim MVP nicht an der Sicherheit sparen sollten

Warum Sie beim MVP nicht an der Sicherheit sparen sollten

Im Vortrag zu „Arbeiten mit MVPs - Erfahrungen aus der Praxis“ im Rahmen des Agile Coaching Meetups fasste Moritz Peitzsch ...
Weiterlesen
Scrum-Ursprünge und ein kurzer Überblick

Scrum-Ursprünge und ein kurzer Überblick

Die Scrum-Ursprünge gehen zurück auf einen Aufsatz von Ikujiro Nonaka und Hirotaka Takeuchi mit dem Titel "The New New Product ...
Weiterlesen
Wie Sie den MVP-Ansatz für vorhandene Anwendungen nutzen können

Wie Sie den MVP-Ansatz für vorhandene Anwendungen nutzen können

Das Minimum Viable Product (MVP) hilft Ihnen in der Produktentwicklung, zentrale Annahmen früh zu überprüfen. Dabei gilt: besser früh und ...
Weiterlesen