Moderne Softwareentwicklung

Transcription

Zusammenfassung
Ingo Grebe
Juni 2014
Quelle: MVA – Moderne Softwareentwicklung
Link: http://www.microsoftvirtualacademy.com/training-
courses/moderne-softwareentwicklung
Autor: Thomas Schissler
Das Dokument ist eine Zusammenfassung des MVA Kurses „Moderne Softwareentwicklung“. Autor
des Kurses ist Thomas Schissler. Der Kurs kann unter folgenden Link absolviert werden:
http://www.microsoftvirtualacademy.com/training-courses/moderne-softwareentwicklung
Inhalt
1
Überblick ......................................................................................................................................... 4
1.1
Waste – Verschwendung ......................................................................................................... 4
1.1.1
2
1.2
Qualität .................................................................................................................................... 6
1.3
Effektive Team-Arbeit.............................................................................................................. 6
Projektmanagement ........................................................................................................................ 7
2.1
Scrum ....................................................................................................................................... 7
2.1.1
3
Bedarfsgerechte Lösungen .............................................................................................. 4
Product Owner ................................................................................................................ 8
2.2
Agiles Projektmanagement mit TFS ........................................................................................ 9
2.3
Agiles Anforderungsmanagement ......................................................................................... 10
2.4
Mehrere Teams / Mehrere Projekte ..................................................................................... 11
2.5
Release-Monitoring ............................................................................................................... 11
2.5.1
BPMN-Prozess ............................................................................................................... 11
2.5.2
Schätzung der Szenarien ............................................................................................... 12
2.5.3
Schätzen des Fertigstellungsgrades............................................................................... 12
Testmanagement........................................................................................................................... 14
3.1
Test-Management mit dem TFS ............................................................................................ 14
3.2
Wie entsteht Qualität? .......................................................................................................... 14
3.3
Team Organisation ................................................................................................................ 15
3.4
Automatisiertes Testen ......................................................................................................... 15
3.4.1
Unit-Testing ................................................................................................................... 15
3.4.2
Load & Performance Tests ............................................................................................ 16
3.5
Exploratives Testen ............................................................................................................... 16
Seite 2 / 28
4
5
Projektkommunikation .................................................................................................................. 16
4.1
Anforderungen verstehen – Bedarfsgerechte Lösungen ...................................................... 16
4.2
Stakeholder einbeziehen ....................................................................................................... 17
4.3
Kommunikation im Projekt.................................................................................................... 18
4.3.1
Feedback Client ............................................................................................................. 18
4.3.2
Storyboarding Tool ........................................................................................................ 18
4.3.3
Kommunikation zwischen Deveoplment Team und Product Owner ............................ 18
4.4
Kommunikation und Wissensverteilung im Team ................................................................ 18
4.5
Team Rooms .......................................................................................................................... 19
Erweiterbare Architektur............................................................................................................... 19
5.1
Testbare Architektur ............................................................................................................. 20
5.1.1
Software-Architektur ..................................................................................................... 20
5.1.2
Komponentenorientierte Architektur ........................................................................... 21
5.1.3
Legacy-Code .................................................................................................................. 22
5.2
Modelle im Agilen Kontext .................................................................................................... 22
5.3
Agile Architektur .................................................................................................................... 23
5.3.1
6
Continous Delivery & Dev Ops ...................................................................................................... 23
6.1
8
Build-Measure-Learn ............................................................................................................. 24
6.1.1
Release Management 2013 ........................................................................................... 24
6.1.2
Measure – Feedback und Telemetry ............................................................................. 25
6.2
7
Architektur-Tools in Visual Studio ................................................................................. 23
Fehler in der Produktivumgebung finden ............................................................................. 26
Entwickler-Produktivität................................................................................................................ 26
7.1
Versionskontrollsystem ......................................................................................................... 26
7.2
Visual Studio IDE Features ..................................................................................................... 27
7.3
Performance Tools ................................................................................................................ 27
Team Power................................................................................................................................... 27
Seite 3 / 28
1 Überblick
Moderne Softwareentwicklung besteht aus:








Anforderungsmanagement
Qualitätssicherung
Stakeholder (Kunden) einbeziehen
App-Telemetrie: Verstehen, wie die Software verwendet wird. Verstehen, womit die Kunden
Probleme haben.
Continous Delivery: Interne Prozesse, um kurze Zyklen zu ermöglichen durch hohen
Automatisierungsgrad.
Erweiterbare Architektur: Schlüsselelement, um gewachsene Produkte effizient weiter zu
entwickeln.
Entwickler-Produktivität: Steigerung der Produktivität durch besseres Verstehen der
Entwicklertools.
Developer Operations: Grenze zwischen operativen Betrieb von Software und der
Entwicklung. Es geht z.B. um das Deployment (Software zur Produktion bringen) und das
effiziente Zurückleiten von Problemfällen.
Moderne Softwareentwicklung benötigt einen guten Mix aus



Tools: TFS (für Test-Automatisierung)
Prozesse: SCRUM
Praktiken: Clean Code, Unit-Testing, TDD
1.1 Waste – Verschwendung
Alles was das Projekt oder das Team nicht weiterbringt, aber trotzdem getan wird ist Waste.
Waste kann durch drei Aspekte identifiziert, reduziert oder sogar vermieden werden:



Bedarfsgerechte Lösungen: Kundenorientiert Software entwickeln: Nur das entwickeln, was
Kunde braucht. Man muss sich auf die Aspekte konzentrieren, die mehr Kundennutzen
generieren.
Qualität optimieren: Die Software macht was sie soll ohne Fehler.
Effiziente Teamarbeit
1.2 Bedarfsgerechte Lösungen
In der klassischen Softwareentwicklung wird mit einem ausgereiften Plan entwickelt. Dies funktioniert
nicht wirklich, weil nicht das Produkt entsteht, welches sich der Anwender tatsächlich vorgestellt hat.
Daher wurde Build-Measure-Learn eingeführt, um bedarfsgerechte Lösungen zu entwickeln.
Seite 4 / 28
Dabei wird möglichst schnell eine Funktionalität umgesetzt, dem Kunden präsentiert und „gemessen“,
ob das Ergebnis dem Kundenwunsch entspricht bzw. ob der Kundennutzen möglichst hoch ist. Es wird
nicht durch langes Nachdenken fertige Software entworfen. Vielmehr werden durch kleine
Experimente in Zusammenarbeit mit dem Kunden Funktionalitäten erstellt, die im Gesamten die
fertige Software ergeben.
Anders gesagt: Früher hat man sich ein Feature überlegt und dieses mit all seinen Möglichkeiten
implementiert und anschließend dem Kunden präsentiert. Heute wird das Feature mit so wenig
Möglichkeiten wie nötig implementiert und dem Kunden präsentiert. Anschließend wird mit dem
Kunden gemeinsam besprochen, welche zusätzlichen Möglichkeiten noch implementiert werden
müssen.
Sequentielle Entwicklung vs. Überlappende Entwicklung
In der modernen Softwareentwicklung werden immer kürzere Release-Zyklen angestrebt. Früher
wurde ein Produkt alle ein bis zwei Jahre veröffentlicht. Heut zu Tage gibt es Zyklen von vier oder sogar
zwei Wochen.
Dies ist möglich wenn man sich von der sequentiellen Entwicklung löst und eine parallele Entwicklung
durchführt.
Sequentielle Entwicklung (Wasserfall-Methode):
Überlappende Entwicklung (Scrum):
Die agile Entwicklung (oder inkrementelle Entwicklung) ermöglicht ab einem bestimmten Zeitpunkt
die (qualitativ hochwertige) minimale Funktionalität der Software zu präsentieren. Bei der WasserfallMethode ist dies nicht möglich. Hier kann erst zum Entwicklungsende die komplette Funktionalität
präsentiert werden.
Dadurch ermöglicht die inkrementelle Entwicklung eine schnellere Markteinführung:


Als erster mit einem neunen Produkt auf dem Markt sein
Schnell reagieren können, wenn der Markt sich verändert
Man könnte die minimale Funktionalität als Basis nehmen und dem Kunden zur Verfügung stellen. Der
Kunde kann damit bereits arbeiten und erhält in kurzen Zyklen weitere Funktionen.
Seite 5 / 28
1.3 Qualität
Entscheidend für die Qualität ist die Effizienz. Je später ein Fehler gefunden wird, desto aufwendiger
ist es diesen zu beheben.
Man muss bereits beim Entwicklungsprozess eine hohe Qualität ins Produkt einbauen. Dies ist möglich
nach dem Einchecken beim Buildprozess. Dort sollte man schon 70% bis 90% Qualität erreicht haben.
Die restlichen 30% bis 10% ergeben sich durch ausgelagertes Testen.
Bisher war es so, dass nach der Implementierung das Testing begonnen wurde und die Testabteilung
für die Qualitätssicherung zuständig war. Davon muss man sich lösen. Die Entwickler müssen
Verantwortung übernehmen und ins Testing mit aufgenommen werden. Im Idealfall gibt es keine
Unterscheidung mehr zwischen Tester und Entwickler.
1.4 Effektive Team-Arbeit
Viele Teams sind eher Arbeitsgruppen aber keine richtigen Teams. Jeder hat seinen Arbeitsbereich und
kümmert sich nicht um die Arbeitsbereiche anderer Mitglieder. Das darf nicht sein. Jeder muss in (fast)
allen Bereichen arbeiten können. Dadurch entsteht automatisch eine gegenseitige Kontrolle. Durch die
gemeinsame Entwicklung der Features ergänzen sich die Talente/Fähigkeiten (z.B. einer entwickelt
langsam aber achtet auf Qualität und der zweite entwickelt schnell achtet aber nicht auf Qualität) der
Teammitglieder. Unterm Strich ergibt dies ein besseres Produkt.
Seite 6 / 28
2 Projektmanagement
2.1 Scrum
Scrum ist ein Prozessframework. Es definiert keinen Prozess. Es stellt Praktiken zur Verfügung, um
einen Prozess zu definieren.
Dwight D. Eisenhower: „Ein Plan ist nichts, Planung ist alles“
Es geht nicht darum einem festen Plan zu folgen. Es geht darum durch kontinuierliche Anpassung des
Plans zu sehen, was aus heutiger Sicht möglich ist und wie auf bestimmte Situationen reagiert werden
kann. Es kommt auf den Planungsprozess an sich an.
In Scrum gibt es drei Rollen:



Product Owner: Er sorgt dafür, dass das Development Team mit seinem Einsatz den maximalen
Kundennutzen erzielt. Der Product Owner ist genau eine Person.
o Er kennt alle PBIs.
o Er sortiert die PBIs nach ihrer Wichtigkeit.
Development Team: Das Team besteht aus allen Personen, die der Product Owner benötigt,
um die Anforderungen umzusetzen. Dazu gehören z.B. Softwareentwickler, Architekten und
Tester. Das Team ist selbstorganisiert. Es gibt keine Person außerhalb des Teams, die es leitet.
Alle haben die gleichen Rechte und Pflichten.
o Arbeitet das Product Backlog von oben nach unten ab.
Scrum Master: Er ist ein Coach für den Product Owner und das Development Team. Er
unterstützt beide Rollen darin ihre Aufgaben bestmöglich zu erledigen und sich weiter zu
entwickeln. Er sorgt dafür, dass die Scrum Regeln eingehalten werden.
Ein Release ist ein lauffähiger Softwarestand zu einem bestimmten Zeitpunkt. Es muss keine
Auslieferungsversion sein. Es kann z.B. auch ein interner Meilenstein sein. In einem Release gibt es
folgende Scrum Artefakte:










Product Backlog: Enthält die Anforderungen, die in einem Release realisiert werden sollen.
Product Backlog Item (PBI): Eine Anforderung im Backlog.
Release Planning Meeting: Hier werden die PBIs besprochen. Dadurch kann es passieren, dass
PBIs genauer beschrieben werden, oder aber auch verworfen werden.
Backlog Refinement Meeting: Findet ca. alle zwei Wochen statt. Hier wird die
Weiterentwicklung des Backlogs besprochen. Es werden neue PBIs vorgestellt und die
Sortierung des Backlogs besprochen.
Impediments: Dinge, die den Product Owner oder das Development Team davon abhalten,
ihre Arbeit mit maximaler Performanz zu erledigen. Wenn beide Rollen die Impediments nicht
abstellen können, dann wird der Scrum Master zur Hilfe hinzugezogen.
Release Burndown (oder Burnup): Wird genutzt um den Stand des Releases zu dokumentieren.
Sprints: Kurze Iterationen von ca. 30 Tagen. Fester Zeitabschnitt. Ein Sprint endet dann, wenn
die Zeit abgelaufen ist und nicht wenn die gesetzten Anforderungen abgearbeitet sind.
Sprint Planning 1: Product Owner und Development Team entscheiden, welche PBIs im Sprint
1 bearbeitet werden sollen. Hierbei fliest die Sortierung des Backlogs mit ein. Die Anzahl der
zu bearbeiteten PBIs im Sprint 1 wird vom Development Team festgelegt.
Sprint Planning 2: Das Development Team erstellt eine Realisierungsvision. Es bespricht, wie
die PBIs umgesetzt werden können und erstellt dafür Tasks.
Daily Scrum: Das Team arbeitet danach in einem täglichen Rhythmus. Der Tag beginnt mit
einem Daily Scrum Meeting. Es werden die abgearbeiteten Tasks und PBIs, sowie die als
nächstes abzuarbeiteten Tasks vorgestellt. Es wird geprüft, ob das Sprintziel erreicht werden
Seite 7 / 28





kann. Es wird besprochen, ob es Probleme im Team gibt, die sofort gelöst werden können oder
ob ein Impediment angelegt werden muss.
Sprint Burndown: Eine Kurve, die den weiteren Verlauf der Tasks im Verhältnis zur Zeit angibt.
Sie lässt erkennen, ob die Tasks rechtzeitig abgearbeitet werden können.
Definition of Done: Wird vom Development Team in Rücksprache mit dem Product Owner für
jedes PBI erstellt. Es gibt an, wann ein PBI definitiv abgearbeitet ist (keine Restarbeiten mehr
notwendig sind). Dazu gehören unter anderem Testläufe und Codereviews.
Increment: Ergebnis des Softwareprodukts nach Ablauf des Sprints.
Sprint Review: Das Development Team präsentiert dem Product Owner und den Stakeholdern
das Ergebnis des Sprints. Darauf basierend besprechen Product Owner und Stakeholder, wie
es mit dem Produkt im nächsten Sprint weitergeht. Daraus ergeben sich wichtige
Informationen für das nächste Sprint Planning 1 und Sprint Planning 2.
Sprint Retrospective: Hierbei treffen sich Product Owner, Development Team und Scrum
Master und besprechen, wie der letzte Sprint verlaufen ist (positives, negatives,
verbesserungswürdiges).
2.1.1 Product Owner






