Ich bin kürzlich einem kleinen Softwareentwicklungsteam beigetreten, das 1 Produkt mit mehreren externen Kunden hat. Es wird keine spezifische Projektmanagement-Methodik oder ein Framework verwendet, sodass die Entwicklung eher ad-hoc erfolgt. Soweit ich weiß, besteht eine ständige Herausforderung darin, dass es ein Muster gibt, bei dem jede Version Fehler aufdeckt, die während der Entwicklung nicht entdeckt wurden, und die Version dann zurückgesetzt werden muss, um die Fehler zu beheben, bevor die Version erneut veröffentlicht wird. Infolgedessen misstraut das Team seinen eigenen Veröffentlichungen und verzögert seine Veröffentlichungen, um diesen Schmerz zu vermeiden.
Derzeit gibt es keine dedizierte QA- oder Testperson, aber ich denke, das ist nicht unbedingt ein kritisches Problem, denn obwohl es ideal wäre, einen primären Tester zu haben, sollten agile Teams danach streben, funktionsübergreifend zu sein. Die Entwickler haben jedoch ihren eigenen Code getestet und genehmigt (ich weiß ...)
Ich möchte eine priorisierte Liste von Qualitätspraktiken erstellen, die implementiert werden sollten, um diese Situation zu verbessern. Was sind in der Reihenfolge ihrer Priorität die wichtigsten Qualitätspraktiken, die Sie ansprechen sollten? Können Sie eine priorisierte Liste dessen geben, was Sie zuerst ansprechen würden?
Das unmittelbarste, was mir in den Sinn kommt, ist:
Was würden Sie vorrangig umsetzen?
Ich werde versuchen, verschiedene Punkte in einigen getrennten Abteilungen in der Reihenfolge anzusprechen, in der ich sie ansprechen würde. Je nachdem, welche Ressourcen und Unterstützung Sie haben, kann die Aufwand-Nutzen-Situation eine andere Reihenfolge vorschreiben.
Sie benötigen klare, vollständige, aktuelle und korrekte Spezifikationen. Es spielt keine große Rolle, wie viele Personen daran beteiligt sind, dass Business-Speak-Anforderungen in Developer-Speak-Spezifikationen umgewandelt werden. Wichtig ist:
Dinge, die hier helfen können:
Sie benötigen zuverlässige, wiederholbare und strenge Tests. Ich habe als Tester in einer Umgebung gearbeitet, die sich ausschließlich auf manuelles Testen konzentrierte. Es ist einfach nicht nachhaltig. Wenn Ihr Feature-Set wächst, wächst der Testbedarf exponentiell. Wenn Sie nicht zumindest einen Teil davon automatisieren, sind Sie am Arsch.
Was hier hilft:
Ihre Idee, Retrospektiven einzuführen, ist gut. Als Scrum Master sollten Sie das sowieso tun (und Sprint Reviews). Stupsen Sie das Team in der Retrospektive dazu an, über Qualitätsprobleme zu sprechen. Ich bin sicher, sie sind genauso frustriert über schlechte Qualität wie Sie. Sie werden auch Ideen darüber haben, was getan werden sollte, um es zu beheben. Extrahieren Sie diese Vorschläge und helfen Sie bei der Umsetzung. Dieser Ansatz hat folgende Vorteile:
Sie sind vor kurzem beigetreten, während das Entwicklerteam schon länger dabei ist. Sie wissen mehr über die Ursache der Qualitätsprobleme und was getan werden sollte, um sie zu beheben. Als neue Person bringen Sie eine frische Perspektive mit. Aber nutzen Sie dies, um die Diskussion zu leiten, um Schuldzuweisungen zu vermeiden und produktive Linien zu führen.
Wenn Sie mit dem Entwicklerteam zusammenarbeiten und bei der Umsetzung seiner Ideen helfen, werden die Ideen besser akzeptiert und der Widerstand gegen Änderungen verringert.
Als Scrum Master möchten Sie ein dienender Leiter sein, anstatt dem Team Ihre Ideen aufzuzwingen.