Aufgaben in der Softwareentwicklung

Die Vision wird gemeinsam mit dem Auftraggeber oder der Auftraggeberin formuliert. Dies hilft dabei, die am Projekt Beteiligten zu führen, zu motivieren und zu inspirieren.
Dann soll dargelegt werden, was genau sich verbessern wird wenn das neue Produkt erhältlich ist.
Gemäss dem SMART Prinzip sollen die formulierten Ziele spezifisch, messbar, zuordenbar (assignable), realistisch und zeitbezogen (time related) sein.
Erstellen der Projektorganisation: Es werden alle Bezugsgruppen und deren jeweilige Rollen im Projekt bestimmt. Innerhalb des Projektteams werden folgende Rollen verteilt: Projektleiter, Scrum Project Owner und Scrum Master. 
Es wird festgelegt, wer alles an den Backlog Refinement Meetings und an den Sprint Reviews teilnimmt. Da alle Sprints einen festen Zeitrahmen haben (d.h. sie sind «time-boxed»), können die Daten für die Meetings gleich am Anfang festgelegt werden.

Die Vision für das Projekt sowie dessen Ziele und Organisation werden im Projektmanagementplan festgehalten.

Welche Technologien eignen sich für das Projekt? Formulieren Sie für jede Technologie Kriterien, gewichten Sie jedes Kriterium und bewerten Sie dann jede Option. Idealerweise werden dabei Optionen festgelegt, die mit dem Know-How und den Vorlieben des Teams übereinstimmen. Das Team kann seine volle Leistung nur abrufen, wenn es mit der gewählten Option vertraut ist. In der darauffolgenden Entwicklungsphase wird kaum Zeit sein für das Erlernen neuer Technologien und es ist auch schwierig, den damit verbundenen Lernaufwand abzuschätzen.
Die Evaluation wird im Softwarearchitekturdokument festgehalten

In der Anforderungserhebung (Requirements Engineering) werden in einem ersten Schritt alle bis dahin bekannten Anforderungen zusammengefasst. Dies in einer Form, die für alle am Projekt Beteiligten verständlich ist. Dabei kann mit funktionalen und nichtfunktionalen Anforderungen auf dieselbe Weise verfahren werden.
Für jede Anforderung wird mindestens ein aussagekräftiger Titel und eine kurze, treffende Beschreibung festgelegt. Danach wird jede Anforderung mit einer Priorität und einer Aussage über die Komplexität ergänzt. Das Team sollte die wichtigsten Anforderungen zuerst implementieren, und der Grad der Komplexität erlaubt eine erste Einschätzung des Umsetzungsaufwands.

Zunächst kann eine einfache Tabelle für das anfängliche Product Backlog benutzt werden. Später dann kann ein Tool mit Versionsverwaltung benutzt werden da sich der Inhalt des Backlogs im Verlauf der Zeit verändert.

Die Anforderungserhebung in der Vorbereitungsphase umfasst auch das Refinement (also die Verfeinerung) der Backlog Items die für den ersten Sprint zur Auswahl stehen. Das Refinement beginnt mit der Formulierung von User Stories (Benutzergeschichten) inklusive Abnahmekriterien. Zu umfangreiche Stories werden mittels «Story Splitting» aufgeteilt. Danach werden die detaillierten Anforderungen für jede Story festgelegt. Dies kann z.B. durch die Beschreibung eines Use Cases geschehen, mittels Specification by Example oder einem Storyboard für eine grafische Benutzeroberfläche.

Die Vorbereitung der Anforderungserhebung wird abgeschlossen mir einem Backlog Refinement Meeting zwischen Team und Auftraggeberin oder Auftraggeber. Dadurch erhält das Team die Chance, von Anfang an die richtige Software zu entwickeln.

Die weitere Planung kann beginnen, sobald das anfängliche Product Backlog verfügbar ist. Das Team hat nun eine Vorstellung vom Arbeitsumfang und die nötigen Informationen, um zwei Pläne zu machen: die Roadmap und den Release Plan.

Es legt dann die Definition of Done (DoD) fest, d.h. wann ein Product Backlog Item erledigt ist. Diese DoD ist ein Vertag zwischen Entwickler und Auftraggeberin und stellt sicher, dass alle im Team wissen, was für Ergebnisse vom Team erwartet werden. Es stellt die für das Produkt und Organisation zu erwartende Transparenz und Qualität sicher.

