close
AllgemeinCloudDevelopment, CodingTeams, Groups

Online Experience: Agile Entwicklung – MS Graph

Finger mit Knoten - Konzepte - Ideen
Finger mit Knoten - Konzepte - Ideen

Die agile Entwicklung hat den Softwaremarkt im Sturm erobert. Vor allem die Vorteile dieser Form der Entwicklung werden hervor gestrichen, ohne aber dessen Limitationen und Probleme im Gegensatz dazu zu stellen. Besonders die Diskrepanz zwischen Marketing und Umsetzung wird hier gerne völlig außen vor gelassen. Eines der bekanntesten Beispiele dafür im Entwicklerbereich ist MS Graph.

MS Graph

Microsoft (MS) Graph wird aufgrund der agilen Paradigmen laufend erweitert, verändert und angepasst. Nur so kann auf die sich ständig entwickelnde Umwelt reagiert werden, um eine zentrale Rest-Service-Plattform für alle Microsoft Produkte zu schaffen. Auch sollen in diese Welt Softwarelösungen anderen Anbieter mit eingebunden werden können. Grundsätzlich ist das eine tolle Sache und für EntwicklerInnen ein guter Schritt in die Vereinheitlichung der Kommunikation zwischen MS Produkten.

Marketing vs. Realität

Aber, und hier beginnt das eigentlich hausgemachte Problem, die Entwicklung von MS Graph hinkt den Ankündigungen von MS hinterher. Bei diesen Ankündigungen sind viele verleitet zu glauben, dass die Entwicklungen bereits vollständig umgesetzt und fertig zur Verwendung sind. Das trifft aber so gut wie nie zu. Viel mehr beginnt ab der Ankündigung der eigentliche Weg zu einem ausgereiften und gut getesteten Feature. Denn auch wenn ein einzelnes Beispiel präsentiert wird, welches in einem Testszenario funktioniert, ist der Weg in die Arbeitswelt damit noch lange nicht zurückgelegt.

Einige Beispiele für diese Diskrepanz liefert MS Graph im Bereich der API von Teams/Planner/Notes;

  • Wird ein Teams über die API gelöscht, bleibt die diesem Team zugrunde liegende Site Collection bestehen.
  • Wird ein Teams über die API entfernt und hatte einen Planner, dann kann auf diesen nicht mehr zugegriffen werden und er wird auch nicht gelöscht.
  • Planner-Pläne können nicht gelöscht werden. Dieser Aufruf existiert in der API nicht.
  • Wird ein Owner in ein Teams über die API hinzugefügt, dann kann er nicht auf Planner zugreifen.
  • Initialisierungen von Notes Section Groups sind unvollständig, wenn diese über die API hinzugefügt werden.
  • Wenn Teams über die Permissions einer APP hinzugefügt wird, erfolgt dies nicht sofort, sondern kann bis zu 16 Stunden dauern.

Für einige dieser Probleme gibt es Workarounds, für andere nicht. Es zeigt grundsätzlich deutlich, dass die MS Graph API in Entwicklung ist und nicht wie ein vollständiges Produkt nach bisherigen Gesichtspunkten der Softwareentwicklung gesehen werden kann.

Fazit

Ein agiles Softwareprodukt darf nicht mit einem herkömmlichen Softwareprodukt verwechselt werden. Es ist nicht nur in der Entwicklung, sondern auch in seinen Bereichen nicht abgeschlossen. Und genauso ist auch alles, was auf einer agilen Lösung aufsetzt nie ganz abgeschlossen, sondern erfordert auch eine organisatorische Anpassung an das Paradigma der Agilität.

Georg Selig

The author Georg Selig

Georg Selig hat sein Informatik-Studium an der TU-Wien im Jahr 2008 abgeschlossen und ist als SharePoint Senior Developer tätig. Georg bringt mehr als 10 Jahre Berufserfahrung im Bereich der Software-Entwicklung mit Fokus auf Microsoft .net-Sprachen mit. Heute arbeitet er in einem SharePoint Development Team im Bereich der SharePoint Add-On und SharePoint Produktentwicklung in einem Wiener SharePoint und Office 365 Beratungsunternehmen. Im Zuge seiner Arbeit wurden von ihm Produkte für SharePoint 2010, SharePoint 2013, SharePoint 2016 und Office 365 SharePoint Online ins Leben gerufen. Heute beschäftigt sich Georg mit der Erstellung von hybriden Softwareprodukten (Development) für SharePoint 2016, SharePoint Online mit und ohne Azure (PaaS).

Leave a Response

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.