Azure DevOps – Projektmanagement mit einem Entwicklertool?

Azure DevOps – Projektmanagement mit einem Entwicklertool?

Der moderne Softwareentwicklungsdienst von Microsoft

Immer wieder begegnen mir Projektleiter, Consultants und natürlich auch Kunden, die mich skeptisch ansehen, wenn ich vorschlage Azure DevOps – ehemals den Team Foundation Server – als Projektmanagement-Werkzeug zu nutzen.

Jede Firma, die das .NET-Framework nutzt, oder mit Microsoft-Technologie entwickelt, kennt diesen Service wahrscheinlich. Die meisten Softwareentwickler in der Microsoft-Welt schwören darauf. Denn der Azure DevOps ermöglicht es Source Code an Artefakte zu hängen. Das wiederrum macht sofort klar, zu welchem Feature welcher Quellcode gehört. Damit wird die Kohärenz für die Softwareentwicklung wesentlich höher. Möchte ein Entwickler wissen, wieso ein Stück Quellcode an dieser Stelle implementiert wurde, kann er auf dem DevOps prüfen, wer dieses Artefakt gebaut hat, und mit welchem Task er verbunden ist. Somit erschließt sich häufig der Zweck einer Funktion.

Natürlich könnte man das auch über Software-Kommentare verstehen, aber bleiben wir realistisch. Im Bereich der Microsoft Softwareentwicklung ist es also der Defacto-Standard. Aber was macht dieses Tool nun zu einem guten Begleiter für normale Consulting-Projekte? Denn natürlich haben wir hier keinen Quellcode, den wir einchecken müssen.

Der zentrale Aspekt von Azure DevOps ist seine Artefaktverwaltung. Wir haben zu jedem Projekt eigene User Stories oder Requirements. Je nachdem, ob wir klassisch oder agil arbeiten. An diese User Stories können wir nun Tasks hängen. Ein Beispiel für eine Kontaktverwaltung in SharePoint:

„Als Vertriebler möchte ich eine Übersicht über alle Kontakte zu meinem aktuellen Kunden, damit ich weiß, wen ich zu welchen Themen anrufen kann.“

Hier könnten wir nun verschiedene Tasks anhängen.

  • Anlage der SharePoint Liste „Kontakte“
  • Anlage der SharePoint Liste „Kunden“

So, gut. Bis hier her könnte es natürlich auch jedes Taskboard schaffen. Jetzt kommen wir zum nächsten Schritt. Denn ich kann nun meine Consultants im Scrum Meeting über diese Tasks gehen lassen. Dort werden wir nun, ganz das agile Mindset vor Augen, die feingranularen Anfoderungen und Akzeptanzkriterien definieren.

  • Anlage der SharePoint Liste „Kontakte“
    • Felder: Vorname, Nachname, Titel, Adresse, Aufgabenbereich
    • Lookup auf Kunde
    • Gruppiert nach Kunde
    • Sortiert nach Nachnamen

Hier sehen wir jetzt schon, dass wir relativ viele Abnahmekriterien haben. Wir sehen in unserem Azure nun alles sauber erfasst und der Consultant schreibt seine Aufwandsschätzung dran. Zum Beispiel 4 Stunden.

In unserem Beispiel haben wir jetzt alle Aufgaben so durchgespielt. Wir haben insgesamt nun Arbeit für 60 Stunden. Auf unserem Scrum-Board sehen wir direkt, dass unsere Kapazität für diesen Sprint nur noch 40 Stunden ist. Also werden wir einen Teil der Aufgaben in den nächsten Sprint verschieben.

Dieses Scrum-Board wird permanent aktualisiert. Wir hätten also bei jedem Scrum-Meeting aktuelle Zahlen. Und zwar nicht nur zum geschätzten Aufwand, sondern die Berater erfassen hier auch ihre tatsächlichen Aufwände.

Wir wissen also auch, wenn Themen wesentlich länger oder kürzer gebraucht haben. Durch diese Zahlen kann man Ursachenforschung betreiben. Außerdem hat man für künftige Projekte eine Datenbasis, sodass man Schätzungen in ähnlichen Fällen validieren kann.

Hier wird schon der Vorteil dieses Entwicklertools Azure DevOps klar. Wir haben jede Menge Daten, die uns einen Big Data Ansatz erlauben. Je mehr Daten unsere Berater erfassen, desto valider können wir künftige Themen beziffern. Und außerdem wissen wir an dieser Stelle immer, wer so etwas schon einmal gemacht hat. Ein Consultant hat eine Frage zu einem bestimmten Thema? Die Volltext-Suche im DevOps zeigt ihm wahrscheinlich recht schnell, wer so etwas schon einmal gemacht hat.

