Wie lassen sich Ressourcen in einem funktionsübergreifenden agilen Team besser ausbalancieren?

Ich glaube nicht, dass es auf diese Frage eine einfache Antwort geben wird.

Aus meiner Sicht sind die kritischen Faktoren:

1. Das Team erfüllt die Entwicklungsziele nicht
2. QA verspätet sich, möchte aber keine Hilfe von Entwicklern, wie sie derzeit angeboten/geliefert wird
3. Entwickler erledigen die Arbeit, die sie für notwendig halten, und sehen keine Notwendigkeit, zusätzliche Arbeit zu leisten.

Ich habe ein paar Fragen:

1. Welche Folgen haben die Terminverschiebungen und die technische Schuld der QS? Haben Sie die Auswirkungen dieses Problems auf die endgültigen Fristen bewertet?
2. Welches Feedback erhalten Sie von Ihren Stakeholdern? Sind sie zufrieden? Sind sie über verspätete Fristen verärgert genug, dass sie Änderungen unterstützen? Werden sie diese Unterstützung dem direkten Vorgesetzten mitteilen?

Wenn ich an Ihrer Stelle wäre, würde ich zuerst die Folgen abschätzen und sicherstellen, dass die Beteiligten genug Schmerz empfinden, um einige Änderungen zu unterstützen. (wenn nicht, dann müssen wir ein anderes Problem besprechen).

Dann würde ich anfangen, technische Schulden zu messen. Auf einem durchschnittlichen Zettel rutschen wir x QA-Aufgaben; die durchschnittliche QA-Aufgabe dauert X Stunden zur Lösung. Erstellen Sie wöchentlich/monatlich/(Zeitraum, der Ihren Sprints entspricht) eine Metrik, die Stakeholder/das Linienmanagement auf dieser Metrik aufsetzt.

Jetzt müssen wir die Einstellung der Entwickler und der Tester ändern. Sie arbeiten nicht als Team zusammen. Zuerst müssen wir sicherstellen, dass wir, der PM, für Motivation/Führung gesorgt haben. Haben wir den Wert der Teamarbeit kommuniziert? Gibt es Anreize für Teamplay?

QA muss ihre Einstellung ändern. QA mag die Hilfe, die Entwickler bieten, nicht; Das ist in Ordnung, bringen Sie ihnen entweder bei, wie sie hilfreiche Hilfe leisten können, oder sagen Sie dem PM, dass er sie schulen soll, damit sie hilfreiche Hilfe leisten können. Fragen Sie die QA, ob der Wechsel zur testgetriebenen Entwicklung hilfreich wäre? QA hat anscheinend einige Prozesse, die verbessert werden müssen. Ziehen Sie eine QA und ein paar Entwickler offline und bitten Sie sie, den QA-Prozess so umzugestalten, dass er (a) schneller ist (b) eine effektive Teamarbeit erleichtert und (c) effektiver ist. Fragen Sie die Entwickler, mit welcher QA-Person war die Zusammenarbeit am einfachsten? Welche QA hat das beste Code-Fu? Diese Person verfügt über Fähigkeiten, die auf den Rest des Teams übertragen werden müssen.

Entwickler wollen keine Qualitätssicherung durchführen? Das ist gut. Arbeiten Sie mit dem direkten Vorgesetzten zusammen, um Entwickler zu finden, die über die richtigen Fähigkeiten verfügen und als Mitglied eines Teams arbeiten möchten. Fragen Sie die QA-Abteilung: „Wer war der hilfreichste Entwickler in diesem Sprint?“ PM kann diese Person erkennen und sicherstellen, dass das Linienmanagement weiß, dass Sie diese Person als Teamplayer schätzen und diese Person für zukünftige Projekte verwenden wird. Das Verhalten dieses Entwicklers hängt direkt mit der Fähigkeit Ihres Projekts zusammen, Fristen einzuhalten und innerhalb des Zeitplans/Umfangs/der Qualität zu bleiben.