Die Produktvision des Product Owners ist entscheidend dafür, ob der Nutzen, den das
Development Team erzielen kann, hoch oder niedrig ist.
Setzt er die falschen Schwerpunkte, dann hat er eine falsche oder schlechte Produktvision.
Dies führt dazu, dass das Scrum Team mit dem Projekt scheitert oder zumindest nicht den
maximal möglichen Erfolg erzielt.
Er muss mit dem Development Team kommunizieren und die Sicht der Anwender vermitteln.
Damit im Development Team klar ist, wie später mit der Software gearbeitet werden soll und
wie sich die Kunden die Software vorstellen und welche Erwartungshaltung sie haben.
Er muss die PBIs priorisieren und Entscheidungen auf Rückfragen vom Development fällen.
Er muss mit den Stakeholdern kommunizieren, um den aktuellen Projekt-Status zu vermitteln
und den Unternehmens-Nutzen zu maximieren. Er muss verstehen, worauf es den
Stakeholdern ankommt.
Er muss mit möglichst vielen potentiellen Anwendern kommunizieren, um zu verstehen wie
die Anwender die Software einsetzen möchten und wodurch ein Kunden-Nutzen entsteht. Er
muss die Neuerungen zu den Anwendern tragen und Feedback einholen.
Seite 8 / 28
2.2 Agiles Projektmanagement mit TFS
Das Agile Projektmanagement kann mit dem TFS 2012 durchgeführt werden.
Backlog Management
 Es gibt zwei Elementarten für das Backlog
o Product Backlog Item: Neue Anforderung
o Bug: Korrektur bestehender Anforderung
Schätzung und Forecasts (Vorhersagen)
 Für jedes Element gibt es einen Effort (Aufwandschätzung). Dieser wird z.B. in Storypoints
gemessen. Es geht nicht darum Tage oder Stunden anzugeben. Es geht darum eine Möglichkeit
zu haben, den Aufwand der verschiedenen Elemente im Backlog zu unterscheiden.
o Planning Poker: Mittels Planning Poker werden im Development Team die Storypoints
für ein PBI vergeben. Jedes Teammitglied schreibt eine Anzahl an Storypoints auf eine
Karte. Alle decken ihre Karte zeitgleich auf. Der mit der höchste Zahl und der mit der
niedrigsten Zahl müssen erklären, warum sie sich für diese Anzahl entschieden haben.
Anschließend gibt es eine zweite Runde, in der alle ihre Karten erneut ausfüllen und
aufdecken. Die am meisten vorhandene Zahl wird dann als Effort genommen.
 Man hat eine Ansicht, wie viele Storypoints in den vergangenen Iterationen abgearbeitet
wurden.
 Man kann eine Vorhersage einschalten, um abzuschätzen welche PBIs in den nächsten Sprints
abgeschlossen werden. Dafür kann man einen Velocity-Wert (Geschwindigkeit) einstellen, um
zu sagen, wie viele Storypoints in Zukunft pro Iteration abgearbeitet werden.
Seite 9 / 28
Empirisches Projektmanagement
Scrum basiert auf empirischen Betrachtungen. Es wird versucht aus der Vergangenheit eine Prognose
für die Zukunft zu erstellen.


Projektion der Vergangenheit zur Vorhersage der Zukunft
Messung des Fortschritts um Prognosen den aktuellen Gegebenheiten anzupassen
Sprintplanung
 Anhand der Vorhersagen können die PBIs den Sprints zugeordnet werden.
 Durch das Sprint Planning 2 ergeben sich Tasks zu den PBIs, die dann im Sprintbacklog zu den
PBIs angelegt werden.
 Zu jedem Task kann Remaining Work (verbleibende Arbeit in Stunden) angegeben werden.
 Zu jedem Sprintbacklog gibt es eine Board-Ansicht. Hier werden die Tasks als Zettel
repräsentiert und dem Status ToDo, In Progress oder Done zugeordnet. Die Board-Ansicht
bietet zu jeder Zeit jedem im Development Team einen Überblick über die Tasks, die erledigt
sind, die gerade bearbeitet werden und die noch zu erledigen sind. Damit ist das Board ein
wichtiges Werkzeug für das Daily Scrum Meeting.
 Es kann ein Sprint-Burndown eingeblendet werden. Dieses zeigt eine Kurve, wie sich der
Arbeitsaufwand im weiteren Sprintverlauf verändert (steigt oder fällt).
Kapazitätsplanung
Anhand der Angabe der verbleibenden Stunden in jedem Task zeigt der TFS an, ob die Arbeit noch im
Sprint vollendet werden kann. Dies wird durch folgende Angaben berechnet:


Dauer des Sprints (in Tagen)
Kapazität (Capacity) der einzelnen Teammitglieder pro Tag. Es werden Stunden angegeben,
die ein Teammitglied pro Tag effektiv am Projekt arbeiten kann. Zusätzlich können pro Mitglied
Urlaubs-/Krankheitstage (Days Off) angegeben werden. Sowie Feiertage im Sprint fürs
gesamte Team (Team Days Off).
2.3 Agiles Anforderungsmanagement
Beim Agilen Anforderungsmanagement geht es darum, dass Anforderungen unterschiedlich detailliert
beschrieben werden. Anforderungen werden zunächst sehr grob beschrieben. Je dichter sie an den
Augenblick der Abarbeitung rücken, desto detaillierter werden sie beschrieben. Dies hat den Vorteil,
dass das Backlog zunächst recht klein ist und sich erst im Laufe der Zeit ausdehnt bzw. erst dann, wenn
es tatsächlich um die Umsetzung geht.
Eine Anforderung wird als komplexes (grob geschriebenes) PBI erstellt [blaues Dreieck]. Wenn die
Umsetzung näher rückt, dann kann dieses PBI in mehrere PBIs heruntergebrochen werden [orangenes
Dreieck]. Kurz vor der Implementierung werden dann detailliertere PBIs angelegt [Kreis].
Seite 10 / 28
2.4 Mehrere Teams / Mehrere Projekte
Um mit mehreren Teams im TFS zu arbeiten gibt es ein Master Backlog. Aus dem Master Backlog
werden die Anforderungen auf die Team Backlogs verteilt. Dadurch ist ein Load Balancing möglich.
Um Anforderungen aus mehreren Projekten abzuarbeiten, wird für jedes Produkt ein Backlog erstellt.
Der Product Owner fasst die Anforderungen aus den einzelnen Produkt Backlogs in einem
gemeinsamen Backlog (oder Team Backlog) zusammen. Dadurch kann die Wichtigkeit der Entwicklung
der unterschiedlichen Produkte festgelegt werden.
2.5 Release-Monitoring
2.5.1 BPMN-Prozess
In einem Softwareprodukt gibt es bestimmte Arbeitsabläufe. Diese können mittels BPMN (Business
Process Modelling Notation) visuell relativ leicht dargestellt werden. In so einer Notation kann man
darstellen, welche Teilfunktionen bereits umgesetzt wurden. Dadurch kann der Fortschritt der
Implementierung eines Arbeitsablaufes dokumentiert werden.
Seite 11 / 28
2.5.2 Schätzung der Szenarien
Hat man mehrere Anwenderszenarien mittels BPMN dargestellt, dann kann man anhand der
Komplexität der einzelnen Szenarien im Verhältnis zueinander sagen, wie sich die Entwicklungszeit
über die Release-Dauer verteilt. Es geht an dieser Stelle nicht darum feste Zeiträume mittels Sprint
Planning zu definieren, sondern Zeiträume anhand der Komplexität der einzelnen Szenarien im
Verhältnis zueinander festzulegen.
Daraus ergeben sich Fragen an den Product Owner und die Stakeholder über den Nutzen der einzelnen
Szenarien:


Wie groß ist der Nutzen der Szenarien im Verhältnis zueinander (Invest)?
Ist der Nutzen von Szenario 1 genau so groß wie der Nutzen von Szenario 2, 3 und 4
zusammen?
2.5.3 Schätzen des Fertigstellungsgrades
Aus diesen Schätzungen kann für jedes Szenario der Fertigstellungsgrad geschätzt werden.



Anhand des Sprintbacklogs ist die erledigte Arbeit eines Szenarios bekannt.
Anhand des Sprintbacklogs ist die geplante Arbeit (die PBIs) eines Szenarios bekannt.
Da nicht nach Wasserfall-Methode gearbeitet wird und daher zu Beginn des Releases nicht
jede Anforderung durchgeplant wird, bleibt etwas ungeplante Arbeit übrig. Diese kann
geschätzt werden.
Hat man für jedes Szenario die Fertigstellung geschätzt, dann kann man dies als Release Monitoring
grafisch darstellen (Scenario Fulfillment). Anhand dieser Grafik sieht man pro Szenario wieviel bereits
fertig ist, wieviel am Ende des Sprints abgeschlossen ist und wieviel Arbeit noch übrig ist. In Absprache
mit dem Product Owner kann dann festgelegt werden, wie die restliche Arbeit auf die einzelnen
Szenarios aufgeteilt wird.
Seite 12 / 28
Mittels Release Burndown (Scenarios Progress) Grafik kann diskutiert werden, wie die Releaseziele
erreicht werden können. Die Lösung, dass die Entwickler schneller arbeiten oder Überstunden machen
müssen darf nicht angestrebt werden.
Seite 13 / 28
3 Testmanagement
3.1 Test-Management mit dem TFS
Akzeptanztests
Zu jedem Backlog Item werden Akzeptanzkriterien angegeben, die beschreiben unter welchen
Voraussetzungen das Backlog Item als erfüllt gilt. Die Akzeptanzkriterien werden vom Product Owner
aufgestellt.
Ein Akzeptanztest stellt sicher, dass die Akzeptanzkriterien erfüllt sind. Akzeptanztests können schon
vor Beginn der Implementierung definiert werden. Sie stehen dann dem Entwickler als
Implementierungsgrundlage zur Verfügung. Dieses Vorgehen nennt sich ATDD (Aceptance Test Driven
Development). Anhand der Beschreibung der Akzeptanztests weiß der Entwickler, wie der
Arbeitsablauf sein soll, welche Steuerelemente in der Oberfläche existieren sollen, usw.
3.2 Wie entsteht Qualität?
In der klassischen Softwareentwicklung entsteht Qualität durch testen. Tester führen Tests aus und
stellen somit sicher, ob das Produkt wie gewünscht funktioniert.
Problematisch bei diesem Ansatz ist jedoch, dass ein Tester im Normalfall keine Ahnung davon hat,
wie die Software im Inneren aussieht. Es werden so genannte „Black Box“ Tests ausgeführt. Das
bedeutet, dass der Tester nur Tests von Außen ausführen kann und das innere der Software nicht
kennt.
Bei der modernen Softwareentwicklung entsteht die Qualität bereits in der Implementierungsphase.
Beim Entwickeln wird auf die Qualität geachtet und somit wird die Qualität fest ins Produkt eingebaut.
Zur Qualität gehören:




Korrektheit der Funktionalität
Codequalität
Berücksichtigung von Sonderfällen und Szenarien, die anhand der Codestruktur erkennbar sind
und nicht direkt von Außen anhand der Benutzeroberfläche erkennbar sind.
Erstellung von Unit-Tests während der Entwicklung (und nicht im Nachhinein).
Durch die Beachtung der Qualität während der Entwicklung ergibt sich ein qualitativ hochwertiger
Code. Dies führt zu einer fehlerarmen Software mit weniger Risiko, dass bestimmte Fehlerfälle
übersehen werden.
Um die Qualität während der Entwicklung zu erreichen sind drei Aspekte relevant:



Team Organisation: Organisation des Entwicklerteams und festlegen wie Tests erfolgen
Test Automatisierung: Besonders wichtig für Agiles Testen
Mindset: Entwickler müssen umdenken, um sich stärker für die Qualität verantwortlich zu
fühlen. Sie müssen sich mit neuen Werkzeugen vertraut machen, um die maximale Qualität
während der Implementierungsphase zu erreichen.
Seite 14 / 28
3.3 Team Organisation
In klassischen Organisationen sind Entwickler Team und QS Team voneinander getrennt. Es ist ein
hoher Kommunikationsaufwand nötig:
Dev:Build -> Qs:Test -> Qs:Bug Report -> Dev: Bug Fix -> Dev:Build -> Qs:Test
Zudem fehlt beim Entwickler Team meist die Verantwortung für die Qualität, da es noch jemanden
gibt, der die Qualität sicherstellen soll. Daher konzentrieren sich die Entwickler darauf, möglichst
schnell neue Funktionen bereit zu stellen.
Vermischt man Entwickler Team und QS Team bzw. bringt sie in einen Raum, dann verringert sich der
Kommunikationsaufwand erheblich, da sich ein Entwickler und ein Tester zusammensetzen können
und einen gefunden Bug direkt beheben können:
Dev:Build -> Qs:Test -> Qs&Dev: Bug Fix
Im Idealfall erweitern Entwickler und Tester ihre Fähigkeiten. Dadurch werden Entwickler auch zu
Testern und Tester werden auch zu Entwicklern. Somit ist es möglich, dass ein Entwickler seinen
eigenen Code oder den eines Kollegen testet. Außerdem ist es möglich, dass ein Tester einen
gefundenen Bug selbst behebt.
3.4 Automatisiertes Testen
Unit-Tests können automatisch beim Build vom TFS durchgeführt werden. Dadurch wird der Entwickler
umgehen auf Fehler hingewiesen. Ebenso ist es möglich Integrationstests, UI-Tests und Load &
Performance Tests automatisch auszuführen.


Unit-Test: Ein Unit-Test testet eine Methode
Integrationstest: Ein Integrationstest testet mehrere Methoden im Zusammenspiel
3.4.1 Unit-Testing
Unit-Tests bieten wesentliche Vorteile:



Verändern das Qualitäts-bewusstsein der Entwickler: Entwickler machen sich mehr Gedanken
über den Code.
Gehören zur Implementierung
Machen Entwickler effizienter: Durch das Schreiben von Unit-Tests ist es wesentlich einfacher
die Korrektheit von Funktionen beim Entwickeln zu testen. Es ist nicht mehr nötig die gesamte
Seite 15 / 28
Anwendung zu starten und eine bestimmte Oberfläche aufzurufen, um eine Funktion daraus
zu testen.
Unit-Tests benötigen bestimmte Voraussetzungen:



Architektur: Eine ungünstige Architektur erschwert die Erstellung von Unit-Tests.
Mindset: Entwickler müssen sich überwinden die ersten Unit-Tests zu schreiben. Um diese
Hürde einfacher zu gestalten, kann man ein Belohnungssystem einführen.
Practices: Es gibt bestimmte Praktiken, die immer wieder angewendet werden müssen. Dies
ist zum Beispiel der Fall, wenn Werte in eine Datenbank geschrieben werden müssen oder
Werte von externen Maschinen eingelesen werden müssen.
3.4.2 Load & Performance Tests
Durch die automatische Ausführung von Load & Performance Tests behält man die Übersicht, wie sich
Codeänderungen (sowohl negativ als auch positiv) auf die Speicher- und CPU-Nutzung auswirken.
Entscheidend ist, dass man tagesaktuell weiß, ob sich etwas verschlechtert hat und kann rechtzeitig
eingreifen.
Mit Hilfe von Load & Performance Tests können Funktionen beliebig oft wiederholt ausgeführt
werden. Dadurch ist es möglich Memory Leaks zu finden. Memory Leaks sind in
Produktionsumgebungen schwer zu finden, da sie nur sporadisch auftreten.
3.5 Exploratives Testen
Beim Explorativen Testen wird die Anwendung geöffnet und beliebige Funktionalitäten getestet. Durch
Verwendung des Microsoft Test Managers können die Aktivitäten in der Anwendung (Klicks, Eingaben,
…) aufgezeichnet werden. Diese Zusatzinformationen ermöglichen es dem Entwickler den Fehler
möglichst schnell nachzustellen.
4 Projektkommunikation
4.1 Anforderungen verstehen – Bedarfsgerechte Lösungen
In der klassischen Projektkommunikation übermitteln die Stakeholder dem Product Owner ihre
Anforderungen. Der Product Owner trägt diese ins Backlog ein. Die Entwickler bauen die
Anforderungen in die Software ein.
Seite 16 / 28
Unter Berücksichtigung von Build-Measure-Lern wird eine Feedbackschleife eingebaut. Nach jedem
Inkrement wird die Working Software den Stakeholdern und dem Product Owner vorgestellt. Nur
durch die Kenntnis über den aktuellen Softwarestand ist es Stakeholdern und Product Owner
tatsächlich möglich Entscheidungen bzgl. Wichtigkeit und Komplexität ihrer Anforderungen zu treffen.
4.2 Stakeholder einbeziehen
Das Entwicklerteam sollte sich stets die Fragen stellen:


Bauen wir wirklich Funktionen die unsere Anwender benötigen?
Oder bauen wir Funktionen von denen wir glauben, dass sie benötigt werden?
Daher darf es nicht sein, dass sich Entwickler vor der Verantwortung drücken und die Anforderungen
einfach runter programmieren. Sie müssen sich bewusst Gedanken machen und bei Unklarheiten mit
dem Product Owner oder den Stakeholdern Kontakt aufnehmen.
Stakeholder
Die Stakeholder sind alle Personen, die ein Interesse an dem Ergebnis haben, ohne direkt an der
Umsetzung beteiligt zu sein:







Management
Marketing / Sales
Kunden / Key-User
Außendienst
Operations (Leute, die die Software später Betreiben bzw. Betreuen müssen)
Trainings (Leute, die für die Software Schulungen anbieten)
Support
Selbst wenn der Wille da ist mit den Stakeholdern zu kommunizieren gibt es oftmals Probleme, die das
Einholen von Feedback erschweren:


Priorität bei Stakeholdern: Stakeholder haben oftmals wichtigeres zu tun, als sich um unsere
Software zu kümmern.
Deployment-Aufwand: Stakeholdern muss es möglichst einfach gemacht werden eine neue
Programmversion zu installieren bzw. zu starten. Je aufwendiger dieser Vorgang für einen
Stakeholder ist, desto weniger wahrscheinlich ist es, dass er Zeit findet die neue Version zu
begutachten.
Seite 17 / 28



Feedback verwalten: Je mehr Feedback die Stakeholder liefern, desto genauer können
Entwickler die Anforderungen umsetzen. Gibt es kein Feedback, dann führt dies vermutlich zu
einem Produkt, das nicht den Wünschen der Stakeholder entspricht.
Unklare Anforderungen und Best Guess: Sind die Anforderungen für einen Entwickler unklar,
dann setzt meistens das „Best Guess“ Prinzip ein. Der Entwickler beginnt dann zu erahnen, was
die Stakeholder wünschen und setzt die Funktionen um, ohne mit den Stakeholdern
Rücksprache zu halten.
Sprach- und Domain-Barrieren: Oftmals kommt es auch zu Kommunikationsproblemen, weil
Stakeholder, Anwender und Entwickler andere Landesprachen oder Fachsprachen verwenden.
4.3 Kommunikation im Projekt
4.3.1 Feedback Client
Der TFS bietet im Webaccess die Aktivität „Request Feedback“ (Feedback einholen). Diese ist
besonders für den Product Owner von Bedeutung.
Es können mehrere Stakeholder ausgewählt werden. Anschließend gibt man die Applikation, für die
man Feedback erhalten möchte, an und weitere Informationen wie z.B. Anmeldedaten. Abschließend
beschreibt man noch, wofür man Feedback haben möchte und schickt das Feedback raus. Im
Hintergrund wird ein Feedback Request Item angelegt. Die gewählten Stakeholder erhalten eine EMail.
In der E-Mail gibt es einen Link, über den das Feedback Tool installiert werden kann und einen Link,
über den eine Feedback Session gestartet werden kann. Der Stakeholder hat dann die Möglichkeit
Texte, Audiokommentare, Screenrecordings und Screenshots als Feedback zu sammeln.
Im TFS Webaccess taucht das Feedback des Stakeholders auf. Zu diesem Feedback Request Item kann
dann ein Product Backlog Item generiert werden.
4.3.2 Storyboarding Tool
Mit Power Point 2013 und Visual Studio gibt es in Power Point ein neues Menü „Storyboarding“.
Mittels Storyboarding ist es relativ leicht möglich Vorstellungen über Funktionen auf der
Programmoberfläche darzustellen. Es geht nicht darum die Oberfläche bis ins Detail darzustellen.
Storyboards können mit PBIs verknüpft werden und so dem Product Owner zur Verfügung gestellt
werden. Sie können auch als E-Mail an Stakeholder verschickt werden.
4.3.3 Kommunikation zwischen Deveoplment Team und Product Owner
Immer wenn sich ein Entwickler die Frage stellt, wie er etwas implementieren soll, dann muss er
Rücksprache mit dem Product Owner halten. Im Idealfall geschieht dies immer in einem kurzen
Gespräch von Angesicht zu Angesicht. Wenn dies nicht möglich ist, dann muss die Kommunikation
mittels E-Mail oder einem Issue Workflow Item im TFS gehen. Um Issue Workflow Items im TFS zu
verwalten bedarf es etwas Konfigurationsaufwand.
4.4 Kommunikation und Wissensverteilung im Team
Um die Zusammenarbeit im Team zu verbessern gibt es einige Praktiken, die angewendet werden
können:



Pair Programming: Zwei Entwickler sitzen vor dem Rechner und erarbeiten eine Lösung.
Daily Scrum: Meeting, bei dem man Hilfe aufgedrängt bekommt, weil man ggf. das gesamte
Team blockiert.
Code Reviews: Sehr effektiv, weil entweder der Reviewer oder der Schreiber etwas dazu lernt.
Seite 18 / 28





