Epics, User Stories und Anforderungen

Teilen!

Lassen Sie uns einen Schritt nach dem anderen machen: Agiles Vorgehen ändert wenig oder gar nichts an der Notwendigkeit, Anforderungen zu dokumentieren. Es spielt keine Rolle, welchen Namen oder welche Struktur wir verwenden. Wir nennen sie Epics, User Stories oder Anforderungen. Wir verwenden sie im Rahmen von Operationen, Projekten oder Innovationen. Die Dokumentation dieser Strukturen, unserer Bedürfnisse oder der Art und Weise, wie wir die von uns ermittelten Möglichkeiten nutzen wollen, ist für jede Initiative von grundlegender Bedeutung. Und damit meine ich nicht nur den Zweck, anderen mitzuteilen, was wir denken, sondern auch den Prozess des Dokumentierens für die Zukunft. Dokumentieren ist ein Prozess des Nachdenkens über das Schreiben, und dabei strukturieren wir oft ungewollt unsere Gedanken besser.

Zunächst einmal ein wenig Geschichte. Die Softwareentwicklung ist heute und war schon immer eine große Herausforderung für die Kommunikation zwischen Menschen. Seit den Tagen der Lochkarten haben Programmierer, die in der Lage sind, Programme für Computer zu erstellen, und Ideengeber, die zwar nicht in der Lage sind, Programme zu erstellen, aber gute Ideen für die Nutzung der Rechenleistung von Maschinen haben, Schwierigkeiten, "miteinander auszukommen".

Anforderungen

Zur Lösung dieses Kommunikationsproblems wurden zahlreiche Werkzeuge entwickelt, und das grundlegende Konzept, das dahinter steht, ist als Software-"Anforderung" bekannt.

In der Systementwicklungstechnik ist ein Anforderung ist eine dokumentierte Anforderung an den Inhalt, die Form oder die Funktionalität eines Produkts oder einer Dienstleistung. Er wird in einem formalen Sinne in der SystemtechnikSoftwaretechnik e Anforderungserhebung.

Wikipedia (April 2020) - https://es.wikipedia.org/wiki/Requisito_(sistemas)

Warum ist es so schwierig, Anforderungen zu schreiben?

Es gibt viele Theorien über die Komplexität von Anforderungen. Um meinen Standpunkt zu verdeutlichen, möchte ich jedoch ein Konzept verwenden, das ich schon immer fabelhaft fand: konzeptionelle Integrität von Fred Brooks. Darunter versteht man die Fähigkeit einer Person oder einer sehr kleinen Gruppe von Personen, den gesamten Entwurf eines Systems, Produkts oder Modells zu kontrollieren.

In einem seiner Bücher - das Design des Designs - hebt die begriffliche Integrität anhand eines Beispiels hervor: Denken Sie einen Moment darüber nach, wer die elektrische Glühbirne, das Telefon, den Telegraphen oder das Flugzeug erfunden hat. Bei all diesen Beispielen ist es leicht, den Erfinder zu identifizieren. Wenn jedoch die Komplexität des zu entwerfenden Systems erheblich zunimmt, ist es für eine einzelne Person fast unmöglich, die Details aller Komponenten im Kopf zu haben. An diesem Punkt ist die Wahrung der konzeptionellen Integrität eine echte Herausforderung.

Wenn Ihnen das Problem immer noch unklar ist, denken Sie an ein Buch, das Sie gelesen und mit einer anderen Person besprochen haben: Wie groß ist die Wahrscheinlichkeit, dass Ihre Vorstellung von den Charakteren und Motivationen der anderen Person genau dieselbe ist? NULL! Und wir sprechen hier von Büchern, die Hunderte von Seiten lang sind.

Ein Schüler sagte einmal zu mir in der Klasse, als wir uns mit diesem Konzept befassten: "das Problem [der begrifflichen Integrität] besteht darin, dass andere Leute denken". Ich verstehe zwar Ihre persönliche Motivation und die Frustration, die es hervorrufen kann, dass unterschiedliche Interpretationen in keiner Weise übereinstimmen, aber wir können nicht für die Idee des "Aufhörens zu denken" eintreten. Was wir anstreben, ist genau das Gegenteil, wir wollen, dass jedes einzelne Mitglied eines Teams denkt.

Zusammenarbeit oder Schuldzuweisung

