Liegt es in der Verantwortung des Produkteigentümers, Anforderungen für die Datenzuordnung/-umwandlung bereitzustellen?

Ich bin ein Full-Stack-Softwareentwickler. Ich habe in vielen Unternehmen gearbeitet, von Fortune-100-Unternehmen bis hin zu Startups, und zu diesem Thema habe ich unterschiedliche Standpunkte gehört. Dies ist die Situation.

Implementieren Sie in einem Softwareprojekt, in dem Daten aus einem System aufgenommen werden müssen, eine Geschäftslogik für diese Daten und geben Sie die Daten dann an ein anderes System aus, damit sie vom Unternehmen genutzt werden können.

Liegt es in der obigen Situation in der Verantwortung des Produkteigentümers, zu verstehen, welche Daten aufgenommen werden, und auch Anforderungen bereitzustellen, wie diese Daten transformiert/zugeordnet werden können, damit sie an ein System ausgegeben werden können, das vom Unternehmen genutzt werden kann?

Wenn es nicht in der Verantwortung des Produkteigentümers liegt, wie kann dann von einem Entwickler erwartet werden, dass er eine genaue Zeitschätzung abgibt, wann er/sie die Recherche durchführen muss, um die Daten zu verstehen, festzustellen, ob die Zuordnung möglich ist, und dann das Unternehmen zu beauftragen, um zu sehen, wie die Zuordnung funktioniert sollte auf eine Weise erfolgen, die einen Mehrwert bietet, und dann die Arbeit erledigen? ... Angesichts der Tatsache, dass dies eine Menge Entdeckungen erfordern würde, scheint es unmöglich, genaue Zeitschätzungen anzugeben.

Vielen Dank im Voraus

"genaue Zeitschätzungen" ist ein Widerspruch in sich. Fragen Sie, wie Sie schätzen können, wenn Sie nicht mit den vollständigen Anforderungen versorgt wurden? Außerdem ... was ist der Umfang der Schätzung, die Sie erstellen müssen? Soll ein Sprint oder das gesamte Projekt geplant werden?
Dies ist für eine Sprintplanung. Im Grunde ist die Situation also so, dass Entwickler ein Ticket erhalten, das die oben genannten Anforderungen nicht erfüllt, und die Entwickler gebeten werden, darauf hinzuweisen. Punkte sind eine Kombination aus Komplexität und Zeit. Wie kann ein Entwickler eine gute Vorstellung davon haben, wie viele Punkte er hat, wenn er die oben genannten Details nicht kennt? ... Dies ist die Situation.
@Dan Schließen Sie Risiken und Unsicherheiten in Ihre Komplexität ein? (Hier scheint es einen Subtext zu geben, dass der Product Owner die Anforderungen für diese Daten besser oder schneller herausfinden kann als Sie, aber IME ist der schnellste/genaueste Weg, um so etwas herauszufinden technische Leute, die mit Unterstützung von der Geschäftsseite die schwere Arbeit erledigen. Aus geschäftlicher Sicht wäre es also nicht sinnvoll, dies in die Verantwortung des Product Owners zu legen, genauso wenig wie der Product Owner entscheiden würde, welche Programmiersprache Sie verwenden usw. )
@ user3067860 Risiko und Ungewissheit sind nicht Teil der Schätzung, aber die Komplexität.
@Dan Einige Scrum-Leitfäden schließen Risiko / Unsicherheit in "Komplexität" ein. Aber ich denke, Sie könnten sie stattdessen rechtzeitig einbeziehen. Irgendwo muss es hier aber reingehen, denn der Durchschnitt von Geschichten mit vielen Unbekannten ist, dass sie viel länger dauern werden als eine ansonsten ähnliche Geschichte, die vorher gut bekannt ist – nicht nur wegen der Recherche, sondern weil Es besteht eine hohe Wahrscheinlichkeit, dass Sie etwas finden, das mehr Aufgaben hinzufügt.
@ user3067860 Das ist eine gute Möglichkeit, dieses Problem zu entschärfen und auch mit dem übereinzustimmen, was andere über Verantwortung gesagt haben.

Antworten (4)

