Scrum - Entwickler, die außerhalb des Sprints arbeiten

11

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 :)

agile scrum

— fml
quelle

3

Ich stimme dem Management zu. Es ist eine schreckliche Idee, Leute wegen eines willkürlichen Zeitraums von zwei Wochen herumzusitzen. Vielleicht sind die Verantwortlichkeiten Ihres Teams zu streng. In so kleinen Teams ist es nicht ungewöhnlich, dass alle Teammitglieder "funktionsübergreifend" sind, sodass sie im aktuellen Sprint dort einspringen können, wo es nötig ist.

— Robert Harvey

... oder vielleicht setzen Sie nicht genug in Ihre Sprints ein, um das Team zwei Wochen lang zu beschäftigen.

— Blrfl

3

Ist ein Hybridpaar-Entwicklungs- / Test-Mashup praktisch? In gewissem Sinne ist der Prozess der gleiche wie der Einheitentestzyklus; schreibe ein wenig test ein wenig. Wir hatten dies formal nicht, aber die Tester pflegten direkt zu uns zu kommen, als ein oder zwei Fehler gefunden wurden. Wir haben nicht über formelle Fehlerberichte kommuniziert. Als "mein Tester" den Test beendet hatte, war die Reparatur abgeschlossen. Als Web-App wurde der Fix-Turnaround effizient. Aber zumindest experimentieren. Und ehrlich gesagt, selbst wenn es nicht besser oder schlechter ist, wird mgt weniger individuelle Wartezeiten wahrnehmen.

— Radarbob

3

Wird die ursprünglich für einen Sprint geplante Arbeit in der Regel mit ausreichender Qualität abgeschlossen? Oder bleiben Ihnen auch halbfertige Geschichten aus der ursprünglichen Planung?

— Bart van Ingen Schenau

2

Sie können Ihren Prozess einfach beibehalten, ihn aber "Kanban" anstelle von "Scrum" nennen, und dann müssen Sie sich keine Gedanken darüber machen, ob Ihr Prozess mit Scrum richtig ist. / etwas sarkastisch, aber nicht wirklich

— Eric King

16

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.

— Sklivvz
quelle

1

Vielen Dank für Ihre Antwort. Die Idee, Entwickler und QS-Ressource miteinander zu verbinden, gefällt mir sehr gut. Ich werde dies bei unserem nächsten Treffen vorschlagen und hoffe, dass wir dies im nächsten Sprint testen können. Ich werde die Frage aktualisieren und Sie wissen lassen, wie es geht!

— fml

@Sklivvz Dies passiert häufiger als nur, wenn es eine QS-Abteilung gibt. Es passiert jedes Mal, wenn die Qualitätssicherung eine Rolle ist, die nur "bestimmte Personen" übernehmen können. Anstatt dass die inaktive Ressource die "nächste" Aufgabe mit hoher Priorität übernimmt, wird der Entwickler inaktiv und nimmt dann mehr Arbeit auf, während die Qualitätssicherung ständig auf die Entwicklerausgabe reagiert.

— Edwin Buck

1

Wenn es oben nicht klar wäre, würde die "nächste Aufgabe mit hoher Priorität" den QS-Rückstand reduzieren, damit Artikel versendet werden können ", nicht die nächste Entwicklungsaufgabe mit hoher Priorität aus dem Rückstand.

— Edwin Buck

1

Ratschläge, wie das gesamte Team, sind verantwortlich, während sie gut klingen, dienen sie in Wirklichkeit nicht dem Team. Es deutet darauf hin, dass jeder austauschbar ist und dass nicht alle mitmachen. Das ist falsch. Jede Person im SDLC hat eine bestimmte Rolle und hat JAHRE damit verbracht, ihre Fähigkeiten zu verbessern. Das Bitten eines Softwareentwicklers zum Testen wirkt sich nachteilig auf die Qualität aus, da er nicht über die erforderliche Erfahrung verfügt, um die Qualität zu testen, und wahrscheinlich einen halbherzigen Versuch unternimmt. Selbst wenn der QS-Ingenieur sie betreut, würde das Mentoring einige Zeit von den Tests wegnehmen und die Arbeit noch länger dauern lassen.