Ein weiterer Aspekt, der bei der Wahl der Instrumente zur Erleichterung der Kommunikation zwischen "denen, die Ideen haben" und "denen, die sie umsetzen können" zu berücksichtigen ist, ist das Ausmaß dieser Zusammenarbeit. Mit anderen Worten, wie viel Zusammenarbeit und Vertrauen es zwischen den Teammitgliedern und innerhalb einer Organisation gibt.

Vertrauen erfordert psychologische Sicherheit innerhalb der Teammitglieder und innerhalb einer Organisation oder eines Unternehmens. Psychologische Sicherheit ist ein Begriff, der von Amy C. Edmondson, einer Professorin der Harvard Business School, geprägt wurde. Edmondson, Professor an der Harvard Business School, dass die Art und Weise, wie wir kommunizieren, und insbesondere die Art und Weise, wie wir während kreativer Prozesse oder bei der Entwicklung neuer Lösungen kommunizieren, beeinflusst wird.

In einem Umfeld mit geringer psychologischer Sicherheit haben die Mitglieder eines Teams oder einer Arbeitsgruppe kein Vertrauen zueinander. Wenn eine Bedrohung auftaucht, sei es ein Problem, ein Fehler oder eine Fehlinterpretation, versucht der Einzelne, die Verantwortung auf andere abzuwälzen". Wenn diese Situation regelmäßig auftritt, werden die Anforderungen zum "Vertrag", der die Beziehung regelt. Dies hat zur Folge, dass die Dokumente, die das Gespräch zwischen den Parteien moderieren, ausführlicher und erklärender werden. Wie der Versuch, zu "dokumentieren", wessen Schuld es ist, wenn etwas schief geht.

Anwendungsfälle

Sie sind die schrittweise Dokumentation der Interaktion eines Benutzers mit einem Informationssystem. Die Beschreibung dieses Schrittes für Schritt, Klick für Klick und Moment für Moment, wich den Use Cases. Ein UC - oder Use Case - enthält detaillierte Informationen über die Interaktionsabläufe, die ein bestimmter Benutzertyp (Actor) hat, fast immer in Form eines Gesprächs:

  • Benutzer führt Aktion X aus
  • Das zu entwickelnde System (SuD) führt die Aktion Y
  • Benutzer führt Aktion aus Z

Ich glaube, sie haben es verstanden. Zu dieser Konversation zwischen dem Benutzer und dem System gehören sie:

  • Ausnahmewege - was passiert, wenn in einem der Schritte etwas anders läuft,
  • Testfälle - Diskussionen darüber, wie die einzelnen Schritte zu validieren sind,
  • Beschreibungen,
  • Bilder

Eines der besten Bücher für die Dokumentation guter Use Cases stammt aus der Hand eines großen Unternehmers - Alex Torrenegra - als ich noch versuchte, für meinen Lebensunterhalt zu programmieren: Effektive Anwendungsfälle schreiben von Alistair Cockburn.

Profis

  • UC ist sehr wertvoll, wenn die Systeme, die wir entwerfen (SuD), extrem komplex sind.
  • Wenn das mit der Entwicklung beauftragte Team mit der Funktionsweise des SuD nicht vertraut ist. Zum Beispiel, wenn wir neue Teammitglieder oder neue Teams haben oder wenn wir neue Lieferanten in unsere Entwicklungsstruktur aufnehmen.
  • Sie geben einen klaren Überblick darüber, was in den Bildschirmen, Abläufen und Prozessen eines komplexen Systems erwartet wird.
  • Sie lassen wenig Raum für Kreativität und abweichendes Denken.

Nachteile

  • UCs lassen keinen Raum für Verbesserungsvorschläge, Kreativität oder allgemein abweichendes Denken.
  • Sie lassen keine offene Diskussion über neue Ideen zur Benutzerfreundlichkeit, Funktionalität oder Leistung zu.
  • UCs sind in hohem Maße von der konzeptionellen Integrität abhängig.

Innovative User-Story-Umgebungen

In Umgebungen mit größerer Ungewissheit, in denen keine Klarheit über die Anforderungen besteht, kann ein detaillierter Detaillierungsgrad schwierig oder einfach unpraktisch sein. Ein Beispiel: Bei der Entwicklung eines neuen Produkts kann die detaillierte Definition von Anforderungen dem Team Kopfzerbrechen bereiten oder es stark einschränken.

