Welche Scrum-Akteure sollten an einer Sitzung zur Erfassung der Anforderungen teilnehmen?

Noch nie... :)

Indem Sie das Scrum-Team aus dem Gespräch herauslassen, bewegen Sie sich nur wieder in die Fallstricke der Wasserfallanforderungen. Wenn Features in einem Vakuum geschrieben werden, dann endet man entweder mit einem Feature, das die Produktmanager selten treffen, oder mit vielen Dokumenten hin und her, während PM und Eng das Feature „verhandeln“.

Außerdem verschenkt man unglaublich viel Know-how, wenn man die Leute auslässt, die die Arbeit machen. Wenn sie das Gesamtbild verstehen, können sie oft eine bessere Lösung anbieten, um dem Kunden einen Mehrwert zu bieten. Wenn Sie dem Entwickler sagen: "Stellen Sie diese Schaltfläche hier ein, damit sie drucken können", wird der Entwickler genau das tun. Wenn Sie dem Entwickler sagen: „Ich möchte, dass der Benutzer die Ergebnisse dieser Ausgabe erfassen kann“, weist er möglicherweise darauf hin, dass die Mehrheit der Benutzerbasis mobil ist und etwas wie Evernote oder Pocket verwendet, und dass es vielleicht wichtiger ist, dies zu unterstützen diese Lösungen als das Drucken, das nur für 5 % der Benutzerbasis funktioniert.

Enterprise Requirements Planning: Wenn Sie beginnen, über eine Handvoll Teams hinaus zu skalieren, kann es sehr schwierig sein, alle in die Übungen zur Anforderungserstellung einzubeziehen. Hundert Teams sind fast hundert Personen.

An diesem Punkt entfernen wir nicht all diese Leute, wir skalieren es einfach nicht anders als ein Scrum of Scrums. Wir nennen dies das Product Owner Team. Ein POT hat Vertreter aus allen wichtigen Bereichen.

• Produkteigentümer
• Stimme des Kunden: (kann der PO sein, kann jemand in Biz oder Sales sein)
• Architekt: (Benötigt einen starken technischen und kaufmännischen Sinn)
• QA-Architekt: (ein leitender QA-Mitarbeiter mit Erfahrung im gesamten Entwicklungszyklus)
• Entwickler-Vertreter: (jemand, der die eigentliche Codierung für diesen Bereich des Produkts übernehmen könnte) Kundendienst: Diese Leute haben ein unglaubliches Gespür dafür, wie der Kunde das Produkt verwendet. Benutze sie. Betrieb: Sie müssen dieses Produkt bereitstellen. Im Voraus zu wissen, wie das passieren wird und welche Herausforderungen bestehen, kann von vornherein zu einer besseren Architektur führen.

Meine Sichtweise ist ein bisschen anders, das hat sich hier schon angehört.

Zunächst einmal glaube ich fest daran, dass es darauf ankommt.

Wir tun dies wie folgt: Der Product Owner führt Gespräche mit Stakeholdern und sammelt Geschäftsanforderungen von ihnen (er stellt diese Anforderungen als User Stories dar). Dann geht er zum Entwicklungsteam und bespricht mit ihnen diese Anforderungen. Das Entwicklungsteam gibt eine grobe Schätzung ab und stellt einige klärende Fragen (falls vorhanden) zu den Anforderungen. Dann bringt der Product Owner diese Fragen und die grobe Schätzung zu den Stakeholdern … und so weiter. Dies ist ein kontinuierlicher und iterativer Prozess. Das ist mein Verständnis von Product Backlog Refinement (Scrum-Begriff). Nur gut verfeinerte Product Backlog Items können in Sprint genommen werden.

Vielleicht ist es besser, den Product Owner nicht als Stellvertreter zu verwenden und das Entwicklungsteam direkt mit den Stakeholdern in Kontakt treten zu lassen (ich habe hier eine ähnliche Frage gestellt )? Vielleicht, aber nicht immer.

In meinem letzten Projekt haben wir versucht, diesen Fall umzusetzen. Wir schickten einen Entwickler als technischen Berater mit dem Product Owner zu Besprechungen mit dem Kunden. Aber wir haben nach zwei oder drei Mund (ich zähle nicht genau) damit aufgehört. Grund dafür ist, dass ihm 15 Minuten gereicht haben, um alle technischen Fragen zu besprechen, und 2 Stunden Pause, er war langweilig und kann keine Hilfe bei geschäftlichen Details leisten. Nun, es ist logisch, er ist ein ausgezeichneter Programmierer, kein Business-Analyst. Außerdem konnte er keine Schätzung abgeben, da die Schätzung in der Verantwortung des gesamten Entwicklungsteams liegt.

Also, ja, Mitglieder des Entwicklungsteams beteiligen sich an der Verfeinerung (einschließlich Klärung) von Product Backlog Items (Anforderungen), aber nicht direkt (durch den Product Owner). Und natürlich sind sie nicht die Typen, die Anforderungen generieren.

Ich glaube, diese Situation ist passiert, weil wir einen bestimmten Entwicklungsbereich haben (wir entwickeln oder passen Softwaresysteme für die Bedürfnisse anderer Unternehmen an, und unser Team und die Projekte unseres Teams sind nicht zu groß: 12 Mitglieder im Scrum-Team - das ist die maximale Anzahl von Projekten, in denen Ich nehme als Scrum Master teil). Wenn Sie eine Unternehmenslösung entwickeln, ist Joels Ansatz möglicherweise besser.

Also... Wie ich eingangs gesagt habe, gibt es auf diese Frage keine richtige Antwort, weil sie von vielen Faktoren abhängt.

Ich höre also, dass die wirklichen Probleme darin bestehen, dass Sie während des Meetings zur Erfassung der Anforderungen Folgendes möchten:

• gute AC entwickelt und
• Sie möchten eine technische Anleitung, um die Machbarkeit der Geschäftsanforderung auszugleichen

Wenn dies das Ziel des Anforderungserhebungstreffens ist, dann...

Beides kann sicherlich durch die Einbeziehung eines technischen und/oder prüfenden Vertreters erreicht werden. Es gibt jedoch keine Ja/Nein-Antwort, wenn dies die richtige Entscheidung für Ihr Team ist.

Ich habe mit einer Vielzahl von BAs gearbeitet, die klug genug sind, um technische Implikationen zu verstehen und gute AC zu schreiben. Ich habe auch mit BAs zusammengearbeitet, die sich ausschließlich darum kümmern, die Wünsche des Kunden zu erfassen, und oft Bridge-to-Knowwhere-Anforderungen stellen.

Ich würde Ihr Problem über den Kostenvorteil betrachten: Ist es effektiver/effizienter, einen Tester und einen Entwickler einzubeziehen, oder gibt es andere Möglichkeiten, die die gleichen Ergebnisse erzielen, die weniger verschwenderisch sind?

Berücksichtigen Sie bei Ihrer Entscheidung auch den Zeitrahmen des Projekts und die Reifeziele des Teams.