Swarming: Alle Entwickler „schwärmen“ um ein PBI herum. Also alle Entwickler beschäftigen
sich mit einem PBI. Dadurch sind alle gedanklich auf einer Ebene und die Kommunikation ist
wesentlich besser. Wenn sich die Entwickler allerdings auf den Füßen stehen, weil ein PBI nicht
genug Arbeit bzw. Tasks hergibt, dann werden einige Entwickler auf das nächste PBI gesetzt.
Cross Functional Teams: Es gibt keine Spezialisten für bestimmte Funktionalitäten im Team.
Jeder Entwickler ist in der Lage mit den verwendeten Programmiermethoden zu arbeiten.
Shared Code Ownership: Es gibt keine Codebereiche, die einem Entwickler alleine gehören.
Findet ein Entwickler einen Bug in einem Codebereich, den er nicht selbst geschrieben hat,
dann sollte er diesen trotzdem lösen. Dadurch ergibt sich ein indirektes Code Review.
Retrospektiven: Sehr effizient, weil sich das Team damit auseinandersetzt, was man im Team
verbessern kann. Dabei muss es nicht nur um Arbeitsabläufe gehen, sondern es können auch
soziale Probleme im Team zur Sprache kommen.
Wissensvermittlung: Besonders wichtig, um Cross Functional Teams zu erhalten.
Wissensvermittlung ist möglich z.B. durch Coding Dojos, Code Reviews im gesamten Team und
Sessions zur Einführung von neuen Werkzeugen.
4.5 Team Rooms
Team Rooms im TFS sollen verhindern, dass Entwickler von Kollegen häufig gestört werden. Damit ein
Entwickler nicht alle Kollegen im Raum durch irgendwelche Neuigkeiten unterbricht, kann er diese
Neuigkeiten im Team Room posten. Dort können die Entwickler, wenn sie kurz Zeit haben, reinschauen
und sich einen Überblick verschaffen, was gerade im Team los ist.
Team Rooms sollen aber auf keinen Fall die Fact-To-Face Kommunikation bei wichtigen Themen
ersetzen.
5 Erweiterbare Architektur
Beim klassischen Architektur Ansatz müssen alle Anforderungen an das Software System bekannt sein.
Aus diesen Anforderungen entsteht dann die Architektur.
Dies funktioniert in agilen Projekten nicht. Denn man beginnt mit einigen Anforderungen, die dann in
jeder Iteration weiter ausgebaut werden. Somit arbeitet man in jeder Iteration PBIs ab, die sich über
alle Schichten hinweg erstrecken können. Daraus ergibt sich das Vorurteil, das in agilen Projekten auf
einem Fundament aufgesetzt wird, dass die gesamte Anwendung im späteren Verlauf nicht mehr
tragen kann. Dies ist aber falsch, denn man ist jederzeit in der Lage das Fundament zu korrigieren oder
sogar auszutauschen.
Ziele moderner Architektur
 Wartbar
 Testbar: Der Code wird mittels automatisierter Tests getestet.
Seite 19 / 28

Erweiterbar: Der Aufwand neue Funktionen hinzuzufügen ist minimal.
Ob eine Architektur wartbar und erweiterbar ist lässt sich oft erst nach einigen Monaten messen. Als
Faustregel kann man aber sagen, dass eine gut testbare Architektur auch wartbar und erweiterbar ist.
5.1 Testbare Architektur
Damit eine Architektur gut testbar ist gilt als oberstes Ziel Entkopplung. Dafür gibt es verschiedene
Pattern und Praktiken:






Single Responsibility: Eine Codestelle sollte immer nur eine Sache tun. Es sollte immer nur
einen Grund geben diese Codestelle zu ändern.
MVVM / MVC: Entkopplung der Business Logik von der Oberfläche.
POCOs (Plain Old Clr Objects): Helfen Applikationsmodule zu entkoppeln und Abhängigkeiten
zu vermeiden. Es soll verhindert werden, dass bestimmte Datentypen einer UI-Komponente
(oder einer Datenzugriff-Komponente) über mehrere Schichten hinweg verwendet werden.
Zwischen den Schichten sollte mit POCOs kommuniziert werden. Denn diese stehen auch dann
noch zur Verfügung, wenn eine UI-Komponente (oder eine Datenzugriff-Komponente) gegen
eine andere ausgetauscht wird.
Sackgassen-Methoden: Methoden, die keine Aufrufe nach Außen haben und daher
unabhängig sind.
Trennung Daten, Orchestrierung, Logik: Es werden nur Klassen verwendet, die entweder
Properties oder Methoden haben. Dies erleichtert die Entkopplung und die Testbarkeit.
Komponentenorientierung IoC Interfaces
5.1.1 Software-Architektur
Software-Architektur erstreckt sich über drei Ebenen:



Code-Ebene: Jede Zeile Code kann die Architektur beeinflussen.
Technologien: Bestimmte Technologien ermöglichen bestimmte Architekturen.
Modelle: UML-Diagramme
Code-Ebene
Hier gibt es fünf bekannte Design Prinzipien, die angewendet werden sollen:





Single Responsibility: Es sollte nie mehr als einen Grund geben, eine Klasse zu ändern. Somit
sollte jede Klasse nur eine Verantwortung haben.
Open/closed Principle: Eine Klasse sollte offen sein für Erweiterungen, aber verschlossen sein
für Änderungen. Somit sollte jede Klasse erweitert werden können (z.B. durch Vererbung) aber
ohne dabei ihr Verhalten zu ändern.
Liskov Substitutability Principle: Eine Instanz einer abgeleiteten Klasse muss sich so verhalten,
dass jemand, der meint, ein Objekt der Basisklasse vor sich zu haben, nicht durch unerwartetes
Verhalten überrascht wird, wenn es sich dabei tatsächlich um ein Objekt eines Subtyps
handelt.
Interface Segregation Principle: Clients sollten nicht dazu gezwungen werden, von Interfaces
abzuhängen, die sie nicht verwenden. Es geht darum große Interfaces in mehrere kleine
Interfaces aufzuteilen, damit Clients nur mit Interfaces agieren müssen, die das können, was
die Clients benötigen.
Dependency Inversion Principle: A. Module hoher Ebenen sollten nicht von Modulen niedriger
Ebenen abhängen. Beide sollten von Abstraktionen abhängen. B. Abstraktionen sollten nicht
von Details abhängen. Details sollten von Abstraktionen abhängen.
Abhängigkeiten sollten immer von konkreteren Modulen niedriger Ebenen zu abstrakten
Modulen höherer Ebenen gerichtet sein.
Seite 20 / 28
5.1.2 Komponentenorientierte Architektur
Der Code setzt sich aus verschiedenen Komponenten zusammen, die Nachrichten untereinander
austauschen. Die Form der Nachrichten wird mittels Data Contract beschrieben. Die Funktionen, die
eine Komponente nach Außen zur Verfügung stellt wird mittels Operation Contract beschrieben.
Ein Data Contract wird im Code mittels einer Klasse, die aus Properties besteht, beschrieben. Ein
Operation Contract wird mittels Interface beschrieben.
Spaghetti-Code
Besonders ungünstig zu testen ist Spaghetti-Code. Hierbei gibt es eine große Methode, die die gesamte
Funktionalität enthält. Spaghetti-Code ist nur durch aufwendige Integrations-Tests testbar.
Wendet man das SOLID-Prinzip auf den Spaghetti-Code an, dann erhält man mehrere Funktionen.
Allerdings sind diese voneinander abhängig und man kann auch wieder nur mit Integrations-Tests
testen. Diese können aber einfacher gestaltet werden als beim Spaghetti-Code.
Die ideale Struktur verwendet eine Orchestrierungsschicht, die sogenannte Sackgassen-Methoden
aufruft. Sackgasse-Methoden verwenden intern keine andere Methode und sind somit nicht von
Seite 21 / 28
anderen Methoden abhängig. Daher lassen sich Sackgassen-Methoden sehr gut mit Unit-Tests testen.
Die Orchestrierungsschicht muss mittels Integrations-Test getestet werden, da es darum geht, ob die
Schicht die einzelnen Sackgassen-Methoden korrekt miteinander verknüpft.
5.1.3 Legacy-Code
Oft ist es schwierig Design Pattern in bestehenden, gewachsenen Code (Legacy-Code) einzuführen.
Entwickler tendieren dann dazu den Greenfield-Ansatz zu wählen. Es soll der bestehende Code
verworfen werden und mit neuen Technologien und neuer Architektur aufgebaut werden.
Es gibt mehrere Probleme beim Greenfield-Ansatz:



Hoffnung: Entwickler haben die Hoffnung den neuen Code mit neuen Technologien, den
richtigen Design Patterns und Unit-Tests zu schreiben. Oftmals endet der Greenfield-Ansatz
aber wieder in Legacy-Code.
Kunden-Feedback: Es ist schwierig Feedback von Anwendern zu erhalten, weil diese noch mit
der bestehenden Software arbeiten. Die Anwender werden erst die neue Software
verwenden, wenn diese Funktionalitäten zur Verfügung stellt, die in der alten Anwendung
nicht vorhanden sind.
Kapazität: Das bestehende Entwicklerteam war bisher für die Pflege und Erweiterung der
bestehenden Software zuständig. Jetzt werden Entwickler abgezogen, um an der neuen
Software zu arbeiten. Dies ist möglich, weil an der bestehenden Software weniger
Neuentwicklungen durchgeführt werden. Dies ist aber ein Nachteil für Bestandskunden. Wenn
dann doch schnell neue Funktionalität entwickelt werden muss, werden die Entwickler von der
neuen Software kurzzeitig abgezogen. Es entsteht ein ständiger Wechsel zwischen alt und neu,
was sich negativ auf die Produktivität der Entwickler auswirkt.
Eine Alternative zum Greenfield-Ansatz ist das Refactoring.
Refactoring
Beim Refactoring werden die Codebereiche nach und nach überarbeitet und verbessert.
5.2 Modelle im Agilen Kontext
Modelle im Agilen Kontext machen dann Sinn, wenn sie die Kommunikation vereinfachen. Es muss der
Nutzen und der Aufwand eines Modells abgewogen werden, bevor man sich entscheidet ein Modell
zu entwerfen.
Es gibt verschiedene Möglichkeiten Modell zu erstellen bzw. darzustellen:



UML
.NET Classdesigner
Workflow Foundation
Seite 22 / 28

Architecture Discovery
5.3 Agile Architektur
Eine entkoppelte Architektur ist besonders geeignet für Unit-Tests.
Nutzung von IoC für Mocking
Durch Verwendung von IoC können im Konstruktor Mocks übergeben werden. Dies vereinfacht das
Testen von Klassen.
5.3.1 Architektur-Tools in Visual Studio
Layer-Diagramme
Layer-Diagramme ermöglichen die Zuweisung von Komponenten zu Layern. Zudem kann man
Abhängigkeiten zwischen Komponenten definieren. Beispielsweise kann man festlegen, dass UIKomponenten auf der Präsentationsschicht nur auf Interfaces aus der Businessschicht zugreifen
dürfen. Ob dies von jedem Entwickler im Code eingehalten wird, kann man mittels Layer-Diagramm
Validierung prüfen. Die Validierung kann automatisiert in einem Buildvorgang ausgeführt werden.
Code Maps
Nach dem Anhalten an einem Breakpoint im Code, kann man für diese Position eine Code Map
einblenden. Die Code Map zeigt, durch welche Aufrufe man an diese Position gekommen ist. Die Code
Map kann als Orientierungshilfe beim Debuggen verwendet werden. Man kann sie auch mit
Kommentaren versehen und an Kollegen weitergeben.
Code Clone Detection
Visual Studio bietet eine Code Clone Detection, mit der redundanter Code gefunden werden kann. Es
wird Code gefunden, der mittels Copy-Paste erstellt wurde und somit exakt übereinstimmt. Es kann
aber auch Code gefunden werden, der teilweise übereinstimmt.
Sequence Diagramms
Zu einer beliebigen Codestelle kann ein Sequenzdiagramm erstellt werden. Dieses zeigt den Ablauf der
Funktion und kann als Grundlage für Diskussionen mit Kollegen verwendet werden.
6 Continous Delivery & Dev Ops
Eine wichtige Rolle in der modernen Softwareentwicklung ist es, kontinuierlich Nutzen für den Kunden
zu generieren. Auf der einen Seite werden Anforderungen definiert, entwickelt und getestet. Im
weiteren Kreislauf geht es um den Betrieb der Software (Operations). Hierbei sind Deployment,
Monitoring und Verwaltung der Software von großer Bedeutung.



Deployment: Veröffentlichen der Software in der Produktivumgebung. Einspielen von
Updates.
Monitoring: Aktuellen Betrieb monitoren. Aus den Ergebnissen können neue Ideen und
Anforderungen generiert werden.
Management: Verwaltung der Software
Seite 23 / 28
6.1 Build-Measure-Learn
Build-Measure-Learn wird auch bei Continous Delivery angewendet:
1. Es wird eine Hypothese aufgestellt und versucht als testbares Experiment umzusetzen.
2. Das Experiment wird als Minimum Viable Product (MVP), der kleinste vermarktbare
Kundennutzen, definiert.
3. Das MVP wird implementiert und eine Messfunktionalität wird eingebaut.
4. Das Produkt wird in die Produktivumgebung gestellt und die Ergebnisse gemessen. Dabei geht
es darum zu schauen, ob die neue Funktionalität von den Nutzern gut angenommen wird und
ob es die Erwartungen erfüllt.
5. Aus diesen Informationen wird gelernt, wie das Produkt weiterentwickelt werden soll.
6. Im letzten Schritt wird entschieden, ob das MVP erweitert, überarbeitet oder verworfen wird.
Je nachdem, ob es die Business Hypothese bestätigt hat oder nicht.
Dieser Kreislauf soll in möglichst kurzen Zyklen durchlaufen werden. Dadurch ist es möglich, in
möglichst kurzen Zeitabständen Anpassungen am Produkt vorzunehmen.
Um in kurzen Zyklen vor ca. zwei bis vier Wochen eine Applikation zu veröffentlichen kann das Tool
„Microsoft Release Management 2013“ verwendet werden.
6.1.1 Release Management 2013
Mit dem Release Management kann aus einem Build heraus die Anwendung auf einer bestimmten
Umgebung veröffentlicht werden. Mögliche Umgebungen sind:


DEV: Entwicklungsumgebung
QA: Qualitätssicherungsumgebung
Seite 24 / 28

PROD: Produktivumgebung
Dabei bietet das Release Management


Automatisches Deployment
Volle Traceability: Information welche Version auf welcher Umgebung installiert ist und ob die
Version freigegeben wurde.
Im Standardfall wird nach dem Einchecken ein Build erstellt und dieses auf der Entwicklungsumgebung
veröffentlicht. Nachdem auf der Entwicklungsumgebung getestet wurde, kann im Release
Management die Version von der Entwicklungsumgebung auf die Qualitätssicherungsumgebung
freigegeben werden. Dies wird dokumentiert.
6.1.2 Measure – Feedback und Telemetry
Um herauszufinden, ob die Business Hypothese bzw. das Experiment erfolgreich ist können
Kundenumfragen generiert und Feedback von Stakeholdern eingeholt werden. Besser ist es aber
Informationen mittels Anwendungs-Telemetry zu messen. Dafür gibt es das Tool Application Insights.
Application Insights
Mit Application Insights können im TFS Dashboards gebaut werden, die bestimmte Informationen über
die Anwendung anzeigen. Mittels Application Insights ist es möglich