Anwenderberichte

Um die Beteiligung aller Mitglieder zu fördern und abweichendes Denken zu begünstigen, entstanden neue Dokumentationsmodelle, die sehr viel leichter und auf die Förderung von Diskussionen ausgerichtet waren, die zur Lösung beitrugen. eXtreme Programming (XP), ein agiler Softwareentwicklungsprozess, der in den 1990er Jahren entstand, schlug die Verwendung von User Stories (US) vor.

User Stories haben den gleichen Zweck wie Anwendungsfälle, sind aber nicht dasselbe. Sie werden verwendet, um Zeitschätzungen für die Release-Planungsbesprechung zu erstellen. Sie werden auch anstelle eines umfangreichen Anforderungsdokuments verwendet. Anwenderberichte sind die von den Kunden als Dinge geschrieben wurden, die das System für sie tun sollte. Sie ähneln den Nutzungsszenarien, mit dem Unterschied, dass sie nicht auf die Beschreibung einer Benutzeroberfläche beschränkt sind. Sie haben das Format von etwa drei Sätzen, die der Kunde in seiner eigenen Terminologie und ohne Fachausdrücke schreibt.

eXtreme Programmierung (April 2020) - http://www.extremeprogramming.org/rules/userstories.html

Im Gegensatz zu den Use Cases fördern die USA mehrere Dinge:

  1. Konzentration auf das Ziel (die zu lösende Aufgabe oder Notwendigkeit) und nicht auf das Wie
  2. Die Konzentration auf das Ziel fördert innovative Lösungen
  3. Vereinfacht, dass Benutzer, Kunden und Interessenvertreter das System nicht kennen müssen, um Ideen zu entwickeln oder neue Funktionen anzufordern
  4. Gespräche, Diskussionen und Debatten darüber, wie ein US zu lösen oder zu vervollständigen ist, sind erwünscht - was bei UC durchaus vorkommen kann, aber fast immer eher wie eine "Erklärung des Ablaufs" als eine echte Diskussion über Gleichberechtigung wirkt.

Profis

  • Die USA fördern abweichendes Denken und kreative Lösungen.
  • Sie ermöglichen andere - und sicherlich effizientere - Vorschläge für die gestellten Probleme oder Bedürfnisse.
  • Steigerung der Produktivität von Teams - ausgereifte, gut eingespielte Teams
  • Förderung der Beteiligung von Kunden - und anderen wichtigen Stakeholdern - durch einfache Formulierung (was die Eintrittsbarrieren für die Beteiligung und Eingabe verringert)

Nachteile

  • Nicht aufeinander abgestimmte Teams können Entwürfe oder Anwendungsarchitekturen verletzen, die in großem Maßstab - in großen Organisationen - entworfen wurden.
  • Die Verwendung von US zu erzwingen, kann ein echtes Problem sein - gerade wegen des Mangels an Details. Ich habe zum Beispiel einmal erlebt, wie ein Team versucht hat, BI- und Analysevorgänge mit US zu beschreiben.
  • Viele sind der Meinung, dass die USA nicht mit anderen Instrumenten wie Aufgaben, Anwendungsfällen oder technischen Anforderungen (NFR) in einem Backlog - einer priorisierten Liste von Anforderungen oder zu erledigenden Arbeiten - koexistieren können.

Wenn Sie mehr darüber wissen wollen, wie man gute User Stories schreibt, empfehle ich Ihnen das Buch "Angular" User Stories von Mike Cohn: Angewandte User Stories. Eine wohlverdiente Erwähnung geht an zwei Kolumbianer (Lucho Salazar y Jorge Abad), die mit ihrer Veröffentlichung eine hervorragende Arbeit geleistet haben Anwenderberichte: Eine pragmatische Sichtweise.

Agile Modellierung

Die agile Modellierung bezieht sich auf die Verwendung anderer Instrumente und Werkzeuge zur Dokumentation von Anforderungen - meist Softwareanforderungen. Sie können als eine Art "Erweiterungspaket" für Frameworks wie XP oder Scrum. Meiner Erfahrung nach sind die nützlichsten ergänzenden Instrumente dieser Zeit:

Skalierung und Disaggregation, über User Stories hinaus