Die Roadmap zeigt die langfristige Planung. Zum Überprüfen der Wirtschaftlichkeit ist sie mit Meilensteinen versehen.
Bei Projekten im Studium skizziert die Roadmap was innerhalb der zur Verfügung stehenden Zeit erarbeitet werden kann. In der Ausbildung ist es gute Praxis, einen Meilenstein in der Mitte des Projektes zu setzen und zu diesem Zeitpunkt das bisher Erreichte zu präsentieren.

Der Release Plan ist ein kurzfristiges, laufend änderndes Artefakt. Es zeigt was nach den nächsten paar Sprints verfügbar ist. Die erste Revision des Release Plans geschieht ausgehend vom anfänglichen Product Backlog. Weil das Product Backlog sich mit der Zeit verändert (neue Items, sich ändernde Prioritäten, ...), wird sich auch der Release Plan ändern.

Das Team stellt sich nun die Frage, was bei der Umsetzung im Weg stehen könnte. Es werden Gefahren mittels Risikomanagement identifiziert und bewertet und, falls nötig, Gegenmassnahmen oder abschwächende Massnahmen festgelegt.  
Je nachdem müssen die beiden Projektpläne angepasst werden, etwa wenn Präventivmassnahmen (z.B. der Bau eines Prototyps) zusätzliche Backlog Items erzeugen.

Pläne, Risikomanagement und DoD werden im Projektmanagementplan festgehalten. 

Wenn es an Zeit und Geld mangelt, liegt Testen nicht drin. Es ist deshalb wichtig, systematisch Testprioritäten mit einer passenden Teststrategie zu definieren.

Eine gute Teststrategie umfasst die folgenden drei Schritte:

1. Testfokus
2. Testpriorisierung
3. Grobe Festlegung der Tests und Testarten

Als Artefakt dokumentiert und legitimiert die Teststrategie diese drei Punkte:

1. Festlegen Testfokus
   Je nach Produkt oder Projekt werden die folgenden Fragen beantwortet:
   - Welche rechtlichen Rahmenbedingungen sind von Belang (Bestimmungen, Datenschutz, Sicherheit, ...)?
   - In welcher Liga befinden wir uns?
   - Was ist die Lebensdauer des Produkts (Lebenszyklus)?
   - Was sind die möglichen Auswirkungen eines Fehlers oder Schadens (gefährdete Personen, Umwelt, Reputation, etc.)?
   - Welche Ressourcen stehen uns zur Verfügung?
2. Priorisierung
   Angemessene Priorisierung stellt sicher, dass das nützlichste Item als erstes getestet wird. Die Strategie bestimmt, wie die Priorisierung zu geschehen hat.
   Risikobasiertes Testen (also Priorisierung anhand von Risiken) hat sich in der Vergangenheit bewährt. Die «RPI-Methode» bietet sich hier als Tool an.
3. Tests, Testarten
   Basierend auf den in Schritt 1 und 2 gewonnenen Erkenntnissen werden in Schritt 3 die nötigen Tests und Testarten als Richtlinie definiert. Der «agile testing quadrant» und die Qualitätskriterien gemäss ISO 9126 sind hier nützliche Hilfsmittel.

Besonderes Augenmerk ist auf die allenfalls nötige Infrastruktur zu legen (s. auch Kapitel «Vorbereitung - Infrastruktur»), insbesondere für Last- und Sicherheitstests und Tests mit sensiblen Daten (Anonymisierung).

Diese Spezifikationen werden dann in der Teststrategie iterativ festgelegt.

Eine Projektablage (Repository) wird angelegt. 
Beim Einsatz von GitLab kann der Inhalt des anfänglichen Product Backlogs ins «Issues»-System verschoben werden.
 
Es wird für jedes Teammitglied eine Entwicklungsumgebung aufgebaut. Mithilfe von Virtualisierung lässt sich sicherzustellen, dass alle Teammitglieder mit denselben Compiler-Versionen, Frameworks, Bibliotheken, Testumgebungen, etc. arbeiten.

Die verbleibenden Dokumentationen werden erstellt und es wird vereinbart, wer sie wie und wann aktualisiert. In der agilen Entwicklung ist es gute Praxis, die gesamte Dokumentation nach jedem Sprint zu aktualisieren. Der «Living Documentation»-Ansatz, wie er von wichtigen Plattformen wie GitLab und GitHub unterstützt wird, gilt aktuell als Vorbild. Diese Plattformen benutzen den Term «Pages».

Die Dokumentation der Entwicklungsinfrastruktur ist Teil des Projektmanagementplans.

