Java >> Java Tutorial >  >> Java

Von der Idee zum Code:Der Lebenszyklus agiler Spezifikationen

Wir haben gerade ein neues Projekt für einen Kunden gestartet, der Widgets verkauft. Dieser Kunde ist der führende Widget-Anbieter der ganzen Welt, also kann das Projekt uns entweder machen oder brechen.

Das Projekt arbeitet mit agilen Methoden, und der Product Owner ist gekommen, um mit dem Team zu sprechen. Er wird dem Team die wichtigsten Funktionen der Anwendung erläutern.

Produkteigentümer: Diese Anwendung ist im Wesentlichen eine Website, die die vom Kunden verkauften Widgets präsentiert. Die wichtigste Funktion dieser Anwendung ist die Funktion zum Hinzufügen neuer Widgets.

Team: Das macht Sinn. Schließlich kann die Anwendung nichts präsentieren, bis Widgets zu ihrer Datenbank hinzugefügt werden können. Können Sie uns die Spezifikation dieser Funktion zeigen?

Produkteigentümer: Sicher. Hier bitte.

Der Product Owner zeigt dem Team die folgende Abbildung:

Team: ...

Lassen Sie uns hier aufhören. Beantwortet diese Zahl die folgenden Fragen:

  • Was ist das Ziel der Funktion?
  • Welche Schritte sind erforderlich, um neue Widgets zur Datenbank hinzuzufügen, und was passiert, nachdem ein neues Widget hinzugefügt wurde?
  • Welche Art von Fehlern können auftreten und wie sollten diese Fehler behandelt werden?

Nein . Wir können herausfinden, dass das Ziel dieser Funktion darin besteht, neue Widgets zur Datenbank hinzuzufügen. Diese Zahl beantwortet jedoch nicht die anderen Fragen.

Ist diese Zahl wirklich eine ausreichende Angabe?

NEIN! Es ist nur ein UI-Mockup, um laut zu schreien! Es ist keine Spezifikation!

Aber es ist eine Idee. Wir können damit arbeiten und diese Idee in eine agile Spezifikation umwandeln.

Von der Idee zur Spezifikation

Das größte Problem der Situation, in der das Team unvollständige Spezifikationen vom Product Owner erhält, besteht darin, dass das Team nichts wirklich implementieren kann, bevor es herausgefunden hat, was es implementieren muss.

Das bedeutet, dass das Team zwei Möglichkeiten hat:

  1. Stellen Sie dem Product Owner eine zusätzliche Frage
  2. Improvisieren

Beide Optionen sind problematisch.

Wenn das Team beschließt, den Dialog mit dem Product Owner fortzusetzen, braucht es Zeit, um die genauen Anforderungen herauszufinden. Das bedeutet, dass sie nicht so viel Code schreiben, wie sie schreiben könnten .

Entscheidet sich das Team für Improvisation, raten sie im Wesentlichen, was sie umsetzen müssen. Was passiert, wenn ihre Vermutung falsch ist? Exakt. Sie haben Abfall geschaffen und sie müssen die Funktion neu implementieren.

Mit anderen Worten, unvollständige Anforderungen töten die Geschwindigkeit des Teams!

Wenn der Product Owner wirklich die Geschwindigkeit des Teams maximieren möchte, muss er dem Team Enabling Specifications liefern. Die Rolle des Product Owners wird in einem Scrum-Muster namens Enabling Specification beschrieben:

Der Product Owner sollte unterstützende Spezifikationen als Zeichen dafür liefern, dass er oder sie bei der Erkundung des Anforderungsraums die gebührende Sorgfalt walten ließ. „Befähigungsspezifikation“ bedeutet, dass die Spezifikation umfangreich genug ist, dass jemand mit angemessener Fachkenntnis eine Lösung ohne wesentliche nachfolgende Klärung implementieren kann.

Wenn der Product Owner dem Team befähigende Spezifikationen liefert, wandelt das Team diese Anforderungen in Code um.

Von der Spezifikation zum Code

Wenn das Team eine Aktivierungsspezifikation erhält, ist der Ball in seinem Feld. Sie müssen herausfinden, wie sie diese Spezifikation implementieren, aber das ist nicht alles, was sie tun müssen. Sie müssen sicherstellen, dass ihr Code die Anforderungen der Spezifikation erfüllt, und die Spezifikation bewahren, damit die nächste Person, die auf ihren Code stößt, weiß, was er tun soll.

Das Problem ist, dass niemand die Dokumentation wirklich liest oder aktualisiert . Aus diesem Grund ist das Schreiben von Dokumentationen eindeutig nicht die Lösung.

Es gibt eine saubere Lösung für dieses Problem:

Wir müssen Ermächtigungsspezifikationen in ausführbare Spezifikationen umwandeln.

Der am meisten gehypte Weg, dies zu tun, ist die Verwendung von Test-Driven Development. Um ehrlich zu sein, ist es mir egal, ob das Team Tests vor oder nach dem Schreiben des Codes schreibt.

Mir ist wichtig, dass das Team diese Richtlinien befolgt:

  • Das Team muss End-to-End-Tests (auch bekannt als Integrationstests) verwenden, um die Anforderungen der Funktion zu spezifizieren.
  • Das Team muss Einheitentests schreiben, die die Anforderungen jeder Ebene spezifizieren.

Wenn diese Bedingungen erfüllt sind, hat das Team ausführbare Spezifikationen erstellt, die jederzeit ausgeführt werden können.

Das gibt uns zwei große Vorteile:

  1. Wir wissen sofort, ob die Software ihre Anforderungen erfüllt oder nicht.
  2. Wenn wir wissen wollen, wie eine bestimmte Funktion funktionieren soll, können wir die End-to-End-Tests lesen und herausfinden.

Wir müssen nicht unzählige Stunden damit verbringen, veraltete Dokumentationen zu lesen und Informationen von anderen Teammitgliedern zu sammeln. Alles, was wir tun müssen, ist, die Tests zu lesen.

Das klingt verdammt gut für mich .

Mach einfach deinen verdammten Job

Die Grundidee hinter diesem Ansatz ist folgende:

Die Anforderungen unserer Bewerbung gehen nie verloren und wir können sie jederzeit herausfinden!

Diesem Ansatz zu folgen ist nicht einfach. Es erfordert viel Arbeit und DISZIPLIN alles richtig zu machen.

Der Product Owner muss das Produkt besitzen und dem Team helfen, dem Kunden so viel Wert wie möglich zu bieten. Andererseits muss das Team sicherstellen, dass Anforderungen der Anwendung während der Implementierungsphase nicht verloren gehen.

Ich habe viele Ausreden gehört, warum dies nicht möglich ist, aber alle diese Ausreden haben ein gemeinsames Problem:

Unser Kunde kümmert sich nicht um unsere internen Probleme . Er zahlt uns viel Geld und erwartet eine gute Rendite seiner Investition.

Ist es nicht unsere Aufgabe, dafür zu sorgen, dass dies geschieht?


Java-Tag