Die Verwendung eines einzigen Instruments im Rückstand - oder die Beschreibung aller Instrumente auf derselben Skala - ist jedoch ineffizient, wenn wir für ein und dasselbe Instrument unterschiedliche Zeithorizonte haben. Das heißt, das Backlog enthält Anforderungen, die so klar und wichtig sind, dass sie in den nächsten Wochen ausgeführt und abgeschlossen werden müssen, und es kann auch Elemente enthalten, die nur vage Ideen sind.

Diese "Anmerkungen" zum Backlog scheinen eher eine "Erinnerung" für zukünftige Diskussionen zu sein - meiner ganz persönlichen Meinung nach und vielleicht beeinflusst durch computergestützte Management-Tools, sollte man immer alle Ideen und Konzepte, die das Potenzial haben, Realität zu werden, im Backlog niederschreiben und sich nicht auf das menschliche Gedächtnis verlassen.

Folglich kann der Umfang des Aufwands und der Komplexität eines Elements innerhalb des Backlogs viele Anforderungen berücksichtigen - in Form von Stories oder Use Cases, oder einfachen Aufgaben - hier weiche ich von den radikalen Puristen ab. In ihrem Bestreben, verschiedene Detail- und Größenordnungen zu benennen und irgendwie deutlich zu machen, dass solche Elemente einer weiteren Untergliederung bedürfen, wurden Konzepte wie Epics, Features und Capabilities geschaffen. Epen, Eigenschaften y Fähigkeiten.

Praktische RatschlägeDie Namen Epic, Trait und Ability können nach Belieben verwendet werden, sollten aber nicht vertauscht werden, um keine Verwirrung zu stiften. Sie können einen, mehrere, diese und andere verwenden. Machen Sie es nicht kompliziert, sondern geben Sie jedem Begriff einen besonderen Kontext und eine besondere Verwendung.

Episch

Eine ausgezeichnete Idee, die das Team von Scaled Agile Framework war es, für jedes Instrument spezifische Zwecke zu definieren - und auch Ziele innerhalb der Planungs- und Durchführungszeiträume. Das ist zwar nicht der einzige Weg, aber meines Erachtens der beste Weg (bisher), um die einzelnen Skalen zu unterscheiden.

In diesem Bezugsrahmen ist die episch sind Instrumente zur Definition von Portfolio-Investitionen - aus Marketinggründen und um sich vom immer weiter zurückliegenden PMI zu distanzieren, haben sie beschlossen, das Wort "Projekt" nicht zu verwenden. Epics sind dann Komponenten eines Portfolios oder Programms, die die Validierung von technischen oder geschäftlichen Hypothesen beinhalten - ähnlich wie ein Agile Business Case. Sie bestehen darauf, dass Epen und Projekte nicht dasselbe sind, aber so wie ich meine persönlichen Differenzen mit der "PMI-Philosophie" habe, habe ich auch meine Differenzen mit der "SAFe-Philosophie".

Im Rahmen eines Epos können wir viele Dinge in Betracht ziehen, von denen einige darauf abzielen, Risiken zu verringern, andere, unsere organisatorischen oder technischen Fähigkeiten zu aktivieren, und wieder andere, die auf die Erfüllung strategischer Ziele ausgerichtet sind.

Merkmale Eigenschaften

Ein in diesem Kontext definiertes Epos scheint jedoch weit entfernt von der Arbeit agiler Teams zu sein. Deshalb brauchen wir intermediäre Instrumente, die die strategische Ebene mit dem Betrieb und der Realisierung dieses Geschäftswerts verbinden. Hier wurden, sehr zu meinem Leidwesen, Begriffe verwendet, die sehr eng mit der Produktentwicklung verbunden sind: die Eigenschaften.

Features sind zwei Dinge, eine High-Level-Anforderung, irgendwo zwischen Epics und Stories, und stellen daher auch ein Set von Backlog-Elementen dar, das ein nahes Instrument für das Team ist - obwohl sie in SAFe andere High-Level-Backlogs definieren. Interessant ist das zeitliche Verhältnis, das sie zwischen Geschichten und Features herzustellen versuchen.

Kapazitäten Fähigkeiten

In SAFe gibt es ein zusätzliches Aggregationswerkzeug, das als Kapazitätderen auffälligster Unterschied zum Eigenschaften ist, dass sie durch die Arbeit verschiedener ARTs abgeschlossen wird - ein Begriff für ein großes agiles Team, das sich auf ein Produkt, eine Dienstleistung oder einen Wertstrom konzentriert.

