Scrum - Wie man besseren Input vom funktionalen/kommerziellen Team bekommt

Question

Wir sind ein kleines Team von 3 Entwicklern (2 erfahren, aber neu in diesem speziellen Geschäftssektor), die ein funktional komplexes Produkt entwickeln. Wir benutzen Scrum und haben am Ende jedes Sprints eine Demo. Es ist klar, dass das funktionale Team viele Ideen hat, aber diese werden dem Entwicklerteam nicht gut vermittelt und die Demo wirft mehr Fragen als Antworten auf.

Haben Sie irgendwelche Empfehlungen für die Verbesserung der Qualität der Eingabe von den funktionalen Menschen?

Weitere Informationen: Ich denke, ein Teil des Problems ist, dass es keine Spezifikationen oder User Stories als solche. Persönlich denke ich, dass sie eine Art von Anforderungen aufschreiben müssen - welche Art von Dingen sollten sie aufschreiben und welche Komplexität angesichts ihres agilen Prozesses?

Answer 1

Nehmen sie an den Stand-up-Meetings teil?

Man könnte vorschlagen, auf denen jeweils einen Vertreter haben (oder etwas) von ihnen, so dass sie vor dem Ende des Sprints für die Eingabe zu fragen

Answer 2

den einfachste Weg Manchmal Eingabe von Menschen zu bekommen, ist es zu zwingen, aus Sie. Meine Firma nutzte SCRUM für ein Projekt und fand sehr schnell heraus, dass die Leute dazu neigen, für sich zu bleiben, wenn sie bereits wissen, was sie tun. Am Ende organisierten wir wöchentliche Treffen, bei denen die Teammitglieder etwas zeigen mussten, was sie während der Woche gelernt hatten. Es war gezwungen, aber es funktionierte ziemlich gut.

Answer 3

Haben Sie versucht, mit Ihrem Kunden zu arbeiten, um Abnahmetests zu definieren/zu formulieren?
Mit etwas wie Fit zu diesen Tests zu kommen - würde in bessere Spezifikationen führen und den Kunden zwingen, darüber nachzudenken, was wirklich erforderlich ist. Das i-Tüpfelchen sind am Ende dieses Prozesses sofort ausführbare Spezifikationen.

Das ist natürlich, wenn Ihre Kunden verfügbar und offen für diesen Ansatz sind. Versuche es!

Wenn nicht (und das scheint die Mehrheit zu sein - weil es weniger Arbeit) - Kalender flash ‚em - die Planung von Meetings/telecons jede Woche, bis sie singen wie Kanarienvögel :) +1 Dana

Answer 4

I‘ Ich bin ein großer Fan von Use Cases, die das Systemverhalten als Reaktion auf Benutzeraktionen detailliert beschreiben. Zusammen können diese eine Reihe von Anforderungen bilden, und in einer SCRUM-Umgebung können Sie die Use Cases priorisieren, die die implementierten Funktionen dieses bestimmten Sprints bilden.

Zum Beispiel, nachdem Sie mit Ihrem funktionalen Team gesprochen haben, identifizieren Sie 15 verschiedene Anwendungsfälle. Sie priorisieren die Use Cases und entscheiden sich für 5 Sprints. Und am Ende jedes Sprints, den Sie durchlaufen, demonstrieren Sie das Produkt, das die während des Sprints implementierten Use Cases erfüllt, notieren das Feedback und ändern die Use Cases.

Answer 5

Machst du Stand-up-Meetings und hast du Burn-Down-Chart? Ich denke, diese beiden Bereiche würden Ihnen sehr zugute kommen.

Answer 6

Ich verstehe, dass die Leute, die Sie funktionale Menschen nennen, als Product Owner handeln, richtig?

Ich denke, ein Teil des Problems ist, dass es keine Spezifikationen oder User Storys als solche gibt. Persönlich denke ich, dass sie eine Art von Anforderungen aufschreiben müssen - welche Art von Dingen sollten sie aufschreiben und welche Komplexität angesichts ihres agilen Prozesses?

