Architektonische Prinzipien als "nicht-funktionale" User Stories

Question

Ich starte gerade ein Pilotprojekt in unserem Unternehmen, um agile Praktiken einzuführen, einschließlich der Verwendung von User Stories. Nachdem ich zwei Bücher von Mike Cohn gelesen habe, insbesondere Agile Estimating und Planning und User Stories Applied, habe ich jetzt eine klarere Vorstellung davon, wie es weitergehen soll. Ich vertraue darauf, unsere Techniken mit der Praxis zu verfeinern.

Allerdings gibt es eine Sache, die mich nicht überzeugt. In this blog post Mike Cohn definiert eine bestimmte Art von User Stories, die er Constraints nennt, um die sogenannten nicht-funktionalen Anforderungen zu definieren. Persönlich mag ich nicht das Wort Constraint und sogar die Verwendung der klassischen Vorlage "Als ... möchte ich ..., so dass ...".

Vielmehr werde ich versuchen, die Kunden machen zu schreiben, immer auf den Karten, vielleicht mit der obigen Vorlage, jene, die Nick Rozanski und Eoin Woods genannt, in ihrer fantastischen Buch Software Systems Architecture, architektonischen Prinzipien:

"Ein architektonisches Prinzip ist eine Aussage über Glauben, Annäherung oder Absicht, die die Definition einer Architektur leitet."

(sie teilen auch diese Prinzipien in Geschäftsprinzipien und Technologie Prinzipien, eine Differenzierung ich denke, wir sollten nicht.)

Was möchte ich mit diesen Prinzipien Karten zu tun ist es, sie neben unser Backlog-Karten-Board zu legen, damit sie während der User-Stories-Definition und den Planungsaktivitäten immer präsent sind. Ich würde auch Kunden und Entwickler ermutigen, sie abzuholen und sie jedes Mal neben das Iteration Board zu legen, wenn sie denken, dass eine Karte als Erinnerung für das Team nützlich sein könnte.

Haben Sie jemals einen ähnlichen Ansatz versucht? Entmutigen Sie es aus irgendeinem Grund? Haben Sie einen Vorschlag in dieser Angelegenheit?

Answer 1

Haben Sie jemals einen ähnlichen Ansatz versucht? Ich habe nichts genau Ähnliches versucht, aber als ich ein Scrum Master meines Teams war, hatten wir eine projektweite architektonische Richtlinie und Vision (an der alle Teams teilnahmen), an die wir uns während der verschiedenen Inspektions- und Anpassungspunkte erinnerten eines Sprints und auch des Scrum-Projekts, wie bei Retrospectives, Sprint-Planning-Meetings und sogar Daily-Scrum-Meetings. Wir erinnerten uns zum Teil daran, dass wir Done Criteria für Aufgaben hinzufügten, die ein Prinzip zur Befolgung von Architekturrichtlinien enthielten, und es konnte auch als kleine Notiz in Backlogs hinzugefügt werden. In meinem Vorschlag unten habe ich erwähnt, wie dies von einem wirklich hohen Niveau aus betrachtet wurde.

Entmutigen Sie es aus irgendeinem Grund? Nein überhaupt nicht. Ich sage, dein Vorschlag ist gut und du solltest es für ein Planungstreffen versuchen. Und wie von Ken Schwaber und Jeff Sutherland in ihrem Scrum Guide vorgeschlagen, sollten Sie während der drei Punkte in einem Sprint inspizieren und anpassen: "Es gibt drei Punkte für die Überprüfung und Anpassung in Scrum. Das Daily Scrum Meeting wird verwendet, um Fortschritte in Richtung der Sprint-Ziel, und Anpassungen vorzunehmen, die den Wert des nächsten Arbeitstages optimieren. Darüber hinaus werden die Sprint Review- und Planning-Meetings verwendet, um den Fortschritt in Richtung Release-Ziel zu überprüfen und Anpassungen vorzunehmen, die den Wert des nächsten Sprints optimieren. Die Sprint-Retrospektive wird verwendet, um den vergangenen Sprint zu überprüfen und festzustellen, welche Anpassungen den nächsten Sprint produktiver, erfüllender und angenehmer machen werden. "

