© Iconic Bestiary/Shutterstock.com
PHP Magazin
Lösungsansätze für einen Erfolg versprechenden Entwicklungsprozess

Scrum und die technische Schuldfrage

Agile Softwareentwicklung hat sich durchgesetzt. Die tief gehende 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.

Thomas Eiling, Jan Philipp Pietrzyk


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 der 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 sogenannte 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.

Technische Schuld

Auf Ward Cunningham geht der Begriff der „technischen Schulden“ (Technical Debt) zurück: „Although immature code may work fine and be completely acce...

PHP Magazin
Lösungsansätze für einen Erfolg versprechenden Entwicklungsprozess

Scrum und die technische Schuldfrage

Agile Softwareentwicklung hat sich durchgesetzt. Die tief gehende 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.

Thomas Eiling, Jan Philipp Pietrzyk


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 der 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 sogenannte 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.

Technische Schuld

Auf Ward Cunningham geht der Begriff der „technischen Schulden“ (Technical Debt) zurück: „Although immature code may work fine and be completely acce...

Neugierig geworden?


   
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang