Wie geht ein Scrum-Team mit traditionellen BA-Aufgaben um?

Verknüpfte Frage

Diese Frage wurde von den Teilnehmern der Diskussion der vorherigen, allgemeineren Frage vorgeschlagen .

Frage

Die Arbeit des Business-Analysten impliziert oft eine Art Wasserfall- oder Upfront-Design-Ansatz. Aus diesem Grund wird es meiner Meinung nach kontrovers diskutiert, wenn es im Kontext einer agilen Scrum-Umgebung betrachtet wird.

Wie geht ein Scrum-Team mit traditionellen BA-Aufgaben um?

Können Sie uns sagen, was Ihrer Meinung nach die „traditionellen BA-Aufgaben“ für Sie sind? Ich habe gerade eine Antwort geschrieben, aber dann wurde mir klar, dass ich vielleicht ganz andere Erwartungen an eine habe als Sie.
Ich möchte die Frage so allgemein wie möglich halten, damit viele verschiedene Ansätze erfasst und diskutiert werden können.
Ich stimme @Erik zu - wenn Sie nicht definieren, was "traditionelle BA-Verantwortlichkeiten" sind, ist diese Frage zu weit gefasst, um beantwortet zu werden. Verschiedene Organisationen haben unterschiedliche Definitionen dessen, was sie unter den Verantwortlichkeiten eines Business Analysten verstehen.
@ThomasOwens Die Frage wurde von einem Teilnehmer der Diskussion der verknüpften Frage vorgeschlagen, also richten wir Ihren Kommentar an ihn. Aber nichtsdestotrotz habe ich (in dieser Frage) das Hauptanliegen in Bezug auf die BAs beschrieben – sie müssen wasserfallartig arbeiten, was bedeutet, dass sie den Umfang und die Anforderungen analysieren müssen, BEVOR die Entwickler beginnen, an ihnen zu arbeiten.
Wenn ich an die Rolle eines Business Analysten denke, sehe ich keine Implikation eines „Wasserfall- oder Upfront-Design-Ansatzes“, weshalb es wichtig ist, dass Sie definieren müssen, was die „traditionellen BA-Verantwortlichkeiten“ sind und was „ die Arbeit des Business Analysten" ist.
@ThomasOwens Zum Beispiel muss in einem komplexen Bereich wie Fintech oder Bankwesen die Aufgabe klar zerlegt und klar definiert werden, bevor die Entwickler eine Aufgabe in der Entwicklung übernehmen können, und das tut BA oft VOR dem Sprint Planning Meeting – BA arbeitet im Voraus die Entwickler. Das ist es, was mit „Wasserfall-ish“ gemeint ist. Der BA und der Entwickler arbeiten während eines Sprints NICHT an denselben Aufgaben.
Eine klare Zerlegung der Arbeit und klare Arbeitseinheiten sind in vielen Branchen üblich und ich würde es als gute Praxis betrachten. In Scrum geschieht dies immer vor dem Sprint Planning in Verfeinerungsaktivitäten als Zusammenarbeit zwischen dem Product Owner und den Entwicklern. Nichts von dem, was Sie beschreiben, ist überhaupt "wasserfallartig".
@ThomasOwens Es ist die zugrunde liegende Annahme, dass Entwickler der Geschäftsanalyse nachgelagert sind und keine aktiven Mitarbeiter in diesem Prozess, die ich hier nur schwer vermitteln kann. Das ist der "wasserfallartige" Teil, auf den er sich bezieht.
@ToddA.Jacobs, eine solche Terminologie ist etwas verwirrend. Es ist eher "jeder-andere-ish", nicht "Wasserfall-ish" :) Nur Scrum besteht darauf, Meetings (einschließlich Verfeinerungen) mit dem gesamten Team abzuhalten. Der Rest der Methoden scheint sich nicht so sehr darum zu kümmern.
@StanislavBashkyrtsev Sie sehen ähnliche Ereignisse in DSDM, obwohl es mehr Rollen gibt, sodass Sie möglicherweise nicht alle Rollen in einem einzigen Ereignis haben, je nachdem, wie sich Ihre Rollen aufteilen. Extreme Programming hat auch das Whole-Team-Konzept. Es ist also nicht nur Scrum. Dies kommt im Agilen Manifest zum Ausdruck: Business people and developers must work together daily throughout the project.Das Ausmaß und die Häufigkeit der Zusammenarbeit verschiedener Rollen hängt von der spezifischen Methodik ab.
@Daniel, wenn eine der Anforderungen "kann nicht erlaubt sein, Dinge auf Scrum-Art zu tun" lautet, ist dies die einzige Antwort, die Sie erhalten. Allerdings ist eines der Projekte, an denen ich arbeite, in einem komplexen Fintech-ähnlichen Bereich, und wir zerlegen oder definieren Aufgaben nicht vor dem Sprint klar, wir tun dies während des Sprints.
@Erik Könnten Sie bitte den Arbeitsablauf Ihres Teams teilen? Was ist die Definition von „Bereit“ für Ihre User Storys und Aufgaben, die nicht klar definiert sind?
Unsere Definition von bereit ist mehr oder weniger "Wir haben eine gute Vorstellung davon, welches Problem Sie haben und wie wir es ungefähr lösen würden". Die meisten User Stories, die in den Sprint gehen, haben etwa 5 Zeilen Problembeschreibung und wurden eine halbe Stunde lang mit dem Team diskutiert. Das reicht aus, um zu wissen, ob wir das Problem innerhalb eines Sprints lösen können oder nicht. Von dort aus arbeiten wir eng mit dem PO zusammen, um dieses Problem zu lösen. Das bedeutet normalerweise, mit unserem BA-Typen über mögliche Lösungen zu diskutieren, einen Prototyp zu erstellen und ihn dann dem PO zu zeigen, während wir ihn bauen.
Wenn der PO der Meinung ist, dass es in die richtige Richtung geht, bauen wir es real aus und dann testet der PO die Funktion normalerweise selbst in einigen realen Szenarien oder sie beauftragt einen Stakeholder damit. Manchmal ziehen wir einen der Stakeholder der PO direkter in den Sprint und arbeiten mit ihnen zusammen, um das Ding mit echten Daten mit ihnen im Raum (oder unter Berücksichtigung der Umstände im digitalen Raum) zu bauen. Wenn wir mit einem Drittanbieter-Team zusammenarbeiten, versuchen wir, es während der Arbeit in Bereitschaft zu halten. Im Allgemeinen können wir aufgrund ihres Domänenwissens und ihres Verständnisses des Problems ohne formelle Dokumente arbeiten

Antworten (5)

Wie geht ein Scrum-Team mit traditionellen BA-Aufgaben um?

Ein erfahrener Analyst ist ein nützlicher Aktivposten für ein Scrum-Team.

Wie gut sie in einem Scrum-Team arbeiten, hängt vom Timing ab.

Die Herausforderung für den BA besteht darin, die Analyse so durchzuführen, dass das Team schnell auf Änderungen reagieren kann. Sie müssen vermeiden, das Team zu früh auf einen bestimmten Ansatz festzulegen. Sie müssen auch kurzfristig Stakeholder- und Kundenfeedback effektiv einbeziehen.

Es gibt keine einheitliche Antwort darauf, wie ein BA in einem Scrum-Team arbeiten wird, da dies vom Team, der Domäne und der Organisation abhängt. Wie bei allen agilen Dingen ist es für das Team wichtig, einen guten Inspektions- und Anpassungszyklus zu haben, der es ihnen ermöglicht, die Zusammenarbeit des BA mit dem Team schrittweise zu optimieren.

Um dies effektiv zu beantworten, ist es wichtig, Rollen, Berufsbezeichnungen und Fähigkeiten aufzuteilen. Scrum hat absolut nichts über Berufsbezeichnungen zu sagen, also können wir das ziemlich schnell lösen, indem wir sagen: Solange ein bestimmter „Job“ nicht ausdrücklich mit Scrum kollidiert, ist er im Scrum-Framework „erlaubt“. Das ist es nicht zu sagen, dass bestimmte Jobs häufig zu Funktionsstörungen führen können. Zum Beispiel ist ein Manager in Scrum „erlaubt“, aber wenn dieser Manager an seiner Fähigkeit gemessen wird, die Leistung des Teams zu steigern, und dann die Regeln von Scrum respektiert werden, was die Fähigkeit des Managers dazu behindert, ist dies ein Rezept für eine Katastrophe .