Die Verfügbarkeit der Anwendung automatisch zu testen.
Vordefinierte Tests automatisiert ausführen zu lassen.
Anzeigen der Anzahl der Benutzer pro Tag.
Anzeigen der Bewegungsprofile der Benutzer innerhalb der Anwendung.
Anzeigen der langsamsten Zugriffe, um Performanzprobleme zu identifizieren.
Application Insights ist für Webanwendung, Windows Phone Apps und Windows Store Apps verfügbar.
Seite 25 / 28
6.2 Fehler in der Produktivumgebung finden


Mean Time to Detect (MTTD): Die benötigte Zeit bis ein Defekt in der Produktivumgebung
bemerkt wird.
Mean Time to Repair (MTTD): Die benötigte Zeit bis ein Defekt in der Produktivumgebung
repariert ist.
IntelliTrace in Production
Um Fehler in der Produktivumgebung zu finden, kann „IntelliTrace in Production“ verwendet werden.
Dafür müssen lediglich einige Dateien auf die Produktivumgebung kopiert und ein PowerShell Script
ausgeführt werden. Anschließend erhält man eine IntelliTrace Datei, die in Visual Studio geöffnet
werden kann.
Mit Hilfe dieser Datei kann zu der Codestelle gesprungen werden, die den Fehler verursacht hat.
Darüber hinaus kann im Code navigiert und die Werte der Variablen abgefragt werden. So findet man
z.B. relativ schnell die Ursache einer NullReference-Exception.
7 Entwickler-Produktivität
Damit Entwickler produktiver werden und sich auf das Entwickeln konzentrieren können, müssen sie
von Routineaufgaben entlastet werden. Dafür gibt es bestimmte Werkzeuge.
7.1 Versionskontrollsystem
Der TFS 2012 bietet ein eigenes Versionskontrollsysteme und Git. Ein Versionskontrollsystem dient
dazu Änderungen mehrere Entwickler zusammenzuführen und einen Verlauf der Änderungen zu
protokollieren. Zusätzlich bietet es Branching und Continous Integration Build.
Branching
Mittels Branching können Änderungen voneinander Isoliert werden. Oftmals gibt es einen MainBranch, einen Dev-Branch und einen oder mehrere Release-Branches. Im Dev-Branch wird das Produkt
stetig weiterentwickelt. In Release-Branches sind Auslieferungsversionen und Hotfix-Stände enthalten.
Continous Integration Build
Mittels CI Build wird nach jedem Eincheckvorgang ein Build erstellt und Unit-Tests automatisch
ausgeführt. Dadurch erhält der Entwickler eine Rückmeldung, ob durch seine Codeänderung Probleme
verursacht werden oder nicht.
Seite 26 / 28
7.2 Visual Studio IDE Features
Code Lense
Mittels Code Lense werden folgende Informationen zu einer Methode eingeblendet:




Referenzen
Testergebnisse
Letzter Eincheckvorgang
Anzahl der Änderungen
Statische Code-Analyse
In den Solution-Einstellungen kann für jedes Projekt das Regelset für Statische Code Analyse eingestellt
werden. Beim Bauen der Solution wird die Statische Code Analyse ausgeführt. Als Ergebnis erhält man
eine Liste aller Codestellen, die gegen eine Regel aus dem Regelset verstoßen.
Eine Statische Code Analyse kann auch automatisiert in einem Build durchgeführt werden.
Test Driven Development (TDD)
Bei TDD wird das erwartete Verhalten einer Methode mittels Tests beschrieben. Anschließend wird
die Methode so implementiert, dass sie die Tests erfüllt. Dabei wird zunächst ein Test geschrieben.
Wenn dieser erfüllt wird, dann wird der nächste Test geschrieben und die Methode weiter
implementiert.
Im Test-Explorer kann eingestellt werden, dass Tests automatisch nach einem erfolgreichen Build im
Studio ausgeführt werden. Dabei werden zuerst die Tests ausgeführt, die neu sind oder die vorher
fehlgeschlagen sind.
7.3 Performance Tools
Profiler
Der Profiler misst die benötigte CPU-Zeit und den benötigten Speicher. Anschließend erhält man eine
Auswertung. Mittels HotPath sieht man, welche Funktionsaufrufe am meisten Performanz verbrauch
haben.
Energy Consumption
Misst den Energieverbrauch von Windows Phone und Windows Store Apps.
8 Team Power
Gute Teams sind selbstorganisiert und arbeiten als echte Teams. Es geht nicht darum am gleichen
Projekt oder im gleichen Raum zu arbeiten. Entscheidend ist, dass alle im Team ein Ziel vor Augen
haben und sich gegenseitig unterstützen.
Es darf nicht sein, dass jeder im Team seine eigene Aufgabe hat und sich ausschließlich darum
kümmert. In einem idealen Team übernimmt ein Entwickler auch Verantwortung für die Aufgaben der
Kollegen.
Bessere Entscheidungen
In einem idealen Team trifft nicht jede Person Entscheidungen für sich selbst. Es werden
Entscheidungen gemeinschaftlich getroffen. Dadurch bringt jedes Teammitglied sein Wissen mit ein.
Dies führt zu besseren Entscheidungen. Bessere Entscheidungen führen zu weniger Irrwegen im Laufe
der Entwicklung.
Ideale Teams arbeiten schneller und effizienter als Einzelkämpfer.
Seite 27 / 28
Teamverantwortung
Jeder im Team muss Verantwortung übernehmen. Selbst wenn jemand nicht an einem Fehler beteiligt
war, kann er Verantwortung übernehmen und diesen beheben. Dadurch erfolgt automatisch ein Code
Review. Zusätzlich stellt sich die Frage, warum der Fehler nicht durch Tests aufgedeckt wurde. Darüber
hinaus überlegt das Team gemeinsam wie es sich verbessern kann, damit in Zukunft ein Fehler mit der
gleichen Ursache nicht nochmal auftritt.
Team-Motivation
Die gemeinsame Verantwortung steigert die Motivation im Team. Denn es kommt nicht mehr vor, dass
jemand für seine eigenen Entscheidungen den Kopf hinhalten muss. Die Entscheidung ist gemeinsam
getroffen worden, somit ist das gesamte Team für die Auswirkung verantwortlich. Dies nimmt den
Druck von jeden einzelnen.
Risiken reduzieren
Weil in einem idealen Team jeder Entwickler auch die Aufgaben seiner Kollegen übernehmen kann,
sinkt das Risiko von einem Entwickler abhängig zu sein. Fällt beispielsweise ein Entwickler wegen
Krankheit oder Urlaub aus, dann gibt es immer noch andere Entwickler, die kritische Probleme in
Codestellen des Entwicklers beheben können.
Wie entsteht ein großartiges Team?
Der Schlüssel für ein großartiges Team ist Selbstorganisation. Es gibt niemanden im Team der wichtige
Entscheidungen alleine trifft. Wie mit kritischen Probleme oder neuen Anforderungen umgegangen
wird entscheidet das gesamte Team gemeinsam.
Aus Management Sicht ändert sich dadurch die Rolle eines Teamleiters. Dieser gibt bei einem
selbstorganisierten Team nicht mehr die Wege vor, sondern die Ziele. Das Team muss die Wege
gemeinsam erarbeiten. Dadurch wird das Management entlastet.
Ein selbstorganisiertes Team lässt sich nicht einfach umsetzen. Es ist ein Lernprozess nötig, bei dem
der Scrum Master sehr viel Unterstützung bieten kann.
Seite 28 / 28

Moderne Softwareentwicklung

Transcription

Similar documents

Zusammenfassung - Software Bakery

The Scrum Guide

An initiative for information fluency for students of Slavic languages

Der TFS in der Praxis

Die Brücke zwischen CMO und CIO

Oracle BPEL in Großprojekten