Kann ein Product Owner ein Entwickler in Scrum sein?

Kann ein Product Owner ein Entwickler in Scrum sein? Theoretisch ja, aber wird es von Scrum empfohlen?

Die Rolle des Product Owners ist in Scrum explizit als eigene Rolle definiert. Die Leute tragen manchmal mehrere Hüte, aber das ist im Allgemeinen eine schlechte Idee und wird vom Framework sicherlich nicht empfohlen.
@CodeGnome: Wo? Können Sie eine Referenz angeben, die besagt, dass Rollen und Einzelpersonen eine 1-zu-1-Beziehung sind?
Die Leute könnten an einem verwandten Thread zu Programmers SE interessiert sein, den ich heute Abend gefunden habe. Obwohl nicht kanonisch, berühren die Beiträge sicherlich das Problem der vielen Hüte, das viele unserer eigenen Antworten unten ansprechen.
@aclear Das Official Scrum Rulebook sagt eindeutig: The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master.Ebenso besteht ein Gefängnis aus einer Wache, einem Insassen und einem Wärter. Bitte zögern Sie nicht zu beschreiben, wie beide Frameworks wie beabsichtigt funktionieren würden, wenn eine Person zwei oder mehr Framework-definierte Rollen gleichzeitig ausübt.
Ich finde es wunderbar erhellend, dass Sie Scrum mit einem Gefängnis verglichen haben. Um Ihre Analogie auf die Spitze zu treiben, wenn das Gefängnis aus 1 Wärter, 1 Wärter und 1 Insassen besteht, würde ich den Wärter nicht daran hindern, dem Wärter eine Auszeit zu geben, die ausschließlich auf seinem Titel basiert.
@AndrewClear - Sie halten es also für akzeptabel, dass ein Mitglied des Entwicklungsteams Prioritäten setzt und den ROI für alle Funktionen festlegt, an denen der Rest des Teams arbeitet? Dieser Entwickler ist auch für die Kommunikation mit externen Stakeholdern verantwortlich (das sorgt für eine unterhaltsame Teamdynamik (Schuldkultur)) und der Entwickler wäre auch im Stand-Up anwesend, bittet aber um Fortschritte als Product Owner. Du denkst, das funktioniert und möchtest, dass eine explizite Regel besagt, dass es nicht funktioniert? Viel Spaß mit den Retrospektiven :-) sie werden äh... "interessant".
@Venture2099 - Mann, das ist eine Menge Hass. Aber ja, vorausgesetzt, die Unternehmenskultur und die Art der Arbeit passen zusammen. Zum Beispiel ein etabliertes Scrum-Team, das an einer älteren Codebasis arbeitet und hauptsächlich Wartungsarbeiten durchführt. Oder ein kleines Start-up, bei dem jeder mehrere Hüte trägt. Oder ein Unternehmen, das sich voll und ganz der Holokratie verschrieben hat. Ich schätze Flexibilität über Starrheit, sowohl im Prozess als auch in der Software.
@AndrewClear Niemand sagt, dass man Flexibilität nicht schätzen soll. Die Frage lautet nicht „Kann ein Entwickler in einem Entwicklungsszenario auch als Lead End User fungieren?“. Die Frage ist, kann ein PO auch ein Entwickler sein und die Antwort in Scrum ist ... nein. Wenn Sie sich dafür entscheiden, Scrum anzupassen, ist das bewundernswert, und ich verbiege die Regeln die ganze Zeit. Ich nenne es einfach nicht Scrum oder bezeichne Leute als Eiferer. Verkörpern Sie agile Werte? Sicher. Machst du Scrum? Nein.
Du liegst falsch, tut mir leid. Hier ist ein Link zum Scrum-Leitfaden: scrumguides.org/scrum-guide.html#team . Lesen Sie jetzt den Teil über die Größe des Entwicklungsteams. Also ja, Sie würden immer noch Scrum machen. Wenn Sie ein Eiferer sein wollen, dann zumindest RTFM.
Zeigen Sie mir den genauen Satz, der besagt, dass der Product Owner Mitglied des Entwicklungsteams ist. Wo ist es? Ich liege nicht falsch und mehrere Leute haben es dir jetzt gesagt; du bist einfach nicht bereit, es zu akzeptieren.
@venture2099, aus dem oben von Andrew Clear geposteten Link, in Bezug auf das Entwicklungsteam: „Die Rollen Product Owner und Scrum Master sind nicht in der Zählung [des Mitglieds des Entwicklungsteams] enthalten, es sei denn, sie führen auch die Arbeit des Sprint Backlogs aus.“ Im Kontext bedeutet dies, dass der Product Owner oder Scrum Master als Teil des Entwicklungsteams angesehen werden kann, wenn er Entwicklungsarbeit leistet. Ob es Best Practice ist oder nicht, werde ich nicht kommentieren, aber Sie haben nach dem genauen Satz gefragt, der besagt, dass sie es könnten, und ich denke, da ist er :)