Es gibt viele Grauzonen, aber die direkte Antwort auf Ihre Frage laut Scrum Guide lautet nein – es liegt nicht in der Verantwortung des Product Owners, Datenzuordnungen bereitzustellen. https://scrumguides.org/scrum-guide.html#product-owner

Also ... in Ihrer Situation hat der PO einen Rückstandsartikel, der so etwas wie "Als Vertriebsleiter möchte ich ein Diagramm der Verkäufe sehen, das mit X demografischen Merkmalen korreliert ist." oder etwas ähnliches. Jetzt wissen die Teams entweder, wie diese Daten funktionieren (zumindest gut genug, um eine grobe Schätzung vorzunehmen und mit der Arbeit zu beginnen), oder sie wissen es nicht. Wenn dies nicht der Fall ist, benötigen Sie möglicherweise andere Arten von Backlog-Elementen, z. B. Spitzen. Ein Spike ist ein Mittel, um Unsicherheit und Risiken zu reduzieren.

Könnten Sie jetzt für jede einzelne User Story, die durchkommt, einen Spike machen? Ja... aber... das ist eine sehr ineffiziente Arbeitsweise. Ein guter Scrum Master wird das Team ermutigen, zu erkunden, was sie tun können, um entweder ihre Datensysteme zu vereinfachen oder Wissen in häufig genutzten Bereichen aufzubauen, damit dies nicht immer passiert.

Danke. Aber ich sehe nicht, dass die Frage, die ich gestellt habe, in diesem Link beantwortet wird.
Ich würde auch eine Folgefrage stellen. Angenommen, dies ist korrekt und der PO ist nicht für die Zuordnungen verantwortlich. Sind sie dafür verantwortlich, die Eingabedaten und Ausgabedaten gut genug zu verstehen, um feststellen zu können, ob eine von den Entwicklern erstellte Zuordnung korrekt ist?
Die PO muss nicht, nein. Die Entwickler (Entwickler, QA usw.) sind dafür verantwortlich, ein Produkt zu entwickeln, das funktioniert. Der PO ist mehr verantwortlich für das Engagement der Interessengruppen, die Priorisierung des Rückstands usw. PO ist "was", Dev ist "wie". Allerdings ist es unglaublich hilfreich, einen PO zu haben, der über dieses Wissen verfügt – nur nicht erforderlich.
Anders ausgedrückt, ich hätte lieber einen PO, der die geschäftlichen Anforderungen versteht, die richtigen Stakeholder an einen Tisch bringen kann, dessen Entscheidungen respektiert werden und dem Team vertraut, dass es gute Arbeit leistet, aber keine technischen Kenntnisse hat, als einen PO zu haben, der wirklich ist kennt die technische Seite und kann die andere nicht, weil dann niemand im Team die anderen Sachen machen kann. Aber beides zu haben ist toll.

Vertrauen ist die Grundlage von Agilität. Mangelndes Vertrauen wird überall in der Art und Weise gemalt, wie die Frage gestellt wird.

Der Product Owner ist in der Tat dafür verantwortlich, die Erstellung der User Stories voranzutreiben . Dafür ist aber nicht nur der PO verantwortlich . Insbesondere bei Storys, die einen beträchtlichen technischen Hintergrund haben, sollte das Entwicklungsteam eine kritische, aktive Rolle beim Verständnis der Anforderungen und der Identifizierung möglicher Lücken spielen.

Es liegt nicht in der Verantwortung des PO, die Anforderungen bis ins letzte Detail aufzuschreiben. Es liegt in der Verantwortung der Entwicklung, sich zu engagieren und bereit zu sein, mit dem PO zusammenzuarbeiten, um herauszufinden, wie die Anforderungen auf evolutionäre Weise erfüllt werden können.

Kurz gesagt, der PO ist dafür verantwortlich, Ihnen eine Geschichte darüber zu erzählen, was benötigt wird, und alle erforderlichen Fragen zu beantworten. Es liegt am Entwicklungsteam, die richtigen Fragen zu stellen, um sich innerhalb des Entwicklungsteams darauf zu einigen, wie die Lösung implementiert wird. Die PO kümmert sich nicht darum, wie die Lösung implementiert wird. Es liegt in der Verantwortung des Entwicklungsteams sicherzustellen, dass der Code so aufgebaut ist, dass er den vom Team erwarteten Standards entspricht .

