Der Product Owner fordert Überstunden für das Schreiben von Unit-Tests. Wie kann ich das ansprechen?

Kürzlich habe ich bei der Arbeit ein neues Projekt gestartet (es war schön, den Schmutz eines alten Projekts abzuschütteln und ein neues aufzunehmen) und mein Team und ich drängen stärker auf professionellere Entwicklungsmethoden, zu denen auch das Schreiben von Unit-Tests gehört. Der Product Owner ist nicht so beeindruckt, da dies nach Meinung des PO zu einer verzögerten Feature-Bereitstellung führt.

Der PO (der auch der Chef meines Chefs ist, was meiner Meinung nach zu einem kleinen Interessenkonflikt führt) ist sehr verärgert über ein Problem, das zu unserem Release-Produkt durchgerutscht ist. Ich weise darauf hin, dass eine gute Unit-Test-Suite das Problem erkannt hätte (einige zusätzliche Umgestaltungen waren erforderlich, um mit den Architekturfehlern einiger unerfahrener Programmierer fertig zu werden), und der PO hat keine Zeit verschwendet, indem er vorschlug, dass wir „herausfinden, wie wir etwas Qualität ausgeben können OT zum Einrichten von Unit-Tests." Unser Zeitplan ist bereits vollgepackt mit Funktionsanfragen und minimalem Zeitaufwand für die Fehlerbehebung und andere erforderliche Wartungsaufgaben.

Ich bin nicht geneigt, Überstunden für etwas anzubieten, von dem ich gelernt habe, dass es Teil des Standardentwicklungsprozesses in einem Team von Fachleuten ist. Wie kommuniziere ich, dass das Schreiben von Unit-Tests ein notwendiger Teil der täglichen Verantwortung des Entwicklers ist? Wie kann ich dazu beitragen, dass mein Team nicht demotiviert wird, wenn Überstunden von ihm verlangt werden?

PS, ich weiß nicht, wie ich das taggen soll, ich würde mich auch über jede Hilfe freuen.

Ich kenne den Begriff „Product Owner“ nicht. Ist das Ihr Kunde?
Möglicherweise verwandt, da es einen Aspekt des Problems anspricht: arbeitsplatz.stackexchange.com/questions/7095/…
@DavidK Ja! Sorry für die Zweideutigkeit. Dies bezieht sich auf die Person, die das Produkt besitzt, das mein Team entwickelt.
@404usernotfound Ich bin kein Auftragnehmer, ich bin mir nicht sicher, ob Ihr Link hilft (obwohl er gut zu lesen ist, danke).
@JoeStrazzere Ich bin Teamleiter und spreche für mich. Ich möchte verhindern, dass auch andere Überstunden machen müssen, denn der Schutz meines Teams ist Teil meines Jobs (der mir sogar Spaß macht).
Weiß Ihr Product Owner, was Unit-Tests sind?
@Brandin Ich hoffe es. Ich verbrachte 30 Minuten damit, sie im letzten Sprint-Planungsmeeting detailliert zu beschreiben, in der Hoffnung, die Art der technischen Schulden zu vermitteln, die sie einsparen könnten.
30 Minuten sind nicht genug, um den Wert zu erkennen, den Unit-Tests für den Entwicklungsprozess bringen. Sie könnten versuchen, seine/ihre Angst zu mildern, indem Sie erklären, dass Sie nicht testen werden, ob der Compiler, die Laufzeitumgebung oder das Betriebssystem korrekt funktionieren.
Welchen Interessenkonflikt könnte es geben, wenn man gleichzeitig Product Owner und Chef des Chefs ist?
@Hyperbole hatte das gleiche Problem, mein Team schreibt keine Tests mehr - es geht einfach nicht, ohne den Chef so zu nerven, dass man gefeuert wird. Wie andere gesagt haben, tun Sie sie einfach nicht, und wenn Tech-Schulden auftreten, bringen Sie das Thema als Diskussion zur Sprache, um zu rechtfertigen, warum Unit-Tests wichtig sind.

Antworten (2)

Da Sie den Begriff Product Owner verwenden, gehe ich davon aus, dass Sie Scrum (oder eine verwandte Methode) verwenden. Wenn nicht, ignorieren Sie diese Antwort vollständig.

Wenn Sie Scrum verwenden, bestimmt nicht die Bestellung, wie viel das Team in einem Sprint leisten kann, sondern das Team. Wenn Sie Unit-Tests benötigen, um die PO-Definition of Done zu erfüllen, nehmen Sie diese in Ihre Punktschätzungen auf. In Scrum sollte Ihr Zeitplan nicht „voll“ sein – Sie können nur so viele Punkte pro Sprint erreichen, und das ist Ihr Zeitplan.

Die PO sollte die Priorität basierend auf dem erzielten Geschäftswert festlegen. Wenn Fehlerbehebungen und technische Schulden für den PO nicht wichtig sind, werden sie nicht ganz oben auf die Prioritätenliste gesetzt. Aber auch Ihr Team sollte nicht dafür haftbar gemacht werden. Wenn die Arbeit der PO-Definition of Done entsprach (und QA-Tests sollten in der Definition of Done enthalten sein), dann haben Sie das Erforderliche getan.

Ihr Scrum Master sollte derjenige sein, der das Team sowohl vor Eingriffen durch den PO als auch vor Eingriffen von höheren Stellen schützt, also binden Sie sie ein.