Besonders effizient wird so etwas, wenn unsere Berater Konzepte oder Skripte erstellen. Denn beides lässt sich anstelle von Source-Code ebenfalls in Azure DevOps hochladen und per Volltext durchsuchen. Somit haben wir auch unsere Dokumente immer zentral am Projekt hängen.

Ihr merkt schon, alles geht in die Richtung der Wiederverwendbarkeit. Denn so wie Code oft nur einmal geschrieben, aber oft benutzt wird, kann man das auch mit Dokumenten und Ideenkonzepten machen. Wir erhalten eine mächtige Datenbasis, die uns auf verschiedenen Ebenen weiterführt.

Als nächster Vorteil würde ich den Workflow sehen. Workflow? Ja. Über ein Statusfeld, welches man frei definieren kann, kann man die Aufgaben kanalisieren. Wir erinnern uns an unseren Task Kontaktliste erstellen. Folgende Status könnte man dafür definieren:

  • Definition erstellen
  • Schätzung
  • Umsetzen
  • User-Acceptance Test
  • Kunden-Freigabe
  • Abgeschlossen

So können wir den Zustand unserer Aufgaben immer genau definieren. Sowohl auf User-Story als auch auf Taskebene. Wir vergessen keine wesentlichen Schritte und haben alles sauber dokumentiert. Denn jede noch so kleine Aktion an einem Dokument wird auch im Verlauf gespeichert. Wir können also sofort sehen, wer die Aufgabe auf Kunden-Freigabe gestellt hat und wann. Somit haben wir eine eindeutige Verantwortlichkeit.

Ach ja, die Kunden. Über eine Sonderrolle in Azure DevOps können Stakeholder kostenfrei an einem Projekt teilnehmen. Sie dürfen keine Arbeitselemente ändern, aber sie dürfen Tests durchführen und Bugs und Issues anlegen. Somit also ihrer Rolle als Kunde gerecht werden.

Und wo wir gerade bei Bugs und Issues sind. Auch diese lassen sich sauber in Azure DevOps erfassen und ggf. einzelnen Arbeitselementen zuordnen. Oder man hat sie zentral in der Liste stehen und weiß, dass sie für alles gültig sind. Auch hier mit Eingangsstempel und Bearbeitungsstatus.

Kommen wir final noch zum Reporting. Oft ist es für einen Projektleiter und Projektmitglieder mühsam einen aktuellen Statusreport zu erstellen. Mit Azure DevOps kann man einen eigenen Report erstellen und sofort sehen, welche Elemente noch offen sind und welche abgeschlossen. Wir sehen sofort, welche Elemente aktuell im Test sind und welche auf die Freigabe durch den Kunden warten. Und das in Echtzeit. Nicht nur durch den Projektleiter, sondern jedes Projektmitglied – auch Stakeholder – können sich ihre individuelle Ansicht erstellen.

Den Berater interessiert vielleicht nur, was er gerade noch zu tun hat. Den PM interessiert, wie der Gesamtfortschritt für den aktuellen Sprint ist und wie viele Bugs und Issues noch offen sind. Wie ist unsere Fehlerquote pro fertigen Task? Hier kann man eigene Metriken erzeugen und weiß so, ob wir bei einer Fehlerquote von 2% oder 20% liegen. Alles dynamisch und in Echtzeit.

Und was hat der Berater davon? Er muss sich künftig die Zeiten und den Arbeitsfortschritt nur noch an einer Stelle aufschreiben. Denn über die Excel-Export Funktion kann man daraus direkt einen Zeitnachweis erstellen. Oder man nutzt die diversen Schnittstellen, um die Daten automatisiert in ein anderes Tool zu exportieren. Die Projektzeiten sollen direkt nach Dynamics 365 portiert werden? Mit einem kleinen Flow ist das Ruck-Zuck erledigt.

Und da wir gerade bei Integration sind, natürlich kann man alle Azure DevOps Artefakte auch direkt in Microsoft Teams einbinden. Somit entfällt auch die Hürde, sich mit einem neuen Tool befassen zu müssen. Der Berater braucht nur ein kurzes Briefing. Danach ist es ihm egal, ob er seine Aufgabe im Planner oder im Azure DevOps ablegt. Doch die Vorteile sind, wie beschrieben, gewaltig.

Sie haben Interesse an den Fähigkeiten von AzureDevOps und möchten eine Beratung für Ihren Projektalltag? Vereinbaren Sie einen ersten Kennenlern-Termin. Unsere Experten helfen Ihnen gerne.

Weitereführende Links:

  • https://azure.microsoft.com/de-de/services/devops/

Zur Übersicht

Kontaktformular

 
© 2020 ISD FENIQS GmbH, Ludwigshafen
Es werden Cookies geladen. Details finden Sie in unserer Datenschutzerklärung.