Antworten (14)

Es ist möglich, dass ein Entwickler auch als Product Owner fungiert, aber ich denke nicht, dass dies empfehlenswert ist. Hier sind meine 2 Hauptgründe:

  • Dies kann zu Interessenkonflikten führen
  • Es wird Ihre Leistung als Entwickler nach unten ziehen

PO muss den Rückstand (den Was-Teil) priorisieren, während das Team über die Menge der Arbeit entscheidet, die in jedem Sprint geliefert werden kann (der Wie-viel-Teil). In ähnlicher Weise gibt PO während Sprint-Review-Meetings Feedback zum Sprint und entscheidet, ob der vom Team gelieferte Sprint genehmigt oder abgelehnt wird, wodurch ein Interessenkonflikt entsteht.

Ein PO zu sein, erfordert eine regelmäßige Zusammenarbeit mit dem Kunden und dem Team, damit jeder eine abgestimmte Vorstellung davon hat, was wann geliefert werden muss. PO muss verfügbar sein, um Fragen zu beantworten, die vom Team kommen. Wenn Ihre Zeit zwischen Engagement und Entwicklung aufgeteilt wird, wirkt sich dies zwangsläufig negativ auf die Effizienz sowohl der Entwickler- als auch der PO-Rollen aus.

Hier ist, was Roman Pichler zur Scrum Alliance zu sagen hat. Der Product Owner muss:

  • eng mit dem Team zusammenarbeiten, um sie anzuleiten und zu leiten
  • das Produkt-Backlog verwalten
  • Fragen des Teams beantworten
  • Rückmeldung geben
  • Arbeitsergebnisse abzeichnen

Dies ist eine Menge Arbeit für eine PO, die ungeteilte Aufmerksamkeit erfordern würde. Für hochgradig ausgerichtete und leistungsstarke Teams benötigt die Rolle des Scrum Masters möglicherweise weniger Zeit, aber ein PO muss trotzdem ähnlich viel Zeit aufwenden.

In Ihrem referenzierten Beitrag über Product Owner sagte Herr Pichler auch: „Ich habe empfohlen, dass er den größten Teil seines Zeitplans freigibt und die meisten seiner anderen Verpflichtungen aufschiebt, um genügend Zeit zur Verfügung zu haben“, um seine Hauptaufgaben als Product Owner zu erfüllen. Ein PO, der alles tut, was die Rolle erfordert, wird keine Zeit haben, auch die Rolle eines anderen zu übernehmen.
Richtig, wie @ToddA.Jacobs sagte, für mich viel beunruhigender als PO-Pflichten, die den Output als Entwickler nach unten ziehen, ist, dass Entwicklungspflichten Sie in der Praxis daran hindern, die PO-Pflichten vollständig auszuführen, was einen weitaus nachteiligeren Effekt hat, weil schlechte Planung mehr ist gefährlicher als schlechte Ausführung.

Der Scrum Guide sagt ausdrücklich, dass dies erlaubt ist:

Die Rollen Product Owner und Scrum Master sind in dieser Zählung nicht enthalten, es sei denn, sie führen auch die Arbeit des Sprint Backlogs aus.

Ich wünschte, ich könnte dem etwa tausend Mal +1 geben. Ich bin mir nicht sicher, warum die Leute in diesem Punkt so verwirrt sind.
Diese Antwort ist die gleiche wie die bereits gegebene: pm.stackexchange.com/a/11501/27189

Während der Scrum Guide nicht ausdrücklich festlegt, ob der Scrum Master oder der Product Owner Teil des Entwicklungsteams sind oder nicht , sind sie Teil des Scrum-Teams:

Das Scrum Team besteht aus einem Product Owner, einem Scrum Master und dem Entwicklungsteam.

Daraus folgt, dass sowohl der Product Owner als auch der Scrum Master außerhalb des Entwicklungsteams agieren.

Darüber hinaus heißt es im Scrum Guide:

Die Rollen, Artefakte, Ereignisse und Regeln von Scrum sind unveränderlich, und obwohl die Implementierung nur von Teilen von Scrum möglich ist, ist das Ergebnis nicht Scrum. Scrum existiert nur in seiner Gesamtheit und funktioniert gut als Container für andere Techniken, Methoden und Praktiken.

Der Product Owner ist auch für viel Administration und Backlog-Grooming verantwortlich, wieder aus dem Scrum Guide:

Der Product Owner ist die einzige Person, die für die Verwaltung des Product Backlogs verantwortlich ist. Product Backlog Management beinhaltet: Product Backlog Einträge klar ausdrücken; Ordnen der Elemente im Product Backlog, um Ziele und Missionen am besten zu erreichen; Gewährleistung des Wertes der Arbeit, die das Entwicklungsteam leistet; Sicherstellen, dass das Product Backlog für alle sichtbar, transparent und klar ist und zeigt, woran das Scrum-Team als Nächstes arbeiten wird; und Sicherstellen, dass das Entwicklungsteam die Elemente im Product Backlog auf dem erforderlichen Niveau versteht. Der Product Owner kann die oben genannten Arbeiten durchführen oder das Entwicklungsteam damit beauftragen. Der Product Owner bleibt jedoch verantwortlich.

Basierend auf den vorangegangenen Informationen würde ich sagen, dass es nicht empfohlen wird - und wenn Sie dies tun würden, würden Sie Scrum nicht wirklich machen (laut dem von den Gründern gepflegten Dokument). Abgesehen davon, ist das von Natur aus eine schlechte Sache - nein, Sie sollten es nur nicht Scrum nennen.

http://www.scrum.org/Scrum-Guides

http://www.youtube.com/watch?v=IyNPeTn8fpo

Nur zur Klarstellung: PO und SM sind sicherlich Mitglieder des Scrum-Teams, aber keine Mitglieder des Entwicklungsteams.
Der Scrum-Leitfaden besagt tatsächlich, dass ein Scrum Master oder Product Owner als Teil des Entwicklungsteams angesehen werden kann. Dies kommt im Abschnitt "Größe des Entwicklungsteams" vor.
@DanSolovay: Wenn Sie sich auf "Der Scrum Master hilft jedem, diese Interaktionen zu ändern, um den vom Scrum-Team geschaffenen Wert zu maximieren" beziehen - ich glaube, dies ist eine Änderung gegenüber der vorherigen Iteration des Leitfadens, da der Abschnitt über die Größe des Scrum-Teams wurde auf andere Weise verändert. Gute Aktualisierung.
@JoshBruce: Nein, in Bezug auf Folgendes: pm.stackexchange.com/a/14570/16719 Die Sprache scheint ziemlich klar zu sein, dass dies zulässig ist. Wann es sinnvoll ist, ist eine viel kniffligere Frage, aber ich kann mir eine Reihe von Szenarien vorstellen, insbesondere für intern ausgerichtete Projekte mit kleinen Teams (z. B. den Aufbau von Entwicklungstools). Die Hauptsache, die der Scrum Guide deutlich macht, ist, dass wenn der Entwickler als Product Owner spricht, er/sie mit einer besonderen Autorität spricht. Wenn die anderen Entwickler dies respektieren, sehe ich keinen inneren Konflikt.
@DanSolovay: Entschuldigung, ich meinte: „Die Rollen Product Owner und Scrum Master sind in dieser Zählung nicht enthalten, es sei denn, sie führen auch die Arbeit des Sprint Backlogs aus“; falsches Zitat eingefügt.

Leider nicht. Ein guter Product Owner hat viel Abstimmungsarbeit mit Kunden, Support, Management was viel Zeit (und Meetings) in Anspruch nimmt. Daher bleibt nur wenig Zeit für Entwicklungsarbeit und Teamarbeit. Außerdem wird diese kleine Zeit ohnehin von Benutzern, Kunden, Managern und Besprechungen unterbrochen.

Wenn der Product Owner außerdem zu viel über die Implementierungsdetails weiß, kann er das Team in eine bestimmte technologische Richtung treiben und ist möglicherweise weniger offen für andere Vorschläge.

Product Ownership erfordert eine andere Denkweise. Selbst wenn man eine PO- und eine Entwickler-Denkweise hat, erfordert der Wechsel zwischen ihnen Zeit und einen enormen Aufwand.

