Das Scrum-Team
- 3 x Entwickler
- 2 x Tester
- 1 x Automatisierungstest-Analyst
Wir sind kein multifunktionales Team, da die Entwickler nicht testen und die Tester nicht entwickeln. Ich glaube, dies ist die Hauptursache des Problems.
Wir machen derzeit zweiwöchige Sprints.
Zu Beginn des Sprints sind alle beschäftigt, die Entwickler beginnen mit der Entwicklungsarbeit und die Tester bereiten ihre Tests vor (Schreiben von Testfällen usw.).
Sobald die Tester ihre Vorbereitung abgeschlossen haben, warten sie nun auf den Abschluss der Entwicklungsarbeiten ODER die Entwicklungsarbeiten sind abgeschlossen und die Entwickler warten auf Feedback / Fehler.
Die Entwickler bekommen hier juckende Füße und beginnen mit der Arbeit an Elementen im Backlog, die außerhalb des aktuellen Sprints liegen. Dies hat einen seltsamen Effekt erzeugt, bei dem wir immer die nächsten Sprints im aktuellen Sprint entwickeln. Für mich fühlt sich das nicht richtig an.
Aus Sicht des Managements möchten die Entwickler lieber arbeiten, als an ihren Schreibtischen zu sitzen und nichts zu tun. Gleichzeitig denke ich, dass das Ziel und der Fokus des Scrum-Teams ausschließlich auf dem aktuellen Sprint liegen sollten. Ich wünschte, unser Team wäre multifunktional, aber leider nicht erreichbar. Die Tester verfügen nicht über die erforderlichen Fähigkeiten, um Entwicklungsarbeit zu leisten, und die Mehrheit der Entwickler ist der Meinung, dass das Testen unter ihnen liegt.
Wird dies als Problem bei Scrum angesehen? Gibt es eine Lösung dafür? Funktioniert Scrum nur mit multifunktionalen Teams?
Ich würde gerne die Erfahrungen anderer Leute damit erfahren, wenn möglich :)
Antworten:
Das ist ein ziemlich häufiges Problem, das durch Pipelining verursacht wird . Das Team ist multifunktional, aber natürlich gibt es interne Silos, die die Leistung beeinträchtigen.
Zunächst möchte ich einige Dinge erwähnen, die ich für wichtig halte:
Wenn Ihre Entwickler im Voraus eine Iteration durchführen, bereiten sie Ihr Planungsmeeting vor. Ihr Produktmanager und das Team müssen besprechen, was für die nächste Iteration am wertvollsten ist. Die Priorisierung sollte von Entwicklern nicht effektiv durchgeführt werden, da sie nichts Besseres zu tun haben.
Unabhängig davon, wie Sie die Iterationen aufteilen und anordnen, können Sie nicht immer alle beschäftigen und ein einziges Team mit einem einzigen Planungsmeeting haben, solange in Ihrem Team Spezialisten für Silos arbeiten. Selbst bei einem reinen Wasserfall-Ansatz müssten Sie immer noch "Sachen über die Mauer werfen" und auf Feedback warten.
Sie haben auch das Problem, dass eine einzelne Story häufig eine Entwicklungsphase haben muss, gefolgt von einer Testphase, gefolgt von einer Fehlerbehebungsphase, gefolgt von ... Dies kann Ihr Team wirklich ineffizient machen - insbesondere, wenn sie im Voraus arbeiten , weil sie den Kontext wechseln müssen.
Diese Situation ist eindeutig mit sehr realen Kosten verbunden: Das Team arbeitet nicht zusammen. Ich habe dies jedes Mal erlebt, wenn ein QS-Team beteiligt war, daher hatte ich etwas Zeit, um verschiedene Lösungen zu experimentieren.
Was für mich sehr gut funktioniert hat, sind diese beiden Tools:
Betonen Sie das Prinzip, dass das gesamte Team für die Erledigung der Aufgaben verantwortlich ist. Verweigern Sie "dev done" -Geschichten, da sie eine Möglichkeit für Entwickler sind, "nicht mehr mein Problem" zu sagen, was sowohl nicht konstruktiv als auch offensichtlich falsch ist. Wenn ein Team keine Geschichte liefert, die es akzeptiert hat, ist es das gesamte Team, das nicht geliefert hat.
Um die Zeit der beiden Entwickler und QA zu besetzen, paaren sie . Dies ist bei weitem die beste Möglichkeit, Fachwissen und Domänenwissen auszutauschen, die Sie auswählen können. Entwickler können Testern helfen, ihre Aufgaben zu automatisieren. Tester können Entwicklern zeigen, wo es wichtig ist, den Code zu testen, da er spröde ist. Beide arbeiten zusammen und arbeiten schneller als nicht.
Mit diesen beiden Techniken sollte das Team weniger dumm und leistungsfähiger werden. Während es sehr unwahrscheinlich ist, dass Tester und Entwickler Jobs austauschen können, können sie als Team arbeiten und das Problem intern lösen, anstatt sich gegenseitig die Schuld zu geben.
quelle
Es gibt kein Problem mit Ihrer Arbeitsweise in Bezug auf SCRUM und Sprints, vorausgesetzt, es wird zum Zeitpunkt der Evaluierung aufgezeichnet, dass die Entwicklerarbeit in kürzerer Zeit (und wie viel weniger Zeit) als geplant abgeschlossen wurde. Auf diese Weise kann das Team mehr Story-Punkte für den nächsten Sprint sammeln. Bei Sprints geht es schließlich darum, die Planung zu verbessern. Offensichtlich haben Sie noch Raum für Verbesserungen.
Whoa! Dies ist in Scrum technisch nicht möglich. Sie wissen nicht, welche Backlog-Elemente im nächsten Sprint vorhanden sein werden, dh zu Beginn des nächsten Sprints in einer Sprint-Planungssitzung.
Es bleibt interessant zu erfahren, wie Unternehmen Scrum sabotieren können.
quelle
Scrum optimiert für das Team , nicht für den Einzelnen. Der springende Punkt ist, dass das Team effizient wird. Wenn Entwickler anfangen, an Dingen außerhalb des aktuellen Sprints zu arbeiten, tun sie dem Team einen schlechten Dienst. Es zeigt auch, dass Sie bei Ihrem Planungsprozess etwas versagen, wenn Sie nicht genügend Arbeit einplanen, um die Feder zu füllen.
Wenn Entwickler keine Entwicklungsaufgaben mehr haben, sollten sie unbedingt die Tester, die technischen Redakteure oder die Designer unterstützen - jeden im Team. Sie müssen nicht unbedingt tatsächliche Tests schreiben ( sollten sie aber ), können aber trotzdem am Testprozess teilnehmen. Sie können Skripte schreiben, die den Testern helfen, effizienter zu sein, oder sie können einfach mit den Testern diskutieren, was ihre Herausforderungen sind, und ihnen dabei helfen, diese Herausforderungen zu bewältigen (z. B. Hinzufügen von ID-Attributen zu Webseitenelementen, Bereitstellen von Hooks oder APIs, die die Tester bereitstellen können in ihren Tests usw. verwenden).
Ich denke, das Herzstück des Problems ist, dass Ihre Entwickler, wenn sie nicht immer am aktuellen Sprint arbeiten, noch nicht als Team arbeiten. Ihr Scrum Master sollte dies zur Kenntnis nehmen und darauf hinarbeiten, dass das Team als Einheit und nicht als Ansammlung von Personen arbeitet.
Ich schlage auch vor, dass dies ein Managementproblem ist. Wenn sie Druck auf Entwickler ausüben, um beschäftigt zu bleiben, haben sie Scrum nicht vollständig angenommen. Dies ist eine weitere Sache, bei der der Scrum Master helfen kann. Sie können mit dem Management zusammenarbeiten, um zu verstehen, wie Scrum funktioniert, damit sie die Entwicklungsteams unterstützen und ermutigen können, anstatt sie zu untergraben.
quelle
Ich denke, das Hauptproblem hier ist das Folgende:
Wir haben dies in unserem Unternehmen so gehandhabt, dass wir die Entwickler gefragt haben, wie sie sagen können, dass sie ihre Arbeit tatsächlich beendet haben, wenn sie es nicht beweisen können. Der einzige Weg, dies zu beweisen, besteht natürlich darin, zu demonstrieren, dass der von ihnen geschriebene Code tatsächlich funktioniert, und dies geschieht durch Testen. Sie sollten darauf hingewiesen werden, dass die Tests schneller durchgeführt werden, wenn sie der Teilnahme an Tests zustimmen, und dass sie mehr Zeit haben, zusätzliche Funktionen zu codieren (die ebenfalls getestet werden müssen).
Stellen Sie sicher, dass das Testen Ihres Codes nicht unter der Entwicklerebene liegt. Es ist ein wesentlicher Bestandteil des Entwicklungsprozesses. Es kann nicht nur von der Codierung getrennt werden. Jeder kann codieren. Nicht jeder kann codieren und beweisen, dass das, was er codiert hat, tatsächlich funktioniert.
Eine andere Möglichkeit, die Entwickler zu beschäftigen, besteht darin, sie an der Codierung automatisierter Tests für die Funktionen zu arbeiten, die sie im Sprint entwickelt haben. Diese Tests könnten dann für Regressionstests verwendet werden, die regelmäßig ausgeführt werden.
In jedem Fall ist es ein großes Nein-Nein, etwas zu tun, das zu Beginn des Sprints nicht geplant war. Es ist besser, nichts zu tun, als etwas zu tun, das nicht geplant war. Die Funktionalität, die sie in diesen Fällen schreiben, erfüllt höchstwahrscheinlich nicht die DoD-Kriterien (Definition of Done), da sie wahrscheinlich nicht gut getestet wird, da die Tester damit beschäftigt waren, das zu testen, was ursprünglich geplant war. Dies ist ein sicherer Weg, um Fehler einzuführen und die Qualität des Produkts zu verschlechtern, was das Team dann in eine Abwärtsspirale von Regressionsproblemen und Kontextwechsel versetzt, was zu Stress, verringerter Geschwindigkeit und schließlich zum Verlassen des Teams führt.
quelle
Theoretisch sollten alle Mitglieder eines SCRUM-Teams das gleiche Wissen haben, damit jedes Mitglied jede Aufgabe von jedem anderen Mitglied übernehmen kann. Wenn nicht, sollten Sie das Wissen verbreiten.
In der Praxis gibt es jedoch immer eine Spezialisierung. Die Software kann komplex sein, das Teammitglied verfügt über unterschiedliche Fähigkeiten usw. Die Aufteilung des Teams in Entwickler und Tester ist nur ein (sehr häufiges) Beispiel für Spezialisierung.
Die Verbreitung des Wissens kann länger dauern, als das Management akzeptieren möchte.
Nach meiner Erfahrung können Sie verschiedene Dinge tun:
Diese Vorschläge sind möglicherweise keine 100% SCRUM-Theorie, aber zuerst müssen Sie die Entwicklung fortsetzen. SCRUM ist nur eine Toolbox.
quelle
Es scheint, dass Sie Ihr Team desychronisieren müssen. So wie das:
Wenn ich die Testautomatisierung verstanden habe, müssen die Jungs ein paar Tage früher beginnen.
Aber ich spüre ein Problem in Ihrem Team: Ich habe ein Problem mit Entwicklern, die ihren eigenen Code nicht testen. Wenn die Testmitarbeiter den Test vorbereiten, ohne den Code zu überprüfen, führen sie wahrscheinlich nur Blackbox-Tests durch, bei denen die Entscheidungspunkte des entwickelten Programms nicht berücksichtigt werden. Sie sind mit der Qualität Ihrer Software zufrieden?
quelle