Beeinflussen Sie die Codequalität als Scrum Product Owner

Der Product Owner ist für das Backlog und das Entwicklungsteam für die Lieferung verantwortlich. In Scrum arbeiten wir jedoch als Team, und nichts hindert den Product Owner daran, Bedenken hinsichtlich der Bereitstellung mit dem Entwicklungsteam zu besprechen. Genauso wie nichts das Entwicklungsteam davon abhält, Bedenken bezüglich des Rückstands mit dem Product Owner zu besprechen. Wir bevorzugen Zusammenarbeit gegenüber Vertragsverhandlungen .

In Ihrer Situation besteht der Schlüssel darin, zu versuchen , das Entwicklungsteam dahingehend zu beeinflussen , dass es seine Codequalität verbessert, anstatt es dazu zu zwingen.

Ich würde einige oder alle der folgenden vorschlagen:

• Heben Sie die Auswirkungen hervor, die Qualität auf die Kunden hat.
• Quantifizieren Sie nach Möglichkeit die Kosten (z. B. „wir konnten aufgrund von Qualitätsbedenken keinen Kunden im Wert von 10.000 an Land ziehen“).
• Betonen Sie, dass Qualität für Sie Priorität hat und dass Sie bereit sind, Verzögerungen bei der Bereitstellung von Funktionen zu akzeptieren, wenn die Qualität hoch ist. Manchmal geht das Entwicklungsteam davon aus, dass die Bereitstellung von Funktionalität die höchste Priorität hat.
• Untersuchen Sie die Gründe, warum sich das Entwicklungsteam nicht auf Qualität konzentriert. Vielleicht fehlt es ihnen an Erfahrung oder sie fühlen sich unter Zeitdruck zu liefern?
• Foren Sie Benutzergeschichten, die die Qualität fördern.

Das Entwicklungsteam zu etwas zu zwingen, mag kurzfristig funktionieren, aber es besteht die Gefahr, dass es einfach in alte Verhaltensmuster zurückfällt. Ein besserer Ansatz ist es, das Entwicklungsteam dazu zu bringen, Qualität genauso hoch einzuschätzen wie Sie.

Der Product Owner kann dem Backlog alles hinzufügen, was er möchte.

Dh.

Richten Sie einen CI-Build-Server ein

Fügen Sie Unit-Tests hinzu, bis Sie eine Codeabdeckung von 90 % haben

Die geschäftliche Rechtfertigung für diese Dinge ist jedoch ziemlich vage und dreht sich um die Produktivität des Entwicklerteams.

Wenn das Team diese Dinge nicht bereits in einem „Sprint Zero“ macht, braucht es entweder etwas Training oder etwas Zeit, um es zu erledigen.

Obwohl Sie Scrum auf „Projekt: Einrichten eines Entwicklerteams“ anwenden können, wird im Allgemeinen davon ausgegangen, dass Sie ein Team haben und es über die Tools verfügt, die Computer, Softwarelizenzen, Schreibtische, ein Büro usw. benötigen, um mit der Arbeit an „Projekt: Schreiben Sie mir ein Programm“ zu beginnen. .

Heutzutage sollte eine automatisierte Entwicklungsumgebung mit verschiedenen Umgebungen, Quellcodeverwaltung, Komponententests und einem CI-Build-Server als Teil dieses Toolsets betrachtet werden.

Mich würde interessieren was du unter Qualität verstehst. Fehler oder etwas anderes?

Wenn sich die Bedenken auf die für den Endbenutzer sichtbare Qualität beziehen, würde ich mich darauf konzentrieren, was Sie als Product Owner tun können, um die Akzeptanzkriterien für Ihre Geschichten besser zu definieren, um die Probleme, die Sie haben, auszuschließen akzeptiert.

Ihre Rolle als Product Owner besteht darin, klare Anweisungen zu geben und kontinuierliches Feedback zur abgeschlossenen Arbeit zu geben. Stellen Sie sicher, dass Sie und Ihr Team regelmäßig über Ihre Ziele und die Annahmekriterien für Geschichten kommunizieren, und stellen Sie sicher, dass Sie eine gute Richtung und ehrliches Feedback zu abgeschlossener Arbeit geben. Stellen Sie sicher, dass Ihr Team versteht, dass es regelmäßig zu Ihnen kommen sollte, um Fragen zur Ausführung zu besprechen und Unklarheiten in Geschichten/Aufgaben zu klären. Stellen Sie sicher, dass Sie sich ihnen zur Verfügung stellen, um diese Fragen anzuhören und zu beantworten.

