Du wirst es brauchen, aber nicht sofort

Der Sinn des Vertical Slicing besteht also darin, so etwas wie die Datenbank zu nehmen und genau zu sagen: „Ich brauche jetzt nicht die ganze Datenbank.“ Lassen Sie uns also Ihre Behauptung validieren: Brauchen Sie die Datenbank?

Lassen Sie uns klarstellen, was eine Datenbank tut: Sie verteilt Zustandsänderungen auf mehrere Server und speichert diese Änderungen, wenn der Server neu gestartet wird. Wenn Sie einfache Persistenz, aber keine Verteilung wünschen, können Sie in eine lokale JSON-Datei oder so schreiben. Wenn Sie eine Verteilung, aber keine Persistenz wünschen, können Sie Knoten dazu bringen, Nachrichten untereinander zu senden, z. B. mit ZeroMQ.

Ich sehe in Ihrer ersten User Story nichts über eine beliebige Anzahl paralleler Server, und ich bin mir nicht sicher, ob ich in Ihrer ersten User Story etwas über Persistenz sehe; Sie können möglicherweise das standardmäßige In-Memory-Verhalten tolerieren: „Wenn wir eine neue Version der Software einführen, wird jeder abgemeldet und alle von ihm vorgenommenen Änderungen werden zurückgesetzt.“

Sie brauchen also keine Datenbank. Möglicherweise benötigen Sie (wenn Sie eine Liste haben, die einige Smartcard-Token einer Art internen Benutzernamen zuordnet) eine statische JSON-Datei (nicht klar, ob sie an das Repo übergeben werden soll oder nur eine Konfigurationsdatei, die über E-Mail/Slack verteilt und als letzter Teil der Initialisierung; wenn es Ihnen nichts ausmacht, dass die Daten im Repo gespeichert werden, können sie sogar in einer Ihrer Quelldateien gespeichert werden, kein JSON-Parsing/Dateilesen erforderlich).

Benötigen Sie in ähnlicher Weise ein großes Javascript-SPA? Ich glaube nicht – Sie benötigen möglicherweise einen Kartenleser oder ein HTML-Formular, je nachdem, ob es sich um einen Hardware-Token handelt, der einige Ziffern oder etwas Interessanteres anzeigt.

Benötigen Sie eine Berechtigungsstruktur? Nein, die einzige Berechtigung, die Ihre User Story abdeckt, ist „kann sich mit einem Benutzernamen und einer mit diesem Benutzernamen verknüpften Smartcard anmelden“, und das ist eine globale Berechtigung.

Wenn Sie vertikal aufteilen, reduzieren Sie jede Ebene auf nur die Teilmenge der Funktionalität, die sie benötigt, damit die User Story funktioniert. Sie versuchen nicht , ein Zwanzigstel der Datenbank und ein Zwanzigstel der Berechtigungsstruktur bereitzustellen, nur weil Sie zwanzig User Storys haben und versuchen, eine davon bereitzustellen. Sie können oft feststellen, dass in den frühen Phasen mehrere Schichten leer sind.

Verwenden Sie verzögerte Funktionen, um bessere Geschäftsanforderungen zu erhalten

In der Tat sollten Sie dies wünschen . Ich würde dringend empfehlen, dass Sie die Erstellung der Datenbank so lange wie möglich hinauszögern , das heißt, bis Sie echte Benutzer haben, die sowohl über Ausfallzeiten als auch darüber, dass ihre Änderungen bei Serverneustarts nicht beibehalten werden, mürrisch werden. Dafür gibt es einen wirklich wichtigen Grund: Top-Down-Design ist typischerweise kurzsichtig. Sie möchten in der Lage sein, bevor Sie Ihre Freiheit verlieren, mit Datenstrukturen herumzuspielen, um einen echten Benutzer dazu zu bringen, mit der Geschäftslogik Ihres Tools herumzuspielen und Ihnen so etwas zu sagen:

"Ach nein! Sie gehen davon aus, dass jede Bestellung einen Vertrag hat, aber das ist nicht richtig, wir haben tatsächlich Prototypen, die Experimente sind, um zu versuchen, einen Vertrag zu bekommen ... Wir registrieren Bestellungen gegen sie, um sie zu bauen, aber sie sind nicht Teil eines Vertrags.

„Ja, das war nicht Teil unserer ursprünglichen Spezifikation. Haben Sie einen gemeinsamen Begriff, der sowohl Prototypen als auch Verträge umfasst, sodass ich Ihnen eine Liste von _____ und dann eine Spalte mit der Aufschrift „type=Prototype“ vs. „type=Contract“ zeigen kann? Wie würde diese Liste heißen?“

„Oh ja, wir nennen sie alle nur Projekte.“

Und dann schreiben Sie Ihre interne Datenstruktur so um, dass Bestellungen zu einem Projekt gehören, das möglicherweise type=Prototypeoder hat type=Contract, es sei denn, Sie haben genügend Unterschiede zwischen ihnen, dass Sie eine Prototype-Tabelle und eine Contract-Tabelle benötigen, die vom Projekt mit Fremdschlüsseln versehen sind.

Der Punkt ist, dass Sie, wenn Sie die Erstellung der Datenbank nicht verzögern, bis Sie dieses Feedback erhalten, unter Druck eine sehr wackelige Datenbank erhalten werden:

„Äh, warum haben diese Verträge all diese Nullwerte? Haben wir einfach vergessen, sie zu machen NOT NULL?“

"Vielleicht. Haben sie eine Nummer für ihre prototype_id?“

"Ja..."

„Nun sehen Sie, was die Datenbank einen Vertrag nennt, ist eigentlich das, was die Benutzeroberfläche ein Projekt nennt, denn als wir anfingen, dachten wir, dass alle Projekte Verträge sind, aber das sind sie nicht, einige sind Prototypen. Also müssen entweder alle Vertragsspalten null und die Vertragsspalten prototype_idnicht null sein, oder die müssen prototype_idnicht null sein und die Vertragsspalten müssen null sein.“

Menschen denken am besten, wenn sie mit einem System interagieren können. Vor allem Menschen, die Ihnen Anforderungen stellen. Der Punkt von Agile ist, dass traditionelles Softwaredesign so etwas ist, als würde man ein Komitee, das nichts über Kleidung weiß, bitten, eine Spezifikation darüber zu schreiben, welche Art von Kleidung sie tragen möchten, und dann werden wir diese Kleidung genau nach dieser Spezifikation produzieren und dann, wenn sie es sind unzufrieden mit ihrer Passform, steht es ihnen frei, sie nicht zu tragen oder Folgedokumente zu erstellen, die voraussehen, wie sie sich verändern. Ein agiler Shop versucht stattdessen, eine Reihe sukzessiver maßgeschneiderter Annäherungen zu erstellen, die jederzeit genau zum Kunden passen, aber nicht richtig aussehen. Sie beginnen also mit „Ok, wir werfen dir ein Laken über den Kopf“ und erhalten die Rückmeldung „OK, aber ich kann nicht durch das Laken hindurchsehen und es hat auch die falsche Farbe für das, was ich vorhabe. ” Neues Blatt in einer besseren Farbe mit einem Loch darin. „Nein, es braucht Ärmel und eine Kapuze.“ Und so weiter.

Sie können es absichtlich verzögern, wichtige Teile der Funktionalität richtig hinzubekommen, weil Sie etwas wie die „Farbe“ missverstehen könnten, die eine beträchtliche Menge an Nachbearbeitung von Grund auf erfordert. Dies passiert ständig mit Datenbankstrukturen.

Wenn Sie ein verteiltes System mit vielen Komponenten haben, können Sie auf diese Art von Problem stoßen. Ich habe festgestellt, dass die Idee der technischen Befähigung ein guter Ausgangspunkt ist. Sie haben einen Ausdruck eines Bedarfs auf oberster Ebene, aber Sie können andere Product Backlog Items erstellen, die dies ermöglichen können. Jeder sollte in der Lage sein, unabhängig entworfen, gebaut, getestet und geliefert zu werden. Vielleicht erfüllen sie allein nicht die Bedürfnisse des Endbenutzers, aber sie ermöglichen es Ihnen, die Arbeit zu planen und sicherzustellen, dass Sie das haben, was Sie brauchen.

Es wird noch besser, wenn diese technischen Unterstützungsaufgaben mehrere verschiedene benutzerorientierte Product Backlog Items entsperren können. Je nachdem, was die verschiedenen Product-Backlog-Einträge sind, können Sie möglicherweise kreative Wege finden, um die technische Befähigung in bestimmten ("untergeordneten") Komponenten aufzuteilen, um eine Reihe von Product-Backlog-Einträgen zu aktivieren und gleichzeitig sicherzustellen, dass sie eine angemessene Größe und einen angemessenen Umfang haben , und lieferbar.

Abhängig von den Tools, die Sie zum Verwalten Ihres Product Backlogs verwenden, können Sie möglicherweise Beziehungen und Verknüpfungen zwischen der Arbeit festlegen, um festzustellen, dass ein technisches Aktivierungselement andere Arbeiten „blockiert“, oder Abhängigkeiten entsprechend festlegen. Dies kann bei der Planung und Terminierung der Arbeit helfen und sicherstellen, dass alles Erforderliche erledigt und geliefert wird, wenn es benötigt wird.

Die kurze Antwort lautet: Nein, schneiden Sie nicht alles durch, es sei denn, das, was Sie tun, geht tatsächlich durch alles, dann halten Sie es in seinem Umfang begrenzt.

Die Idee des Vertical Slice war es, von Backlog-Items wie „Entwurf von Datenbanktabellen für Kunden“ wegzukommen. Wenn Sie Backlog-Items verwenden, die aus Kundensicht einen Mehrwert bieten und nur einige davon berühren, ist das in Ordnung.

Beginnen Sie außerdem mit einfachen Architekturen. Sie brauchen all diese Dinge mit ziemlicher Sicherheit nicht, um Ihre ersten paar Backlog-Elemente zu unterstützen. Ich bin oft überrascht, wie weit in ein Softwareprojekt ich ohne Dinge wie eine Datenbank einen Mehrwert liefern kann. Wenn wir die Anwendung als lose gekoppelten Code oder noch besser als stark entkoppelten Code erstellen, ist das spätere Hinzufügen zusätzlicher Komponenten, wenn wir sie benötigen, nicht allzu viel Arbeit.