Was tun Sie, wenn Sie X Monate in ein Projekt investieren, das Scrum verwendet, und entweder eine Geschichte, ein Entwickler, ein Review oder eine Planungssitzung deutlich machen, dass ein schwerwiegendes Architekturproblem offensichtlich ist, das zu Beginn des Projekts nicht offensichtlich war? ? Ignorieren, warum es so ist, wessen Schuld es ist oder warum die aktuelle Architektur gewählt wurde.
Derzeit arbeite ich nicht täglich in Agile oder Scrum, das mag naiv klingen, aber könnten Sie nicht versuchen, das Architekturproblem in eine Geschichte zu verwandeln? Support-Teams, DBAs und zukünftige Entwicklerteams können als „Benutzer“ bezeichnet werden und Ansichten zu Benutzerfreundlichkeit, Skalierbarkeit, DR/BC usw. haben, und Sie können sie in den gleichen Bewertungsprozess wie jede andere User Story einbeziehen.
Kurze Antwort
Dies mag wie eine offensichtliche oder zu einfache Antwort erscheinen, aber normalerweise ist die richtige Antwort, es anzusprechen, sobald Sie es sehen. Einfach ausgedrückt, ist es in der Regel besser, das Problem jetzt zu beheben, als ein paar weitere Funktionen auf einer fehlerhaften Architektur aufzubauen, bevor Sie es beheben.
Seien Sie auch offen für die Idee, dass Sie einige Teile möglicherweise sofort reparieren müssen, um zu verhindern, dass zusätzliche Arbeit das Problem verschlimmert, während andere Teile möglicherweise weniger dringend sind. Das kann dazu beitragen, dass der Refactoring-Aufwand etwas weniger umfangreich ist.
PBI ist keine User Stories
Scrum verlangt keine User Stories. Die Idee, dass jedes Backlog-Element eine User Story sein kann, ist eine nette akademische Übung, aber hängen Sie sich nicht daran auf. Geben Sie die erforderlichen Product-Backlog-Elemente ein, um Ihre Architektur zu korrigieren.
Was die Erzeugung eines wertvollen Inkrements betrifft, so gibt es einen Benutzerwert, wenn die Architektur wirklich problematisch ist. Vielleicht kommt es nach 100 gleichzeitigen Benutzern zu einem Deadlock, oder Sie erhalten Daten, die zwischen Sitzungen gemischt werden, oder vielleicht ist das technische Problem ausschließlich codebezogen und Ihre Fähigkeit, in Zukunft Korrekturen und vom Benutzer angeforderte Funktionen zu entwickeln, wird behindert. In jedem Fall liegt in diesem Inkrement ein Wert.
Verwenden Sie Einschränkungen
Es ist schwierig, von Anfang an die perfekte Architektur zu finden. Jahrzehntelange Softwareentwicklung hat uns das gelehrt. Verwenden Sie architektonische Einschränkungen, um Ihre Architektur "in Grenzen" zu halten und Sie zu warnen, wenn Sie zu weit abdriften. Progressive Web-Apps bieten ein großartiges Beispiel für architektonische Einschränkungen. Einige dieser Regeln beinhalten:
Diese lockeren Regeln ermöglichen es dem Team, bessere architektonische Entscheidungen zu treffen, ohne dass eine Architektur von Anfang an in Stein gemeißelt werden muss.
Dies wird Ihre Situation natürlich nicht vollständig verhindern, aber wenn es eintritt, können normalerweise eine oder mehrere Einschränkungen daraus hervorgehen, um die Dinge wieder auf Kurs zu bringen.
Bei Scrum ist, wie bei den meisten agilen Entwicklungsansätzen, das gesamte Team verantwortlich.
Das ist das 11. Prinzip des Agilen Manifests:
Die besten Architekturen, Anforderungen und Designs entstehen in sich selbst organisierenden Teams.
Ich muss also darauf hinweisen, dass es sehr wahrscheinlich ist, dass sich dasselbe Problem in einem viel späteren Stadium (zeitlich) in einem BDUF-Ansatz gezeigt hätte. Anstatt einer Einzelperson die Schuld zu geben, wird das Team zumindest jetzt das Problem anerkennen, es beheben, daraus lernen und weitermachen.
Gummiente
Matt W