Ich verwalte den Testaufwand für eine neue Softwareanwendung als Testmanager. In einem Meeting mit dem Projektmanager empfehle ich, Anforderungen, Designs und Code einem Review zu unterziehen. Der Projektleiter sagt: „Das klingt nach viel Arbeit. Was ist der Vorteil?“
Was ist Ihrer Meinung nach eine gute Antwort, die die Frage des Projektmanagers beantwortet?
Beim modernen Testen dreht sich alles darum, wie Sie dazu beitragen können, „das Erreichen lieferfähiger Qualität zu beschleunigen “.
Helfen Ihre Bewertungen beim Beschleunigen? Welche Metriken verwenden Sie, um das zu belegen? Testen hilft Risiken zu reduzieren, aber zu welchem Preis? Was ist die Rendite.
Insgesamt denke ich, dass die Frage des Projektmanagers sehr berechtigt ist. Frage mich, ob es wirklich ein Qualitätsproblem gibt. Seien Sie vorsichtig, wenn Sie Wasserfall-ähnliches Gating in einen aktuellen Arbeitsprozess einführen.
Anstatt Prozessverbesserungen vorzuschlagen, die in der Vergangenheit für Sie funktioniert haben könnten, würde ich eine Risikoanalyse ermöglichen und bei Bedarf gemeinsam Risiken mindern.
Liest:
Was verstehen Sie in diesem Zusammenhang unter „Bewertungen“? Viele Entwicklungsteams führen Peer-Reviews von Code und Analysen durch, weil sie feststellen, dass Reviews die Produktivität und Qualität verbessern. Viele Teams machen auch Endbenutzerbewertungen zu einem Teil ihrer Definition of Done für die Arbeit. Das ist etwas, wozu das ganze Team eine Meinung haben sollte, nicht etwas, das Sie nur mit dem PM besprechen müssen.
Review Gates , d. h. leitende Teammitglieder oder Stakeholder müssen alle Spezifikationen vor dem Testen genehmigen, sind eine ganz andere Sache. Gated Reviews sind meiner Erfahrung nach von begrenztem Wert, da der Nachweis von Tests, Peer-Review und Benutzerakzeptanz im Allgemeinen weitaus wertvoller ist als jeder formelle Vorab-Review-Prozess. Review Gates verursachen in der Regel viel Arbeit und können leicht kontraproduktiv werden, da sie den Spielraum für späte Änderungen einschränken können (die Begrenzung von Änderungen ist oft der Grund, warum überhaupt Reviews eingeführt werden).
Es ist ein Prinzip des guten Arbeitsmanagements, die Anzahl der Schritte zu eliminieren oder zu reduzieren, die ein einzelnes Arbeitselement durchlaufen muss. Wenn Ihr Team noch keine etablierte Arbeitsweise hat, warum probieren Sie dann nicht verschiedene Ansätze aus und sehen, wie sie sich in Ihrer Umgebung auswirken.
Ich denke, es ist eine sehr faire Frage, die der PM stellt. Die Bewertung des vorgeschlagenen Aufwands anhand seiner Vorteile, Kosten und Risiken ist eine angemessene Führung und Verwaltung. Wenn Sie einen Vorschlag zum Testen haben, sollten Sie in der Lage sein, den Wert zu artikulieren. Wenn Sie es nicht können, verstehen Sie die Arbeit dann wirklich?
Testen ist Risikominderung, und PMs sind dafür verantwortlich, den Grad der angemessenen Risikominderung zu bestimmen. Wie viel Geld geben wir aus, um ein probabilistisches Ergebnis mit unterschiedlichen Auswirkungen abzumildern?
Mit Qualität können Sie unendlich viel Geld und Zeit für Inspektionen und erneute Inspektionen aufwenden und die Qualitätsnadel nur sehr wenig, wenn überhaupt, bewegen, um einem Sinn für Perfektion nachzujagen, den wir vernünftigerweise nicht erreichen können. Es muss also eine Grenze gezogen werden, um das Qualitätsrisiko zu mindern, wo genug genug ist und wir den Rest aufs Spiel setzen.
Ich bin mir nicht sicher, ob es eine gute Antwort auf die Frage des Managers gibt. In manchen Kontexten kann es von Vorteil sein, formelle Gate-Reviews zu haben. Bewertungen sind jedoch in der Regel nachträgliche Inspektionen, die nicht der beste Weg sind, Qualität in ein Produkt einzubauen.
Ich würde empfehlen, noch einmal zu überdenken, was Sie mit "Rezension" meinen. Die drei Amigos können Ihnen beispielsweise beim Requirements Engineering und bei Planungsaktivitäten helfen, um sicherzustellen, dass Sie alle Perspektiven auf eine Arbeit erhalten. Anstatt eine nachträgliche Überprüfung vorzunehmen, erledigen alle Schlüsselpersonen gemeinsam die Arbeit. In ähnlicher Weise kann die Verwendung von Paar- oder Mob-Programmierung zur Entwicklung der Software die Notwendigkeit für jede Art von formaler Codeüberprüfung reduzieren.
Insbesondere als Testmanager möchte ich keine Überprüfungen erzwingen. Stattdessen möchte ich, dass die Leute, die das System testen werden, als Mitarbeiter von Anfang an bis zum Ende der Bemühungen beteiligt sind. Ich möchte auch, dass die anderen Teammitglieder - Entwickler, Designer, Projektmanager, Produktmanager, Business-Analysten usw. - von Anfang an bis zum Ende des Testprozesses einbezogen und investiert werden, um sicherzustellen, dass Probleme auftreten die in späteren Tests auftauchen, können effektiv gesichtet und gelöst werden.
Mögliche Argumente:
Der größte Einzelvorteil – es hilft, die Hybris von Entwicklern anzugehen, die falsche Annahmen treffen.
Warum ist es schwer?
Warum wird hinterfragt?
Sie müssen Arbeitsprozesse durch mehr Überprüfungen, Tests und Diskussionen verlangsamen ... um die Liefergeschwindigkeit im Laufe der Zeit zu beschleunigen oder aufrechtzuerhalten. Heute langsamer zu werden, um morgen, nächste Woche und nächsten Monat schneller zu werden, erfordert Reife und Vision.
Es hört sich so an, als ob der PM Sie um eine Kosten-Nutzen-Analyse bittet. Tests und Reviews verlangsamen (zumindest kurzfristig) den Prozess der Softwareerstellung und kosten dadurch Geld. Wenn Sie den PM davon überzeugen wollen, dass es sich lohnt, sie zu implementieren, müssen Sie zeigen, dass der erwartete Wert ihrer Umsetzung diese Kosten überwiegt.
Sie brauchen keine genauen Zahlen, aber sie müssen genau genug sein, um zu überzeugen. Versuchen Sie, einige Schätzungen darüber zu erhalten, wie viel Zeit und Geld derzeit für die Reparatur von Fehlern in der Codebasis aufgewendet wird, einschließlich des verlorenen Werts, der entsteht, wenn Entwickler neue Funktionen nicht wie geplant bereitstellen können. Wenn Sie nicht viele dieser Daten zur Verfügung haben (z. B. weil es sich um ein neues Produkt handelt), versuchen Sie, einige Persönlichkeiten des öffentlichen Lebens zu finden, die für Ihre Branche relevant sind.
Beiläufig ... "höchstwahrscheinlich kennt der PM bereits die Antwort." Aber (s)er weiß, dass Ihre Vorschläge weiter entwickelt werden müssen: (s)er konnte es nicht vor anderen Interessenvertretern des Unternehmens annehmen. Fair genug.
Zum Beispiel: „Ich empfehle, dass Anforderungen, Designs und Code überprüft werden sollten.“ ist eigentlich ziemlich allgemein. Dasselbe könnte man von „jedem Softwareprojekt überall“ sagen.
Ganz im Ernst, zuerst sollten Sie vielleicht den PM einladen, ihm/ihr vorzuschlagen, wie Ihre Rolle für ihn/sie von größerem Nutzen sein könnte. Oder um vorzuschlagen, wie Ihr ursprünglicher Vorschlag verbessert werden könnte (wie er es sieht).
Don Branson
Nicht der Typ
MCW