Skramsara Analytics / Sudo Null IT-Nachrichten

Der Artikel widmet sich den schwierigen / arbeitsintensiven Umständen der Arbeit von Analysten in Projekten, die nach einer bestimmten Variante von „Scrum + Analyst“ durchgeführt werden, diese Umstände sind die Ursache für Stress. Wenn Sie denken, dass ich Ihnen einige Lösungen geben werde, dann leider nein. Diese Schwierigkeiten werden in absehbarer Zeit nicht verschwinden, Sie können bedenken, dass Sie sich im Samsara-Kreis des Analytikers bewegen. Wisse, dass du nicht alleine darauf gehst, vielleicht wird es für dich psychologisch einfacher.

Aktueller Sprint VS Zukünftiger Sprint

Alle arbeiten in Sprints. Wie viele aktive Sprints hat ein Analyst? Natürlich zwei. Zum einen unterstützt er Entwickler analytisch, erklärt die Aufgaben des aktuellen Sprints, eliminiert die Kommentare, die ihm zu Beginn des Sprints entgegengeschleudert wurden. Gleichzeitig muss der Analyst eine Beschreibung der Aufgaben für den zukünftigen Sprint erstellen. Von den anderen Mitgliedern des Teams scheint dies so zu sein, wie es sein sollte. Entwickler denken gerne, dass sie Schöpfer sind und in einem Fluss arbeiten, von dem sie nicht abgelenkt werden können. Und für den Analysten stellt sich heraus, als ob dies nicht zutrifft, dass der Analyst die Materialien studiert und über eine Lösung nachdenkt, hier, bam, eine Frage zur Aufgabe des aktuellen Sprints. Dann noch eine Frage zu einer anderen Aufgabe, und es wird Fragen geben, und das ist normal. Angenommen, ein Analyst hat im Voraus eine Reihe von Aufgaben beschrieben, ist mit der Analyse vor dem Entwicklungsteam davongelaufen, Moment mal, erinnert mich das an etwas? Das ist also ein Wasserfall, und was passiert mit den Aufgaben, wenn das Entwicklungsteam damit beginnt, richtig, es wird noch viele Fragen geben, und der Analyst muss alles neu machen. Stellen wir uns außerdem vor, dass die Aufgaben zu Beginn des Sprints perfekt beschrieben und von den Entwicklern vollständig verstanden werden. Wissen Sie, was das bedeutet? Nichts Gutes. Wahrscheinlich entwickelt sich das Projekt langsam, niemand hat es eilig, es gibt keine Dynamik, vielleicht braucht niemand Ihr Projekt / Produkt. Daher sind zwei aktive Sprints für den Analysten die Norm.

Wir arbeiten in Sprints, aber wir haben auch einen Plan!

Um diesen Widerspruch zu verstehen, denken Sie daran, wie sich Ihre Projekte entwickelt haben, und bauen Sie eine logische Kette auf. Wieder dasselbe, alle arbeiten jetzt an Sprints. Aber die anfängliche Planung und Arbeitsschätzung erfolgt nicht durch Sprints. Im besten Fall haben Sie einen Architekten, er oder Sie haben einen Vorentwurf erstellt, das System in Komponenten und Module zerlegt, die Arbeitskosten für die Implementierung geschätzt oder sogar zusammen mit dem Projektleiter eine Roadmap oder vielleicht sogar eine erstellt Planen Sie mit einem Gantt-Diagramm. Gleichzeitig verstehen sie immer noch, dass Sie in Sprints arbeiten werden. Und wie sieht das im Vergleich zur klassischen Planung aus? Es stellt sich heraus, dass diese Lücke in den Köpfen der Menschen normal auskommt, oder vielmehr ignoriert wird. Aber dieser Rake kann gut funktionieren, wenn ein Meilenstein aus dem Gantt-Diagramm in einem zukünftigen N-ten Sprint ohne angemessene Neubewertung landet. Ein Teil dieses Problems besteht darin, dass die Arbeit an Sprints und die Anwendung von Scrum-Praktiken, d. h. die Planung zu Beginn des Sprints, täglich, Demo-Tag, Retrospektive, von vielen Menschen so wahrgenommen wird, als würden wir zunächst an Scrum arbeiten. Aber Scrum ist kategorisch gegen Meilensteine ​​und langfristige Pläne. Und warum ist es so einfach, den Plan anzupassen und im Kopf in Sprints zu arbeiten? Ich möchte anmerken, dass ich nicht gegen Pläne mit weitem Horizont bin. Planung ist eine gute mentale Aktivität, die Ihnen ein Verständnis dafür vermittelt, was getan werden muss. Aber ich bin dagegen, den Plan in seiner ursprünglichen Form ohne Anpassungen zu fixieren, weil es so nicht funktioniert. Aber wird es funktionieren, wenn es in Sprints aufgeteilt wird? Ist Sprintarbeit eine Anpassung des Plans? Und wenn die Lieferzeit starr fixiert ist, kann man das dann als Klarstellung bezeichnen? Nun ja, es gibt noch zwei Parameter, die wir klären können, Inhalt und Qualität. Verstehen alle, in welche Richtung die Veränderung gehen wird?