Letztendlich ist das einzige Werkzeug, das Sie haben, der Wunsch Ihrer Stakeholder, die Frist einzuhalten. Verspätete Fristen bereiten den Beteiligten Schmerzen; Ihre Aufgabe ist es, diesen Schmerz so umzuleiten, dass Veränderungen motiviert werden.

Nach dem, was Sie gesagt haben, haben Sie ein erhebliches Problem, das Änderungen an Motivation, Fähigkeiten und Prozessen erfordert. Die besonderen Details Ihrer Situation werden diese Änderungen um mindestens eine Größenordnung schwieriger machen als das, was ich oben munter beschrieben habe. Wenn es so einfach wäre, würden Sie den Mindestlohn verdienen.

Stellen Sie sicher, dass Ihre Stakeholder wissen, dass es ein Problem gibt, dass Sie Maßnahmen ergreifen, um es zu lösen, und dass Sie nicht erwarten, dass das Problem in diesem oder im nächsten Sprint gelöst wird. Das Beste, was Sie ihnen versprechen können, ist, dass sich die Wachstumsrate der technischen Schulden in jedem Sprint um x % verlangsamen wird.

Das direkteste Ergebnis davon ist, dass die QA ständig hinterherhinkt. Wenn wir einen Sprint starten, sind bereits mehrere Elemente für die QA bereit. Während sie an diesen Elementen arbeiten, stapeln sich die Dinge weiter und am Ende des Sprints haben wir eine riesige Menge von Elementen in der QA und Entwickler sagen, dass sie nichts zu tun haben. Wenn Elemente in einem Sprint nicht fertig werden, kommt natürlich der nächste Sprint und das Problem wird immer schlimmer, da die QA nicht mithalten kann.

Eine andere Möglichkeit, dies zu betrachten, ist, dass Ihre Entwickler ständig einen Schritt voraus sind. In beiden Fällen sind Sie in Bezug auf Entwickler überbesetzt und/oder in Bezug auf QA unterbesetzt.

Sie können dies beheben, indem Sie die Ressourcenebenen ändern. Sprechen Sie mit Ihrem Projektsponsor und finden Sie heraus, wie wichtig der Gesamtzeitplan des Projekts aus geschäftlicher Sicht ist. Holen Sie auf dieser Grundlage die Zustimmung Ihres Sponsors ein, um entweder:

• Bieten Sie Ihnen zusätzliche QA-Ressourcen, damit Sie Ihr aktuelles Tempo beibehalten oder verbessern können, indem Sie der QA helfen, mit den Entwicklern Schritt zu halten; oder
• Setzen Sie die überschüssigen Entwickler auf andere Projekte um, damit Ihre QA mit Ihren Entwicklern Schritt halten kann, obwohl das Risiko besteht, dass Ihr Projekt länger dauert, bis es fertig ist.

Leider stehen Sie vor einem der Bugs in Scrum. Standardmäßig wird davon ausgegangen, dass Menschen unabhängig von ihren früheren Rollen oder Ambitionen gerne zusammenarbeiten und diese gerne für das Allgemeinwohl aufgeben. Ich bin mir nicht sicher, ob es eine generische Lösung gibt, aber hier sind einige Ideen:

Wenn Sie Scrum beibehalten möchten

1. Höchstwahrscheinlich hat das Team einige Probleme damit, die Grundprinzipien von Scrum zu verstehen. Die empfohlene Lösung besteht darin, das Team zu coachen und geduldig zu sein und vorübergehend zu versuchen, mit der aktuellen Situation zu leben, bis diese Prinzipien verstanden werden.

2. Es besteht eine gute Chance, dass die Entwickler schneller sind als die Tester, sodass Sie die unnötigen Tester entfernen und an anderer Stelle verwenden oder zwei Teams aus dem aktuellen Team erstellen können. Mit diesem Ansatz schaffen Sie einen künstlichen Engpass – die Anzahl der Tester – der Ihnen mehr Informationen über die Situation liefert.

3. Sprechen Sie mit Ihrem Scrum Master, denn sie ist diejenige, die dieses Problem eskalieren und versuchen sollte, Lösungen zu finden und das Scrum Team zu coachen. Irgendetwas stimmt hier nicht.