— Chuck Conway

1

@CuckuckConway niemand schlägt vor, was Sie sagen. Pairing ist kein Ersatz oder Mentoring. Im Idealfall vertrauen Sie darauf, dass das Team den besten Weg findet, um Ausfallzeiten zu minimieren. Dies kann nur damit beginnen, dass die Mitarbeiter die Rollen und Bedürfnisse des anderen verstehen. Die besten und effizientesten Teams organisieren sich selbst (wahr oder nicht, es ist ein Grundprinzip der Agilität).

— Sklivvz

2

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.

Wir entwickeln immer die nächsten Sprints im aktuellen Sprint

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.

— Martin Maat
quelle

3

Das Problem mit Aussagen wie "Whoa! Dies ist in Scrum technisch nicht möglich" und "... neue kreative Wege, wie Organisationen Scrum sabotieren" ist, dass sie implizieren, dass es einen richtigen Weg gibt, "Scrum zu machen". Damit es einen richtigen Weg gibt, muss Scrum proskriptiv sein, dh Prozesse vor Menschen stellen. Scrum ist daher kein agiler Prozess, wenn es einen korrekten Weg gibt, Scrum durchzuführen.

— David Arno

@ David Arno Das ist schön, Sie sagen im Grunde, dass jede Methodik per Definition nicht agil ist. Sogar das agile Manifest. Nur ein unvorhersehbares Chaos wäre agil. Aber warte ... wer sagt mir, dass ich chaotisch sein soll? Jetzt ernst: Das agile Adagium "Menschen vor Prozessen" ist da, um Konflikte zu lösen. Wenn man sich entscheiden muss, sollte man tun, was Sinn macht, nicht unbedingt, was die Regeln sagen. Es scheint mir, dass das OP-Team ohne Probleme das Scrum-Buch lesen könnte. Und vielleicht tun sie es, die Schlüsselfrage scheint zu sein, wie transparent sie sind.

— Martin Maat

1

@DavidArno bedeutet eigentlich nur, dass es bestimmte falsche Methoden für Scrum gibt, und das scheint unumstritten. Zum Beispiel scheint alles, was dem Agilen Manifest widerspricht, objektiv falsch zu sein.

— Sklivvz

1

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.

— Bryan Oakley
quelle

0

Ich denke, das Hauptproblem hier ist das Folgende:

Die Mehrheit der Entwickler ist der Meinung, dass Tests unter ihnen liegen

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.

— Vladimir Stokic
quelle

Ich würde sagen, die Programmierer testen den Code, sie erstellen einfach keine automatisierten Tests. Es gibt einen großen Unterschied.

— JeffO

In diesem speziellen Fall bin ich bereit zu wetten, dass die einzigen Tests, die diese Programmierer durchführen, die von IDE sind. Nicht viele Entwickler bauen die Lösung tatsächlich in ein Installationspaket ein, stellen das Paket wie der Endbenutzer von Grund auf neu bereit und testen die Lösung dann tatsächlich. Dies reicht in den meisten Fällen nicht aus und ist ein Grund für eine erhebliche Qualitätsverschlechterung.

— Vladimir Stokic

0

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:

Mach das Team nicht zu klein. Wenn Sie zum Beispiel 4 Entwickler und 4 Tester haben, ist es viel einfacher, eine Aufgabe auf einen anderen Entwickler oder Tester zu verschieben, als nur 3/2 wie in diesem Beispiel.
Versuchen Sie, größere Aufgaben aufzuteilen. Wenn Sie kleinere Aufgaben haben, sind Sie flexibler.
Definieren Sie einige optionale Aufgaben, die ausgeführt werden können, wenn noch Zeit übrig ist.

Diese Vorschläge sind möglicherweise keine 100% SCRUM-Theorie, aber zuerst müssen Sie die Entwicklung fortsetzen. SCRUM ist nur eine Toolbox.

— Bernie
quelle

0

Es scheint, dass Sie Ihr Team desychronisieren müssen. So wie das:

   Test.   -------s1 -----------s2
   Dev.        --------s1 -----------s2

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?

— Lucas
quelle