Kürzlich entdeckte Anforderungen in Scrum

Wenn eine Anforderung während eines Projekts oder sogar später entdeckt wird, können die Kosten für die Implementierung dieser Anforderung sehr hoch sein.

In dieser Aussage sagen Sie, dass die Kosten für Änderungen hoch sind (insbesondere spät in einem Projekt).

Der agile Ansatz erkennt an, dass Veränderungen stattfinden, und versucht daher, die Kosten der Veränderung zu reduzieren .

Dies ist der grundlegende Unterschied zwischen dem agilen Vorgehen und der traditionellen Entwicklung:

Traditionelle Entwicklung : Lassen Sie uns wirklich gut darin werden, vorherzusagen, was passieren wird (gut planen)

Agile Entwicklung : Lassen Sie uns wirklich gut darin werden, auf Veränderungen zu reagieren (gut reagieren)

Priorisierung, Continuous Delivery und Review sind der Weg, das Lieferrisiko für jede Softwareentwicklung zu kontrollieren, nicht nur bei der Verwendung von Scrum. Dem ersten Satz Ihrer Frage kann ich jedoch nicht zustimmen. Wenn die Arbeit klug geordnet wird, kommt die wichtigste und riskanteste oder teuerste Arbeit normalerweise zuerst, sodass die Kosten für unerwartete Arbeiten im Laufe der Zeit eher sinken als steigen sollten. Ein erfahrenes Team wird auch versuchen, für eine frühzeitige Verfeinerung alle Elemente zu identifizieren, die weitreichende Auswirkungen auf die Architektur haben oder viele Abhängigkeiten aufweisen.

Keine Methode bietet eine Garantie gegen das Unerwartete, aber Continuous Delivery hilft, böse Überraschungen zu vermeiden, indem das Produkt frühzeitig und häufig getestet wird. Dies ist normalerweise eine viel zuverlässigere Methode, als sich allein auf eine frühzeitige Analyse zu verlassen, um Probleme zu identifizieren.

Du sagst:

Wenn eine Anforderung während eines Projekts oder sogar später entdeckt wird, können die Kosten für die Implementierung dieser Anforderung sehr hoch sein.

Dies kann wahr oder falsch sein. Das hängt von der Art der Änderung ab, auf die Sie sich beziehen . Ich nehme eine große Veränderung an, oder etwas, das auf eine wichtige Weise fehlt, oder etwas, das in irgendeiner Weise von dem abweicht, was Sie bis zu diesem Punkt aufgebaut haben. Wenn dies der Fall ist, dann ja, der Wechsel kann teuer werden. Wenn es nur eine Anforderung wie andere ähnliche ist, wird die Implementierung wahrscheinlich nicht so hoch sein.

Die Art und Weise, wie Sie diesen ersten Satz und den Rest der Frage formuliert haben, impliziert, dass Sie einen prädiktiven Ansatz verwenden oder einen traditionellen Ansatz, bei dem Sie zu Beginn Anforderungen sammeln und dann einen Plan erstellen, den Sie dann implementieren können. Nur so kann man von „der Mitte des Projekts“ sprechen.

Wenn Sie das Produkt beispielsweise agil entwickeln, wissen Sie nicht, dass Sie sich mitten im Projekt befinden, weil Sie sich auf die Bereitstellung von Werten konzentrieren und nicht auf Zeitpläne, die Ihnen sagen, wo Sie sich im Projekt befinden. Dies bedeutet jedoch nicht, dass die Verwendung von Agile oder Scrum garantiert, dass eine Anforderung spät in der Entwicklung kostengünstig zu implementieren ist. Wenn Sie ein weißes Flugzeug bauen und irgendwann feststellen, dass Sie ein U-Boot brauchen, können Sie nicht einfach seine Flügel abhacken, es schwarz anstreichen und es fertig nennen. Diese Art von Änderung wird Ihre Implementierung durcheinander bringen, egal ob Sie einen traditionellen oder einen agilen Ansatz verwenden.

Agile ermöglicht es Ihnen jedoch, früher herauszufinden, dass Sie ein U-Boot anstelle eines Flugzeugs benötigen , da Sie inkrementell und iterativ Dinge bauen, zu denen Sie Feedback sammeln und lernen können, was benötigt wird, anstatt davon auszugehen, dass Sie es tun alles von Anfang an wissen und es in Anforderungen spezifizieren, die sich nicht ändern oder in irgendeiner Weise fehlen. Wie bereits in den anderen Antworten erwähnt, ist der agile Ansatz anders und verringert die Chancen, etwas zu entdecken, dessen Implementierung irgendwann wirklich sehr teuer sein kann.

Aus sequenzieller Sicht ist die Idee, dass eine Anforderung, die später im Projekt entdeckt wird, wahrscheinlich teurer zu erfüllen. In ähnlicher Weise ist ein Fehler, der spät nach der Entstehung entdeckt wird, wahrscheinlich auch teurer. Das liegt daran, wie viel Arbeit geleistet wird. Bedenken Sie, dass Sie bei Bemühungen, die mit sequentiellen Methoden ausgeführt werden, versuchen, alle Anforderungen frühzeitig zu ermitteln. Anschließend erstellen Sie eine Architektur und ein Design, die alle diese Anforderungen erfüllen. Anschließend setzen Sie das gewählte Design um. Eine Änderung, insbesondere eine neue Anforderung oder eine Änderung an einer bestehenden Anforderung, erfordert die Analyse des gesamten Anforderungssatzes auf Probleme und Konflikte, dann die Analyse und Aktualisierung der Architektur und des Designs, dann die Aktualisierung der Implementierung und schließlich die Tests. Änderungen ziehen sich durch jede Phase des Lebenszyklus und alle damit verbundenen Artefakte.

Scrum und die meisten anderen agilen Methoden verfolgen einen anderen Ansatz. Es gibt gerade genug Architektur und Design, um die bekannten Anforderungen zu unterstützen. Das System wird im Laufe der Zeit weiterentwickelt, um neuen oder geänderten Anforderungen gerecht zu werden. Das bedeutet nicht, dass eine radikal andere Anforderung keine große Menge an Nacharbeit verursacht, aber das Risiko wird reduziert. Indem Sie schrittweise aufbauen und Feedback erhalten, um das zu bauen, was als das Wichtigste als nächstes wahrgenommen wird, werden die Chancen auf etwas, das sehr wichtig, aber auch sehr schwierig zu implementieren ist, verringert. Jegliche Überarbeitung wird auf die bereits gebauten Teile des Systems beschränkt sein, anstatt sich durch viele Phasen der Entwicklung zu ziehen.

Ich möchte auch hinzufügen, dass mit zunehmender Komplexität die Kosten für die Änderung der Funktionalität des Systems kostspieliger werden. Die Verwendung von inkrementellem Design, die einfache Gestaltung des Designs (denken Sie an Prinzipien wie KISS und YAGNI ) und die frühzeitige Tilgung technischer Schulden können zukünftige Änderungen weniger kostspielig machen. Die vorhandene Komplexität sollte sich mehr in Richtung essentieller Komplexität verschieben als in zufällige Komplexität.