Ein Sprint sollte höchstens zwei Wochen dauern, denn schliesslich ist direktes und regelmässiges Feedback ein zentraler Erfolgsfaktor bei der agilen Entwicklung.

Ein Sprint beginnt mit dem Planungsmeeting. Das Team vereinbart, welche Backlog Items implementiert werden. Zur Abschätzung des Aufwands kann es die «Planning Poker»-Methode benutzen.
Die Arbeit wird für jedes ausgewählte Backlog Item weiter in Tasks (Aufgaben) unterteilt, wobei ein Task der Tagesleistung einer Person entspricht. Typische Tasks sind: «Entwerfe das...», «Bereite Datenbank vor», «Programmiere den...», «Automatisiere den Test», ... . Ein Task ist erst erledigt, wenn die entsprechende Dokumentation aktualisiert ist!

Während dem Sprint bewirtschaftet das Team laufend das Product Backlog. Die Verfeinerung (Refinement) der Backlog Items für den nächsten Sprint ist obligatorisch. In der Mitte des Sprints wird ein Refinement Meeting durchgeführt um sicherzustellen, dass alle im Team die detaillierten Anforderungen für den nächsten Sprint verstehen, dass sie von der Kundin oder dem Kunden akzeptiert werden und dass die Annahmekriterien erfasst sind.

Gleichzeitig mit dem Projektfortschritt wächst und verändert sich auch der Testumfang mit jedem Sprint. 
Während sich die ersten Sprints auf Machbarkeit konzentrieren und auf funktionale Tests, die beweisen, dass etwas funktioniert (positive Tests), müssen in den darauffolgenden Sprints weitere Aspekte berücksichtigt und, falls nötig, geplant und umgesetzt werden.
Auch hier bieten sich der Risikoassessment-Standard und die Norm ISO 9126 (Softwarequalität) als Basis an, um die Situation nochmals neu zu überblicken und pragmatisch, respektive auf agile Weise - also im Dienst des grösstmöglichen Nutzens - die Testabdeckung zu erweitern.
Insbesondere ist auf die folgenden Punkte zu achten:

• Konzeption und Aufbau negativer Tests
• Konzeption und Aufbau von Grenzwert- und Ausnahmetests
• Zunehmende Automatisierung von Tests
• Die nötigen Testdaten sind zu bewirtschaften, aktualisieren und erweitern, da sie oft anonymisiert werden müssen (Datenschutz) und jederzeit relevant und im korrekten Format verfügbar sein müssen.
• Die Testinfrastruktur ist zu unterhalten, aktualisieren und erweitern, einschliesslich der notwendigen Autorisierungen und Lizenzen.

Diese Aktivitäten sind ebenfalls ins Product Backlog aufzunehmen, denn was nicht geplant ist, wird auch nicht implementiert.

Am Ende jedes Sprints führt das Team der Auftraggeberin oder dem Auftraggeber die aktuell funktionierende Software auf dem Zielsystem vor und bittet um Feedback. Falls nötig werden neue Backlog Items eingefügt.
Die Sprint Review endet mit einer Vorschau auf den nächsten Sprint. Passt er in den Release Plan oder gibt es Änderungswünsche? Und wie steht es mit den Risiken? Stehen weitere Massnahmen zur Risikominimierung an?

Während der Sprint Retrospektive (Rückschau) identifiziert das Team mögliche Prozessverbesserungen. Es kann ausserdem besprechen, ob die in der Sprint-Planungsphase gemachten Schätzungen korrekt waren und falls nicht, was für Verbesserungsmöglichkeiten es gibt. 

Der geschätzte und der effektive Aufwand für jedes ausgewählte Backlog Item ist im Projektmanagementplan zu vermerken. Die Resultate der Sprint Review, der Retrospektive und eine aktualisierte Risikoliste vervollständigen die Sprint Controlling-Dokumentation.

Definition

Das DevOps Modell kennt keine Trennung zwischen Entwicklungsteams und operationalen Teams.
 
Manchmal werden die beiden Teams in einem einzelnen Team vereint, in dem die Informatikerinnen und Informatiker über den ganzen Anwendungszyklus hinweg tätig sind. Die Aufgaben reichen von der Entwicklung übers Testen, von der Verteilung zum Betrieb. 
Die Bandbreite der Aufgaben und Fähigkeiten ist nicht auf eine einzelne Funktion beschränkt.

Abbildung 4: «DevOps» Prinzip: Die Verknüpfung von Entwicklung und Betrieb sowie der sie unterstützenden Prozesse ermöglicht es Unternehmen, mit der Geschwindigkeit der Entwicklung Schritt zu halten.

