Wir sind ein kleines Start-up, das schnell wächst.
Wir haben 4 Abteilungen: (Backend-Entwickler [2 Personen], Frontend-Entwickler [2 Personen], QA [2 Personen] und ein Systemadministrator)
Bevor wir die Scrum-Methodik verwendeten, hatten wir keine klare Vorstellung von unserem Fortschritt, woran andere arbeiten usw. Jetzt haben wir dieses Problem bestanden, aber wir stehen jetzt vor einem großen Problem; Es scheint, dass das Team mit der aktuellen Methodik nicht konform ist.
Um Ihnen einen klaren Überblick über unseren Fall zu geben, gehen wir wie folgt vor, um ein Projekt abzuwickeln:
Wir haben ein Backlog-Meeting mit dem Product Owner. Das Team definiert den Release-Backlog in einem anderen Meeting (basierend auf der vom Product Owner festgelegten Priorität). Jede Abteilung schneidet den Release-Backlog und listet alle Aufgaben auf, die bis zum nächsten Sprint erledigt werden müssen. Beispielsweise beginnt die Backend-Gruppe mit der Arbeit an einer API, das Frontend befasst sich mit Designern und stellt die fertigen Vorlagen bereit, das QA-Team liest und versteht Geschichten, und Systemadministratoren müssen die nächste Priorität gemäß dem aktuellen Projekt definieren.
Jede Abteilung erstellt ihren eigenen Sprint. (Es ist komisch, ich weiß :s) und am Ende haben wir 5 Sprints. (Der 5. ist für Arbeitgeber. Nun, sie wollen Teil der Methodik sein, lol.)
Bevor wir Scrum verwenden, haben wir einen Zyklus von zwei Wochen eingehalten, und nach der Implementierung von Scrum schlägt der Projektmanager vor, dass Sprints in zwei Wochen durchgeführt werden müssen. Wir haben jedoch gerade festgestellt, dass ein Sprint mehr :s dauern kann.
In Bezug auf unseren Fall kommt mir eine Liste von Fragen in den Sinn.
Passen QA, Backend, Frontend und Systemadministration in die Scrum-Methodik? Was können wir tun, wenn QA und Systemadministration tägliche Aufgaben haben? Können wir statt 5 nur einen Sprint verwenden?
Im traditionellen Scrum werden alle diese Rollen als Teil desselben Scrum-Teams betrachtet. Release-Backlog-Elemente werden in das Sprint-Backlog verschoben, wenn sie vom gesamten Team zugesagt werden (unabhängig davon, welche Funktion die einzelnen Teammitglieder haben) und dann (wiederum vom gesamten Team) beauftragt werden.
Der Grund, warum Scrum normalerweise die Funktionsbereiche des Teams nicht trennt, ist 1) nur weil Sie QA sind, bedeutet das nicht, dass Sie nichts zu Entwicklerdiskussionen beitragen können und 2) Sie arbeiten alle am selben Produkt und sollte eine gewisse Ansicht/Eingabe zum Produkt als Ganzes haben, damit Sie alle Konflikte zwischen Funktionsbereichen erkennen können. Ihre Front-End-Entwickler müssen zum Beispiel wissen, was Ihre Back-End-Entwickler tun und umgekehrt.
Wo die funktionalen Bereiche wirklich ins Spiel kommen, sind Teammitglieder, die Gegenstände aus Ihrer „Nicht begonnen“-Leiste Ihrer Kartenwand ziehen. Wenn ich ein QA-Typ bin, werde ich zuerst Aufgaben ziehen, an denen ich arbeiten kann, die QA-spezifisch sind. Wenn ich ein Front-End-Entwickler bin, werde ich Aufgaben ziehen, an denen ich arbeiten kann, die sich auf die Benutzeroberfläche beziehen. Es ist Sache des einzelnen Teammitglieds, an Elementen zu arbeiten, die mit seinem Funktionsbereich zusammenhängen.
Als nächstes kommt immer die Frage - Was ist, wenn es keine Aufgaben mehr für meinen Funktionsbereich gibt? Die Antwort ist - probieren Sie etwas anderes aus. Wenn niemand daran arbeitet, schadet es nicht, wenn Sie es versuchen. Dadurch erhalten Sie nicht nur einen Einblick in die Funktionsweise der anderen Funktionsbereiche, sondern auch in die Funktionsweise Ihres Produkts in Bereichen, die Sie möglicherweise nicht regelmäßig sehen. Sie können die Aufgabe später jederzeit an jemanden aus diesem Funktionsbereich übergeben (wenn verfügbar) und Sie haben etwas aus der Erfahrung gelernt.
Das ist traditionelles Gedränge, so wurde die Frage formuliert. Wenn Sie nach Ratschlägen speziell für Ihr Szenario suchen, ist dies eine ganz andere Diskussion, bei der es um die Gründe geht, warum Sie die Dinge so tun, wie Sie es tun.
Der Wechsel zu Scrum ist schwierig, da es nicht so einfach ist, wie ein Team zu haben. Der schwierige Teil besteht darin, die Teammitglieder dazu zu bringen, als eine Einheit (ein Team) zusammenzuarbeiten und die alten Gewohnheiten der Isolation zu durchbrechen. Viel leichter gesagt als tatsächlich getan.
Das ist der Hauptgrund, warum wir kurze Sprints und eine Retrospektive haben, die es dem Team ermöglichen, ihre Zusammenarbeit zu überprüfen und nach Verbesserungsmöglichkeiten zu suchen. Der Scrum Master sollte nach diesen Verhaltensproblemen Ausschau halten und sie im Nachhinein ansprechen und das Team fragen, wie sie ihre Arbeitsweise ändern werden.
Dies sind einige, aber alles häufige Probleme, die ich bei neuen Teams sehe; sie können auf Sie zutreffen oder auch nicht.
Das Team denkt als Berufsbezeichnung und nicht als gemeinsame Verantwortung für die Erledigung
Es gibt keine klare Definition von erledigt, die die Qualität bestimmt
Teams organisieren sich nicht selbst und Scrum Master oder Manager versuchen immer noch , das Team zu kontrollieren .
Teams lernen nicht zu prüfen und anzupassen, sondern umkreisen einfach die gleichen Probleme
Die Tester glauben, dass sie die einzigen sind, die für die Qualitätskontrolle verantwortlich sind
Scrum Master suchen nicht nach Schwächen und Verbesserungsmöglichkeiten und präsentieren sie dann dem Team; Fragen Sie das Team, wie sie es beheben werden
Teammitgliedern wurde Scrum nicht erklärt
In vielen Unternehmen ist die Werkzeugausstattung oft schlecht, was die Fähigkeit der Teams behindert, bewährte Verfahren zu übernehmen
Anfangs wird Scrum viele Probleme hervorheben, aber viele werden ignoriert
Scrum-Rookie-Master erkennen den Unterschied zwischen guten und schlechten Änderungen nicht, da sie die harten Lektionen nicht gelernt haben.
Um Scrum in ein Unternehmen einzuführen, ist ein starkes Coaching durch qualifizierte und erfahrene Fachleute erforderlich. Organisatorische Veränderungen sind etwas anderes und sollten nicht ohne die richtige Erfahrung durchgeführt werden.
Das Hauptkonzept hinter Scrum besteht darin, alle (DB, UI, Dev, QA) zusammenzubringen. Dies wirkt Wunder, da der Entwickler jetzt weiß, mit welchen Problemen die QA während des Testens konfrontiert ist, und aufmerksamer auf die Probleme achtet, die sie normalerweise vor der Übergabe an die QA ignorieren würden. In ähnlicher Weise wüsste die QA, wie die Entwicklung Tag für Tag funktioniert, und würde helfen. Dies ergibt sich aus dem Prinzip der gemeinsamen Verantwortung von Scrum. Für die Lieferung ist das gesamte Team verantwortlich. Ich kann nicht sagen, dass die Lieferung fehlgeschlagen ist, da der Dev zu spät fertig war oder die QA nicht rechtzeitig fertig war.
Jeder fängt an, darüber nachzudenken, welche Verbesserungen er am System vornehmen kann und die zum Erfolg des Teams beitragen. Wenn Sie alle Ihre Teams zusammenbringen, würden die Silos, die möglicherweise vorhanden sind, aufbrechen. Hier gibt es eine nette Preso über Team-Mentalität von Linda Rising .
Die Methodik, die Sie verwenden, heißt ScrumBut.
http://www.scrum.org/ScrumBut
Für mich ist es in Ordnung, Änderungen an Scrum vorzunehmen, um eine angenehmere Umgebung für das Team zu schaffen. Aber nachdem Sie diese Änderungen vorgenommen haben – nennen Sie es einfach nicht mehr Scrum.
Früher folgten wir bei unserem Projekt dem Scrum-Prozess. Die Erfahrung war schrecklich. Dann haben wir im Laufe eines Jahres viele Modifikationen vorgenommen. Wir haben noch Retrospektiven, (ad-hock) Planungsmeetings, zweiwöchige Sprints, kleinen Rückstand, Demo am Ende des Sprints. Wir messen keine Geschwindigkeit und wir haben zusätzliche Sprints für Regressionstests und Fehlerbehebung. Wir haben Demo und Retrospektive zusammen gemacht.
Als Tester habe ich keine Möglichkeit, tiefgreifende Tests für das Feature durchzuführen, das 2 Stunden vor der endgültigen Demo abgeschlossen wurde, also sage ich das beim Demo+Retrospective-Meeting. Normalerweise nehme ich diese Testtage vom nächsten Sprint.
Das ist kein Scrum, aber das funktioniert bei uns.
Ergänzend zu dem, was @NightMan und @Nikhil Gupta in ihren Antworten geschrieben haben: Es mag für Sie und Ihr Team sehr kontraintuitiv sein, aber bringen Sie sie alle als ein Team zusammen und arbeiten Sie an einem Sprint.
Ja, es wird am Anfang holprig sein, aber Sie werden ein Gefühl für gemeinsame Ziele entwickeln und vor allem werden Sie beginnen, Ihre Organisation zu verbessern.
Einige der Beispielbereiche, die sich ändern/verbessern werden:
Problem: Wir können dies nicht im selben Sprint tun, da wir 10 Minuten vor dem Ende des Sprints mit dem Codieren fertig sind . Lösung: Führen Sie die Testautomatisierung ein, Entwickler und Tester automatisieren von Anfang an beim Codieren bestimmter Backlog-Elemente auch das Testen , da es kaum eine Möglichkeit gibt, während des Sprints genügend Zeit zum Testen zu bekommen. Langfristig werden Sie einen enormen Produktivitätsvorteil daraus ziehen.
Problem: Wir können unseren DBA nicht als Teil des Scrum-Teams einsetzen, er/sie ist eine „geteilte Ressource“. Lösung: Beziehen Sie sie auch nur teilweise in das Team ein und lassen Sie sie sich mit anderen Teammitgliedern paaren. Mit der Zeit werden sie anfangen, einen Teil ihrer Fähigkeiten zu erwerben, und sich nicht mehr so sehr auf eine bestimmte Person verlassen.
Fazit ist: Holen Sie sie sich als ein Team, probieren Sie es aus und Sie werden überrascht sein, wie sehr Sie davon profitieren werden.
Ich habe schon früher sehr ähnliche Teams geleitet, und ich habe festgestellt, dass es unglaublich wichtig ist, dass alle Rollen im selben Team arbeiten.
Zunächst einmal denke ich, dass Sie auf jeden Fall ein einzelnes Team leiten sollten. Der Grund ist folgender: Ihre Teammitglieder arbeiten auf ein gemeinsames Ziel hin. Alles in Ihrer Teamstruktur sollte darauf hinarbeiten. Ein einzelnes Scrum-Team hat gemeinsame Verpflichtungen in seinen Sprintzielen, eine gemeinsame Frist, und sie müssen zusammenarbeiten, um dies zu erreichen. Wenn Sie künstliche Trennung hinzufügen, fordern Sie die Leute auf, das Schuldzuweisungsspiel zu spielen. Ich kann nicht zählen, wie oft ich Dinge gehört habe wie "Nun, es ist fertig, es wurde nur nicht getestet" oder "Wir konnten unsere Arbeit nicht erledigen, weil Bob krank war und den Server nicht eingerichtet hat." Sicher, Sie sind effizienter, wenn Sie die Leute sich auf ihr Fachgebiet konzentrieren lassen, aber wenn das gesamte Team gleichermaßen am Haken ist, um Ziele zu erreichen, stellen Sie fest, dass es da ist.
Zweitens denke ich, dass Sie viele Vorteile von Scrum verlieren werden. Um ein wenig in Ihren Fall hineinzulesen, erwähnen Sie, dass das BE-Team an der API arbeitet. Wenn dies isoliert vom FE-Team und der Geschäftsgruppe geschieht, wie wählen sie dann aus, was sie schreiben? Es kann sehr schwierig sein, nachzuweisen, dass sie am Ende jedes Sprints einen freisetzbaren Funktionssatz liefern, der dem Endkunden einen Mehrwert bietet. Das ist eine Situation, die ich zu oft gesehen habe. Auf die Frage, welchen Wert die Arbeit schafft, habe ich gehört: "Nun, im Moment noch keinen, aber im Juni, wenn alles andere erledigt ist, wird es ziemlich wichtig sein." Das ist großartig, solange wir bis Juni kommen. Ich war an einigen Projekten beteiligt, die vorzeitig abgebrochen wurden, und das Unternehmen war sehr frustriert, dass es die gesamte aufgewendete Projektzeit verschwendet und nichts davon bekommen hatte.
Ich hoffe das hilft.
Das klingt zu interessant.. Sie werden immer mit einigen Hindernissen konfrontiert sein, wenn Sie zu SCRUM migrieren.. Um das Problem zu lösen, mit dem Sie konfrontiert sind..
Shannon Davis
Luceo
Ravi Parek
Ravi Parek