Ursprünglicher Auslöser für diesen Blogbeitrag war die Anfrage eines bei der CKW angestellten Bekannten. Sein Projekt damals im Herbst 2017: Die Mitarbeit bei der Einführung einer Field-Service-Management-Software. Unterstützt werden sollte das Team mit einem «modernen» Projektmodell und «modernen» Tools: Agile, Scrum und mit den Visual Studio Team Services.
Die Themen sind aktueller denn je, deshalb ist es an der Zeit, den Beitrag zu aktualisieren. Die CKW hat übrigens ihr Projekt im Dezember 2019 abgeschlossen und dies auch via Medien entsprechend bekannt gemacht.
Das Projekt als praktische Anwendung
Wie das so ist, bei umfangreichen Softwarelösungen kann man ein Werkzeug fürs Service Management oder für andere umfangreiche Prozesse nicht einfach installieren und nutzen, sondern passt es zunächst an die Bedürfnisse an. Dieser Prozess, das «Customizing», sollte im Rahmen des genannten Projekts abgewickelt werden, und zwar mit einer neuen Methode und zusätzlichen Tools: Agil und mit den Visual Studio Team Services (VSTS). Hier kam ich also ins Spiel. Ich durfte bei der CKW die VSTS vorstellen und ihnen einige Tipps & Tricks mit auf den Weg geben. Davon sollen mit diesem Blogpost auch andere profitieren.
Zuerst: Begrifflichkeiten klären
Das Wort «Agil» kommt aus dem Lateinischen und bedeutet laut Duden «von grosser Beweglichkeit zeugend; regsam und wendig». In der Informatik – bzw. konkret in der Softwareentwicklung – bedeutet «agil» oder englisch «agile» die Orientierung am «Agile Manifesto»:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Das Manifest ist im Jahr 2001 entstanden und seither in verschiedenen Sprachen online abrufbar.
Scrum kommt aus dem Englischen, heisst übersetzt «Gedränge» und hat seinen Ursprung im Rugby-Sport. Die japanischen Schöpfer des Begriffs beschreiben damit das Gedränge im Rugby als Analogie für erfolgreiche Produktentwicklungsteams. Die kleinen, selbstorganisierten Einheiten bekommen von aussen eine Richtung vorgegeben, entwickeln aber ihre eigene Strategie zur gemeinsamen Erreichung der Ziele. Der Name passt perfekt zu diesem Vorgehensmodell, einem Baukasten (Framework), der sich selbst beschreibt als:
lightweight yet incredibly powerful set of values, principles and practices
und konkrete Anleitungen gibt für die Abwicklung von «agilen» Software-Projekten. Scrum wird von der Non-Profit-Organisation «Scrum Alliance» betrieben, deren Website einen guten Einstieg und Überblick anbietet.
Agile, bzw. Agilität ist also die Grundlage für die konkrete Anwendung von Scrum als Prozessmodell mit einer klaren Definition von Rollen und Prozessen.
Scrum im Software-Projekt
Ich muss noch vorausschicken, dass wohl niemand in der realen Welt seine Projekte rein «nach Scrum» durchführt. Einerseits, weil es «das Scrum» nicht wirklich gibt (es ist ja ein Baukasten, Framework) und andererseits, weil die meisten Unternehmen bzw. Teams es auf ihre Bedürfnisse anpassen (Baukasten eben). Scrum akzeptiert, dass der Entwicklungsprozess nicht vorherzusehen ist. Das Produkt ist die bestmögliche Software unter Berücksichtigung der Kosten, der Funktionalität, der Zeit und der Qualität.
Prozesse, Artefakte und Rollen in Scrum
Die in Scrum beschriebenen Prozesse und Artefakte können vereinfacht wie folgt dargestellt werden:
Hauptbestandteil ist der «Sprint», der zwischen zwei und vier Wochen dauert und zur Umsetzung der darin (genannt «Sprint Backlog») enthaltenen «Stories» durch das «Dev Team» dient. Die Stories sind die Beschreibungen der Funktionalität, die die zu entwickelnde Softwarelösung enthalten soll und stammen vom «Product Owner», dem Verantwortlichen für das ganze Produkt. Im «Daily Scrum»-Meeting treffen sich die Teammitglieder täglich zum Informationsaustausch über ihre Ziele und ggf. was dabei im Weg steht. Wichtig ist, dass am Ende eines Sprints immer eine funktionsfähige, getestete, nutz- und auslieferbare Software bereitstehen muss. Weitere Meetings dienen zur Definition, welche Stories im nächsten Sprint umgesetzt werden («Sprint Planning») und zum organisatorischen Rückblick auf den Sprint inkl. Demo der umgesetzten Stories («Sprint Review»). Aus methodischer Sicht überwacht, unterstützt und ggf. in der «Linie» vertreten wird der gesamte Prozess vom «Scrum Master» (Wichtig: Er sollte somit auch die entsprechenden organisatorischen Kompetenzen haben!). All diese Rollen sollten den Teammitgliedern zugewiesen sein und die Meetings entsprechend stattfinden.
Application Lifecycle Management (neu Azure DevOps) – das grosse Ganze
Der bis hierhin beschriebene Prozess zur «Entstehung» der Softwarelösung ist in Organisationen meist eingebettet in einen umfangreicheren Prozess, zu dem auch die Verteilung/Installation, die Überwachung und neue Ideen zur Produkt(weiter)entwicklung gehören. Microsoft nennt dazu den Begriff «Application Lifecycle Management (ALM)». Nannte, muss man präzisieren: Seit Herbst 2018 ist ALM veraltet, Microsoft nutzt mittlerweile den Begriff «Azure DevOps» und stellt den Prozess wie folgt dar:
Zusammengefasst geht es also um die nahtlose Zusammenarbeit, nicht nur (wie bisher, primär dem Softwareentwickler-Team zugeordnet) beim Planen und Bauen der Softwarelösung, sondern auch (und das ist neu) beim fortlaufenden Verteilen/Installieren sowie Betreiben (bisher dem IT-Partner bzw. System-Engineer-Team zugeordnet) in einem gemeinsamen Team.
ALM mit Visual Studio Team Services (neu: Azure DevOps)
Genau diesen «Lebenszyklus» der Applikation unterstützt Microsoft mit den Visual Studio Team Services, bzw. nun Azure DevOps Services wie sie seit 2018 heissen:
Beim Aufrufen zeigt Azure DevOps zuerst ein «Dashboard» als Übersicht an. In der Navigationsleiste links können dann die Bereiche des ALM bzw. DevOps ausgewählt werden:
(Wer genau hingeschaut hat, hat’s gemerkt: Wir arbeiten teilweise mit der lokal installierten Version, dem Azure DevOps Server, vorher Team Foundation Server genannt und teilweise online mit den Azure DevOps Services)
Overview: Individuell anpassbare Startseite des Projekts und Dashboards für den «Management-View»
Boards: Die Verwaltung der Work-Items und deren Zuweisung zum Backlog, zu Sprints und Teammitgliedern
- Stories (einzelne Funktionen des Systems) sind Work-Items aber auch die Zusammenfassung mehrerer Stories als Feature oder als Epic. Weitere Items können natürlich auch Bugs oder allgemeine Tasks sein.
- Vorzugsweise gruppiert man sie zu «Areas» (Softwarebereiche, Module, o.ä.)
Repos: Die Quellcode-Verwaltung, entweder auf Basis des proprietären «Team Foundation Version Control (TFVC)» oder Git
- Ich empfehle, die neuere und verbreitetere Variante «Git» zu nutzen. Sie bietet zudem mehr Funktionalität und ist mit anderen Anbietern kompatibel.
- Pull-Requests bieten sich an zur Etablierung des Vier- oder Mehraugenprinzips als zusätzliche Qualitätskontrolle vor dem «Einchecken» von Code.
Pipelines: Die Verwaltung von automatisierten Builds und Releases der Software
- Das Scrum-Credo «jederzeit funktionierende Software» lässt sich erstens über tägliches (z.B. in der Nacht) automatisiertes Kompilieren und Testen des Codes (auch «Continous Integration» genannt) und zweitens dem Verteilen und ggf. Installieren als Softwarepaket («Continous Delivery») mit entsprechender Freigabe erreichen.
- Besonders bewährt hat sich das automatisierte «builden», damit fehlerhafter Code erkannt und das fehlbare Teammitglied z.B. mit einer Gipfeli-Spende «bestraft» werden kann. 😉
Test Plans: Das Verwalten von Testplänen und den entsprechenden Testdurchläufen
- In Scrum nimmt Testing keine besondere Phase im Prozess ein, als Unterschied zu vielen anderen Modellen. Das Testen gehört immer zur entsprechenden Story dazu (nicht nur das Programmieren).
- Das heisst nicht, dass deswegen nicht strukturiert/dokumentiert getestet werden soll. Es empfiehlt sich die Testfälle (was wie getestet wird) aus der «Rückwärtssicht» (vom Benutzer her) zu erstellen: Also zuerst die umfangreichen Systemtests, dann etwas granularere «Modultests» und dann detaillierte Tests auf Funktionsebene.
- Wichtig ist auch, das Ergebnis der Testfälle als Test-Run zwecks Nachvollziehbarkeit zu dokumentieren.
- Nicht vergessen: Die gefundenen Fehler müssen unbedingt wieder als Work-Items erfasst werden.
Wenn das «Sprint-Review» sorgfältig durchgeführt wird und allfällige Stolpersteine vom «Scrum Master» eliminiert werden können, steht einem erfolgreichen Projektverlauf nichts mehr im Weg. Hoffentlich auch mit dem erwarteten «Output» zur Zufriedenheit des Kunden. So (bzw. so ähnlich denn 1:1 adaptiert wird der Prozess selten) wurde auch bei der CKW im genannten Projekt gearbeitet.
Zum Schluss: Probiere Azure DevOps online kostenlos selbst aus mit einem Beispielprojekt.
Wenn du nicht weiterkommst oder Fragen hast, melde dich einfach hier via Kommentar oder fülle dieses Formular aus für eine umfangreichere Beratung:
