Thomas Eiling shopware AG

Wir Entwickler müssen uns davon verabschieden, dass
es nur gute und schlechte Lösungen gibt. Im Alltag macht
der Kunde auch Kompromisse, wir also auch.

Jan Philipp Pietrzyk shopware AG

Ob man nun Softwarehersteller oder Agentur ist, Scrum unterstützt niemanden aktiv dabei, mit technischer Schuld umzugehen. Hier ist es wichtig, dass sich das Team selbst dafür sensibilisiert.

Agile Softwareentwicklung hat sich durchgesetzt. Die tiefgehende Erkenntnis, dass iterative Softwareentwicklung sowohl Firmen- und Endkunden als auch Systemherstellern und Internetagenturen einen entscheidenden Wettbewerbsvorteil bietet, ist in der Branche angekommen. In Deutschland hat sich dabei Scrum als eines der führenden Prozessmodelle etabliert. In diesem Artikel möchten wir verschiedene Facetten von Scrum und technischer Schuld betrachten, jeweils im Kontext eines Softwareherstellers und einer E-Commerce-Agentur. Dabei wollen wir auch die Frage auflösen, wie mit technischer Schuld umzugehen ist.

Scrum ist ein einfacher und guter Prozess, um Softwareentwicklung zu verwalten. Kurzfristige Ziele werden der langfristigen Planung vorgezogen. Der Hauptvorteil besteht darin, dass agile Teams schneller auf Kundenwünsche reagieren können und gleichzeitig die Sicherheit eines soliden Plans und eines konkreten kurzfristigen Ziels haben. In einem Buch über Scrum beschrieb einer dessen Erfinder, Jeff Sutherland, die vielfältigen Vorteile dieses Prozesses. Er hob dabei hervor, dass man diese Methode nicht nur für Softwareentwicklung einsetzen könne, sondern zum Beispiel auch bei einer Kirchengruppe, beim Hausbau oder für die Selbstverwaltung. Das ist zunächst einmal verwirrend, da es doch bedeutet, dass Scrum nicht nur speziell für die Softwareentwicklung geeignet ist, obwohl es doch eigentlich genau für diesen Zweck eingeführt wurde. Tatsächlich bietet sich jedoch für viele unterschiedliche Branchen ein iterativer Entwicklungsprozess an. Scrum beschreibt im Kern vor allem einen Produktentwicklungs- und Pflegeprozess. Dieser eignet sich für die IT, aber eben auch für andere Gebiete.

Scrum implementiert Qualitätsziele nur über die sogenannten Definition of Done (DoD). Dabei handelt es sich nicht um konkrete Vorgaben, sondern einen Vertrag, der durch die Mitwirkenden für den Entwicklungsprozess definiert wird. Die DoD legt fest, unter welchen Kriterien ein einzelner Vorgang als erledigt gilt. An dieser Stelle entsteht das Hauptproblem mit Scrum in der Softwareentwicklung. Möchte man ein Medikament entwickeln, muss man durch eine Zulassungsstelle, möchte man ein Haus bauen, muss man die Pläne von der Behörde abnehmen lassen, doch möchte man eine Software veröffentlichen, scheint es keine Kontrollstelle zu geben.

Industrieweit vereinbarte und gehaltene Standards existieren in diesem Bereich nicht. In der Praxis gibt es daher Teams, die sich hohe Qualitätsstandards setzen und daran halten und andere Teams, die ihr Hauptaugenmerk auf andere Punkte legen. Es ist bestimmt für jeden leicht vorstellbar, dass ein Team eine teilweise sehr strenge DoD für die UX-Elemente hat, aber dafür jede festgelegte technische Konvention schnell über Bord wirft. Einfach nur, weil es dadurch auf kurze Sicht schnell vorankommt. Die DoD als Gefäß für unumstößliche Qualitätsstandards muss eben auch von Entwicklern gefüllt werden.

Den vollständigen Artikel lesen Sie in der Ausgabe:

PHP Magazin 3.18 - "Haftungsfalle DSGVO"

Alle Infos zum Heft
579832019Scrum und die technische Schuldfrage
X
- Gib Deinen Standort ein -
- or -