Und warum haben sich Ihre Analyseaufgaben im Sprint geändert?!

Dieses Problem kennt jeder, das ist der Fall, wenn es einen Arbeitsplan gibt, nach dem alle Arbeiten des Teams in Sprints in Jira erledigt werden sollen. Analysten, Designer, Entwickler, Tester, alle werden in einen typischen Sprint getrieben. Und zuerst sieht es aus wie ein Meme “Im Oblonsky-Haus ist alles durcheinander.” Warum es unmöglich ist, mit Analyseaufgaben genauso zu arbeiten wie mit Entwicklungsaufgaben, und mit welchen Tricks wird das verhindert oder umgekehrt. Und warum eine analytische Aufgabe jederzeit geöffnet oder geschlossen werden kann. Und darüber, wie dies das Sprint-Reporting für das gesamte Team ruiniert. Ich werde nicht darüber reden. Aber ich bitte Sie, noch einmal darüber nachzudenken, über die Qualität, in diesem Fall über die Qualität der analytischen Arbeit. Wenn Ihre Sprintplanung rein formal ist und Sie keine separate Karte oder Liste analytischer Aufgaben führen, dann ist die analytische Arbeit desorganisiert. Um dies zu verhindern, greifen Analysten auf die Hilfe externer Tools zurück und können einen Parallelsprint außerhalb der Regeln von Scrum bilden, es wird wahrscheinlich in einem Tool wie Trello sein. Als Ergebnis erhalten wir eine seltsame Situation, dass, wenn Sie nach den Regeln von Scrum arbeiten, dies eine Desorganisation der Analyse nach sich zieht, und paralleles Arbeiten außerhalb von Scrum der Unterwasserteil des Eisbergs ist, der sich nicht in den Berichten widerspiegelt und einen beschreibt viel Arbeit und Risiken für das Projekt. Was tun damit?

Hallo, ich bin ein Designer, ich werde CJM bauen

Designer ist eine relativ junge IT-Spezialität. Die Tätigkeiten von Designern sind sehr eng mit denen von Analysten verzahnt. Aber sie haben sich ihren Platz an der Sonne verdient. Was sind ihre coolen Tools wie Figma und ihre wunderbaren Techniken, die sie von Vermarktern gestohlen haben, nur ein Scherz, geliehen. Ich werde keine banalen Dinge über die Notwendigkeit beschreiben, CJM zusammen zu bauen und nicht separat an verschiedene Benutzer zu gehen. Und je nachdem, wie Analyst und Designer zusammenarbeiten, werden sie zu Freunden oder Feinden. Ich schlage vor, zu sehen, was die Designer über alles oben Gesagte denken, denn sie müssen auch in Sprints arbeiten. Oder sollte nicht?

Agilität und Design: So vermeiden Sie Frankensteining für Ihr Produkt

Die Kombination von Agilität und Design ist wie der Blick auf ein Bild durch ein Schlüsselloch. Der Designer muss schrittweise arbeiten und das Ganze in Teile zerlegen. Es ist dieser Ansatz, der zu dem führen kann, was ich das „Frankensteining“ digitaler Produkte oder Dienstleistungen nenne.

Frankensteining tritt auf, wenn Produkte oder Dienstleistungen, die mit Agile erstellt wurden, fragmentiert oder unzusammenhängend werden. Fragmentierung unterbricht die Integrität der Wahrnehmung, was sich negativ auf die Benutzererfahrung auswirkt.

Design und UX in agilen Methoden

Für Programmierer ist es einfach und komfortabel, in Iterationen zu arbeiten, für Designer jedoch nicht. Weil es für einen Designer einfacher ist, das Konzept vollständig zu überdenken und diese Aufgabe nicht in kleinere aufzuteilen, während er die globale Vision des zu lösenden Problems des Kunden verliert.

Es stellt sich als Dilemma heraus: Entweder qualitativ und langfristig (wenn das Konzept ganzheitlich durchdacht ist) oder ein Rohprodukt, aber schnell (wenn keine Zeit für eine globale Vision bleibt, aber die Arbeit den Gesetzen von unterliegt Agil).

Tatsächlich wurde vor langer Zeit eine Kompromisslösung erfunden – parallele Design- und Entwicklungsströme, bei denen der Designstrom um eine Iteration voranschreitet.

