Agile Analytics: Was Sie wissen sollten

Agile Analytics konzentriert sich darauf, den Wert in einem Datensatz zu finden, anstatt eine unbegrenzte Anzahl von Geschäftsableitungen aus den Datensätzen abzuleiten. 

Agilität in Business Intelligence hatte eine Agenda: analytische Flexibilität und Anpassungsfähigkeit an sich ändernde Bedürfnisse, anstatt an einer starren Struktur festzuhalten. Agile Analytics wurde aus diesem Konzept abgeleitet und bietet einen Datenfluss für die Datenermittlung, während es sich schnell an die gegenwärtige und prognostizierte Geschäftslandschaft anpasst. 

Agiles Fundament ist die Bereitstellung oder Ableitung von Wert, sei es in einem Entwicklungslebenszyklus oder einer Business-Intelligence-Plattform.

Welche Vorteile bringt Agile mit sich?

• Jeder fühlt sich gleichermaßen für die Produktqualität verantwortlich 
• Die Ergebnisse jeder Iteration ermöglichen es den Benutzern, Feedback zu geben und schnell Änderungen umzusetzen, um den Anforderungen der Stakeholder gerecht zu werden und die Entwicklung für das zukünftige Karussell anzupassen 
• Es ist auch bekannt, dass es die Produktkosten senkt, indem die Scale-Out-Version des Systems über verschiedene unabhängige Funktionen hinweg implementiert wird. 
• Agile Analytics ist bekannt dafür, dass es Self-Service-orientiert ist. Mit weniger Abhängigkeit und verteilten Talenten wird es zu einer echten Lernkurve. 

Was ist die traditionelle Analysemethodik?

Analyseprojekte sind schwieriger zu verwalten als die übrigen Produktlinien. Sie waren schon immer die anspruchsvollsten ihrer Art. 

Wie jedes andere Projekt hat auch ein digitales Analyseprojekt ein Anfangs- und Enddatum, aber die Anforderungen scheinen von Kunden- oder Stakeholderseite nie zu enden. Es gibt immer etwas, das die Zeit aufbraucht und die Projekte um 2-3 Sprints verlängert. 

Jede Person hat Rollen und Verantwortlichkeiten, die auf übliche Weise zugewiesen werden, was oft zu viel Nacharbeit führt, und die traditionelle Wasserfallmethode scheint nicht zu funktionieren, um das Projekt zu kontrollieren. 

Wenn digitale Analyseprojekte nicht zustande gekommen wären, wäre die Bedeutung von Agile und seinen Methoden nicht so gut verstanden worden. Dies steht im Einklang mit der sich ständig verändernden digitalen und analytischen Welt.

Bevor Sie mit Agile in der Analyse beginnen, sollten Sie verstehen, wie es sich unterscheidet. 

Analyseteams haben oft Schwierigkeiten, sich zwischen der traditionellen sequenziellen, aber unflexiblen Wasserfallmethode und Agile zu entscheiden, was in den Analyseteams für viel Unruhe gesorgt hat, da sie anpassungsfähiger an Veränderungen ist. 

Wasserfall bringt Planung ins Spiel, Agile geht davon aus, dass es immer wieder zu Änderungen kommt. 

Wasserfall neigt dazu, die Anforderungen von Kunden oder Stakeholdern sehr früh in der Projektphase zu ermitteln. Die in der Anfangsphase durchgeführte Anforderungserhebung bestimmt das Tempo und die Komplexität des Produkts, und alle Änderungen oder Anpassungen erfolgen danach. 

Auf der anderen Seite erlaubt Agile Änderungen auch in fortgeschrittenen Phasen. Agile konzentriert sich mehr darauf, so früh wie möglich in der Projektlaufzeit ein Minimum Viable Product zu erstellen, und die restliche Zeit wird damit verbracht, den weiteren Umfang zu definieren und die Engpässe bei der Bereitstellung komplexer Lösungen auf der Geschäftsseite zu ermitteln. Mit Hilfe des kontinuierlichen Feedbacks der Stakeholder kann das Projekt in die richtige Richtung beschleunigen. 

Wasserfall läuft seriell, Agile läuft parallel. 

Ein Wasserfallprojekt wird in der Regel in mehrere Phasen unterteilt, die sich nach den Anforderungen der Stakeholder richten. Diese Phasen haben dann entsprechende Meilensteine, die als stärkere Meilensteine an sich gelten. Viele Phasen können parallel laufen, während einige seriell laufen können, je nach den funktionalen und nicht-funktionalen Anforderungen des Projekts. 