Nun, Scrum beschreibt 3 Rollen (in der neuesten Version des Leitfadens eigentlich Verantwortlichkeiten genannt). Der Product Owner, der Scrum Master und die Entwickler (denken Sie an Produktentwickler, nicht an Programmierer). Es gibt einige Regeln, wie diese 3 Verantwortlichkeiten interagieren. Beispielsweise ist der Product Owner für die Bestellung des Backlogs verantwortlich, während die Entwickler für die Erstellung des Plans für den Sprint verantwortlich sind.

Beides erfordert bestimmte Fähigkeiten, und hier hat jemand, der es gewohnt ist, die BA-Rolle zu spielen, möglicherweise einige Herausforderungen zu meistern. In vielen Organisationen wird von einem BA erwartet, mit Stakeholdern zusammenzuarbeiten, Prioritäten zu verstehen, Transparenz zu schaffen usw. Dies sind eindeutig Fähigkeiten, die von der PO gefordert werden, und Verantwortlichkeiten der PO. Andererseits werden viele BAs auch gebeten herauszufinden, welche Arbeiten wie erledigt werden müssen. Dies sind Fähigkeiten und Verantwortlichkeiten der Entwickler. Hier kann es in Scrum problematisch sein, einen BA zu haben. Nun, es gibt einen Punkt im Scrum Guide, der besagt, dass der PO nicht die Dinge tun muss, für die er verantwortlich ist. Man könnte also argumentieren, dass ein BA einfach ein Mitglied des Entwicklungsteams ist, das die Dinge tut, die der PO besitzt. Dies wird jedoch in der Praxis chaotisch. Ist die PO wirklich Eigentümer? Oft nicht. Auch, Es gibt keine Unterteams in den Entwicklern – hat jeder Entwickler eine gemeinsame Verantwortung für die Dinge, die der BA tut? In den meisten Fällen nicht.

Am Ende des Tages läuft die Frage zu BAs für die meisten Unternehmen auf Folgendes hinaus: Wenn Sie versuchen, Ihre Arbeitsweise halb zu ändern und halb gleich zu bleiben, setzen Sie sich aufs Scheitern fest. Sie können Ihre Softwareentwicklung verbessern, ohne Scrum einzuführen. Sie können sogar einige Scrum-Praktiken übernehmen, wenn Sie sie mögen. Aber wenn Sie sagen, dass Sie Scrum praktizieren und alle Vorteile von Scrum nutzen möchten, müssen Sie sich irgendwie verpflichten.

Schön gesagt! Ich habe dafür gestimmt, weil ich denke, dass Ihr dritter Absatz den Kern der Sache trifft. Ich denke auch, dass Ihr letzter Absatz wichtig ist, obwohl ich dazu neigen würde, ihn stärker zu machen als (betont meins) „ irgendwie verpflichten müssen“.
In Bezug auf Rollen, für zukünftige Besucher (betont von mir): "Scrum definiert drei spezifische Verantwortlichkeiten innerhalb des Scrum-Teams: die Entwickler, den Product Owner und den Scrum Master." scrumguides.org/scrum-guide.html#scrum-team
Angesichts der Unklarheiten in der Frage ist dies eine fantastische Antwort. Der letzte Absatz, der ungefähr die Hälfte einer Arbeitsweise ändert, bringt für mich wirklich alles zusammen.
„Aber wenn Sie sagen, dass Sie Scrum praktizieren und alle Vorteile von Scrum nutzen möchten, müssen Sie sich dazu verpflichten.“ Sie können sich auch dazu verpflichten, andere agile Projektentwicklungsmethoden zu übernehmen, die für Sie möglicherweise besser funktionieren als Scrum.
Es gibt keine (formellen) Subteams in Scrum, aber die Idee, dass alle „Entwickler“ identische Fähigkeiten haben, um jedes auftretende Entwicklungsproblem anzugehen, ist offensichtlich Unsinn. Ein Entwickler, der über Fachkenntnisse in „BA-Sachen“ verfügt (wie auch immer die Organisation des OP entscheidet, was das ist), unterscheidet sich nicht von einem Entwickler, der über Fachkenntnisse in Datenbankdesign, Nanotechnologie oder irgendetwas anderem verfügt.
@nik012000 - absolut! Und ich weise Teams auch auf Kanban hin, das eigentlich gar keine Methodik ist, sondern ein Ansatz, um Ihre Methodik nach Belieben abzustimmen.

