So arbeiten Sie mit mehreren Entwicklern an einem Power BI-Bericht

Inhaltsverzeichnis

1. Der problematischste Aspekt von Power BI
2. Warum ist die Zusammenarbeit so schwierig?
3. Wie man in Power BI erfolgreich zusammenarbeitet
4. Was könnte schiefgehen?
5. Abschließende Gedanken

Der problematischste Aspekt von Power BI

Mit der höchsten Fähigkeit zur Umsetzung und der sogenannten „Completeness of Vision“ wird Power BI, laut Gartners 2022-Analyse der verfügbaren BI-Lösungen, als einer der führenden Anbieter im Bereich Business Intelligence (BI) gefeiert – zum vierten Mal in Folge. Es hat eine lange Liste von Vorteilen und repräsentiert mehr als ein Drittel des Marktanteils in einem wachsenden Markt. Doch trotz der Anerkennung und breiten Akzeptanz gibt es immer noch einige Aspekte, die bei Power BI fehlen – der ausschlaggebendste davon ist die Schwierigkeit, mit anderen Power BI-Entwicklern an einem Bericht zu arbeiten.

Dies ist nicht etwas, mit dem Sie jeden Tag konfrontiert sind. In Ein-Entwickler-Projekten ist das Problem strittig, während in größeren Projekten mit mehreren Berichten und Teammitgliedern die Zuweisung eines Berichts pro Entwickler der beste Ansatz sein könnte. Es gibt tatsächlich großartige Power BI-native Funktionen, welche die Zusammenarbeit unterstützen können, einschließlich Arbeitsbereiche und Microsoft Teams. Bei Projekten zwischen diesen beiden Szenarien treten jedoch Schwierigkeiten auf, wenn mehrere Entwickler an derselben PBIX-Datei zusammenarbeiten müssen. Ob es an einer nahenden Frist liegt oder der Bericht selbst zu umfangreich für eine Person ist, es wird Projekte geben, bei denen es einfach sinnvoll ist, sich die Arbeit zu teilen.

Also, was ist das Problem? Einfach ausgedrückt geht es darum, die Arbeit des anderen zu überschreiben. In Softwareentwicklungsprojekten werden Versionskontrollsysteme wie GIT oder Azure DevOps verwendet, um dies zu vermeiden. Mit der Verbreitung der Graphstruktur in solcher Software können Teams „Entwicklungszweige“ erstellen, die nach dem Testen und Akzeptieren in die Hauptsoftware integriert werden können. Dies funktioniert sehr gut bei der Programmierung, da das Zusammenführen normalerweise einen Textvergleich des zusammengeführten Zweigs beinhaltet, was eine klare Übersicht darüber ermöglicht, wann und wo Änderungen aufgetreten sind. Allerdings sind die Dinge in Power BI nicht so einfach – obwohl dies eine Funktion ist, die seit 2015 von der Power BI-Community gesucht wird, gibt es bis jetzt keine native Funktionalität, um eine Quellcodeverwaltung zu erreichen. In diesem Artikel werde ich überprüfen, warum dies der Fall ist, und verschiedene Ansätze für die Zusammenarbeit als Power BI-Entwickler untersuchen.

Warum ist die Zusammenarbeit so schwierig?

Betrachten wir ein Projekt in Power BI mit zwei Vollzeitentwicklern. Sie haben die Aufgabe einen einseitigen Bericht zu entwickeln und sie kooperieren bei der Aufnahme von Daten und der Erstellung eines Datenmodells in einem Bericht. Sie nehmen jeweils eine Kopie des Berichts und entwickeln Funktionalitäten mit der Absicht, sie nach Abschluss ihrer jeweiligen Aufgaben zusammenzuführen. Wenn es an der Zeit ist die Berichte zusammenzuführen, dauert die Aktivität länger als die Arbeit, die sie in ihre einzelnen Freigaben investiert hatten.

Was ist schief gelaufen? Es gibt 3 Hauptaspekte von Power BI:

1. Backend – Datenmodell
2. Berechnungen (DAX) – Kennzahlen
3. Frontend – User Interface

Bei jedem dieser Aspekte traten unterschiedliche Probleme auf. Im Backend beschloss ein Entwickler, das Datenmodell zu ändern und einige Dimensionen zu normalisieren, während der andere beschloss, einige Werte zu aggregieren, um die Leistung zu verbessern. Aufgrund des Modellunterschieds funktionierten DAX-Messungen aus jeder Kopie des Berichts in der anderen nicht, was direkt zu Problemen im Frontend führte, bei denen die Messungen keine Daten anzeigten. Während dieser Teil mit irgendeiner Art von Quellcodeverwaltung behandelt werden könnte, würde dies Frontend-Funktionen wie Interaktionen, versteckte Filter und Lesezeichen nicht berücksichtigen. Am Ende mussten sich diese Entwickler zusammentun und Schritt für Schritt ihre Änderungen an einem Bericht vornehmen.

Wie man in Power BI erfolgreich zusammenarbeitet

