Betrachten wir ein agiles Softwareprojekt.
Am Anfang eines Projekts kann jede Story ziemlich schnell implementiert werden, da die Codebasis klein ist, es wenige Abhängigkeiten zwischen verschiedenen Codeteilen gibt, wir keine Abwärtskompatibilität aufrechterhalten müssen usw.
Aber je weiter das Team voranschreitet, desto größer und komplexer wird die Codebasis – es erfordert mehr Zeit, alle Abhängigkeiten zu verstehen. Wir müssen mehr Zeit damit verbringen, mit anderen Entwicklern über die aktuelle Architektur zu sprechen. Eine Geschichte, die früher in ein paar Tagen fertig war, benötigt jetzt mindestens eine Woche.
Gegen Ende des Projekts wird es oft sehr schwierig, selbst einen kleinen Fehler zu beheben, da die Codebasis riesig ist, es viele Abhängigkeiten und Einschränkungen gibt (z. B. Abwärtskompatibilität).
Wenn das Team Fortschritte macht, sollte sich seine Geschwindigkeit verlangsamen. Dieselbe Story am Anfang des Projekts kann als 1 Story Point geschätzt werden, aber genau diese Story, die am Ende des Projekts in die Entwicklung aufgenommen wird, kann vom Team auf 10 Story Points oder mehr geschätzt werden.
Das agile Manifest besagt, dass ein agiles Team ein konstantes Tempo beibehalten sollte – ist das wirklich möglich?
Das Team kann Stories natürlich mehr Punkte geben, um diese zunehmende Komplexität zu kompensieren, aber das würde bedeuten, dass Story Point selbst keine feste Maßeinheit ist und wir Story Points daher nicht für die Prognose verwenden können Zeitaufwand für die Fertigstellung des Projekts.
Es gibt ein paar Dinge zu beachten.
Bezüglich „konstantes Tempo“ heißt es im Manifest for Agile Software Development:
Agile Prozesse fördern eine nachhaltige Entwicklung. Die Sponsoren, Entwickler und Benutzer sollten in der Lage sein, ein konstantes Tempo auf unbestimmte Zeit beizubehalten.
Das sagt nichts darüber aus, dass die Komplexität der Arbeit mit der Zeit zu- oder abnimmt. Es spricht auch nicht für die Geschwindigkeit, mit der Arbeitsaufgaben erledigt werden. Es besagt, dass das Maß an Anstrengung, das alle Beteiligten aufrechterhalten, auf unbestimmte Zeit aufrechterhalten werden sollte. Dies dient dazu, Aktivitäten zu entmutigen, die zu Burnout führen – lange Tage, zusätzliche Tage oder andere „Crunch Time“-Aktivitäten, die körperliche und geistige Erschöpfung, Stress, Negativität gegenüber der Arbeitsumgebung oder andere Auswirkungen oder Symptome von Burnout verursachen. Die Idee ist, dass Sie ein stabiles Team für die langfristigen Bemühungen aufrechterhalten möchten, und "nachhaltige Entwicklung" und "konstantes Tempo" sind eine Sache, die dazu beitragen kann, dies zu fördern.
Die Zunahme der Komplexität eines Systems im Laufe der Zeit ist normal, aber es gibt Möglichkeiten, sie zu mindern. Die erste besteht darin, die zwei Arten von Komplexitäten zu erkennen, die im System existieren können – zufällige und essentielle Komplexität. Manche Systeme sind einfach komplex – sie ergeben sich aus dem/den zu lösenden Problem(en) und sind inhärent. Möglicherweise können Sie die Komplexität isolieren, aber sie existiert. Zufällige Komplexität ist etwas, das unnötig eingeführt wird und behoben werden kann.
Wenn ein System wächst und reift, ist es wichtig, nicht nur nützliche Funktionen hinzuzufügen, sondern Funktionen zu verwerfen und schließlich zu entfernen, die keinen Mehrwert mehr bieten. Dies ist Teil des Produktmanagements und muss die Kosten für die Unterstützung und Wartung einer bestimmten Funktionalität mit dem Mehrwert für die Endbenutzer in Einklang bringen.
Technische Schulden sind ein weiterer Faktor. Die Minimierung rücksichtsloser technischer Schulden und die Rückzahlung vorsichtiger technischer Schulden können dazu beitragen, die Fähigkeit zur Wartung des Systems zu verbessern. Wenn Sie sich entscheiden, technische Schulden einzugehen, haben Sie auch einen Plan, wie Sie diese zurückzahlen können. Wenn Sie die gewonnenen Erkenntnisse anwenden, robuste Testfälle zur Unterstützung von Änderungen (einschließlich Refactoring) haben, über eine angemessene Dokumentation verfügen (einschließlich der Pflege von lesbarem Code) und sicherstellen, dass Sie die Auswirkungen von Designentscheidungen durchdenken können, können Sie die Auswirkungen der Komplexität reduzieren.
Aber selbst wenn Sie alles richtig machen, werden Sie langsamer. Das Beste, was Sie tun können, ist, Ihre Verlangsamung zu minimieren.
Offensichtlich ein Fall von Flacid Scrum im Sinne von Martin Fowler.
Es gibt ein Durcheinander, von dem ich in letzter Zeit bei einigen Projekten gehört habe. Es funktioniert so:
- Sie wollen einen agilen Prozess verwenden und entscheiden sich für Scrum
- Sie übernehmen die Scrum-Praktiken und vielleicht sogar die Prinzipien
- Nach einer Weile ist der Fortschritt langsam, weil die Codebasis ein Durcheinander ist
Was passiert ist, ist, dass sie der internen Qualität ihrer Software nicht genug Aufmerksamkeit geschenkt haben. Wenn Sie diesen Fehler machen, werden Sie bald feststellen, dass Ihre Produktivität nach unten gezogen wird, weil es viel schwieriger ist, neue Funktionen hinzuzufügen, als Sie möchten. Sie haben eine lähmende technische Schuld auf sich genommen und Ihr Gedränge ist in den Knien schwach geworden. (Und wenn Sie in einem echten Gedränge waren, wissen Sie, dass das eine schlechte Sache ist.)
Die Lösung ist theoretisch einfach:
Wenn Sie Scrum einführen möchten, achten Sie unbedingt auf technische Praktiken. Wir neigen dazu, viele von denen aus Extreme Programming anzuwenden, und sie passen gut. XPer scherzen oft, mit einiger Berechtigung, dass Scrum nur XP ohne die technischen Praktiken ist, die es zum Laufen bringen. Sniping beiseite, die XP-Übungen sind ein guter Ausgangspunkt – und werden sicherlich viel besser sein, als gar nichts zu tun.
In der Praxis erfordern XP-Übungen jedoch viel Geschick und Disziplin. Und das Hinzufügen von XP-Praktiken zu bereits bestehenden Projekten bedeutet, dass Sie zunächst den größten Teil der technischen Schulden abzahlen müssen. Und meiner Erfahrung nach kann es Jahre dauern, bis dies gelingt. Sie müssen also längerfristig an die Sache herangehen.
Todd A. Jacobs
Todd A. Jacobs