Jeder geht davon aus, dass die Bestellung codiert wird. Was ist mit der Ausführung manueller Testfälle, die von den testorientierten Mitgliedern des Teams geschrieben wurden? Was ist mit der Erstellung automatisierter UI-Tests? Neue Unit-Tests für Legacy-Code schreiben?
Wenn wir über Scrum sprechen, sehe ich keinen Unterschied zwischen Codieren und Testen. Stellen Sie sich vor, die PO beginnt mit der Programmierung eines Abnahmetests, wird aber gebeten, an einem Meeting teilzunehmen, und danach muss sie einen Statusbericht schreiben usw. Unabhängig von der Art der Aufgabe kann sie sich nicht konzentrieren oder sich voll auf die Arbeit des Teams einlassen.
Ich stimme Zsolt zu: Der PO sollte kein Programmierer sein. Tatsächlich kann es sogar noch besser funktionieren, wenn der PO kein Mitglied der Entwicklungs- oder IT-Abteilung ist. Wenn Ihr Unternehmen über ein Produktmanagement-Team verfügt, ist es am besten, Ihre Bestellung von dort zu erhalten.

Einige Antworten beziehen sich auf den Scrum Guide, wenn sie nein sagen. Gemäß dieser Referenz würde ich jedoch sagen, dass es unter den richtigen Umständen kein Problem für sowohl den SM als auch den PO wäre, sich zu entwickeln:

Die Rollen Product Owner und Scrum Master sind in dieser Zählung [der Größe des Entwicklungsteams] nicht enthalten, es sei denn, sie führen auch die Arbeit des Sprint Backlogs aus.

Ja. PO ist ein Hut wie jeder andere. Die einzige ausgeschlossene Kombination ist PO und Scrum Master.

Bearbeiten Da ich wusste, dass die Community hier vehement gegen mich sein würde, habe ich die Länge meiner Antwort kurzgeschlossen, da ich die Idee eines weiteren Streits mit einem Scrum-Eiferer nicht wirklich mochte. Zu ihnen werde ich Folgendes sagen: Der Scrum-Leitfaden sagt sehr explizit, dass er sehr explizit ist (siehe die Zitate in Josh Bruces Antwort als Beweis). Der Scrum Guide sagt nicht ausdrücklich, dass der PO kein Mitglied des Entwicklungsteams sein kann.

Davon abgesehen, wenn Ihr PO nur 20 % der Zeit beschäftigt ist und ein voll qualifizierter Entwickler ist, ist es mir wirklich wichtig, ob Sie mich dazu bringen, nicht mehr zu sagen, dass ich „Scrum“ mache, während ich weiterhin Wert für meine liefere Kunden? Nein, nicht im Geringsten.

Der Product Owner ist für die Wirtschaftlichkeit des Produkts verantwortlich. Solange er/sie diese Rolle erfüllt und seine laufende Arbeit kontrolliert wird, sehe ich keinen Grund, warum er/sie nicht zur Tastatur greifen sollte.

Vielen Dank für die Änderungen (auch wenn Ihre Ansicht möglicherweise anders ist als die anderer in Bezug auf Scrum). Ich bin kein Scrum-Experte, aber ich denke immer an Frameworks wie diese als etwas, das man nehmen und dann modifizieren kann, um es an die eigenen Anforderungen und Unternehmensziele anzupassen. Sicher, es mag an diesem Punkt kein echtes Scrum sein, aber richtig oder falsch, ich war schon immer ein Fan davon, einfach das zu verwenden, was funktioniert.
Ich denke, Ihre Antwort wäre besser ohne den kleinen Mini-Rant über die Community. Halten Sie sich an Fakten und nützliche Informationen.
Mein „Mini-Rant“ handelte von Scrum-Fanatikern und ganz sicher nicht von der Stack-Community im Allgemeinen (ich bin mir auch nicht sicher, ob 1,5 Sätze als Rant gelten, aber ne).
Ihre brillante Idee ist also, ein Mitglied des Entwicklungsteams für die Genehmigung und Ablehnung der restlichen Arbeit des Entwicklungsteams verantwortlich zu machen ... lassen Sie mich mit dem langsamen Klatschen beginnen. Genius. Ich muss Scrum Eiferer sein. Die Teamdynamik wird großartig!
Ja Ja es ist. Dies kann gut funktionieren, wenn der richtige Kontext und die richtige Kultur gegeben sind. Und warum die Feindseligkeit? Wenn Sie mir nicht zustimmen, gut. Es gibt eigentlich keinen Grund, unhöflich zu sein...
Die Feindseligkeit ist eine Reaktion auf Ihre lächerliche Einstellung, dass die "Community" irgendwie nicht bereit ist, Ihr Genie zu akzeptieren, und jeder, der nicht Ihrer Meinung ist, ein Eiferer ist. Ich weiß Ihre Einstellung nicht zu schätzen und habe in gleicher Weise geantwortet. Was Sie vorschlagen, funktioniert möglicherweise in einem winzigen Bruchteil des Scrum-Teams, und selbst dann ist es kein Scrum. Es ist ein angepasstes Framework, das Sie selbst erfunden haben. Keine schlechte Sache, aber hören Sie bitte auf zu argumentieren, dass es irgendwie vom Scrum Guide empfohlen wird. Es ist nicht. Im Ernst, können Sie den Unterschied wirklich nicht sehen?
Siehe die Antwort von Dan Solovay unten. Beruhigen Sie sich, gehen Sie zu RTFM und haben Sie einen schönen Tag.
Ich habe es gelesen. Zeigen Sie mir den Satz, der besagt, dass der Product Owner Mitglied des Entwicklungsteams sein kann/ist/sollte. Auch ein Kopieren und Einfügen reicht aus.
„Die Rollen Product Owner und Scrum Master sind in dieser Zählung nicht enthalten, es sei denn, sie führen auch die Arbeit des Sprint Backlogs aus.“ Diese Aussage weist direkt auf „kann“ hin.

Wenn Sie nach Anekdoten suchen, ich bin sowohl PO als auch Entwickler/Architekt für ein Team. Dies ist mehr aus der Notwendigkeit als aus der Wahl heraus. Ich persönlich finde es ziemlich schwierig, weil es bedeutet, dass ich nicht die Möglichkeit habe, das angemessene Maß an PO-Unterstützung bereitzustellen, das mein Team verdient. Ich bin nicht in der Lage, 100 % meiner Zeit der Entwicklung zu widmen, und ich bin nicht in der Lage, 100 % meiner Zeit darauf zu verwenden, der Product Owner zu sein, also leiden beide Rollen.

OTOH, mein Team ist hochproduktiv, wohl das produktivste und glücklichste Team im Unternehmen. Als Team können wir es also schaffen. Das ist am Ende doch das Wichtigste, oder? Ein wirklich selbstorganisierendes Team wird tun, was es braucht, um die Arbeit zu erledigen.

Davon abgesehen empfehle ich nicht, es zu versuchen, es sei denn, Sie haben keine andere Wahl. So produktiv mein Team auch ist, ich denke gerne, dass wir mit einem Vollzeit-PO noch produktiver wären, egal ob ich es bin oder jemand anderes.

JA!!!!!

Schauen wir uns den Geist von Scrum an

1) Konzentrieren Sie sich darauf, wie Sie helfen können, nicht auf Ihren „Job“

2) Iterative Retrospektive zur Veränderung und Anpassung.

Sie können es also ausprobieren und sehen, wie es funktioniert, darüber nachdenken und als Gruppe entscheiden, ob es von Vorteil ist. Denken Sie daran, dass die Rolle des Product Owners darin besteht, das Backlog zu organisieren und Anweisungen zu geben. Stellen Sie also sicher, dass dies effektiv geschieht und Sie keine Probleme haben sollten.

Ich kann sagen, dass ich Scrum die ganze Zeit über selbstständig an Soloprojekten betreibe. Ist es eine Art Blasphemie, dass ich Teammitglied, Zeremonienmeister und Product Owner bin? Es sind 3 unterschiedliche Rollen, aber ich tue nur so, als ob ich 3 Personen bin und sie alle selbst mache.

Menschen, die mit Nein antworten, sind nur Eiferer, der Prozess definiert Flexibilität und Anpassung. Sie können tun, was zu Ihnen passt, was sich von Situation zu Situation ändert. Sie sollten versuchen, Ihren ersten Sprint rein zu machen, aber danach soll die Retrospektive Verbesserungen und Veränderungen hervorrufen.

Auch wenn es dabei Nachteile gibt, heißt das nicht, dass Sie es nicht können. Wenn dies auf Ihr Projekt und Ihre Organisation zutrifft, dann tun Sie es. Die Verwendung von Scrum bedeutet nicht, „das Gehirn abzuschalten“ und strenge Regeln zu befolgen, ohne sie an Ihren Fall anzupassen.

