Da wir ein kleines Unternehmen sind, arbeite ich sowohl als Projektmanager als auch als Entwickler. Die Spezifikationen, die ich für Kunden erstelle, enthalten eine Reihe von Elementen zur Beschreibung und Definition des Projekts, einschließlich User Stories neben anderen Elementen, die ich zum Definieren des Projekts (z. B. Wireframes, Userflows, Sitemaps usw.) zum Client hinzufügen muss.
Wenn eine funktionale Spezifikation "beschreibt, wie ein Produkt vollständig aus der Sicht des Benutzers funktioniert. Es ist egal, wie das Ding umgesetzt wird. Es geht um Features. ". Hat jemand dann Probleme mit der Verwendung von User Storys, um eine funktionale Spezifikation für eine Website zu definieren? Macht jemand tatsächlich funktionale Spezifikationen auf diese Weise?
Ich versuche wirklich, mein Spiel ein wenig aufzurüsten, und ich frage mich, ob dies für größere Kunden funktionieren würde, die vielleicht strengere Vorstellungen darüber haben, was eine funktionale Spezifikation enthalten sollte, wobei ein formaler Ansatz erforderlich sein könnte. Auf jeden Fall reagieren unsere Kunden im Moment gut auf unsere Art der Dokumentationserstellung.
Ich bin interessiert zu hören, was Menschen, die Projektmanagement betreiben, professionell darüber denken.
Ich bin im Widerspruch zu dem, was ein paar andere Leute gesagt haben.
Zunächst einmal stimme ich zu - Geschichten sind eine gute Möglichkeit, funktionale Anforderungen zu formulieren. Für mein Geld sind sie eine der besten Möglichkeiten, Anforderungen wirklich so zu kommunizieren, wie es Endanwender wirklich tun. Ich habe zu viele Spezifikationen gesehen, die abgemeldet werden, ohne jemals gelesen worden zu sein.
Das einzige, was ich sagen möchte, dass Sie an sie anhängen könnten, sind nicht-funktionale Anforderungen - darunter Leistung, Sicherheit, Datenvolumen, Audit, Archivierung und so weiter. Während sie mit Geschichten bedeckt sein können, sind sie manchmal besser so überdeckt, dass sie alle Geschichten durchdringen.
In Bezug darauf, ob es für große Unternehmen geeignet ist, ist dies der Punkt, wo ich nicht stimme. Meiner Erfahrung nach (und ich habe Projekte für Shell, American Express, ein paar multinationale Banken und andere Projekte gemacht) sind sie oft nicht formeller als kleinere Unternehmen, so dass es ihnen mit Geschichten gut geht. Die Realität ist, dass ein Benutzer in einem großen Unternehmen nicht besser daran interessiert ist, Klassen- und Sequenzdiagramme zu lesen (oder daran interessiert) als anderswo.
Die Größe und Komplexität des Projekts kann detailliertere Anforderungen erfordern, aber es hängt von der Größe des Projekts und nicht von der Größe des Unternehmens ab, wenn Sie bestimmen, wie Sie Anforderungen dokumentieren.
Für mich ist die Dokumentation der besten Anforderungen eine Dokumentation, die für das Publikum geeignet ist. Für mich sind User Storys die meiste Zeit ein Nagel auf den Kopf - sie sind kurz genug und klar genug, dass sie sich abzeichnen, wenn sie sich abmelden weil sie sie gelesen und verstanden haben (im Gegensatz zur Abzeichnung einer 100-Seiten-Spezifikation, die unweigerlich bedeutet, dass sie sie nicht wirklich gelesen haben), aber gut genug, dass die Entwickler auch arbeiten können.
Ja, Sie können User Storys für Ihre funktionalen Anforderungen verwenden. Ich mache es die ganze Zeit und seit Jahren. Meiner Meinung nach funktioniert es wirklich gut und besser als andere Systeme, die ich benutzt habe.
Würde dieser Ansatz für größere Kunden funktionieren? Um eine grobe Generalisierung zu machen, nein. Sie werden ein System haben, mit dem Anforderungen definiert werden, und wahrscheinlich sind es keine User Stories. Wenn Sie mit User Stories kommen, wird es eine Trennung von den aktuellen Praktiken geben, die Sie durcharbeiten müssen.
Es ist mir gelungen, User Storys mit größeren Organisationen zu verwenden, aber es bedarf einer gemeinsamen Anstrengung, der sich beide Parteien widmen müssen.
Was Sie beschreiben, sind die Use-Case-Szenarien, die die Features definieren. Dies ist aus Sicht der Benutzerfreundlichkeit erforderlich und genau das, was der Client versteht und dem er zustimmt. Bildschirmmodelle und Flussdiagramme werden definitiv sowohl dem Kunden als auch den Entwicklern helfen.
Eine Implementierungsspezifikation kann dann erforderlich sein, um Entwickler darüber zu informieren, was in die tatsächliche Konstruktion einbezogen werden muss. Die Tiefe wird von den Fähigkeiten Ihrer Entwickler bestimmt, die ihr Wissen über die Hausarchitektur / das Framework und die Methoden / Konventionen beinhalten kann Besonderheiten enthalten, die sich auf verschiedene Teile der Anwendung auswirken.
Wir arbeiten auch in kleinen Teams (manchmal ein oder zwei Entwickler) und glauben, dass das oben Genannte alles ist, was in diesem Fall benötigt wird.
Größere Unternehmen mit viel größeren Teams können Modellierungssoftware, UML-Diagramme und andere detailliertere Spezifikationen verwenden. In dem Fall, in dem Sie der Hauptentwickler sind, sollten Sie immer noch die Zeit für die Gestaltung Ihrer Anwendung aufwenden, aber wenn niemand die Entwürfe überprüft und auf allen Formalitäten besteht, verbringen Sie Ihre Zeit besser mit der Implementierung der Software.
Tags und Links project-management user-stories agile-project-management