Interview
02.06.2022, 00:00 Uhr
"Dass man auf Git umsteigen sollte, daran führt kein Weg vorbei. "
Wo ist der Team Foundation Server geblieben und welches Versionskontrollsystem sollte man verwenden? Diese Fragen stellte dotnetpro dem Experten für Agilität und Organisation der Softwareentwicklung Neno Loje.
(Quelle: Neno Loje)
Früher, als es noch Mammuts gab, hast du unzählige Entwickler auf den Team Foundation Server geschult. Wer heute nach dem Tool sucht, wird nicht mehr fündig. Kannst du kurz umreißen, was damit passiert ist?
Neno Loje: Der (Visual Studio) Team Foundation Server existiert weiterhin, wurde aber mit der Version 2019 umbenannt in "Azure DevOps Server". Die gehostete Cloud-Variante, bislang bekannt als Visual Studio Team Services, entsprechend zu "Azure DevOps Services". Zeitgleich gab es ein größeres Update an der Oberfläche, um diese auf heutige Standards zu heben.
Die Umbenennung mag ein wenig verwirrend sein, insbesondere weil nun Azure im Produktnamen vorkommt - ohne dass sich am Server etwas ändert, oder man Microsofts Azure Cloud nutzen müsste - aber natürlich kann. Laut Microsoft wollte man den Server vor allem für neue Zielgruppen attraktiver machen, zum Beispiel für Unternehmen, die Microsoft Azure nutzen und nach einer Lösung suchen, um Änderungen in der Cloud-Infrastruktur professionell zu verwalten, zu versionieren und auszurollen.
Ungeachtet dessen kann man mit Azure DevOps weiterhin alle Arten von Anwendungen, von Windows über Mobile bis Web, verwalten, für beliebige Sprache und Technologien. Es gibt Unterstützung für alle gängigen Cloudanbieter.
Wie sieht es mit der Quellcode-Verwaltung darin aus? Das war ursprünglich eine selbstprogrammierte von Microsoft. Aber inzwischen muss man die wohl nicht mehr verwenden?
Neno Loje: Genau. Gab es früher nur die Team Foundation Version Control (TFVC), so hat man mittlerweile die Wahl: In jedem Teamprojekt kann man sowohl die klassische TFVC nutzen als auch Git-Repositorys. In der Praxis erlaubt einem das in jedem Projekt selbst zu entscheiden, wann man mit welchem Teil seiner Software umsteigt.
Dass man auf Git umsteigen sollte, daran führt meines Erachtens kein Weg vorbei. Microsoft selbst hat alle relevanten Projekte - inklusive Schwergewichte wie den Windows-Quellcode - bereits umgestellt. Einer der treibenden Faktoren dabei war vor allem, dass man auf Basis von Git die Arbeitsweisen neu gedacht hat. Mit Hilfe von kurzlebigen (Feature)-Branches, Pull Requests und Branch Policies kann man mit mehreren Personen effizient arbeiten und gleichzeitig die Qualität hochhalten.
Du hältst auf der Developer Week einen Workshop zu Azure DevOps. Was lernen die Teilnehmer darin?
Neno Loje: In einem Satz: es geht darum, wie man ein Entwicklungssystem aufsetzt, mit dem man in kleinen wie auch großen Teams möglichst reibungsfrei gemeinsam erfolgreich Software entwickeln kann. Denn heutzutage wird Softwareentwicklung immer vielschichtiger: Es gibt immer mehr Aspekte zu berücksichtigen (wie zum Beispiel Security, UX, etc.), die Breite an Technologien, die zum Einsatz kommen, nimmt zu (nach dem Motto: die passende Technologie für die jeweilige Aufgabe) und externer Code (Stichwort: Bibliotheken, insbesondere auch Open-Source-Komponenten) macht in vielen Projekten den Großteil der gesamten Codezeilen aus.
Dies zu beherrschen, gerade auch in kleineren Teams, ist ohne einen hohen Grad an Automatisierung und passenden Arbeitsweisen kaum mehr zu stemmen. Hier kommt dann Azure DevOps ins Spiel. Der Workshop richtet sich also genau an die, die Azure DevOps optimal als Entwicklungsumgebung für das eigene Team beziehungsweise Unternehmen einrichten wollen.
Eine weitere Session, die du zusammen mit Nico Orschel hältst, stellt GitHub Actions vor. Wo liegt deren Unterschied zu Azure DevOps?
Neno Loje: Durch den Zukauf und konsequenten Ausbau von GitHub besitzt Microsoft nun zwei umfangreiche Plattformen für die Softwareentwicklung: Azure DevOps und eben GitHub. GitHub Actions sind das Pendant zu Azure Pipelines, mit dem man Build- und Releaseprozesse entwerfen und automatisieren kann. Doch die folgenden Punkte machen GitHub Actions aus meiner Sicht besonders spannend:
- Es handelt sich um die derzeit wohl größte öffentliche Build-Infrastruktur der Welt.
- Die Nutzung nahm in kürzester Zeit stark zu, sodass sich eine große Community gebildet hat, die neue Erweiterungen (zum Beispiel neue Befehle, die sogenannten "Actions") täglich herausbringt.
- Die Breite an Einsatzmöglichkeiten ist riesig – es hört nämlich nicht bei Build-/Releaseprozesse (CI/CD) auf, sondern man kann auf sämtliche Ereignisse mit Automatisierung reagieren.
Gerade der letzte Punkt ist hochgradig spannend: Als Produktverantwortlicher könnte ich einen Teil meiner Arbeit automatisieren und zum Beispiel automatisierte Release Notes erstellen, wenn ein Feature abgeschlossen ist. Die Liste an Möglichkeiten ist lang – ein paar konkrete Beispiele liefern wir im Vortrag.
Requirements zerstören die Agilität - behauptest du zumindest mit Thomas Schissler im Titel einer Session. Wie kann aber ein Projekt entstehen, wenn es keine Anforderungen gibt?
Neno Loje: Wir beobachten, dass der Begriff Requirement in vielen Teams dazu führt, dass man davon ausgeht, dass es da jemanden gibt, der genau weiß, was die Software tun soll. Wenn wir genau das implementieren, wird eine gute Software entstehen, die unsere Nutzer(innen) zufrieden macht - so die irrtümliche Schlussfolgerung.
Wir plädieren dafür, dass die Aufgabe eines Entwicklungsteams nicht nur aus der Abarbeitung von Bestellungen, sondern eben gerade auch darin besteht, die Wünsche und Ideen auf dem Backlog zu hinterfragen und gerne auch alternative Lösungen aufzuzeigen. Das macht unserer Erfahrung nach nicht nur mehr Spaß, sondern führt auch häufig zu smarteren, durchdachteren Softwarelösungen.
Gibt es trotzdem ein Happy End zwischen Anforderungen und Agilität?
Neno Loje: Agilität heißt für uns, dass es nicht den endgültigen Zustand gibt, wie eine Software oder ein Feature optimalerweise aussehen sollte. Statt in Anforderungen denken wir lieber in Wünschen und Ideen auf dem Backlog und betrachten diese erstmal als Annahmen, von denen wir glauben, dass damit die Software den Bedürfnissen der Anwender(innen) gerechter wird. Ob die erhoffte Verbesserung letztlich eintritt, ist so lange unklar, bis das Feature ausgeliefert und produktiv genutzt wird.
Dafür wollen wir im ersten Schritt verstehen, wie die Nutzer(innen) arbeiten und entwickeln dann im Anschluss als Team, also gemeinsam mit den Entwicklern/-innen, Ideen für mögliche Features, um diese Arbeitsweisen zu unterstützen beziehungsweise die Prozesse zu digitalisieren und optimieren.
Um mögliche negative Überraschungen zu vermeiden kann es lohnend sein, sich kleinere Features zu überlegen, die zwar nicht den gesamten gewünschten Funktionsumfang abdecken, aber ein kleines Stück in die richtige Richtung gehen und diese Features zeitnah auszuliefern, um so einen Erkenntnisgewinn zu erlangen, wo die Annahmen korrekt waren beziehungsweise wo noch weitere Experimente nötig sind, um eine passgenaue Umsetzung zu finden, die unsere Anwender(innen) begeistert).
Dies ist unserer Meinung nach einer der größten Vorteile der agilen Softwareentwicklung und ein echter Hebel für mehr Produktivität, da es nicht darum geht, möglichst viele neue Feature zu programmieren, sondern sich zu fokussieren und diese an den Bedürfnissen der Nutzer(innen) auszurichten.
Neno Loje ist selbstständiger Berater und Professional Scrum Trainer. Mit großer Leidenschaft unterstützt er große wie kleine Unternehmen und Teams dabei, agiler zu werden, das Risiko zu minimieren, mehr zu automatisieren und mit pragmatischen Lösungen den Alltag aufzuwerten. Seine Schwerpunkte sind dabei Microsofts Azure DevOps (ehem. TFS) sowie Scrum.
Developer Week ist die große Entwicklerkonferenz in Nürnberg. Fünf Tage lang können sich Softwareentwickler zu Themen wie Architektur, .NET, Web, Datenbanken oder Softskills fortbilden. 150 Sprecher, 30 Themenstränge, DevSessions und Workshops formen das Programm. Sie findet dieses Jahr vom 4. bis 8. Juli statt.
