[Hochschulprojekt]
Ich möchte möglichst viele Praktiken aus dem agilen Projektmanagement für ein Hochschulprojekt übernehmen. Ich habe entschieden, dass der eigentliche Entwicklungsansatz auf einem FDD-Modell (Feature Driven Development) basieren wird .
Ich möchte meine Features mit einer User Story verknüpfen. Wenn ich meine zwei wöchentlichen Meetings mit einem Supervisor habe, kann ich darüber sprechen, welche User Stories ich in der nächsten Iteration integrieren möchte, welche ich noch nicht abgeschlossen habe, welche in kleinere Aufgaben aufgeteilt werden müssen usw.
Da liegt das Problem, ich habe keinen Benutzer. Ich könnte "der Benutzer sein", aber ich denke, es würde einen Interessenkonflikt geben, da ich das Produkt verwalte und entwickle.
Irgendwelche Vorschläge zum Umgang mit einer Situation, in der ein bestimmter Benutzer nicht identifiziert wurde?
Als Referenz sind Projektnotizen unter imat3451.blogspot.com verfügbar
Nur weil "User Story" so betitelt ist, heißt das nicht, dass User sie schreiben. Vielmehr werden User Stories erfasst/geschrieben, um das Nutzerverhalten oder „die Geschichte“ dessen, was der Nutzer erreichen möchte, festzuhalten.
Sie haben 3 Hüte in diesem Projekt. Die Rolle des PM, die Rolle des Entwicklers und die Rolle des Benutzers:
Wenn Sie neu in der „agilen“ Szene sind, würde ich Ihnen wärmstens empfehlen, im Voraus etwas Zeit in das zu investieren, was es braucht, um eine gute Geschichte zu schreiben. Die Investitions-Mnemonik ist meiner Meinung nach einer der grundlegendsten Aspekte beim Schreiben guter Geschichten, der oft übersehen wird.
Unabhängig
Verhandelbar
Wertvoll
Schätzbar
Klein
Testbar
Eine Option, die Sie vielleicht in Betracht ziehen sollten, ist diese. Schreiben Sie für jedes Feature die Geschichten auf, die Ihrer Meinung nach sinnvoll sind. Wenn Sie fertig sind, z. B. alle Geschichten für einen Spielfilm, dann versuchen Sie, mit einem anderen Studenten zusammenzuarbeiten, der selbst ein Projekt durchführen muss. Sie können Ihre Geschichten überprüfen und Sie können ihre Geschichten überprüfen. Ihr beide werdet lernen.
Alternativ könnten Sie eine Person, der Sie vertrauen und die Erfahrung hat, bitten, Ihre Geschichten zu überprüfen. Vielleicht hast du einen Freund, einen Bekannten oder vielleicht einen Mentor, der dir helfen kann.
Beim Software-Engineering geht es meiner Erfahrung nach vor allem um Kommunikation, daher werden Ihnen alle oben genannten Punkte über das jeweilige Projekt hinaus helfen. Viel Glück!
Wenn Sie keine Benutzer haben, mit denen Sie sprechen können, identifizieren Sie Benutzertypen, auf die Sie Geschichten ausrichten können. Wenn Sie zum Beispiel eine Website erstellen, auf der Leute Bewertungen von Produkten veröffentlichen können, haben Sie möglicherweise Benutzer wie:
Wenn Sie über eine Funktion aus der Sicht dieser Benutzer nachdenken, können Sie sich auf das konzentrieren, was für diesen Benutzertyp wichtig ist.
Sie können sogar Ihre Benutzerrollen verwenden, um die Reihenfolge zu priorisieren, in der Ihre Funktionen ausgeführt werden sollen - vielleicht bin ich als junge Bewertungsseite am meisten daran interessiert, Leute vom Typ Rezensenten für den Aufbau meiner Inhalte zu gewinnen, also priorisiere ich die Funktionen, auf die sie ausgerichtet sind diese Benutzer.
Nun, in unserem Fall hatten wir einen Benutzer, aber unser Ansatz war für das Team, sagen wir 2 Tage Recherche über die Funktionen bzgl. Trends, Wettbewerb, wie es allgemein implementiert wird, Best Practices und was wir als Team denken, muss Mindestgeschichten sein.
Planungssitzung, ein Lead bietet Kontext mit dem Nutzen einer solchen Funktion. Das Team wird seine Ansichten darüber, welche Geschichten gemacht werden sollten, um diesen Nutzen zu erzielen, auf Post-Its schreiben. Lead kategorisiert die Geschichten (Post-Its) an einer Wand in übergeordnete Kategorien und entfernt alle Duplikate.
Wir priorisieren die verbleibenden Geschichten in jeder Kategorie und planen sie in Sprints ein. Effektiv kann jeder, der auf die Idee gekommen ist oder Visionen/Ziele vor Augen hat, zum Anwender werden und sie vorantreiben.
Sie haben darüber gesprochen, dass ein Entwickler Schwierigkeiten haben könnte, die Benutzerrolle zu besetzen, aber wenn ein ganzes Team in der Planung sitzt, wird dies neutralisiert, indem mehrheitlich gewählte Geschichten den Spitzenplatz einnehmen. Unnötig zu sagen, wie auch immer Sie es tun und was auch immer Sie als Geschichte definieren, sollte Ihnen eindeutig einen Mehrwert bieten.
Lukas