In meinem 12-köpfigen Team gibt es 2 BAs* und im Moment haben wir 24 Tickets (Bugs, neue Features, technische Sachen) im Rückstand. Daher bin ich nicht der Meinung, dass BAs viel Vorarbeit bedeuten.

Was Scrum betrifft, so scheint es, wie ich in den Kommentaren besprochen habe, keine BAs zuzulassen:

  • Sie können sie sich als POs vorstellen, aber meistens sind BAs keine Stakeholder
  • Wenn Sie sie als Entwickler betrachten, dann würde das bedeuten, dass sie nicht an aktuellen Sprint-Zielen arbeiten, sondern Aufgaben für zukünftige Sprints vorbereiten.

Obwohl es vielleicht nicht Scrum ist, glaube ich nicht, dass BAs Sie in irgendeiner Weise daran hindern, agil zu sein.

*Um fair zu sein – wir sind nicht nur BAs. Ich bin auch Teamleiter und der andere BA führt manchmal Tests durch. Und wir übernehmen beide unterstützende Tätigkeiten. Aber trotzdem schaffen wir beide Zukunftsaufgaben. Wir verwenden Scrum nicht, aber selbst wenn wir es täten - wir würden dasselbe tun, es gibt einfach keine andere Möglichkeit für uns zu arbeiten.

'Stattdessen bereiten sie Aufgaben für zukünftige Sprints vor'. Aus diesem Grund habe ich den Begriff „im Voraus“ verwendet. Warum sind Sie anderer Meinung?
@Daniel, weil 24 Aufgaben nicht viel Vorarbeit sind. Sie brauchen in jedem Fall Vorarbeit. Sogar in Scrum haben Sie einen PO, der das Produkt-Backlog vorbereitet, Dinge für den nächsten Sprint verfeinert – das ist die Vorarbeit, die Sie nicht eliminieren können. Aber wir wollen sicher nicht viel davon machen. Und manche Leute verbinden BAs aus irgendeinem Grund mit viel Vorarbeit.
@StanislavBashkyrtsev Ich denke, das ist das Herzstück. Das gesamte Scrum-Team nimmt an der Backlog-Verfeinerung teil, aber die Entwickler sind für die Sprint-Planung (emph. von mir) verantwortlich: „Dies geschieht oft durch die Zerlegung von Product-Backlog-Elementen in kleinere Arbeitselemente von einem Tag oder weniger Ermessen der Entwickler. Niemand sonst sagt ihnen, wie sie Product Backlog-Einträge in Wertinkremente umwandeln können. “ scrumguides.org/scrum-guide.html#sprint-planning ), und die Entwickler sind für das „Wie“ verantwortlich.
Das Ziel ist es, Mini-Wasserfälle und BUFD zu vermeiden, und die Verantwortlichkeit für typische BA-Arbeit wird auf den Product Owner und die Entwickler verteilt. Wenn das gesamte Scrum-Team nicht an der Design- und Spezifikationsplanung teilnimmt, verlieren Sie die größten Vorteile, die Scrum zu bieten hat.
@ToddA.Jacobs, gut "Gewinne" ist ein relativer Begriff. Scrum bietet „Gewinne“ nur im Vergleich zu sehr ineffektiven Teams. Es führt einfach zu viel Abfall ein. Ich möchte nicht, dass das gesamte Team an der langwierigen Design-/Spezifikationsplanung teilnimmt, da dies (höchstwahrscheinlich - besser und schneller) von 1-3 Personen erledigt werden kann. Ich mag es, wenn Menschen konzentriert bleiben, und sie sind normalerweise dankbar dafür. Zu Ihrem 2. Punkt: Scrum ist ein Mini-Wasserfall, da es zeitbasierte Inkremente hat. Der Unterschied ist quantitativ, nicht qualitativ. Obwohl Wasserfälle sehr unterschiedlich sein können, können sich einige von ihnen auch qualitativ unterscheiden.
@ToddA.Jacobs Was ist der größte Gewinn? Können Sie ein Beispiel aus der Praxis nennen?

Eine Einschränkung im Voraus ... Ich habe nur begrenzte Erfahrung mit formalem Agile (insbesondere Scrum), aber ich habe Aspekte agiler Ansätze ziemlich häufig verwendet, und einige meiner Teams haben Leute mit BA-Kenntnissen aufgenommen. Ich gehe davon aus, dass eine BA-Rolle innerhalb eines Projekts, das nach formalen Agile-Prinzipien (einschließlich Scrum) durchgeführt wird, ziemlich weit verbreitet sein könnte.