Eigentlich, ohne irgendwelche Spezifikationen haben Sie wahrscheinlich keinen Abnahmetest für den Rückstand itens ebenso. Du solltest die PO bitten, die User Storys zu schreiben, ich mag den "As a - type of user -, ich möchte -einiges Ziel-, also -einigen Grund-." bilden. Beachten Sie, dass die User Stories werden INVEST werden - I ndependent, N egotiable, V aluable an Benutzer oder Kunden, E stimable, S Mall und T estable. Es ist ein Muss, dass die Akzeptanztests zusammen mit der Geschichte geschrieben werden, damit das Team weiß, was die Geschichte tun muss, damit es fertig ist.

Denken Sie daran, dass, wenn sich das Produkt entwickelt, es der PO erwartet, Ideen zu haben, wenn er das funktionierende Produkt sieht. Es ist keine schlechte Sache, eigentlich ist es eines der besten Dinge, die Sie durch Agile bekommen können. Sie müssen darauf achten, dass diese Ideen in den Produktstau aufgenommen werden und von der PO priorisiert werden müssen. Und wenn es notwendig ist und dem Kunden einen Mehrwert bietet, sollte die Idee im nächsten Sprint geplant werden.

Answer 7

Ich empfehle das Buch "" es ist voller Vorschläge, wie man ein Scrum-Team erfolgreich macht. Es gibt auch gute Tipps, wie man den Produkteigentümer/Kunden stärker involviert und wie man den gesamten Prozess in Gang bringt. Es ist das Geld wert, IMHO.

Answer 8

Ein Mitglied des Funktionsteams sollte Teil des Teams sein und Ihre Fragen zu den von Ihnen hinzugefügten Funktionen beantworten.

Wie können Sie den Backlog-Artikel schätzen, wenn er nicht detailliert genug ist?

Sie könnten eine Regel festlegen, dass Backlog-Artikel, die keine eindeutigen Abnahmekriterien haben, nicht geplant werden können.

Wenn es besser wäre, wenn jemand aus dem funktionalen Team als Product Owner fungiert, um die Backlog-Elemente zu ermitteln, auszuwählen und zu priorisieren und/oder als Domain-Experte.

Stellen Sie außerdem sicher, dass sowohl im funktionalen Team als auch im Entwicklungsteam jeder die gleiche Sprache spricht, um Missverständnisse zu vermeiden. Siehe ubiquitous language.

Verfolgen Sie die Zeit, die das funktionale Team am meisten auf Antworten wartet, und verschwenden Sie Zeit damit, unnötige Funktionen zu entwickeln oder bestehende Funktionen zu überarbeiten, damit sie der Rechnung entsprechen.

Answer 9

Ich stimme zu, dass Sie eine Art von Anforderungen (User Stories oder sonst) benötigen.

Ein Ratschlag, den ich geben kann, ist, eine Art von visuellen Hilfen mit den funktionalen Teams zu verwenden. Wenn Kunden viele Ideen haben (wie Sie gesagt haben), haben sie normalerweise auch eine visuelle Vorstellung davon, wie ein Feature aussieht. Wenn das entwickelte Produkt nicht zu dieser visuellen Idee passt, erzeugt es viele Zweifel, selbst wenn es das tut Job funktional.

Bei der Besprechung der Funktionalität mit Kunden versuche ich sehr visuell zu sein. Skizzen auf ein Brett zeichnen oder sogar verbal beschreiben, wie etwas aussehen würde. Versuchen, ein gemeinsames visuelles Bild zu finden. Sie können dann ein Foto von den Skizzen machen und sie als Teil der Dokumentation verwenden.

Ein weiterer Tipp ist, Ihre Sprints so kurz wie möglich zu halten, damit Sie häufigere Demos machen. Vielleicht tust du das schon, weil du deine aktuelle Sprintdauer nicht erwähnt hast.