Systemgeschichten für agile Architektur

Question

Während wir versuchten, agile Prinzipien auf unseren Entwicklungsprozess anzuwenden, insbesondere Scrum-Prinzipien und XP-ähnliche User Stories, sahen wir uns mit einem Problem in Bezug auf die Architektur konfrontiert.

Vielleicht sind wir immer noch zu sehr mit der architekturzentrischen Entwicklung verbunden, aber wir versuchen, eine starke komponentenbasierte Entwicklung beizubehalten, die mit den agilen Modellierungsprinzipien gemischt wird. Unser Ziel ist es, ein kleines Design im Vordergrund zu haben, das während der Entwicklung anfällig für Entwicklungen ist.

Was ich suche, ist etwas, das mich in meine Backlog-Geschichten über meine Architektur und die darin enthaltenen Komponenten einbinden könnte: Entwicklungsgeschichten, nicht nur Nutzungsgeschichten. Systemstory könnte eine andere Art von User Story sein, die etwas erzählt, das nicht unbedingt mit dem geschäftlichen Wert zusammenhängt, sondern stattdessen mit Architektur- und Qualitätsaspekten eines Systems verknüpft ist.

Edit: I this research der Aalborg Universität über "Entwickler Geschichten" gefunden.

Haben Sie irgendwelche Erfahrungen, Ideen oder Widerstände?

Vielen Dank im Voraus! (Dies ist meine erste Frage !: D)

Answer 1

IMO ein Rückstand sollte nicht schließen Entwickler Geschichten. Es gibt keine Möglichkeit, dass ein Product Owner diese sinnvoll neben der Geschäftsfunktionalität priorisieren kann. Und was passiert, wenn der Product Owner einen von ihnen für unwichtig hält und ihn so aus dem Rückstand reißt? Wenn das Team darauf besteht, die Geschichte festzuhalten, befinden Sie sich in einer Situation, in der das Eigentum am Rückstand unklar wird.

Allerdings denke ich definitiv, dass das Team Architektur früh im Projekt bauen muss. Ein Problem bei meinem Projekt war, dass wir uns in den ersten Sprints zu sehr auf die Funktionalität konzentriert haben.

Denken wir über "architektonische Schulden" (ähnlich wie technische Schulden) als Zeit, die für den Aufbau von Infrastruktur und Architektur aufgewendet werden muss. Im Gegensatz zu technischen Schulden (die bei Null beginnen und sich aufstocken, wenn das Team Funktionalität ohne richtiges Refactoring produziert), beginnt ein Team mit mit Schulden und muss arbeiten, um es zu reduzieren. Die Zeit, die zum Reduzieren von Architekturschulden aufgewendet wird, bedeutet, dass weniger Zeit dafür aufgewendet wird, Funktionalität zu erzeugen, d.h.eine niedrigere Teamgeschwindigkeit und reduzierte Sprint-Leistung. Auf diese Weise ähnelt die architektonische Verschuldung der technischen Verschuldung. Wenn Anforderungen aufkamen, die nicht zur aktuellen Architektur passten, würde sich das Niveau der Architekturschulden erhöhen.

Denken Sie daran, dass das Team entscheiden sollte (und in der Lage sein muss, gegenüber dem Product Owner zu rechtfertigen), wie sie ihre Zeit verbringen werden. Und so können sie ihre Bemühungen auf Funktionalität, technische Schulden und architektonische Schulden verteilen, wie sie es für richtig halten.

Architektur Arbeit sollte immer noch von Funktionalität angetrieben werden. Mit anderen Worten, das Team sollte eine Infrastruktur aufbauen, um eine bestimmte User Story zu unterstützen und zu aktivieren. Nicht nur weil sie denken, dass es in Zukunft nützlich sein wird. The YAGNI principle gilt für diese Art von Ansatz.

Answer 2

Meine Antwort here gilt.

Es gibt eine sehr herausfordernde Balance zwischen Architekturarbeiten und mehr funktionsspezifischen Arbeiten. Technisch gesehen sind beide gültige Ansätze und funktionieren, aber je länger Sie eine Menge nutzbarer Produkte (Sprint-Ergebnisse) verschieben, desto größer ist das Risiko, dass Sie nicht das richtige Produkt bauen (Benutzeranforderungen, Leistungsanforderungen usw.). Gehen Sie so früh wie möglich an einen Punkt, an dem Sie Tests auf Systemebene durchführen können, um zu beweisen, dass Ihr Produkt funktioniert, und Sie den Wert und die Richtung des Produkts mit Ihren Interessengruppen demonstrieren können.

Answer 3

Es ist so einfach wie ein Stellen Sie sicher, die Mitgliedschaft Komponente kann von allen anderen Komponenten getestet werden 'Benutzer' Geschichte, Ihr Backlog sollte System/Entwicklung Geschichten haben, solange es synchronisiert wird mit dem Wunsch des Produktbesitzers einer solchen Implementierung.

Dies ist, wie wir in der Regel die nicht-funktionalen Anforderungen in einem Backlog setzen, wie „Das Domain-Modell auf einem anderen Rechenzentrum unter Last laufen muss balancing“ usw.

Answer 4

Ein Objektiv, das ich nützlich finde, um Entwickler Geschichten zu nehmen, ist darüber nachzudenken, wer "der Benutzer" für irgendeine gegebene Geschichte ist. Nur weil Sie kein Feature schreiben, das von Personen außerhalb Ihres Unternehmens gesehen wird, heißt das nicht, dass es keinen Benutzer für diese Arbeit gibt. Sie können Code für ein Team in der Halle schreiben. In einigen Fällen ist der Benutzer Sie selbst. Dies ist häufig der Fall bei Entwicklergeschichten. Think "Als Entwickler habe ich eine skalierbare Architektur, sodass ich problemlos neue Funktionen hinzufügen kann." Indem der bestimmte Benutzer aufgerufen wird, erhält der Product Owner einen Einblick darüber, wer den Wert der Story sehen wird. Und es ist auch hilfreich, das "Warum" zu verdeutlichen, welchen Nutzen die Geschichte zu erreichen hofft. Wie andere bereits erwähnt haben, geht die Verwaltung des Rückstandes auf eine Verhandlung zwischen dem Product Owner und dem Team zurück. Und wie immer müssen Sie herausfinden, was für Ihr Team am besten funktioniert, unabhängig vom Dogma des Prozesses. Jedes Team hat eine andere Situation und Ideen, die gut für ein Team funktionieren, übersetzen nicht immer in ein anderes.

Answer 5

In unserem Team nennen wir es "IT-Karten", also Karten der Form: "Als Entwickler. Ich möchte die xyz-Komponente umgestalten. Um Wartungskosten zu reduzieren und die Flexibilität zu erhöhen."

Teammitglieder können jede IT-Karte, die sie für wichtig halten, auswählen, anstatt eine "Feature-Karte" aus dem priorisierten Backlog herauszuholen.

Ich finde diesen Ansatz, um einigermaßen gut zu arbeiten, um technische Schulden auf einem akzeptablen Niveau zu halten und ein gesundes Tempo der Innovation zu ermöglichen.

Ich habe es etwas fehlt als ein Mittel zur Re-Architektur des Systems though. Es ist schwer zu rechtfertigen, lange vom Feature-produzierenden Flow abzuweichen.

Während ich dies schreibe denke ich, dass man sich der Architektur nähern könnte, indem man die Geschichten thematisiert. Identifizieren Sie die architektonischen Ziele mit Epen, die Sie in ein Thema aufteilen, auf das Sie sich konzentrieren sollten.