Wie die Frage formuliert ist, gibt es kein agiles Team. Es gibt einen funktionalen Analysten, der Anforderungen in einem sehr wasserfallartigen Ansatz an das Entwicklungsteam weitergibt.

Vielen Dank für Ihre Antwort. Der Kern der Frage besteht jedoch nicht darin, alle Anforderungen im Ticket zu erfüllen, sondern darin, die Geschäftslogik/den Geschäftsprozess rund um die Daten zu verstehen. Wollen Sie damit sagen, dass es nicht in der Verantwortung des PO liegt, die Geschäftslogik/Prozesse der eingehenden/ausgehenden Daten und die Verarbeitung der Daten zu verstehen?
@Dan Ihr seid ein Team. Er muss die Installation nicht kennen.
@Dan, es ist die PO-Rolle, die Geschäftsanforderungen zu verstehen . Die Chancen stehen gut, dass diese Schnittstelle eine API erfordert, damit Daten ausgetauscht werden können. Wie die API implementiert wird, erfordert technischen Hintergrund. Die PO wird wahrscheinlich sagen "Sie müssen XYZ-Informationen konsumieren.". "Sie werden fragen, wie ?". Er wird antworten "hilf mir, es herauszufinden".
Denken Sie daran, die PO sagt, was getan werden muss. Ihre Frage konzentriert sich viel mehr auf das Wie (weil Ihre zugrunde liegende Sorge nicht auf der Anforderung, sondern auf der Schätzung liegt ).
@TiagoCardoso Die Frage, wie ich eine gute Zeitschätzung für die Fertigstellung dieser Arbeit abgeben kann, wenn wir diese Details nicht kennen und die PO sie nicht bereitgestellt hat.
@TiagoCardoso Ich habe immer noch keine Antwort auf das Teil gehört. Liegt es in der Verantwortung des Product Owners, die Daten so zu verstehen, wie sie aufgenommen werden, und was ein wertvoller Output aus geschäftlicher Sicht ist?
Hallo @Dan, danke für das Feedback. Ich habe meine Antwort etwas erweitert. Hoffe das macht es klar.

Wenn sich ein Unternehmen häufig mit dieser Art von technischen Geschichten auseinandersetzen muss, stellt es technische Product Owner ein/hat sie. Wenn solche Geschichten ab und zu auftauchen, pflegen die Product Owner die Geschichten mit Unterstützung der Softwareentwickler im Team.

Also, meine Antwort ist; Dies liegt vollständig im Bereich der Product Owner-Rolle.

Willkommen bei PMSE. Ihr letzter Satz scheint im Gegensatz zum vorherigen zu stehen. Das Team als Ganzes trägt zur Verfeinerung des Backlogs bei (Verfeinerung ist eher der bevorzugte Begriff als Grooming)
Ich mag Ihre Antwort am besten wegen meiner Voreingenommenheit, aber ich werde die Aufwertung deswegen nicht verschmutzen. Haha. Ich werde das eine Woche oder so ruhen lassen und die mit den meisten Stimmen akzeptieren, meine nicht eingeschlossen.

Das Team als Ganzes ist für Anforderungen und Spezifikationen verantwortlich. Backlog Refinement – ​​das Vorbereiten von Backlog-Elementen, damit sie für zukünftige Sprints bereit sind – ist ein kontinuierlicher Prozess. Einige Teams weisen formell jedem Sprint eine bestimmte Zeit für die Verfeinerung des Backlogs zu oder führen dies alternativ einfach als Hintergrundaufgabe durch.

Der Punkt der Backlog-Verfeinerung ist jedoch, dass die Story startbereit ist , nicht, dass sie umfassend in jedem Detail spezifiziert ist. In Bezug auf die Schätzung benötigt das Team nur genügend Informationen, um zu beurteilen, ob eine Story klein genug ist, um sie in einem einzigen Sprint zu erledigen, oder ob sie weiter aufgeschlüsselt werden muss. Im Falle einer Transformation kann es ausreichend sein, die Anzahl und Art der Quellen, die Anzahl der Attribute und vielleicht die Art der erforderlichen Berechnungen zu kennen, aber vielleicht ist es nicht notwendig, jedes Element der Kartierung zu kennen, damit die Geschichte erstellt werden kann bereit.