Sollten Entwickler während der Story-Planung/-Verfeinerung mit Benutzern sprechen?

Ja, natürlich, warum sollte sich das Entwicklungsteam mit Informationen aus zweiter Hand zufrieden geben. Selbstorganisierende Teams sollten sich die Informationen aus der Quelle holen!

Dieser Punkt aus der Cargo Cult Agile Checklist gefällt mir sehr gut :

Stakeholder werden daran gehindert, mit den Scrum-Teams zu sprechen

Was sind Stakeholder? (zitiert aus Agile Modeling: Active Stakeholder Partizipation )

Ein Stakeholder ist jeder, der ein direkter Benutzer, indirekter Benutzer, Manager von Benutzern, leitender Manager, Betriebsmitarbeiter, der „Goldbesitzer“, der das Projekt finanziert, Support-Mitarbeiter (Helpdesk), Prüfer, Ihr Programm-/Portfoliomanager, Entwickler, die an anderen Systemen arbeiten, die das in der Entwicklung befindliche System integrieren oder mit diesem interagieren, oder Wartungsfachleute, die möglicherweise von der Entwicklung und/oder Bereitstellung eines Softwareprojekts betroffen sind.

Das bedeutet also, dass jeder ein Stakeholder ist. Engagieren Sie sie! Aber wen soll man einladen, alle?

Meine aktuellen Teams versuchen, wichtige Interessengruppen zu unseren Verfeinerungs- und Planungssitzungen einzuladen, um den Kontext von der Quelle zu erhalten. Wer eingeladen wird, hängt stark davon ab, welche Themen wir bearbeiten. Der Product Owner macht diesen Anruf, der Scrum Master stellt sicher, dass der PO im Voraus darüber nachdenkt, wen er einladen soll. Die Stakeholder erklären Zusammenhänge, das Entwicklungsteam stellt Fragen.

Fördern Sie, dass das Entwicklungsteam mit so vielen Stakeholdern wie möglich spricht. Dies dient zum Abrufen von Domänenwissen und Verständnis dafür, wie tatsächliche Benutzer das Produkt verwenden. Planungs-, Review- und Verfeinerungsmeetings sind dafür der ideale Ort, da Entwickler ihre (Codierungs-)Zone bereits verlassen haben.

Probieren Sie es einfach aus und prüfen und passen Sie es nach einigen Sitzungen mit PO, einschließlich Benutzern und Entwicklern, an. Bitten Sie sie um ihr Feedback oder veranstalten Sie eine spezifische Retrospektive, um zu sehen, was für diese Art der Entdeckungskommunikation funktioniert und was nicht.

In bestimmten Situationen denke ich, dass sie es tun sollten, aber es gibt viele Vorbehalte und Fallstricke. Lassen Sie mich Gründe auflisten, warum ich es getan habe, und auch Zeiten, in denen ich es nicht tun würde, und vielleicht hilft das, wenn Sie überlegen, was Sie brauchen.

Bevor ich anfange, möchte ich Sarov jedoch darin widersprechen, dass, wenn Ihr Hauptgrund dafür ist, dass die PO nicht technisch ist, dort einige Schulungen durchgeführt werden sollten, um seinem / ihrem Verständnis zu helfen. Unabhängig von der Gültigkeit der folgenden Gründe sollte dieser Mangel an Erfahrung/Schulung dennoch langfristig behoben werden. Wenn Anforderungen Ihr Hauptanliegen sind, würde ich den Scrum Master bitten, den PO beim Schreiben von Anforderungen zu unterstützen und sie dem Team zu erklären, und im Laufe der Zeit dem PO helfen, dies besser zu machen. Dies ist wahrscheinlich die Hauptantwort auf Ihre Frage, aber ich werde über die Beteiligung von Entwicklern sprechen, da ich immer noch denke, dass dies für Sie wertvoll sein könnte.

Gründe, warum ich Entwickler in die Entdeckung einbezogen habe:

• Ich identifizierte ein Problem, bei dem die Entdeckung sehr langsam voranging, und es gab ein großes Problem, bei dem das Geschäft und die PO viel zu tief in ihre Ideen und deren Umsetzung eindrangen, sich emotional engagierten und es dann über den Haufen warf Wand zur Entwicklung. Als Teil meiner Strategie, dies zu beheben, habe ich einen Prozess eingeführt, an dem das gesamte Produktteam vom ersten Tag an beteiligt war, um den Verlauf des Produkts zu steuern. Dies war nicht immer Anwesenheit, aber es war für alle sichtbar. Zuerst hatte ich einen Entwickler und einen Designer, die zu den Haupttreffen gingen, aber wie ich gehofft hatte, als sich alle an die Zusammenarbeit und Kommunikation gewöhnt hatten, wurde dies immer weniger notwendig, da Vertrauen und Respekt aufgebaut wurden und die PO sich mehr auskennte Entwicklungsprobleme. Die Kommunikation wurde auch ohne Anwesenheit fortgesetzt,

• Ein weiterer guter Grund, warum ich Entwickler schon früh eingebunden habe, ist, dass ich bei einigen Projekten wollte, dass sie die Schmerzpunkte aus erster Hand aus dem Mund des Kunden hören. Dies erfordert ein wenig Zeit für einen Entwickler, führt aber wiederum zu einem viel größeren Buy-in und Verständnis für das Problem, das das Projekt zu lösen versucht. Ich habe festgestellt, dass dies in vielen Situationen zu mehr Kreativität und Einfallsreichtum auf Seiten der Entwickler führt, da sie die Herausforderungen für den Kunden besser verstehen. Dies führt zu einem besseren Produkt als es sonst der Fall sein könnte, was einer der Hauptgründe für Agile ist und durch diese Prinzipien im Agile Manifest unterstützt wird:

Unsere höchste Priorität ist es, den Kunden durch frühzeitige und kontinuierliche Lieferung wertvoller Software zufrieden zu stellen. -Betonung hinzugefügt

Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist das persönliche Gespräch . -Hervorhebung hinzugefügt http://agilemanifesto.org/principles.html

• Der letzte Grund ist eine Erweiterung des zweiten, in manchen Fällen wünsche ich mir vielleicht ein höheres Maß an Kommunikation zwischen Kunden und Entwicklern während des Projekts. Indem ich sie frühzeitig einbinde, helfe ich beiden Seiten, Vertrauen und Vertrautheit aufzubauen. Der Kunde vertraut darauf, dass der/die Entwickler sein Problem verstehen, weil sie dabei waren, als sie es erstmals erklärt haben. Die Entwickler fühlen sich wohler, wenn sie den Kunden eine Frage stellen, weil sie wissen, wer sie sind und woher sie kommen. Auch dies ist etwas, das großer Sorgfalt bedarf, da es je nach Situation entweder sehr nützlich sein kann, um das richtige Produkt zu erhalten, oder die Zeit des Entwicklers verschwendet.

Um es kurz zu machen, die Hauptgründe für die Einbeziehung der Entwicklung sind, ob es ihnen hilft, ein besseres Produkt zu entwickeln. Dies muss von Projekt zu Projekt analysiert werden und sollte im Allgemeinen die Entscheidung des Teams sein. Wenn das Projekt zunächst klein oder eher intern basiert oder auf sehr hohem Niveau ist und ein einfacher Überblick oder Besprechungsnotizen die Bedeutung vermitteln, würde ich mir keine Gedanken darüber machen, die Entwickler einzubeziehen.

Normalerweise wird davon ausgegangen, dass Entwickler mit Benutzern und Interessenvertretern in der von Ihnen gewünschten Weise als Ausnahme und nicht als Regel interagieren können .

---

Allgemeine Antwort

Du hast immer drei Rollen:

1. Stakeholder, die wissen, „was zu tun ist“.
2. Entwickler, der weiß, wie es geht.
3. PO/BA dazwischen, der die Umwandlung von „was zu tun“ in „wie zu tun“ erleichtert.

In jedem dieser Hüte steckt immer jemand. Es könnte eine Person sein, die hinter dem Bildschirm sitzt und ein neues soziales Netzwerk in drei Hüten übereinander schreibt. Oder ein riesiges Unternehmen mit Abteilungen, die jeweils mit einem eng spezialisierten Hut herumlaufen.

Um auf Ihre Frage zurückzukommen, wie kann man tatsächlich eine Entscheidung treffen, „sollten Entwickler während der Entdeckung mit Benutzern sprechen“ oder nicht? Es hängt allein von dem Ziel ab, das Sie erreichen möchten, ist es gut für Ihr Ziel oder nicht. Und ich gehe davon aus, dass das Ziel die Vision der Organisation als Mechanismus hinter dem Produkt ist, der es so effizient wie möglich als Wert liefert.

Wenn die aktuelle Verteilung der Hüte (Rollen) auf die Personen in Ihrer Organisation so ist, wie sie sein sollte, dann machen Sie alles richtig. Aber da es eine Person mit PO-Titel gibt, können wir daraus schließen, dass genau diese Person einen PO-Hut tragen sollte und es in Wirklichkeit nicht kann. Hüteverteilung scheint falsch zu sein und die Antwort auf Ihre Frage in Ihrer Situation lautet: Nein, sollten sie nicht. (Oder jemand hat einen falschen Titel, der nicht mit der tatsächlichen Rolle übereinstimmt.)

Auch einige Beispiele, wenn Sie ein direktes Engagement wünschen, das nicht so ist, wie Sie es gefordert haben :

1. Lassen Sie Menschen sich persönlich treffen, um sich kennenzulernen. Es ist bequemer für uns, wenn wir hinter dem Benutzernamen auf dem Bildschirm eine echte Person kennen.
2. Lassen Sie das Entwicklungsteam zuhören, um den Schmerz zu teilen, wie Majaii bereits erwähnt hat. Wir lieben es zu helfen und wissen über die Entlastung der tatsächlichen Person Bescheid.
3. Lassen Sie alle Projektbeteiligten versammelt sein und buchstäblich auf einer Seite sitzen, während Sie Produkt-/Projektänderungen und -ergebnisse präsentieren.

---

Situative Antwort

Das Entwicklungsteam hat nichts zu tun, da PO als Engpass das Team nicht laden kann. Wir können den Engpass lindern, indem wir ihn umgehen und das Entwicklungsteam direkt von den Benutzern laden. Sollen wir das tun?

Leider findet hier die eigentliche Kunst des Projektmanagements statt. Sie müssen alle kurz- und langfristigen Risiken, Konsequenzen und Vorteile abwägen. Einige davon werden bereits in anderen Antworten erwähnt.

---

PS Ihre Frage geht davon aus, dass Stakeholder irgendwie technischer sind als PO. Darüber hinaus muss das Entwicklungsteam technisches Wissen von den Beteiligten erhalten. Das klingt sehr verdächtig.

Theoretisch könnten Sie das, aber das könnte zu einer erheblichen Belastung des Entwicklers aufgrund des Zeitaufwands und des Aufgabenwechsels führen, insbesondere wenn dies mitten in einem Sprint geschieht.

Welchen Vorteil würden Sie sich erhoffen, wenn Entwickler während der Discovery anwesend wären?

Wenn die Entwickler die Anforderungen besser verstehen sollen, würde ich mich stattdessen darauf konzentrieren, die Fähigkeit Ihres PO zu verbessern, diese zu analysieren und an Ihre Entwickler weiterzugeben.

Wenn die Stakeholder sich ein besseres Bild davon machen können, was machbar ist, könnte dies wahrscheinlich während des Sprint Reviews angesprochen werden, zu dem die Stakeholder eingeladen werden können/sollten.