Genauer gesagt, hier sind ein paar Möglichkeiten, mit verschiedenen "Qualitätsproblemen" umzugehen:

Wenn es sich um Fehler handelt, arbeiten Sie an Ihrer Definition of Done, um sicherzustellen, dass die Funktionen ordnungsgemäß getestet werden – einschließlich Regressionstests, wenn sie integriert werden. Arbeiten Sie an Ihren eigenen Fähigkeiten zum Schreiben von Geschichten und wie Sie die Akzeptanztests für Ihre Geschichten im Voraus definieren und kommunizieren. Schließlich, wenn die Anforderungen für das Testen und die Integration klar sind und die Definton of Done die Annahme von fehlerhaftem Code ausschließt und das Team dies nicht erreicht, dann besprechen Sie das Problem mit Ihrem Team bei der nächsten Retrospektive und arbeiten Sie mit ihm daran adressiere es. Stellen Sie außerdem sicher, dass Sie Ihren Scrum Master einsetzen, der versuchen sollte, herauszufinden, was die Fähigkeit der Teams behindert, die während einer Iteration geleistete Arbeit ordnungsgemäß zu testen.

Wenn Sie mit einem Qualitätsproblem nicht Fehler meinen, sondern etwas anderes, wie z. B. eine Informationsanforderung, deren Ausführung zu lange dauert, oder eine Benutzeroberfläche, die zwischen Bildschirmen nicht kohärent ist, oder ähnliches, finden Sie hier einige Tipps für die Behandlung dieser Art von Problemen:

Konzentrieren Sie sich zunächst wieder auf die Entwicklung eines besseren DOD und die bessere Definition von Abnahmetests während der Backlog-Grooming- und Sprint-Planung. Arbeiten Sie auch mit Ihrem Scrum Master zusammen, um sicherzustellen, dass das Team seine Verantwortlichkeiten vollständig versteht. Wenn etwas mehrdeutig oder unklar ist, sind die Entwickler dafür verantwortlich, sich mit dem Product Owner oder Kunden zu besprechen und zu klären. Im Idealfall wird alles während der Sprint-Planung geklärt, aber das ist möglicherweise nicht immer der Fall, und es ist wichtig, dass die Entwickler wissen, dass sie für die Klärung der Anforderungen und Akzeptanzkriterien für eine Geschichte oder Aufgabe verantwortlich sind, indem sie sie mit dem PO (oder direkt mit dem PO) besprechen Kunde/Endverbraucher).

Zweitens, wenn diese Funktionalität bereits existiert (z. B. Teil einer früheren Story, die bereits akzeptiert wurde) und Sie mit der Ausführung einfach nicht zufrieden sind, dann erstellen Sie einfach eine weitere Story, um weiter zu verdeutlichen, was Sie wollen. Wenn z. B. Anfragen zu lange dauern, um Informationen zurückzugeben, schreiben Sie eine Geschichte „Ich möchte, dass X schnell geschieht“ und befolgen Sie dann die obigen Ratschläge, um mit Ihrem Team zusammenzuarbeiten, um zu klären, was für eine „schnelle“ Befriedigung akzeptabel ist. Oder wenn das Problem bei der Benutzeroberfläche liegt, schreiben Sie eine Geschichte: „Die Benutzeroberfläche sollte beim Wechseln von Bildschirmen konsistent sein.“ Auch hier würde die Klärung beider idealerweise während der Sprint-Planung oder des Backlog-Grooming stattfinden, wenn das Team Fragen stellt, um die Story einzuschätzen, oder wenn sie damit beginnen, sie in auszuführende Aufgaben zu zerlegen.

Denken Sie schließlich daran, dass Sie ein Team sind, und denken Sie daran, dass Sie sich regelmäßig treffen, um Ihren Prozess zu besprechen und zu verbessern. Wenn Sie der Meinung sind, dass das Team von kontinuierlicher Integration, Paarprogrammierung oder einem anderen Entwicklungstool oder einer anderen Strategie profitieren würde, würde ich dies während einer Retrospektive als etwas vorschlagen, das einen Versuch wert sein könnte. Letztendlich ist es aber Sache des Entwicklerteams, zu entscheiden, wie es entwickeln möchte. Als PO sind Sie dafür verantwortlich, die Anforderungen für den Endbenutzer festzulegen, und das Team ist dafür verantwortlich, die Lösungen für diese Anforderungen zu entwickeln.