Wenn Sie etwas anderes als Scrum wollen

1. Ich habe Setups gesehen, in denen es zwei verschobene Iterationen gab: eine Iteration zum Entwickeln und Testen und eine nur zum Testen – diese begann später. Die Idee war, dass die Entwickler sich überlasten und mehr Arbeit leisten, als sie in einer Iteration testen können, und die zusätzliche Arbeit in der Test-Iteration getestet wurde. Das war keine optimale Lösung, aber jeder bekam etwas zu tun und das/die Team(s) lieferten – die vollständig getesteten User Stories wurden dem Product Owner vorgeführt.

2. Sie können anfangen, etwas mehr über Scrumban zu lernen und langsam von einem iterationsbasierten Ansatz zu einem kontinuierlichen Ansatz wie XP + Kanban wechseln.

Es gibt bereits eine ausgezeichnete Antwort von Mark C. Wallace, aber ich dachte, ich würde noch etwas hinzufügen.

Versuchen Sie, das System ein wenig auszubalancieren, indem Sie Work-in-Progress-Limits verwenden.

Im Moment produziert der Entwickler Arbeit schneller, als die QA sie testen kann. Versuchen Sie, ein Work-in-Progress-Limit für den Entwicklungsprozess festzulegen, das die Arbeit in einer Rate in die QA einspeist, die sie abschließen können. Sie vermeiden, dass in Ihrer QA-Phase eine Menge Arbeit gesichert wird. Sie können dem QA-Schritt auch ein Work-in-Progress-Limit hinzufügen, damit klar ist, wann die QA überlastet ist.

Wenn Sie beispielsweise 4 Entwicklerpaare haben, versuchen Sie, ein Work-in-Progress-Limit von 3 für den Entwicklungsschritt und ein Work-in-Progress-Limit von 2 für den QA-Schritt festzulegen (1 wird bearbeitet, 1 in der Warteschlange).

Dies bedeutet, dass Ihre Entwickler weniger Zeit haben, da nur 3 Paare gleichzeitig an der Entwicklung arbeiten können. Dies mag wie eine schlechte Idee erscheinen, aber es ist im Allgemeinen besser, im System Puffer zu lassen, anstatt weiterhin Arbeit zu produzieren, die dann nicht durch nachgelagerte Schritte aufrechterhalten werden kann.

Die Entwickler in der Pufferzeit könnten sich Dinge wie das Entfernen von technischen Schulden, Spitzen, Live-Support, Analysen zu bevorstehenden Geschichten usw. ansehen, die immer noch produktiv sind, aber den QA-Schritt nicht verstopfen.

Indem ich sie zwinge, nichts zu tun, um zum Sprint beizutragen, während ihre Kollegen alle ihre Sprichwörter abarbeiten, um Geschichten zu vervollständigen, würde ich hoffen, dass ihre berufliche Integrität sie dazu ermutigen würde, bei einigen Tests mitzuhelfen!

Eine ausgezeichnete Reihe von Antworten bisher. Ich möchte nur das hinzufügen:

Ich empfehle das Buch Wie Google Software testet . Dieses Zitat fasst ihr Ziel zusammen, Entwicklung und Qualitätssicherung in Einklang zu bringen:

Qualität ist nicht gleich Test. Qualität wird erreicht, indem Entwicklung und Test in einen Mixer gegeben und gemischt werden, bis sie nicht mehr voneinander zu unterscheiden sind.

Dies ist meine Erfahrung. In meiner Rolle bei YouView, wo wir die Benutzeroberfläche für eine Set-Top-Box erstellten, hatten wir ein hervorragendes Testteam, aber bis wir sie zu einem Teil des Entwicklungsteams machten; Wir arbeiteten mit ihnen in Spezifikations-Workshops , bevor die Entwicklung begann, und stellten ihnen früh und oft Funktionen zur Verfügung, um Feedback zu erhalten. Wir hatten eine ähnlich dysfunktionale Beziehung wie die von Ihnen beschriebene.

Die richtige Zusammenarbeit zwischen Entwicklern und Testern herzustellen, war meiner Erfahrung nach von grundlegender Bedeutung, um die Qualität der produzierten Software zu steigern.