Wie können Sie Probleme bei der Zusammenarbeit vermeiden? Ich werde zwei unterschiedliche Ansätze skizzieren, die ich „Check-in“ und „funktionale Trennung“ nenne. Diese unterschiedlichen Arbeitsweisen haben unterschiedliche Vor- und Nachteile und die Wahl der besten Art der Zusammenarbeit hängt wirklich davon ab, die beste Lösung für das jeweilige Projekt auszuwählen. Weiterhin bleibt der Schlüssel zum Erfolg einer effektiven Zusammenarbeit - die Kommunikation.

Der Check-in-Ansatz

Beim Check-in-Ansatz arbeitet jeweils nur eine Person an einem Bericht. Bei der Bearbeitung wird der Bericht „ausgecheckt“ und „eingecheckt“, wenn dies nicht der Fall ist. Dadurch wird der Entwicklung im Wesentlichen die Mehrdeutigkeit genommen und es besteht nicht das Risiko, die Arbeit eines anderen Entwicklers zu überschreiben. Obwohl dies logisch und sinnvoll ist, ist es möglicherweise nicht angemessen für ein lokales Team, in dem zwei Entwickler in Vollzeit zur gleichen Zeit arbeiten – was soll der andere tun, während der Bericht ausgecheckt wird? Wenn sich die Entwickler jedoch in unterschiedlichen Zeitzonen befinden und zu unterschiedlichen Zeiten arbeiten oder, wenn sie nicht in Vollzeit Änderungen am Bericht vorzunehmen, könnte dieser Ansatz eine solide Methode darstellen, um gemeinsam einen Bericht zu erstellen.

Dies kann auf verschiedene Arten implementiert werden. Solange es einen zentralen Ort gibt, an dem Dateien gespeichert werden und die Kommunikation zwischen den Teammitgliedern offen ist, könnten Entwickler den Bericht ein- und auschecken und dem Team mitteilen, dass sie Änderungen am vorhandenen Bericht vornehmen. Es gibt auch Check-in- und Check-out-Optionen, die sowohl in SharePoint als auch in Teams nativ verfügbar sind. Sie zeigen auch den Versionsverlauf an und könnten verwendet werden, um dem Ansatz eine gewisse Struktur zu verleihen. PowerBI.Tips hat eine großartige Lösung, die in PowerApps erstellt wurde, welche auch die Check-in-Check-out-Funktionalität bietet.

Der funktionale Split-Ansatz

Eine andere Form der Zusammenarbeit ist die Aufteilung der Arbeitsbereiche. Ein Entwickler könnte sich mittels PowerQuery und Datenmodellierung auf das Backend konzentrieren, ein anderer auf das Frontend, wodurch eine klare Arbeitsteilung entsteht. Alternativ könnte die Arbeit nach bestimmten Seiten innerhalb des Berichts aufgeteilt werden.

Es gibt mehrere Möglichkeiten, wie dies funktionieren kann, aber der Erfolg hängt von einer sehr starken Kommunikation innerhalb des Teams ab. In dem Szenario, in dem ein Entwickler am Datenmodell und der andere am Frontend arbeitet, könnte ein veröffentlichtes Dataset verwendet werden, in dem das aktualisierte Modell gespeichert und in die Frontend-Version geladen wird, sobald es an den Power BI-Dienst übertragen wurde. Dadurch kann der PBI-Dienst als Interim zwischen den verschiedenen Berichtsversionen fungieren und auch verwendet werden, wenn verschiedene Entwickler separate Registerkarten erstellen. Der am Backend arbeitende Entwickler, müsste lediglich Änderungen vornehmen und den Frontend-Entwickler informieren, sein Datenmodell zu aktualisieren.

Wenn die Verwendung eines veröffentlichten Datensatzes nicht möglich ist, gibt es Tools von Drittanbietern, die als eine Art Quellcodeverwaltung fungieren können. Das ALM-Toolkit ist ein Drittanbietertool, mit dem zwei vollständig separate PBIX-Dateien zusammengeführt werden. Es überprüft die BIM-Dateien, bei denen es sich um JSON-Textdateien handelt, die das Datenmodell und DAX Measures skizziert. Dies ist für zwei PBIX-Desktopdateien kostenlos möglich, für die Bereitstellung des Dienstes ist jedoch eine Premium-Lizenz erforderlich. Ein Nachteil dieser Zusammenführungsmethode ist jedoch, dass das Frontend des Berichts nicht zusammengeführt wird.

 

 

Quelle: Home Page - ALM Toolkit (alm-toolkit.com) 

Am Frontend ist jedoch nicht alles verloren, da Visuals mit demselben Datenmodell aus einem Bericht kopiert und in einen anderen eingefügt werden können. Nicht sichtbare Elemente dürfen nicht kopiert werden, daher besteht die beste Vorgehensweise beim Kopieren einer ganzen Seite einer PBIX-Datei in eine andere darin, das Auswahlfenster zu öffnen, alle Objekte auszuwählen und sie in die andere Datei einzufügen – so einfach wie Strg + C, Strg + V. Wie bereits erwähnt, müssen bearbeitete Interaktionen, Lesezeichen und einige andere Dinge, die nicht kopiert werden, manuell neu erstellt werden.

