Es stellte sich heraus, dass dies länger war als geplant (es hatte als Kommentar begonnen), aber ich hoffe, dass die hinzugefügten Längen / Details hilfreich sind und Sie sie als gerechtfertigt ansehen.
Agile ist nicht spezifisch für CRUD-Apps
Der größte Teil der Agilitätsliteratur scheint auf CRUD-Geschäftsanwendungen ausgerichtet zu sein, bei denen der Benutzer ziemlich genau weiß, was hinter den Kulissen vor sich geht. (Das ist in Ordnung, da der größte Teil des Codes, der geschrieben wird, wahrscheinlich zu dieser Klasse gehört.)
Ich denke, das liegt daran, dass es einfacher ist, einfach zu verfolgende Beispiele dieser Art zu erstellen, und nicht wirklich daran, dass die Methodik auf diese Art von Systemen abzielt. Wenn Sie ein nicht so einfach zu verfolgendes Beispiel erstellen, besteht die Gefahr, dass der Leser feststeckt und versucht, das Beispiel zu verstehen, in dem der Leser über agile Konzepte unterrichtet werden sollte.
User Stories! = Anforderungen
Bei dieser Art von Anwendung ist die Beziehung zwischen User Storys (Anforderungen) und Entwicklungsaufgaben meist unkompliziert: Teilen Sie die User Story einfach in einige Aufgaben auf.
Eine User Story ist nicht dasselbe wie eine Anforderung. Es kann zwar zu Überschneidungen kommen, abhängig davon, wie hoch die Anforderung ist, aber im Allgemeinen nicht die gleiche. Ich habe den Eindruck, dass Sie in die gleiche Falle geraten, in die sich viele meiner ehemaligen Manager verliebt haben: User Stories einfach als Synonyme für "Anforderungen" zu verstehen, ähnlich wie bei SVN-Benutzern, die versuchen, auf Git umzusteigen, dies aber beibehalten Denken in Bezug auf SVN. (Sie stoßen dann aufgrund der schlechten Startannahmen auf Probleme.)
Meiner Meinung nach besteht ein wesentlicher Unterschied zwischen Anforderungen und User Storys darin, dass Anforderungen im Detail festlegen, wie sich bestimmte Systemkomponenten verhalten sollen. Es handelt sich um Spezifikationen , die Eingaben, Ausgaben, Annahmen / Voraussetzungen, mögliche Ausnahmen usw. umfassen. Sie konzentrieren sich auf das, was das System tut.
OTOH, User Stories konzentrieren sich auf das erwartete Ergebnis für den Endbenutzer, ohne zu versuchen, eine detaillierte Verhaltensspezifikation für Systemkomponenten zu erstellen. Sie konzentrieren sich auf die erwartete Benutzererfahrung .
Früher habe ich, und dies war eine Praxis, die mein Team übernommen hat, User Storys in Aufgaben unterteilt. Ihre Aufgaben könnten so spezifisch oder vage sein, wie Sie es wollten / brauchten, aber sie sollten Ihre Fortschrittsindikatoren für die tatsächliche Arbeit sein, um die Geschichte in einen Zustand zu versetzen, in dem sie erledigt ist.
Beispiel
Ich erinnere mich grob an die USA, an denen ich vor Jahren gearbeitet habe und an denen Benutzer Testfälle selbst zuweisen mussten, damit jeder im Team wusste, an welchen TCs sie arbeiteten, um Doppelarbeit zu vermeiden. Die Benutzeroberfläche war eine (n interne) Webanwendung. Der Benutzer sah nur eine Schaltfläche, aber die Story war in mehrere Aufgaben unterteilt, die einige Details zur technischen Implementierung usw. enthielten.
Sichtbarkeit des Benutzers
Es gibt jedoch eine andere Art von Anwendung, bei der der größte Teil des Codes mit komplexen Vorgängen zu tun hat, die für den Benutzer nicht direkt sichtbar sind.
Ist es möglich, es auf irgendeine Weise für den Benutzer sichtbar zu machen?
Betrachten Sie ein GPS. Wenn Sie nicht an der Reihe sind, sehen Sie den tatsächlichen Prozess der Neuberechnung der Route nicht, aber der Benutzer erhält einige nützliche Rückmeldungen (z. B. "Neuberechnung ...").
Compiler können Warnungen oder Fehler anzeigen oder neue Einstellungen / Optionen in die GUI aufnehmen, damit Benutzer sehen können, dass etwas Neues hinzugefügt wurde. Ich würde denken, die Benutzer für Compiler wären Programmierer, oder? Würden sie nicht Unterstützung für einen neuen Standard sehen?
Während die Unterstützung eines neuen Standards wahrscheinlich auf Feature- Ebene erfolgt und in User Storys unterteilt werden müsste, haben Sie sichergestellt, dass Sie zumindest in einigen Fällen keine Storys verwenden, wenn Sie stattdessen Features verwenden sollten ?
Die Bildanalyse in einem Auto könnte so formuliert werden, dass der Benutzer weiß, dass die Wahrscheinlichkeit eines Autounfalls verringert wurde. Beispielsweise:
Als Passagier in einem selbstfahrenden Auto muss die Wahrscheinlichkeit, dass das Fahrzeug durch einen Zusammenstoß mit einem nicht erkannten Objekt einen Unfall verursacht, so nahe wie möglich bei Null liegen, damit ich sicherer fahren kann.
Die USA erfassen auf hohem Niveau Dinge, die Sie normalerweise mithilfe einer Kombination aus funktionalen und nicht funktionalen Anforderungen spezifizieren müssten, einschließlich Sicherheit, Sicherheit usw.
Eine Anforderung bezieht sich jedoch möglicherweise eher auf das System. z.B:
Für die Funktion abcin der Komponente Amuss der Toleranzschwellenwert im Bildvergleichsalgorithmus verringert werden, um Objekte, die sich langsam bewegen, besser erkennen zu können.
Für mich wäre dies leicht eine Aufgabe in der oben erwähnten User Story mit dem Titel: Verringern Sie die FunktionstoleranzA.abc und fügen Sie dann andere relevante Details hinzu.
Für ein Fluidsimulationssystem könnte es sogar eine Fortschrittsanzeige geben, die Rückmeldung zu Hintergrundaufgaben gibt, die das System ausführt, wenn dies sinnvoll ist. (Es gibt immer eine Möglichkeit, den Benutzer über etwas zu informieren, auch wenn Sie Spam vermeiden möchten.)
Ich weiß nicht genug über die bestimmten Domänen, die Sie erwähnt haben, um bessere und / oder realistischere Beispiele zu finden, aber wenn es hier einen Ausweg gibt, können Sie auf verschiedene Arten Benutzerfeedback zu etwas geben, das weniger sichtbar ist Das System könnte dies tun, dh es könnte Möglichkeiten geben, unsichtbare Dinge ein bisschen sichtbarer zu machen. (Auch wenn es darauf hinausläuft, eine Reihe von Versionshinweisen zu verfassen, die dokumentieren, wie viel schneller die Systemleistung jetzt aufgrund Ihrer Bemühungen ist usw.)
Beziehung zwischen Geschichten und Aufgaben
Hier kann es sehr schwierig werden, Aufgaben und User Stories in Beziehung zu setzen.
Unser Ansatz war es, User Storys darauf zu konzentrieren, was die Anfrage war, warum sie gestellt wurde und welche Dinge zutreffen mussten , um die USA als "erledigt" zu betrachten. Das How wurde immer aus den USA ausgelassen und den Entwicklern überlassen.
Die Entwickler würden das in den USA beschriebene Problem in eine Reihe von Aufgaben aufteilen, an denen sie arbeiten würden.
Ich sage dies als jemand, der zum größten Teil Back-End-Programmierung auf dem Server durchgeführt hat, was für den Endbenutzer wahrscheinlich so "unsichtbar" ist.
Je nachdem, was ich tun musste, verwendete ich manchmal AJAX, um eine einfache "Lade ..." - Animation / GIF anzuzeigen, damit der Benutzer wusste, dass er ein bisschen warten musste, bis etwas anderes abgeschlossen war, ohne den falschen Eindruck zu bekommen. Manchmal war es so einfach. Eine Aufgabe hierfür wäre angebracht.
Anderes Paradigma, Übung und Erfahrung
Gibt es Techniken, um dieses Problem zu lösen, oder müssen wir nur akzeptieren und das Beste daraus machen?
Jenseits des Akzeptierens des Paradigmenwechsels, des Übens und der gesammelten Erfahrung, gibt es wahrscheinlich nicht viel mehr zu sagen. Ich habe oft Leute gesehen, die versucht haben, Abkürzungen durch den Prozess zu nehmen. Ich würde dagegen raten, besonders wenn Sie anfangen. Wenn Sie mehr Erfahrung sammeln, können Sie etwas Flexibilität zulassen, aber vermeiden, sich selbst zu untergraben.
In Anbetracht Ihrer vorherigen Formulierung denken Sie immer noch über Geschichten nach, als wären sie "umbenannte Anforderungen", was ich für eine falsche Annahme halte. Ich denke, dies ist ein Symptom für ein tieferes Problem in Bezug auf die grundlegenden Unterschiede zwischen agilen und nicht-agilen Ansätzen.
Zweitens denke ich, dass Sie akzeptieren sollten, dass Agilität ein Paradigmenwechsel im Vergleich zum Wasserfall ist, was bedeutet, dass der Prozess zwar ähnliche Ziele verfolgt, diese jedoch auf sehr unterschiedliche Weise durchgeführt werden. (Denken Sie SVN vs Git, wenn das hilft.)
Versuchen Sie, Ihr aktuelles Verständnis der konzeptionellen Unterschiede zwischen Anforderungen und User Stories zu verbessern, und akzeptieren Sie, dass sie nicht dasselbe sind.
Von Ihren Sprints lernen - Rückblicke
Was ich nicht genug betonen kann, ist die Retrospektive zwischen Scrum Master und Entwicklern am Ende jedes Sprints. Dies ist der Ort, an dem sie auf ehrliche / transparente Weise über Dinge diskutieren, die "gut gelaufen " oder "nicht gut gelaufen" sind , und welche umsetzbaren Änderungen für den nächsten Sprint vorgenommen werden, um die "nicht gut gelaufen" -Punkte anzugehen .
Dadurch konnten wir uns anpassen und sogar voneinander lernen, und bevor wir es wussten, hatten wir uns deutlich verbessert, gemessen an der allgemeinen Konstanz der Geschwindigkeit unseres Teams.