Haben Sie einen Vorschlag zu diesem Thema? Ist es sicher für mich anzunehmen, dass dieses "Agile" -Projekt in Ihrem Unternehmen gerade erst beginnt und Sie noch keine solide Vision für das Projekt haben? Wenn ja, würde ich vorschlagen, dass Sie einen 2-wöchigen projektweiten Release-Planungs-Workshop vereinbaren. Der Zweck dieses Workshops ist es, alle Interessengruppen, POs, SMs und Projektmanager an einem Ort zu finden und eine Super User Story und Vision zu entwickeln. Der Rest der Backlogs wird von der Super User Story getrennt. Die Super User Story wäre die hohe Vision des Projektziels. Wenn Sie dies bereits getan haben, dann ignorieren Sie bitte diesen Vorschlag, aber mein Punkt, dies zu bringen ist, dass die High-Level-Vision oder Super-User-Story einen Teil haben könnte, der dem architektonischen Prinzip in Ihrem Unternehmen entspricht.

Vorteile davon? Sie bezieht den Stakeholder direkt aus der Super User Story in den architektonischen und technischen Aspekt des Produkts ein, was dazu beiträgt, ein gutes Verständnis für die Vision zwischen der geschäftlichen und der technischen Seite zu schaffen, und ohne das andere nicht leben kann.

Ich habe absichtlich versucht, die Antwort über den Fragenumfang hinaus zu erweitern, damit ich auch ein Feedback zu meinen Ideen bekommen kann.

Danke, Sid.

Answer 2

Das war das Thema eines Vortrags, den ich im Januar dieses Jahres in der Architect Factory gesehen habe. Ich habe es aufgespürt. Es war Lee Ingrams "Business Driven Architecture: Ein Beispiel aus einem aktuellen Startup". Ich kann keine Folien finden, aber er sprach über die Idee von übergreifenden Prinzipien, die leiten, wie Anforderungen zu erfüllen sind.

Er hatte Dinge wie Mandantenfähigkeit und White-Labeling. Bei einem mandantenfähigen Web-Service müssen Sie von Anfang an für die Trennung/Isolation von Benutzern planen. Wenn Sie in der Lage sein möchten, Ihren Dienst mit einem White-Label-Dienst zu versehen, müssen viele weitere Dinge konfigurierbar sein (Stil, Labels usw.). Beide beeinflussen fast jede Geschichte.

Answer 3

Ich empfehle dringend Jeff Patton's presentation on user story mapping.

Er klärt nicht nur genau, welche Zwecke Geschichten erfüllen (oder wie immer man sie nennen möchte), sondern auch, wie man Beziehungen oder Abhängigkeiten zwischen Geschichten aufbaut und wie man damit umgeht.

Answer 4

Ich mache es in der Weise, die Sie beschrieben haben. Ich habe Beschränkungen für Karten (andere Farbe) definiert. Die Einschränkungen sind nicht im User-Story-Format geschrieben, sondern als einfacher Satz wie:

Das System unterstützt die maximale Nutzung von 30 Benutzern.

Importe müssen täglich ausgeführt werden.

Alle Filter und Suchergebnisse müssen auf der gleichen Seite sein.

Wenn Kunde einige spezielle Anforderungen hat, die nicht direkt einzelne Benutzergeschichte sind, aber breitere Wirkung haben, schreibe ich sie als Beschränkungen. Diese Einschränkungen werden nicht geschätzt und sind nicht Bestandteil des Produktstaus. Wir verwenden sie, um einige Implementierungsanforderungen für echte User Stories zu erinnern.

Answer 5

Diese allgemeine Idee von "Prinzipien" (oder Einschränkungen) scheint wie eine gute Idee. Ich habe gesehen, was passiert, wenn Dinge, die wirklich in dieser Klasse sein sollten - z. B. "System muss ein spezifisches, quantifiziertes Leistungsniveau erreichen" - einfach in den Backlog geworfen und unter all den anderen "Feature" -Geschichten verloren gehen Leistung (weil "es ist OK ... da ist eine Geschichte für das irgendwo") und wenn dann jemand es schließlich aufhebt (seltsamerweise werden diese Dinge trotz des hohen Wertes für den Kunden dauern gelassen), finden sie sich mit einem unmögliche Aufgabe für die wenigen Tage, die eine Geschichte voraussichtlich dauern wird, und wahrscheinlich nur mit einer ernsthaften Umgestaltung des Systems, die viel früher hätte durchgeführt werden müssen und nun enorme Umrüstkosten hat.