Angenommen, das Entwicklungsteam entwickelt ein Produkt für sich selbst. Der PO könnte leicht im Team sein. Das passt vielleicht nicht genau zur Definition von Scrum-Teams, aber Agile sagt ja auch nicht, dass man Scrum verwenden muss. Selbstorganisierende Teams – organisieren Sie sich also so, wie es am besten funktioniert.

Nein, natürlich kann der PO kein Entwickler sein und umgekehrt. Bei Scrum dreht sich alles um Rollen und unterschiedliche Sichtweisen auf dieselbe Vision oder dasselbe Ziel. Außerdem unterscheiden sich die von einem PO zu erledigenden Aufgaben völlig von den Aufgaben, die von einem Entwickler zu erledigen sind.

Um ein gutes Produkt zu liefern, ist es gut, dass das Team vom PO herausgefordert wird (ich denke, deshalb heißt es Scrum ) und umgekehrt.

Durch die Bereitstellung von Feedback kann das Team den PO auch dazu bringen, über das Produkt oder die Funktionen nachzudenken, die er implementiert haben möchte. Durch die unterschiedlichen Sichtweisen entwickeln sich also alle Beteiligten weiter. Wenn ein PO auch ein Entwickler wäre, würden Sie diesen Effekt nicht nutzen.

Bei Scrum geht es darum, Ihren Kunden schrittweise einen Mehrwert zu bieten. Die Rollen, Ereignisse und Artefakte sind lediglich der Mechanismus, der dies ermöglicht. Verlieren Sie nicht den Wald vor lauter Bäumen, oder bezahlen Sie Ihre Kunden tatsächlich dafür, dass Sie ein Scrum-Team nach Vorschrift sind?
Ich bin ganz bei dir. Aber ich denke, wenn die Trennung nicht wie im Buch geschrieben verwendet wird, könnte man auch sagen ‚Machen wir das als normales Team mit einer Standardhierarchie. Vergiss Gedränge.“ Ich habe bereits in einem Scrum-Team gearbeitet und wir hatten einige ernsthafte Probleme, weil wir uns nicht an das Rollensystem gehalten haben ...
Fürs Protokoll, der Scrum Guide erlaubt es. Im Abschnitt „Größe des Entwicklungsteams“ heißt es: „Die Rollen Product Owner und Scrum Master werden nicht in diese Zählung einbezogen, es sei denn, sie führen auch die Arbeit des Sprint Backlogs aus.“ Ob es eine gute Idee ist, ist jedoch eine andere Frage. [Dan Solovay, Andrew Clear, Josh Bruce und user9015 haben dies auch in anderen Kommentaren und Antworten hier zitiert.]

Der PO hat normalerweise andere Verantwortlichkeiten, aber wenn er glaubt, dass er als Mitglied des Entwicklerteams einen Beitrag leisten kann, wird das Team seinen Beitrag hoffentlich begrüßen. Ein Risiko besteht darin, dass die flache Selbstorganisationsstruktur des Teams beeinträchtigt wird, wenn jemand als „Erster“ unter Gleichen angesehen wird. Ich denke, ein guter PO sollte klar unterscheiden zwischen den Zeiten, in denen er seinen PO-Hut aufsetzt, und den Zeiten, in denen er nur als ein weiterer Entwickler im Team arbeitet.

Ich empfehle es nicht. Die Rollen sind sehr unterschiedlich. Wie der SM repräsentiert der PO Geschäftseinheiten (und ihre Perspektiven), die sich von denen des Teams unterscheiden.

Nachdem ich noch etwas darüber nachgedacht habe, würde ich einfach sagen: "Die Antwort ist nein."

Der PO ist die Verbindung zwischen dem Unternehmen und dem Team, er repräsentiert die Perspektive des Unternehmens auf das, was vor sich geht (als „Input“ für das Team), und kommuniziert den Status an das Unternehmen (als „Output“). Und das muss ihre Vollzeitbeschäftigung sein. Wenn Sie versuchen, "auch" jemand zu sein, der Quellcode schreibt, können Sie sich wirklich nicht an diese Objektivität halten. Wenn Sie Quellcode schreiben, beginnen Sie unweigerlich, alles in Bezug auf Quellcode zu sehen, und das ist wirklich der Grund, warum PO als separate Rolle formalisiert wird.

Kann ein Product Owner ein Entwickler in Scrum sein?
AntwortenHierDatenschutz-Bestimmungen1y, 6v