Das bedeutet, dass eine Phase erst beginnen kann, wenn eine andere abgeschlossen ist. Im Wasserfall werden die Projekte in Mini-Sprints unterteilt, die über zwei aufeinanderfolgende Wochen laufen und deren Ergebnisse einvernehmlich festgelegt werden. Agile gliedert das Projekt jedoch in aufeinanderfolgende Sprints, die in der Regel zwei Wochen dauern, klare Ergebnisse liefern und sich auf die Verbesserung des Modells auf der Grundlage des Feedbacks der Geschäftsanwender konzentrieren.

Wasserfall testet am Ende, Agile testet durchgehend. 

Das Testen erfolgt in einem wasserfallbasierten Projekt in späteren Phasen, während Agile das Testen über den gesamten Zeitraum des Sprints hinweg durchführt. Der Ansatz des späteren Testens gibt den Stakeholdern und dem Testteam etwas Zeit, das Projekt in einer viel umfassenderen Weise zu verstehen. 

In Agile wird das Testen jedes Sprints während des laufenden Sprints durchgeführt, so dass Änderungen leichter umzusetzen sind. Es werden jedoch während des gesamten Projekts Qualitätstester benötigt, was sich drastisch auf die Kosten auswirkt und dazu beiträgt, qualitativ hochwertige Sprint-Ergebnisse zu erzielen. 

Wasserfall funktioniert für Benutzer, Agile agiert als Teamplayer. 

Agile hat sich schon immer auf die Zufriedenheit der Geschäftsanwender konzentriert, sie während der gesamten Entwicklungsphase einbezogen und ihnen eine häufige Überwachung ermöglicht. Auf der einen Seite reguliert das Business-Team die Anforderungen und Prioritäten, während das Analyse-Team damit beschäftigt ist, die Funktionen zu sortieren und Berichte zu erstellen, die für die Unternehmen unter Berücksichtigung ihrer Prioritäten am wirkungsvollsten sind und entsprechende Erkenntnisse liefern können. 

Kostenprognosen und -schätzungen sind mit Wasserfall besser. 

Wasserfall hat einen planbaren Workflow mit einem klaren Anfang, Engpässen und einem Ende, so dass der Bewertungsprozess vergleichsweise einfacher ist. Dies macht es einfach, Kosten und Zeitpläne in Abwesenheit von Änderungen zu schätzen. Jeder Sprint hat eine feste Zeitdauer, aber es kann schwierig sein zu verstehen, wie viele Sprints benötigt werden, da Änderungen zulässig sind. 

Wie gelingt der Übergang zu Agile?

Wenn Sie schon lange ein Verfechter des Wasserfalls sind, ist es definitiv eine schwierige Entscheidung, Ihren Prozess und Ihre Abläufe auf Agile umzustellen. Meinungsverschiedenheiten sind normal und unvermeidlich, und es kann ein Szenario geben, in dem die Hälfte Ihres Teams an einem Wasserfall festhalten will, während die andere Hälfte zu Agile übergehen will. 

Im Allgemeinen möchten die Stakeholder, dass die Dinge detailliert und auf den Punkt gebracht werden, aber Architekten und Fachleute gehen gerne Meilenstein für Meilenstein vor und lassen die Dinge unterwegs herausfinden. Wenn es jedoch um Analysen geht, verwenden die Teams in der Regel hybride Entwicklungskonzepte, anstatt sich an eines zu halten, da der Wasserfall es ihnen ermöglicht, eine konsistente Klarheit und Rückverfolgbarkeit beizubehalten, während Agile in Zeiten eingesetzt wird, in denen Anpassungsfähigkeit und Komplexität extrem notwendig sein könnten. 

Wie sollte Ihre Teamstruktur aussehen?

• Um in der agilen Rolle gut zu funktionieren, müssen Analyseteams so konfiguriert sein, dass die Mitglieder sich an die sich ändernden Geschäftsanforderungen anpassen und verschiedene Rollen dynamisch übernehmen können. 
• Es gibt einige Faktoren, die Sie berücksichtigen sollten, bevor Sie ein Team in das agile Analyseteam aufnehmen:
• Das Team sollte entweder vollständig zentralisiert oder in einem Remote-Collaboration-Konzept arbeiten, je nachdem, was auf dem Teller des Unternehmens liegt und ob es mit der aktuellen Rollendynamik bewältigt werden kann?

Sobald diese Kriterien erfüllt sind, sollte das Team dazu übergehen, die Dinge auf natürliche Weise entsprechend der Kapazität des Teams zu entwickeln. Die Ressourcenausstattung muss möglicherweise je nach Bedarf variieren. 

Abschließende Worte 

Agile Analytics wird in einigen Szenarien als die beste Lösung angesehen, in anderen der Wasserfall, aber aufgrund der zahlreichen Vor- und Nachteile ist es gut, auf der sicheren Seite zu sein und sicherzustellen, dass die Dinge gründlich getestet werden und jede vorgeschlagene Änderung sinnvoll ist, bevor sie in die Entwicklung geht.