Planungsinstrumente

Erinnern Sie sich daran, dass Backlog-Elemente Instrumente zur Identifizierung von Werten und zur Aufrechterhaltung des Abgleichs zwischen Zweck und Lieferung sind - ein Konzept, das in der Welt, die den "Flow of Business Value" fördert, immer mehr an Bedeutung gewinnt. Ebenso sind diese Elemente sehr nützlich für die Festlegung von Zeithorizonten und, ob man will oder nicht, von geschäftlichen Meilensteinen.

Elemente, die verschiedene Aufwandsstufen repräsentieren, sind sehr nützlich für die Festlegung der Lieferkadenz. Als Beispiel sei hier der Vorschlag von Scaled Agile Framework:

  • Zweiwöchige Iterationen (längere erscheinen mir unnötig, ich mag einwöchige Iterationen lieber) sollten mehrere User Stories liefern.
  • Zyklen von 5 oder 6 Iterationen oder Sprints, um verschiedene Funktionen und Fähigkeiten zu liefern (Programminkrementalismus in SAFe)
  • Ein Jahr könnte mehrere Epics (Lean Portfolio) liefern, lösen oder angehen.

Schlussfolgerungen und Überlegungen

Die Herausforderung ist dieselbe: die Wahrung der konzeptionellen Integrität zwischen den Beteiligten - den wunderbaren, vielfältigen und verstreuten Menschen - und die Erleichterung und Förderung der Entwicklung der "bestmöglichen Lösungen" - technisch, wirtschaftlich, funktional und benutzerfreundlich. Es gibt Instrumente, die die Kreativität und das abweichende Denken einschränken - sehr nützlich für die Lösung komplexer Probleme, bei denen die Teams nicht über das nötige Fachwissen und/oder Wissen verfügen oder bei denen es einfach unpraktisch ist, verschiedene Lösungen vorzuschlagen oder die Interpretation zu fördern - wie z. B. bei fortgeschrittenen Berechnungen mit Daten, Berichten und streng regulierten Geschäftsprozessen. Es gibt Werkzeuge, die divergentes Denken und innovative Lösungen fördern, die zur Schaffung neuer und besserer Produkte beitragen, und mentale Ausrichtungsmechanismen - wie Agile Personas - zur Stärkung der konzeptionellen Integrität darstellen.

Diese Werkzeuge, wie z. B. User Stories, sind auch je nach Reifegrad des Teams und den Kenntnissen der Mitglieder über das System selbst nützlich. Stellen Sie sich vor, eine Gruppe von "Neulingen" ohne vorherige Erfahrung würde versuchen, ein System innerhalb einer Organisation mit starken Design-Zwängen oder technischen Beschränkungen - wie z. B. Altsysteme - zu entwerfen, und das zum Zeitpunkt der Erstellung von Benutzergeschichten - das wäre frustrierend!

Stellen Sie sich umgekehrt eine erfahrene Gruppe enger Kollegen vor, die versuchen, eine Aufgabe zu lösen, indem sie in die Fußstapfen von jemandem treten, der nicht dabei ist - langweilig! - Wir müssen immer ein Gleichgewicht zwischen Fähigkeiten und Herausforderungen finden, und diese Werkzeuge können in jeder Phase eines jeden Zyklus nützlich sein.

Andere Instrumente gibt es nur, um verschiedene Aufwands- und/oder Zeitskalen zu verwalten, wie z. B. Epen und Merkmale. Sie sind nützlich, um mehrere Teams auf hohem Niveau zu managen und wertvolle Absichten, Zwecke und Ziele zu vermitteln.

Zum Abschluss möchte ich Ihnen noch dieses kurze Video über das Konzept der konzeptionellen Integrität zeigen. Nichts so Tiefgründiges und Radikales wie das Video von Amy.

In Zukunft wird es sicherlich neue Möglichkeiten der Kommunikation und Dokumentation unserer Bedürfnisse geben, und ich hoffe, dass ich dabei sein kann, um sie zu nutzen und das Beste aus ihnen zu machen.

Teilen!

Alberto Dominguez
Alberto Dominguez

Führung von Teams von der Theorie bis zur tatsächlichen und nachhaltigen Bereitstellung innovativer IT-Produkte und -Dienstleistungen.

Artikel: 37

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.

de_DE