Probleme mit dem iterativen Entwicklungsmodell

Wenn Sie über eine gute Versionskontrolle verfügen, sollten Sie in der Lage sein, die Fehlerbehebung von Version 7.3 durch alle Releases bis zum aktuellen zu kaskadieren. Es sollte kaum notwendig sein, herauszufinden, wie die zukünftigen Versionen gepatcht werden können. Wenn Sie über gute automatisierte Testwerkzeuge verfügen, müssen Sie nur überprüfen, ob der Fehler in jeder Version, jedem Patch vorhanden ist, und die Korrektur überprüfen.

Für diese Art von Veröffentlichung würde ich auf dem Stamm entwickeln und bei der Veröffentlichung verzweigen. Verzweigen Sie so früh wie nötig und so spät wie möglich. Ich habe Projekte gesehen, bei denen jede Version eine eigene Codeinsel ist. Es neigt dazu, Probleme einzuführen, auf die Sie stoßen.

Ich würde die Arbeit an Fehlern in früheren Versionen in einen separaten Wartungsstrom aufteilen. Der Wartungsstrom sollte erfahrene Entwickler haben oder Sie könnten mehr Fehler einführen als Sie beheben. Diese Gruppe sollte in der Lage sein, Fehlerkorrekturen in die aktuelle Version einzufügen.

Wenn Sie Fehler finden, möchten Sie diese möglicherweise bis zur ältesten unterstützten Version zurückverfolgen und sie in dieser Version beheben. Verschieben Sie dann den Patch auf die neueste Version, die defekt ist.

Das Dokumentieren der Ursache des Fehlers (wie er eingeführt wurde) kann hilfreich sein, um die Rate zu verringern, mit der Sie neue Probleme einführen.

Eine Verringerung der Anzahl der unterstützten Versionen würde ebenfalls helfen. Betrachten Sie wie einen Wartungsplan so etwas wie:

• Jede Version wird unterstützt, bis zwei vierteljährliche Versionen veröffentlicht wurden.
• Vierteljährliche Releases werden ein Jahr lang unterstützt.
• Jährliche Releases werden für zwei Jahre unterstützt.

Muss man so viele Versionen haben? Gibt es eine Möglichkeit zu einem Track zu wechseln ? (Ein Track bedeutet, dass Sie abhängig von Ihrem Versionskontrollsystem einen Haupt- oder Master-Branch haben und jede Änderung in diesen Haupt- oder Master-Branch geht und es keine Versionen gibt.)

Wenn es nicht notwendig ist, dann schlage ich vor, die Versionen zu vergessen und iterativ in diesen einen Track (Zweig) zu liefern. Mit diesem Ansatz können Sie die Zykluszeit in Ihrer Organisation verkürzen, aber dennoch iterativ entwickeln.

Wenn es notwendig ist, versuchen Sie, einen Weg zu finden, sie nicht zu haben. Die Verwaltung mehrerer Versionen ist ein enormer Overhead, und der Aufwand für die Verwaltung von Zweigen und Versionen kann für neue Funktionen aufgewendet werden. Versuchen Sie, dem Kunden die Verwendung unterschiedlicher Versionen auszureden. Wenn es intern ist, finden Sie heraus, warum es überhaupt eingeführt wurde, und lassen Sie es verschwinden. Oder Sie können einen Track haben und ihn mit der neuesten Versionsnummer taggen, aber nicht verzweigen.

Meiner Erfahrung nach sind 90 % der Kunden mit einer Spur zufrieden. Die restlichen 10 % verloren das Vertrauen und entschieden sich deswegen gegen neue Patches. Dies ist jedoch eine andere Situation.

Reduzieren Sie den Umfang, integrieren Sie das Testen in den Release-Zyklus (z. B. ist es nicht getan, bis es getestet und behoben ist) und veröffentlichen Sie es häufiger.

Damit ein iterativer Zyklus gut funktioniert, müssen Sie:

1. Erhöhen Sie die Häufigkeit der Veröffentlichungen , und
2. Bewege dich immer vorwärts

Die Idee ist:

1. Kunden müssen nicht lange auf die Behebung von Problemen warten
2. Kunden können sicher sein, dass neuere Versionen besser sind als alte

Es ist in Ordnung, einen Kunden bei einer älteren Version zu lassen, aber es ist unproduktiv, wenn er erwartet, dass sie für lange Zeit gewartet oder gepatcht wird.

Um zu verhindern, dass Ihre Mainstream-Kunden verärgert werden, bauen Sie außerdem eine Gruppe von „Power-Usern“ auf, die vor allen anderen eine neue Version erhalten, und helfen Sie dabei, die größten Probleme auszusortieren.

Zu Punkt 1

Ihre Nachfrage übersteigt das Angebot und verursacht einen Arbeitsstau, der ins Unendliche tendiert. Es ist schwer, konkrete Ratschläge zu geben, um das zu beheben, aber ich würde damit beginnen:

Messen Sie, wie oft neue Funktions-/Änderungsanforderungen gemeldet werden. Wie oft wird ein Fehler in einer Produktionsversion gemeldet. Achten Sie auf die Ebenen der Wertnachfrage (neue Dinge, die Kunden wollen, die neue Geschäfte anregen oder die Ausgaben erhöhen) und der Fehlernachfrage (die Anfragen, die durch einen Fehler Ihrerseits verursacht werden (z. B. Fehler).

Sobald Sie richtig verstanden haben, woher die Nachfrage kommt und wie oft, versuchen Sie, Ihre Angebotsseite an die Nachfrage anzupassen, indem Sie die Ausfallnachfrage entfernen und die Arbeit so sequenzieren, dass sie der Wertnachfrage entspricht.

Weitere Informationen finden Sie in der Warteschlangentheorie. Es gibt eine Menge Material da draußen, aber ich empfehle besonders, „Managing the Design Factory“ von Don Reinertsen zu lesen, das einen wirklich guten Abschnitt über Warteschlangen enthält (und ein allgemein großartiges Buch ist).