Die PO-Definition von Done wurde gegen mein besseres Wissen so ausgehandelt, dass sie "Entwicklung abgeschlossen, aber mit QA" anzeigt.
Dann muss Ihr Scrum Master sicherstellen, dass der PO und nicht das Team für diese Entscheidung verantwortlich ist.
@Kathy hat die richtige Idee. OP Sie müssen Ihren Chef darüber aufklären, warum Komponententests wichtig sind, damit er zustimmt. Im Moment scheint er den Wert davon nicht zu verstehen, der beste Weg, dies zu tun, ist, seinen Ansatz zu verfolgen, und wenn sich die technischen Schulden häufen, erwähnen Sie ihm gegenüber, dass dies daran liegt, dass Sie keine Komponententests durchführen. Er wird dann eher zuhören.

Unterteilen Sie beim Umfang oder der Dimensionierung Ihrer Funktionen die Einheitentests als Teil davon oder handelt es sich um eine separate Position? Ich würde vorschlagen, dass Sie Unit-Tests zu einem Teil Ihres Entwicklungsprozesses machen und die Aufgaben dann entsprechend ausrichten, ohne sie in Code herunterzubrechen. Dieses Feature testen Sie dieses Feature. Nehmen Sie einfach an, dass der Aufwand zum „Codieren“ einer Funktion das Schreiben der Testfälle umfasst.

Wenn Sie gefragt werden, warum die Dinge höher gefasst werden, geben Sie einfach an, dass das Projekt wächst. Je größer das Projekt, desto mehr Funktionen kosten das Hinzufügen. Sie könnten ihn über TDD (Test Driven Development) aufklären, aber ich glaube nicht, dass es einen großen Unterschied machen wird. Auf der anderen Seite, wenn TDD Teil Ihres Entwicklungsprozesses ist, dann ist es einfach alles integriert und nicht wirklich eine separate Sache, es ist einfach so, wie Sie Dinge erledigen.

Wenn Sie agil/scrum arbeiten, sollte der PO sowieso nicht den Zeitplan diktieren, er/sie sollte nur Prioritäten setzen und Funktionen definieren. Es ist die Aufgabe Ihres Teams, ihm einen Zeitplan zu geben. Wenn Sie zurückgehen und etwas aufräumen müssen, gibt es einige Argumente für Ihre eigene Zeit, aber Sie möchten vielleicht eine bestimmte Menge an "Engineering" -Zeit aushandeln. Wo ich jetzt arbeite, haben wir ausgehandelt, dass 15 % unserer Zeit für technische Bemühungen aufgewendet werden. Dies sind Dinge, die wir intern als reparaturbedürftig identifiziert haben. Es könnte eine Leistungssache sein, die jetzt nicht allzu auffällig ist, aber bald sein wird, oder es könnte das Modul sein, das beim ersten Mal nicht richtig gemacht wurde und etwas Liebe braucht.

UT zu einem Einzelposten in einer Aufgabe zu machen, ist ein praktisches Risiko, die Bestellung ist sehr widerstandsfähig gegen alles, was keinen unmittelbaren, greifbaren geschäftlichen Nutzen hat. Selbst nach diesem schwerwiegenden Fehler in einem veröffentlichten Produkt ist der PO nicht bereit, die Vorteile von UTs zu hören.
Sie sagten, „development done“ sei Teil Ihrer Definition von „done“. UT ist Teil der Entwicklung, es handelt sich um von Entwicklern geschriebene Testfälle und sollte Teil Ihrer Definition von Entwicklung sein, vorausgesetzt, Sie haben eine Definition dafür. Möglicherweise müssen Sie dies vorantreiben, wenn Sie dies integrieren möchten, sodass es nicht fertig oder sogar für die QA bereit ist, bis alle Komponententests bestanden sind. Es ist auch Code, Ihr PO versteht offensichtlich nichts von Softwareentwicklung, also viel Glück.
@Hyperbole Es ist im Allgemeinen besser, Komponententests überhaupt nicht zu erwähnen, aber eine allgemeine Regel im Team zu haben, dass jeder neue oder geänderte Code über ausreichende Komponententests für das erforderliche Vertrauensniveau verfügen muss, und dann alles basierend darauf neu zu schätzen. Ja, einige Geschichten oder Aufgaben, die einfach aussehen, werden plötzlich viel teurer, wenn Sie die Komponententests schreiben müssen, die zuvor geschrieben werden sollten (oder sogar noch teurer, wenn Sie den Code selbst neu schreiben müssen, damit er testbar ist).
Aber diese zusätzlichen Kosten sind jetzt die Kosten, um daraus herauszukommen und technische Schulden zurückzuzahlen. Wenn es wirklich unangenehm ist, können Sie die Dinge ein wenig betrügen, indem Sie die schlimmsten Fälle jetzt unzureichend testen und bessere Tests für später hinzufügen, aber Sie müssen mit der Durchführung von Tests fortfahren. ¶ Das Wichtigste ist, Verhandlungen von Laien darüber zu vermeiden, wie der Code zu schreiben ist; Das XP-Prinzip, dass nur Personen, die Code schreiben, Entscheidungen darüber treffen können, wie Code geschrieben wird, wurde ausdrücklich entwickelt, um dieses Problem anzugehen. Und dazu gehört auch, wie viele Unit-Tests Sie durchführen.
Der Product Owner fordert Überstunden für das Schreiben von Unit-Tests. Wie kann ich das ansprechen?
AntwortenHierDatenschutz-Bestimmungen1y, 0v