Ebenso können PowerQuery-Elemente auch von einem Bericht in einen anderen kopiert und eingefügt werden, was eine weniger kontrollierte Alternative zur Verwendung des ALM-Toolkits darstellen könnte. Die Sicherheitsanmeldeinformationen werden möglicherweise nicht kopiert, aber die Auswahl von Elementen im Abfragebereich und die Verwendung von Strg + C, Strg + V können eine einfache Möglichkeit sein, alle erforderlichen Schritte zu replizieren. Andernfalls kann das Kopieren der M-Abfrage mithilfe der erweiterten Editorfunktionalität die Möglichkeit sein, das Backend auszurichten.

Das tabellarische Modell

Es gibt einige Überlegungen, wenn sich die Daten nicht im Importmodus befinden – insbesondere, wenn die Daten mithilfe eines tabellarischen Modells (Azure Analysis Services) mit dem Bericht verbunden sind. Dies ist eine Möglichkeit, sehr große Datensätze direkt mit dem Bericht zu verbinden und wird normalerweise als Schritt zwischen den Kosten von Power BI Pro und Power BI Premium gewählt. Ein semantisches Modell wird mithilfe von Azure-Ressourcen erstellt, die DAX-Measures enthalten. Daher werden alle Backend- oder Maßänderungen, die an das tabellarische Modell übertragen werden, sofort für alle anderen Berichte, die mit diesem Modell verbunden sind, live.

Es gibt einige Optionen, die Sie bei diesem Ansatz auswählen können, z. B. die Verwendung von Visual Studio und der BISM Normalizer-Erweiterung. Letzteres fungiert wie das ALM-Toolkit für die Versionskontrolle und wendet auch Bereitstellungsfunktionen in Visual Studio an. Das tabellarische Modell könnte durch den tabellarischen Editor beeinflusst werden, der in direkter Verbindung mit dem Modell oder über lokale BIM-Dateien arbeitet. Das tabellarische Modell kann direkt in GIT oder Azure DevOps integriert werden und auf diese Weise kann eine strenge Versionskontrolle aufrechterhalten werden. Dies kann auch in Deployment-Pipelines integriert werden.

Dieser Ansatz ist jedoch nicht nur auf die Verwendung von Azure Analysis Services beschränkt. Sie können die BIM-Datei tatsächlich mit dem tabellarischen Editor extrahieren. Es gibt keine direkte Integration mit Power BI Desktop, daher müssen Sie möglicherweise die BIM-Datei extrahieren und ein anderes Programm finden, um die Zusammenführung zu überprüfen und die Änderungen zu steuern. Wenn Ihr Projekt jedoch wirklich eine Versionskontrolle ohne AAS benötigt, könnte dies der richtige Weg sein.

Was könnte schiefgehen?

Auch bei besonderer Sorgfalt können Probleme auftreten, wenn mehrere Personen gemeinsam an einem einzigen Bericht arbeiten. Was kann getan werden? Meiner Erfahrung nach gibt es ein paar Best Practices, die das Risiko reduzieren. Ein definiertes Benennungsschema und eine Ordnerstruktur für Kennzahlen, Sicherungen früherer Versionen (ob PBIX, eine mit VertiPaq Analyzer extrahierte Aufzeichnung von Kennzahlen oder die BIM-Datei) und eine gute Dokumentation des Entwicklungsprozesses (um festzustellen, wann etwas geändert wurde) sind gute Angewohnheiten in jedem Projekt.

Die größten Probleme entstehen jedoch durch Änderungen in der Modellierung oder den Namenskonventionen. In Fällen, in denen DAX-Measures aufgrund einer großen Anzahl von Änderungen nicht mehr funktionieren, kann es sich lohnen, das ALM-Toolkit oder die erweiterte Skripting-Funktion des tabellarischen Editors zu verwenden, um die Kennzahlen zu kopieren oder zu bearbeiten. Advanced Scripting ermöglicht es Ihnen, programmgesteuert Änderungen an Ihrem DAX-Code vorzunehmen. Wenn also das Problem darin besteht, dass sich ein Spalten- oder Tabellenname geändert hat, kann es schnell behoben werden, indem der Code alle Kennzahlen durchläuft und Textersetzungen vornimmt.

Abschließende Gedanken

Die Zusammenarbeit in Power BI sollte einfacher werden und wird es hoffentlich bald sein. Es läuft wirklich darauf hinaus, was in Bezug auf die Arbeitsteilung und das effizienteste Zeitmanagement sinnvoll ist. Die besten verfügbaren Tools sind die externen Tools, die ich in diesem Beitrag erwähnt habe: das ALM-Toolkit und der tabellarische Editor, die in jedem Projekt berücksichtigt werden sollten, um die besten Ergebnisse zu erzielen. Wenn das Projekt schließlich abgeschlossen ist und Sie den Bericht verteilen möchten, können Sie aus einigen effizienten Möglichkeiten wählen, Power BI-Berichte mit Endbenutzern zu teilen.