Modul 426
Software mit agilen Methoden entwickeln
Das Agile Manifest
Kurzfassung
Im Jahr 2001 wurde das agile Manifest erarbeitet
Agilität in einem Satz
Autonome Teams mit Businessfokus, die ihren Prozess in Besitz nehmen und dafür die Verantwortung tragen.
Aspekte im agilen Manifest
Die 9 Agile Werte
Einfachheit ist ein Zustand, der sich dadurch auszeichnet, dass nur wenige Faktoren zu seinem Entstehen oder Bestehen beitragen und dadurch, dass das Zusammenspiel dieser Faktoren durch nur wenige Regeln beschrieben werden kann. Damit ist Einfachheit das Gegenteil von Komplexität.
Wikipedia
Die einfachste Lösung ist normalerweise die beste Lösung.
… Ein “transparentes” Objekt ist eines, was durchschaut werden kann. Die Forderung nach Transparenz ist eine nach Information, Offenheit, Kommunikation und Rechenschaft.
Wikipedia
Möglichst direkt und ohne Umwege an Informationen heranzukommen.
Als Kohärenz bezeichnet man allgemein den inneren oder äusseren Zusammenhang oder Zusammenhalt von etwas
Wikipedia
Kohärenz bedeutet “Zusammenhang” bzw. “Zusammenhalt”.
- Durch Kohärenz wird die Zusammenarbeit gefördert, da alle ein gemeinsames Ziel verfolgen.
Als Adaption … wird die Umarbeitung eines künstlerischen Werks bezeichnet; Als Adaption in Technik und Wissenschaft wird bezeichnet: eine silch selbst anpassende Regelung …
In Agilen Projekte sind Veränderungen willkommen. Dies erfordert jedoch, dass die Vorgehensweise laufend dieser Veränderung angepasst wird.
Lernen bezeichnet den Vorgang der Aufnahme und der Speicherung von Erfahrungen und der Konditionierung des Verhaltens. Ergebnis des Lernprozesses ist die Veränderung der Wahrscheinlichkeit, mit der Verhaltensweisen in bestimmten Situationen auftreten.
Der neue Brockhaus – Band 3 (6. Auflage), Stichwort: lernen, F.A. Brockhaus, 1979
Nur wenn Wissen und Erfahrungen im Team verteilt werden, können Einzelpersonen in Problemsituationen, die für das Team und das Projekt richtigen Entscheidngen treffen und somit möglichst effektiv unterwegs sein.
Die Zusammenarbeit … bezeichnet in der Regel ein bewusstes, gemeinsames Zusammenwirken zur Erreichung eines Ziels.
Enge Zusammenarbeit ist einer der Grundpfeiler agiler Softwareentwicklung.
Lernen wird durch Zusammenarbeit gefördert, da so unser Horizont erweitert wird und wir uns neue Vorgehens- oder Sichtweisen aneignen können.
Mut auch Wagemut oder Beherztheit: Man traut sich (und ist fähig), bereitwillig etwas zu wagen.
Es braucht Mut, Entscheidungen zu treffen, selbst wenn es unangenehme sind.
Als Respekt oder Achtung wird die „anerkennende Berücksichtigung des Wertes“ von etwas, im Standardfall einer anderen Person bezeichnet. Respekt in diesem Sinne kann jedoch auch Regeln (insbesondere moralischen Regeln) entgegengebracht werden,
Beruht darauf, dass jeder im Team bzw. im Projekt sein Bestes gibt. Man vertraut darauf, dass Teammitglieder die Verpflichtungen (Commitments) einhalten sowie alles daran setzen, diese zu erfüllen.
Verantwortung bedeutet, die Folgen für eigene oder fremde Handlungen zu tragen. Sie drückt sich darin aus, bereit und fähig zu sein, später Antwort auf mögliche Fragen zu deren Folgen zu geben. Eine Verantwortung zieht immer eine Verantwortlichkeit nach sich, d. h. dafür Sorge zu tragen, dass die Entwicklung des Verantwortungsbereichs im gewünschten Rahmen verläuft.
In einem agilen Umfeld ist die Verantwortung noch viel wichtiger als in traditionell geführten Organisationen.
Da jeder selbst verantwortlich und initiativ handeln soll, trägt auch jeder Einzelne viel mehr Verantwortung.
Scrum Process
Kurzfassung
Scrum Roles
Wichtig: Es gibt keinen Projektleiter oder irgenwelche andere Rollen!
Product Owner
Der Product Owner ist eine Person, kein Komitee und kann Produktentscheidungen fällen.
Zudem ist der Product Owner für den geschäftlichen Erfolg des Produkts verantwortlich.
Aufgaben
- Produktwert sowie den Wert der Arbeit des Entwicklungsteams maximieren.
- Product Backlog pflegen.
- Klare Product Backlog Items formulieren.
- Product Backlog sichtbar und transparent machen.
- Klarstellen, woran als nächstes gearbeitet wird.
- Sicherstellen, dass das Entwicklungsteam die Product Backlog Items versteht.
Development Team
Das Entwicklungsteam ist für ein technisch erfolgreiches sowie wartbares Produkt verantwortlich.
Aufgaben
- Entwickelt das Produkt und liefert Produktinkremente ab.
- Organisiert die Arbeit selbstständig, wobei alle Team-Mitglieder gleichwertig sind.
- Kann Product Backlog Items genauer definieren.
- Schätzt Backlog Items und plant Sprint selbständig.
- Ist verantwortlich für die Produktqualität.
Scrum Master
Der Scrum Master sorgt für die erfolgreiche Anwendung von Scrum “Servant Leader für Scrum Team”.
Aufgaben
- Moderiert bei Bedarf oder Notwendigkeit die Meetings.
- Hilft dem Product Owner in methodischen Fragen.
- Coacht das Entwicklungsteam in Selbstorganisation und Cross Funktionalität.
(Cross Funktionalität: Jeder ist auf etwas anderes spezialisiert) - Beseitigt Hindernisse (Impediments).
- Hilft anderen dabei, Scrum zu verstehen.
- Arbeitet mit anderen Scrum Master zusammen, um die Effektivität von Scrum in der Organisation zu verbessern.
Scrum Artifacts
Product Backlog
- Der Product Owner pflegt und priorisiert das Product Backlog mit den entsprechenden PBI’s (Product Backlog Items).
- Product Backlog Items werden als Epics und User Stories aus sicht des Anwenders formuliert.
Sprint Backlog
- Enthält Product Backlog items.
- Sprint Backlog Items SPI’s werden in Sprint zu auslieferbarem Produktinkrement realisiert.
- SPI’s werden vom Development Team in Tasks zerlegt.
Product increment
- Ist das Ergebnis eines Sprints.
- Dies kann als ein neuer Release an den Kunden ausgeliefert werden.
- Ermöglicht Kundenfeedback.
- Erhöht Nutzen sowie Wert des Produktes fortlaufend.
Die Meetings
Sprint Planning
Im Sprint Planning soll ein realistischer Plan für die Umsetzung wichtiger Features im aktuellen Sprint erstellt werden.
Teilnehmer:
- Product Owner
- Development Team
- Scrum Master → moderiert
Vorgehen:
- Der Product Owner stellt seine Idee für ein Sprint Ziel vor.
- Alle formulieren das Sprintziel gemeinsam.
- Alle nehmen Userstories in Sprint Backlog auf.
- Development Team zerlegt die Userstories in Tasks und schätzt den Aufwand.
Daily Scrum
Daily Scrum findet täglich statt und dauert maximal 15 Minuten.
Dies betrifft nur das Entwicklungsteam, der Product Owner muss nicht zwingend am Daily Scrum teilnehmen.
Teilnehmer:
- Development Team
- Scrum Master → moderiert
Fragestellungen an einem Daily Scrum:
- Was habe ich gestern gemacht, das dem Entwicklungsteam hilft, das Sprintziel zu erreichen?
- Was werde ich heute tun, das dem Entwicklungsteam hilft, das Sprintziel zu erreichen?
- Sehe ich irgendwelche Hindernisse, die das Entwicklungsteam davon abhalten könnten, das Sprintziel zu erreichen?
Sprint Review
Das Sprint Review soll das Lernen über das Produkt ermöglichen. Dafür gibt es folgende Fragestellungen.
- Entwickeln wir das richtige Produkt?
- Hat es die richtigen Features?
- Erfüllt das Produkt seinen Zweck?
- Welche Funktionen fehlen noch, damit es benutzt werden kann?
Teilnehmer:
- Product Owner
- Scrum Master → moderiert
- Development Team
- Stakeholder
Zudem wird auch angeschaut, welche Sprint backlog Items erledigt wurden.
Dabei ist es wichtig, dass Stakeholder (Kunden, Anwender) am Sprint Review teilnehmen. → Sie geben das wertvollste Feedback zum Produkt.
Schätzung der Sprint Review Dauer:
1h pro 1 Woche Sprint Länge.
Das heisst: bei einem Zwei Wochen Sprint → 2h Sprint Review
Sprint Retrospective
Gesamtes Scrum Team, inklusive Product Owner arbeiten zusammen und versuchen die Zusammenarbeit sowie den Entwicklungsprozess zu verbessern.
Teilnehmer:
- Product Owner
- Scrum Master → moderiert
- Development Team
Der Scrum Master moderiert die Sprint Retrospektive und sorgt dafür, dass am Ende konkrete Verbesserungsmassnahmen entstehen.
Epics und User Stories
Kurzfassung
CCC Eigenschaften
Card, Conversation, Confirmation
User Stories
sind Anforderungen aus Nutzersicht.
Die CCC-Eigenschaften
Die Details zu den User Stories werden entweder im Entwicklungsteam oder zusammen mit dem Product Owner erstellt.
User Stories sollen keine vollständige Spezifikationen sein
Die User Story soll ein Hilfsmittel für das persönliche Gespräch sein.
Es ist ein Versprechen für ein Gespräch.
Es soll klar sein, wie festgestellt wird, ob die User Story erfolgreich umgesetzt wurde. (Akzeptanzkriterien)
Was sind User Stories?
- User Stories sind Nutzergeschichten.
- der Product Owner beschreibt in einer User Story die Anforderungen aus Nutzersicht.
- User Stories sind in wenigen, leicht verständlichen Sätzen geschrieben.
- User Stories geben keine technischen Lösungen vor.
Beispiele für User Stories:
- Ein neuer Kunde soll sich bei einem E-Learning Portal registrieren, um sich auf eine Zertifizierung vorzubereiten.
- Ein Kunde möchte Waren in einem Webshop auswählen und dann bestellen können.
- Ein IT-Administrator möchte Datenbanken verwalten können, indem er Datensätze hinzufügt, bearbeitet oder löscht.
Wie sollte eine User Story fomuliert sein?
- Eine User Story sollte einfach und leicht verständlich sein.
- Eine User Story soll sich auf das Wesentliche konzentrieren.
Wer fordert etwas an?
Was wünscht sich der Anforderer?
Warum ist das für den Geschäftsfall wichtig?
Klassisches Satzschema für User Stories
Als [Akteur] möchte ich [Funktion], damit [Nutzen] Alternatives Satzschema für User Stories
Damit [Nutzen] möchte ich als [Akteur] [Funktion]. Akzeptanzkriterien
“Definition of done”
Akzeptantkriterien geben an, wie das Team feststellt, ob die User Story abgeschlossen ist.
Product Owner und Entwicklungsteam definieren die Akzeptanzkriterien gemeinsam.
Faustregel:
3 – 8 Akzeptanzkriterien für eine User Story.
Falls eine User Story zu gross ist und aufgeteilt werden muss:
- Man kann meist pro Akzeptanzkriterium eine eigene User Story definieren.
Woran erkennt man eine gute User Story
Mithilfe den “INVEST” Kriterien erkennt der Product Owner, ob die User Story gut ist.
Jede einzelne User Story sollte unabhängig von anderen User Stories sein.
User Stories werden gemeinsam diskutiert
Das Ergebnis der User Story mus für den Anwender sinnvoll sein.
Der Aufwand für eine User Story muss einschätzbar sein
Der Umfang der User Story sollte in einem Sprint realisierbar sein.
Jede User Story muss getestet weren können. Mit dem Test wird die erfolgreiche Umsetzung der User Story festgestellt.
Epic, Story und Task
Epic
Epic ist eine User Story welche für einen Sprint zu gross ist. Der Product Owner zerlegt diese in meherere kleinere User Stories.
Story
die User Story ist ein Teil einer Epic. Eine Story ist in wenigen, einfachen Sätzen geschrieben und beschreibt die Anforderungen.
Task
Entwickler und Tester erlegen eine User Story in kleine einzelne Aufgaben (Tasks).
Eine Story ist dann erledigt, wenn alle Aufgaben der Story erledigt sind.
Pair Programming
Die 5 Werte
- Kommunikation (Communication)
- Rückkopplung (Feedback)
- Einfachheit (Simplicity)
- Mut (Courage)
- Respekt (Respect)
Die 14 Prinzipien
- Menschlichkeit (Humanity)
- Wirtschaftlichkeit (Economics)
- Gegenseitiger Vorteil (Mutual Benefit)
- Selbstähnlichkeit (Self-Similarity)
- Mannigfaltigkeit (Diversity)
- Reflexion (Reflection)
- Fluss (Flow)
- Gelegenheit (Opportunity)
- Redundanz (Redundancy)
- Fehlschlag (Failure)
- Qualität (Quality)
- Babyschritte (Baby Steps)
- Akzeptierte Verantwortlichkeit (Accepted Responsibility)
Primärpraktiken
- Räumlich zusammensitzen (Sit Together)
- Komplettes Team (Whole Team)
- Informative Arbeitsumgebung (Informative Workspace)
- Energiegeladene Arbeit (Energized Work)
- Programmieren in Paaren (Pair Programming)
- Geschichten (Stories)
- Wochenzyklus (Weekly Cycle)
- Quartalszyklus (Quarterly Cycle)
- Freiraum (Slack)
- Zehn-Minuten-Build (Ten-Minute Build)
- Kontinuierliche Integration (Continuous Integration)
- Inkrementeller Entwurf (Incremental Design)
Folgepraktiken
- Echte Kundenbeteiligung (Real Customer Involvement)
- Inkrementelle Ausbreitung (Incremental Deployment)
- Teamkontinuität (Team Continuity)
- Schrumpfende Teams (Shrinking Teams)
- Gemeinsamer Quelltext (Shared Code)
- Quelltext und Tests (Code and Tests)
- Tägliche Auslieferung (Daily Deployment)
- Vertrag mit verhandelbarem Umfang (Negotiated Scope Contract)
- Bezahlung pro Benutzung (Pay per Use)
Clean Code
Kurzfassung
Clean Code Prinzipien
- Es soll das richtige Werkzeug verwendet werden.
- Maximierung des “Signal to noise ratio”
Signal: gewünscht (Logik)
Noise: unerwünscht/unnötig (Hilfsklassen usw.) - Selbst dokumentiert
Signal to noise ration
Signal:
- Logik – TED Regeln:
- Terse
- Expressive
- Do one thing
Don't Repeat Yourself (DRY)
- Ähnlich wie Normalisierung von Datenbanken.
- Copy & Paste ist oft ein Anzeichen für ein Designproblem.
SOLID Prinzipien
Single responsibility Principle SRP
- Eine Klasse soll nur eine Verantwortung (Aufgabe) haben.
Open Closed Principle OCP
- Softwaremodule (Klassen Funktionen) sind offen für Erweiterungen, jedoch geschlossen für Modifikationen.
Liskov Substitution Principle LSP
Interface Segregation Principle ISP
Dependency Invasion Principle DIP
Funktionen
- Funktionen sollten nur eine Aufgabe erledigen
- Funktionen sollen nicht zu lange sein
- Keine lange Parameterlisten
- Faustregel: Grundsätzlich nicht mehr als 3 Parameter. Totales maximum sollte 7 Parameter sein.
- zusammengehörige Parameter kapseln
- Faustregel: Grundsätzlich nicht mehr als 3 Parameter. Totales maximum sollte 7 Parameter sein.
- Funktionen sollen das tun, was man unter dem Funktionsname versteht.
Variablendeklarationen
- Variablennamen sollen aussagekräftig sein.
Schlecht
Customer theCustomer;
List listOfApprovedCustomers; Besser
Customer customer;
List approvedCustomers; Kommentare
- Meistens sind Kommentare redundant
Refactoring
- verbessert Design von Software
- macht Software leichter verständlich
- hilft Fehler zu finden
Wann Refaktorisieren
Dreierregel:
- Wird etwas ähnliches zum 3. mal gemacht, wird refaktorisiert.
Refaktorisieren beim
- hinzufügen von Funkonen
- beim Beheben eines Fehlers
- bei Codereviews
Refactoring (noun)
A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behaviour
Refactoring (verb)
To restructure software by applying a series of refactorings without changing its observable behaviour
Magic Numbers
Dabei hat man keine Ahnung, was die Zahlen bedeuten.
public final void ApproveDocument(int status) {
if (status == 1) {
...
}
else if (status == 2) {
...
}
} Besser ist es, ein enum zu verwenden.
public enum DocumentState {
DRAFT,
PUBLIC,
PRIVATE
}
public final void ApproveDocument(DocumentState status) {
if (status == DocumentState.DRAFT) {
...
}
else if (status == DocumentState.PUBLIC) {
...
}
} SWITCH Statement
public final void rejectDoument(int status)
{
switch (status)
{
case 1:
// ...
break;
case 2:
// ...
break;
}
} public enum DocumentState {
DRAFT,
PUBLIC,
PRIVATE
}
public final void rejectDoument(DocumentState status)
{
switch (status)
{
case DRAFT:
// ...
break;
case PUBLIC:
// ...
break;
default:
break;
}
} Verschachtelte Verzweigungen
if(a) {
if(b) {
if(c) {
...
} else {
...
}
}
} if (a && b && c) {
...
} else {
...
} Prüfungsvorbereitung
Eclipse - Autoformat
ctrl + shift + f
Scrum Prozess
User Stories sollen keine vollständige Spezifikationen sein
Die User Story soll ein Hilfsmittel für das persönliche Gespräch sein.
Es ist ein Versprechen für ein Gespräch.
Es soll klar sein, wie festgestellt wird, ob die User Story erfolgreich umgesetzt wurde. (Akzeptanzkriterien)
Vor- und Nachteile von Scrum
Nachteile:
– Aufwändige Kommunikation ( Daily Scrum)
– Kein Gesamtüberblick über das gesamte Projekt
Vorteile:
– Stärkere Eigenverantwortung des Teams
Kurze Kommunikationswege
Hohe Flexibilität / Agilität
Hohe Transparenz durch regelmässige Meetings
Scrum Team
Ein Scrum team ist cross-funktional, arbeitet autonom und organisiert sich selbst.
“Scrum-Teams sind autonome, businessfokussierte Teams, die ihren Prozess in Besitz nehmen und die Verantwortung für ihn tragen.”
S: 3 – Lehrmittel SCRUM – verstehen und erfolgreich einsetzen
Ereignisse
- Sprint Planning
- Daily Meeting
- Sprint Review
- Sprint Retrospektive
Artefakte
- Product Backlog
- Sprint Backlog
- Product Increment
User Story bewerten / formulieren
User Stories sollen keine vollständige Spezifikationen sein
Die User Story soll ein Hilfsmittel für das persönliche Gespräch sein.
Es ist ein Versprechen für ein Gespräch.
Es soll klar sein, wie festgestellt wird, ob die User Story erfolgreich umgesetzt wurde. (Akzeptanzkriterien)
Beispiel einer User Story:
- Als Kunde mit begrenztem Datenvolumen möchte ich meinen aktuellen Datenverbrauch abrufen können, um jederzeit zu wissen, ob ich für den aktuellen Monat noch ausreichend Datenvolumen zur Verfügung habe.
Alternatives Satzschema für User Stories
Damit [Nutzen] möchte ich als [Akteur] [Funktion]. Woran erkennt man eine gute User Story
Mithilfe den “INVEST” Kriterien erkennt der Product Owner, ob die User Story gut ist.
Jede einzelne User Story sollte unabhängig von anderen User Stories sein.
User Stories werden gemeinsam diskutiert
Das Ergebnis der User Story mus für den Anwender sinnvoll sein.
Der Aufwand für eine User Story muss einschätzbar sein
Der Umfang der User Story sollte in einem Sprint realisierbar sein.
Jede User Story muss getestet weren können. Mit dem Test wird die erfolgreiche Umsetzung der User Story festgestellt.
Akzeptanzkriterien
“Definition of done”
Akzeptantkriterien geben an, wie das Team feststellt, ob die User Story abgeschlossen ist.
Product Owner und Entwicklungsteam definieren die Akzeptanzkriterien gemeinsam.
Faustregel:
3 – 8 Akzeptanzkriterien für eine User Story.
Falls eine User Story zu gross ist und aufgeteilt werden muss:
- Man kann meist pro Akzeptanzkriterium eine eigene User Story definieren.
Sourcecode analysieren
Abnahmekriterien
Scrum Lehrmittel Seite 106
Refactoring
1. Korrektur funktionaler Fehler
2. Unit Tests
3. Code anpassen
Unit tests
@Test
@Test definiert, dass die folgende Methode eine Testmethode ist.
@Test
void doSomething() {
System.out.println("Do something!");
} @DisplayName
Mit @DisplayName kann der Name der Methode in der JUnit Laufzeitübersicht angepasst werden.
@Test
@DisplayName("printTest")
void printTest() {
System.out.println("Testing");
} @BeforeEach
@BeforeEach definiert, dass die folgende Methode vor jeder Testmethode zuerst aufgerufen wird.
@BeforeEach
void init() {
System.out.println("BeforeEach");
} @AfterEach
@AfterEach definiert, dass die folgende Methode nach jeder Testmethode zuerst aufgerufen wird.
@AfterEach
void init() {
System.out.println("AfterEach");
} Assertions
assertEquals
AssertEquals wird verwendet, wenn der erwartete Wert sowie der tatsächliche Wert identisch ist.
@Test
void isEqual() {
assertEquals("expected", "actual");
} assertNull
AssertNull wird verwendet, wenn überprüft werden soll, ob das Objekt null ist.
@Test
void isNull() {
assertNull(actual);
} @BeforeAll
Mit @BeforeAll wird die folgende Methode vor allen Testmethoden durchgeführt.
@BeforeAll
void printTest() {
System.out.println("Run once before all tests");
} @AfterAll
Mit @AfterAll wird die folgende Methode nach allen Testmethoden durchgeführt.
@AfterAll
void printTest() {
System.out.println("Run once after all tests");
}