Wie Sie sehen können, erhalten wir eine ähnliche Situation, wenn „Design“ durch „Analyse“ ersetzt wird. Nun, wie gefällt Ihnen dieses Agile, wo Analysten ihren eigenen inhaltlichen Sprint haben, Designer ihren eigenen Sprint und Entwickler ihren eigenen. Nehmen wir an, sie arbeiten sogar technisch innerhalb desselben Sprints in Jira. Aber nach den Regeln für den Sprint wird ein Ziel vergeben, was ist das Ziel eines solchen Sprints? Wie werden Berichte gesammelt?

Du hast einen Job als Analyst in Scrum gefunden?!

Und da ist er nicht. Nun, nein, nein, können Sie hinzufügen? Aber zuerst müssen Sie eine einfache Sache verstehen: Scrum ist eine Möglichkeit, die Arbeit zu organisieren, um Softwareprodukte zu erstellen. Und die Art der Arbeit an der Erstellung blieb die gleiche wie zuvor: Analyse, Design, Programmierung, Test. Und hier müssen Sie die zweite einfache Sache verstehen: Die Aufgabe der Analyse ist der Kampf gegen die Ungewissheit, um zu einer Verständigung zu kommen. Scrum weist dafür keine eigene Analystenrolle zu. Analyse-, Design- und Programmierarbeiten werden vom Entwickler durchgeführt. Diese Organisationsmethode funktioniert gut für ein kleines Team, wo enge Interaktion, schneller Informationsaustausch und direkter Kontakt durch das Konzept des Scrum-Teams impliziert werden. Sobald das zweite Produkt, das zweite Team auftaucht und es gilt, die Interaktion des Teams, also die Verständigung zwischen den Teams zu gewährleisten, hat Scrum keine Möglichkeit, dies zu organisieren. Um dieses Problem zu lösen, beginne ich, andere Methoden zu verwenden, zum Beispiel Sicher. Aber wenn Scrum auf der untersten Ebene verwendet wird, bedeutet dies, dass das Verständnis des Produkts in den Köpfen des Produktteams verankert ist. Und hier beginnt der Spaß:

  • Hatten sie die Zeit und die Aufgabe, die Dokumentation zu schreiben?

  • Sollten Entwickler überhaupt Dokumentation schreiben?

  • Wer unter den Entwicklern will schon von den Fragen des Nachbarteams abgelenkt werden?

  • Möchte einer der Entwickler das Scrum-Board und den Rückstand des Nachbarteams analysieren?

  • Will er sich auf etwas einigen und Kompromisse eingehen?

Und natürlich entsteht eine geniale Idee: „Los, lass das den Analysten machen!“ Außerdem werden Entwickler müde, die von Scrum vorgeschriebene Analyse zu machen, es ist am Anfang interessant, aber irgendwie tauchen Schwierigkeiten auf, ihre Begeisterung verfliegt schnell. Schließlich ist es viel interessanter, Code zu schreiben. So bekommt der Analytiker seinen Anteil. Jetzt muss er seine Arbeit irgendwie organisieren, was bedeutet, sich den Schwierigkeiten zu stellen, die ich oben beschrieben habe:

  • eine umfassende, nach Sprints aufgeschlüsselte Analyse durchführen;

  • Arbeit in zwei aktiven Sprints;

  • Brechen Sie nicht die Scrum-Board-Berichterstattung des Teams.

Samsara / Scrumsara

Alle Entwürfe zur Einbettung von Analytics in Scrum sind projekt- und unternehmensspezifisch, sie sehen auf den ersten Blick sogar gut aus, sind aber in der Praxis nur begrenzt leistungsfähig, genauso wie das Wasserfallmodell in der Theorie funktioniert, in der Praxis aber alles hängt von Menschen ab. Und ganz allgemein gesagt, wenn Sie ein Team von Profis haben, dann ist es im Prinzip egal, mit welcher Methodik sie arbeiten. Aber was ich sicher weiß, ist, dass das Arbeiten nach dem Schema „Scrum + Analyst“ an Live- und ziemlich aktiven Projekten regelmäßig zum Verbrennen der Arbeit der Analysten und zum Burnout der Analysten selbst führt. Sie sind motiviert, unter solch schwierigen Bedingungen zu arbeiten. Sätze wie „Du musst nicht nach Schuldigen suchen, du musst die Arbeit erledigen!“ werden verwendet! oder „Wir werden es später beheben“ und dergleichen. Da Scrum aber nicht von Haus aus eine eigene Rolle für den Analysten einnimmt, ist dies durch etwaige Retrospektiven irreparabel. Egal was irgendjemand sagt, Scrum kann sich selbst nicht grundlegend ändern. Vielleicht müssen Sie in Projekten, die nach irgendeiner Version von „Scrum + Analyst“ durchgeführt werden, das Schicksal des Analysten akzeptieren? Ist das Skramsara?

Similar Posts

Leave a Reply

Your email address will not be published.