Erstens, um die Arbeit des Product Owners bei der Definition der spezifischen Outputs und Ergebnisse des Systems zu unterstützen, was möglicherweise eine Untersuchung und Analyse mit Eingaben von Systembenutzern und Empfängern der Outputs des Systems erfordert. Der PO verfügt möglicherweise nicht über die spezifischen Detailkenntnisse aller Aspekte der Anforderungen und würde daher von jemandem profitieren, der bei der Dokumentation dieser Anforderungen zur Unterstützung der User Stories hilft. (Entschuldigung, wenn die Terminologie nicht ganz richtig ist).

Zweitens, als Teil des Entwicklungsteams zu arbeiten, die geschäftlichen Inputs im Namen des Product Owners bereitzustellen und dem Rest des Teams zu helfen, die Anforderungen richtig zu interpretieren, wodurch Nacharbeiten in nachfolgenden Sprints vermieden werden.

Drittens, als Mitglied des Entwicklungsteams zu arbeiten, um bei der Überprüfung der Ergebnisse und Ergebnisse der Entwicklung (Definition, Design und Durchführung von Tests und Testfällen) zu helfen.

Schauen wir uns die konkreten "traditionellen BA-Aufgaben" genauer an:

  1. Klärung von Fehlern/Fehleranforderungsanalyse: Die Entwickler analysieren/beheben Fehlertickets, die von Benutzern erstellt wurden, weil sie das meiste Wissen darüber haben, wie sich das System verhalten sollte. Wenn Sie eine zusätzliche Ebene der Analyse von Fehlertickets von BA hinzufügen, dauert es meiner Erfahrung nach manchmal Stunden, bis sie eine Klärung finden, die oft nicht einmal korrekt ist. Weil sie die Codebasis nicht kennen. Fehler sollten von den Entwicklern behandelt werden, da Sie auf diese Weise auch das Wissen und die Kreativität der Entwickler nutzen. Entwickler sollten keine „Codierungsaufgaben“ erhalten, sondern geschäftliche Probleme. Genauso sollten User Stories dem Kunden des Produkts einen echten Geschäftswert liefern.
  2. Anforderungen an User Stories/Features sammeln: Die Entwickler arbeiten mit dem Product Owner zusammen, um die Probleme ihrer Kunden zu verstehen und kreative Lösungen zu finden. Das Durchführen von Kundenbefragungen, Prototypen usw. liegt eher in der Verantwortung des PO, während Lösungen für echte Kundenprobleme oder Funktionen, die Sie als nützlich für die Kunden bewertet haben, eher die Arbeit der Entwickler sind. Sehen Sie sich auch das Buch Inspired by Marty Cagan an, das großartigen Input zur Arbeit innerhalb des Scrum- Frameworks bietet .

Meiner Erfahrung nach sind dies >90 % die Aufgaben von BAs, und wenn BAs sich mit diesen Aufgaben befassen, wird die Komplexität nur erhöht und es entstehen keine Vorteile. BAs in Ihrem Team zu haben, ist normalerweise ein Zeichen dafür, dass (einige) Mitglieder des Teams die enormen Vorteile der Anwendung von Scrum nicht erkannt haben. Und wie der Scrum-Leitfaden besagt, können Sie Scrum entweder zu 100 % anwenden oder nicht. Werfen Sie außerdem einen Blick auf die Timeboxen von Scrum-Events. Das Sprint-Planning, bei dem traditionell Problemlösungen erarbeitet und User-Stories erstellt werden, kann bis zu 8 Stunden dauern – das längste aller Scrum-Events. Gleichzeitig nimmt dieses Meeting in der Realität oft viel weniger Zeit in Anspruch (selbst wenn Sie während des Sprints Refinement-Meetings hinzufügen). Dies liegt daran, dass die Entwickler und PO nicht die Aufgabe übernehmen, echte Geschäftsprobleme zu lösen, sondern BAs oder andere Personen spezifizieren, was "

Wie geht ein Scrum-Team mit traditionellen BA-Aufgaben um?
AntwortenHierDatenschutz-Bestimmungen1y, 1v