Ich frage mich, wie ausgeklügelt Ihre automatisierten Testeinrichtungen sind. Wenn auch nicht besonders gut, dann kann es einen echten Vorteil bringen, Zeit und Mühe in diesen Bereich zu investieren, da sich die Amortisation schnell und beträchtlich einstellen wird. Sie weisen in einem Ihrer Kommentare darauf hin, dass Sie vor jeder Veröffentlichung eine einmonatige Regressionstestphase haben: Das klingt in der Tat sehr bedeutend, und obwohl ich Ihre Umgebung nicht kenne, scheint es, dass dies durch eine aggressive Automatisierung Ihres Tests reduziert werden könnte Zyklen, würden Sie echte Vorteile ernten.

In seinem Buch „Agiles Projektmanagement“ spricht Jim Highsmith viel über „rücksichtsloses automatisiertes Testen“ und stellt fest: „Die Erfahrung hat gezeigt, dass der größte Unterschied zwischen reifen und unreifen agilen Teams in ihrem Engagement für rücksichtsloses automatisiertes Testen liegt“. Sie stimmen vielleicht nicht ganz zu, aber es lohnt sich, die Auswirkungen dieser Aussage zu berücksichtigen.

Ein weiteres Thema aus demselben Buch bezieht sich darauf, die richtigen Leute zu finden. Das ist schwer zu sagen und noch schwerer umzusetzen, aber Sie scheinen einige Probleme mit Ihren Leuten zu haben. Vielleicht ist das ein weiterer Schlüsselbereich, auf den man sich zumindest kurzfristig konzentrieren sollte.

Viel Glück...

Ich denke, Sie werden feststellen, dass dies ein strukturelles Problem ist und nicht mit der individuellen Einstellung oder dem Verständnis von Scrum zusammenhängt. Wann immer ich Entwickler getroffen habe, die keine Tests durchführen, Tester, die den Code auf einer Platte erhalten möchten und so weiter, dann deshalb, weil sie tun, was ihnen gesagt wird oder was durch die Umstände ihrer Beschäftigung impliziert wird.

Wenn Entwickler nicht testen möchten, kann es an ihrem Vorgesetzten oder der Unternehmenskultur liegen. „Entwickler kosten mehr als Tester, also sollten sie entwickeln und nicht testen.“ Ich habe dies von den Entwicklern selbst, von ihrem Manager, von Projektmanagern und von leitenden Angestellten gehört. "QA ist letztendlich für die Qualität verantwortlich." Ich habe dies von Testern, ihrem Vorgesetzten, Projektmanagern und leitenden Angestellten gehört.

Bis sich die Führungsebene Ihrer Entwicklungsorganisation (und höher) zu einer teamorientierten Organisation bekennen kann, werden Sie diesen Kampf führen.

In Ihrem Fall scheinen die Personalchefs verständnisvoll zu sein. In diesem Fall würde ich vorschlagen, ihre Unterstützung zu testen … sie zu bitten, die Erwartungen aller Mitarbeiter auf eine teamorientiertere Zusammenarbeit anstatt auf die individuelle Rollenerfüllung umzustellen. Sie können die Erwartungen aufschlüsseln, und sie verkaufen es. Oder wenn nicht, sind Sie der Ursache des Problems näher gekommen und haben möglicherweise andere Ressourcen zur Verfügung, um es dort anzugehen.

Google testet die Art und Weise, wie sie es tun, weil ihre Kultur die Agilität von oben nach unten stärkt. Die meisten Geschäfte, in denen ich gearbeitet oder gecoacht habe, haben diesen Luxus nicht – am Ende bringen wir Agilität in die Organisation. Es ist langsam, aber manchmal funktioniert es.

Wie mein eigener Trainer Richard Lawrence gesagt hat: Versuchen Sie zuerst, den Meilenstein zu erreichen, an dem das Team konsequent das liefert, wozu es sich verpflichtet. Dann baue darauf auf. Ich werde hinzufügen, dass es eine ganze Weile dauern kann, bis man überhaupt dort ankommt.