Was sind die vorrangigen Qualitätspraktiken?

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:

  1. Halten Sie Entwickler davon ab, das Testen ihres eigenen Codes zu genehmigen.
  2. Führen Sie Lean-Agile-Scrum-Praktiken ein (ich bin ein Scrum Master), insbesondere eine Definition of Done (DoD), um Qualitätskriterien, Sprint-Reviews zur Demonstration und Überprüfung des fertigen Codes und Retrospektiven zur Planung von Qualitätsverbesserungen aufzunehmen.
  3. Beginnen Sie mit der Einführung von TDD und Praktiken aus Working Effectively with Legacy Code von Michael Feathers .

Was würden Sie vorrangig umsetzen?

Antworten (2)

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.

Spezifikationen

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:

  1. Es wird erledigt
  2. Es wird richtig gemacht
  3. Die Verantwortlichkeiten sind klar
  4. Sie haben einen einzigen Kanal (wenn Sie N Entwickler haben, die alle mit M Kunden sprechen, hören Sie auf)

Dinge, die hier helfen können:

  • Ein Product Owner (hauptsächlich wegen Punkt 4 oben)
  • Eine Definition von bereit (um bei den Punkten 1 und 2 zu helfen)

Prüfungen

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:

  1. Haben Sie einen engagierten Tester. Ich weiß, dass es schick ist, darüber zu sprechen, wie Entwickler in der Lage sein sollten, ihren eigenen Code zu testen. Und es ist sicherlich nützlich. Aber ich war ein Entwickler, der für meine eigenen Tests verantwortlich war, ich war ein Entwickler mit einem zugewiesenen Tester und ich war ein Tester, der einem Entwickler zugewiesen war. Es hat etwas sehr Befreiendes, den Code eines anderen testen zu können. Ebenso macht es viel mehr Spaß, einen guten Tester an seiner Seite zu haben, als selbst mit Hüten zu jonglieren. Wir trennen Bedenken in unserem Kodex aus einem bestimmten Grund. Wenn Sie also die Wahl haben, Entwickler dazu zu drängen, mehr zu testen, oder einen engagierten Tester zu bekommen, ist dies nicht einmal ein Wettbewerb ...
  2. Automatisierte Tests. Wie ich oben gesagt habe, wenn Sie an mehr als einem One-Shot-Projekt arbeiten, bestrafen Sie sich nur selbst, wenn Sie dies nicht tun. Es spielt keine Rolle, ob Sie TDD annehmen oder es nach der Entwicklung im Wasserfallstil tun. Ihre Tester sollten jeden Fehler genau einmal finden müssen. Wenn es nur eine Situation gibt, in der Sie einen Test schreiben, dann ist es diese.
  3. Automatisierte Builds. Als Voraussetzung für kontinuierliches Testen und um Zeit zu sparen. Ich habe in der .NET-Welt einen manuellen Build-Prozess mit 30 Schritten gesehen. Tu das nicht
  4. Kontinuierliches Testen. Je enger Ihre Feedback-Schleife ist, desto schneller können Sie Fehler beheben
  5. Definition von Done. Das alleine trägt nicht viel zur Qualität bei. Aber es ist hilfreich, das Bewusstsein dafür zu schärfen, auf welchem ​​Qualitätsniveau Sie arbeiten, und ein besseres gegenseitiges Verständnis zu schaffen, was es bedeutet, wenn jeder sagt: „Das ist erledigt.“

Organisation

  • Frühes Benutzerfeedback. Egal wie fleißig Ihr Tester und Product Owner sind, einige Dinge werden durch das Raster fallen.
  • Kürzere Iterationen / weniger Umfang pro Iteration. Je kleiner Ihr Inkrement, desto weniger Interaktionen müssen Sie auf einmal testen. Dies kann dazu beitragen, dass sich das Testen weniger lästig anfühlt.

Bitten Sie das Entwicklungsteam, Schritte zur Verbesserung der Qualität vorzuschlagen

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.