In manchen DevOps-Modellen werden auch die Qualitätssicherungs- und Sicherheitsteams stärker in Entwicklung und Betrieb integriert. 

Wenn der Fokus aller Beteiligten in einem DevOPs-Team auf Sicherheit liegt, ist manchmal auch von DevSecOps die Rede.

Diese Teams automatisieren Prozesse, die traditionell langsam und von Hand erledigt wurden. Sie verwenden Technologie-Stacks und Tools, die es ihnen erlauben, Applikationen schnell und verlässlich auszuführen und zu entwickeln. Dank dieser Werkzeuge können Entwicklerinnen und Entwickler zudem unabhängig voneinander Tasks auszuführen, für die sie normalerweise die Hilfe anderer Teams gebraucht hätten. Dadurch kann das Team schneller arbeiten.

 definiert DevOps wie folgt: «DevOps ist eine Sammlung unterschiedlicher technischer Methoden und eine Kultur zur Zusammenarbeit zwischen Softwareentwicklung und IT-Betrieb. DevOps soll durch gemeinsame Prozesse und Software-Werkzeuge eine effektivere und effizientere Zusammenarbeit der Bereiche Softwareentwicklung (Dev), Systemadministratoren (Ops), aber auch Qualitätssicherung und der Nutzerschaft ermöglichen. Mit DevOps sollen die Softwarequalität, die Geschwindigkeit der Entwicklung und der Auslieferung, sowie das Miteinander der beteiligten Teams verbessert werden.»

Tätigkeiten

DevOps-Teams praktizieren täglich:

• Programmierung: Entwicklung und Überprüfung des Codes, Quellcode-Verwaltungstools, Code Merging. Schwerpunkt: Kontinuierliche Entwicklung und Tests. Es braucht kontinuierliche und voll automatisierte Tests.
• Bau: Kontinuierliche Integration von Tools, Baustatus. Schwerpunkt: kontinuierliche Integration und Bereitstellung
• Testen: Kontinuierliche Test-Tools, die schnelles und zeitnahes Feedback zu Geschäftsrisiken ermöglichen. Unterstützt kontinuierliche Entwicklung.
• Paketierung (Packaging): Artefakt-Repository, Applikations-Pre-Deployment Staging. Unterstützt kontinuierliche Lieferung in einem Geschäftsumfeld.
• Releasing: Change-Management, Releasefreigabe und -automation. Unterstützt die kontinuierliche Lieferung und Bereitstellung produktiver Server.
• Konfigurieren: Infrastrukturkonfiguration und -management, Infrastruktur als Code-Tools. Unterstützt den «Infrastruktur als Code» Ansatz.
• Monitoring (Überwachung): Leistungsmonitoring der Applikationen, Endbenutzer-Experience. Schwerpunkt: kontinuierliches Monitoring und Alarmierung, Optimierung der Wiederherstellungszeit-Metrik.

Ein paar zentrale DevOps-Metriken:

• Häufigkeit (Frequenz) der Bereitstellung: Analysiert, wie oft der aktuelle Release der Software in die Produktion geschickt wird. Bereitstellungsautomatisierung ist abgedeckt durch kontinuierliche Bereitstellung und Lieferung. Leistungsfähige Teams erbringen höhere Frequenzen.
• Durchschnittliche Durchlaufzeit: Überwacht die Durchlaufzeit (lead tie tracking) und misst so, wie lang es dauert, eine komplett neue Anforderung zu entwickeln, zu untersuchen, zu liefern und bereit zu stellen. Optimierung der Durchlaufzeit mittels Wertstromansätzen.
• Mittlere Zeit bis zur Wiederherstellung: Misst die Zeit zwischen einer – durch eine Bereitstellung oder durch Systemversagen verursachten – Unterbrechung und der kompletten Wiederherstellung mittels «mean time to recovery (MTTR)» Tracking. Es geht dabei heute mehr um eine effiziente Wiederherstellung und weniger um die mittlere Wiederherstellungszeit. Bei Organisationen, die sich innert Minuten erholen, ist die Ausfallrate selten im kritischen Bereich.
• Ausfallrate: Zeigt an, wie oft die Änderungen eines Teams oder Hotfixes nach der Bereitstellung des Codes zu Fehlern führen.

Microsoft hat eine DevOps-Checkliste veröffentlicht zur Evaluation der eigenen DevOps-Kultur und Prozesse.