SWEN2

• Independent
• Negotiable
• Valuable
• Estimatable
• Small
• Testable

=> INVEST

Abhängigkeiten führen zu Problemen in Bezug auf die Priorisierung und Schätzung. Im Idealfall kann eine User Story für die Umsetzung ausgewählt werden, ohne dass eine Vielzahl anderer Stories mitberücksichtigt werden müssen.

Vermeiden durch Kombination und erneutem Aufteilen

User Stories sind keine Verträge aber zentrale Artefakte für die Entwicklung und den Kunden.

Unnötige Details sind zu vermeiden.

Details können im Rahmen von Tests niedergeschrieben werden (auf der Rücksseite)

User Stories sollten für den Kunden von Wert sein und nicht für die Entwicklung.

Solche, die aus der Entwicklung kommen, sollten umgeschrieben werden, damit sie den Wert für den Kunden reflektieren.

User Stories sollten unbedingt schätzbar sein. Die Planung basiert darauf.

Gründe warum sie nicht schätzbar sind:

• Der Entwicklung fehlt das Fachwissen
• Der Entwicklung fehlt das technische Know-How
• User Storie ist zu umfangreich

Kleine User Stories sind einfacher zu planen und zu priorisieren.

User Stories müssen testbar sein.

• Komplexe User Stories
• User Stories, die eine Vielzahl von Anforderungen abdecken.

Sie sind die wichtigste Determinante für die Priorisierung.

Dass sie sich über die Zeit verändern können.

Die Ersparnis oder die zusätzlichen Einnahmen durch eine bestimmte Funktion

• Neue oder zusätzliche Einnahmen, bessere Effizienz / Effektivität
• Der Wert der Zeit
• Net Present Value (NPV)
• Return On Investment (ROI)

Sie sind ein integraler Bestandteil der meisten Projekte. Sie haben eine Eintretenswahrscheinlichkeit und einen Impact auf das Projekt im Falle eines Eintretens.

• Zeitliche Risiken
• Risiken bzgl. Kosten
• Funktionale Risiken

• Wissen über das Produkt (Was wird entwickelt)
• Wissen über das Projekt (Wie wird entwickelt)

Zu einer Reduktion der Unsicherheit.

• Basic Needs: "must be" requirements
• Performance Needs: more is better
• Delighters: not expected but provide great customer satisfaction

Software Architektur ist der Blueprint (Bauplan) für die Konstruktion und Evolution eines Software Systems.

• Structure
• Behaviour
• Interaction
• Non-Functional Properties

• Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, even late in delevopment. Agile processes harness change for the customer's competitive advantage.
• Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Business people and developers must work together daily throughout the project
• Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
• The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• Working is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical exellence and good design enhances agility.
• Simplicity - the art of maximizing the amount of work not done - is essential
• The best architectures, requirements and desings emerge from self-oranising teams.
• At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly

• Individuals and interactions over processes and tools
  • Leute sollen mehr Wertschätzung erhalten als Prozesse oder Tools, denn es sind Leute, die auf Geschäftsbedürfnisse eingehen und den Entwicklungsprozess vorwärts treiben.
    Wenn der Prozess oder die Tools das tun würden, könnte das Team weniger schnell auf Änderungen reagieren und weniger auf Kundenbedürfnisse eingehen.
• Working software over comprehensive documentation
  • Agilität elliminiert die Dokumentation nicht, aber es strafft sie in einer Art, die dem Entwickler gibt, was nötig ist um die Arbeit zu erledigen, ohne sich in Details festzufahren.
• Customer collaboration over contract negotiation
  • Durch Kollaboration wird der Kunde in den ganzen Entwicklungsprozess eingebunden und nicht nur am Anfang und am Ende. Das stellt sicher, dass das Produkt den Geschäftsbedürfnissen des Kunden entspricht.
• Responding to change over following a plan
  • Durch die Kürze der Iterationen in Agile können Prioritäten von Iteration zu Iteration angepasst und neue Features können hinzugefügt werden. Änderungen verbessern, aus der Sicht von Agile, immer das Projekt. Sie fügen zusätzlichen Wert hinzu.

• Kent Beck
• Mike Beedle
• Arie van Benekum
• Alistair Cockburn
• Ward Cunningham
• Martin Fowler
• James Grenning
• Jim Highsmith
• Andrew Hunt
• Ron Jeffries
• Jon Kern
• Brian Marick
• Robert C. Martin
• Steve Mellor
• Ken Schwaber
• Jeff Sutherland
• Dave Thomas

• Project cancelled
• Business misunderstood
• Business changes
• Staff turnover

XP soll uns Prinzipien und Praktiken geben, um mit diesen Risiken umzugehen.

• Communication
• Simplicity
• Feedback
• Courage
• Respect

Jeder ist Teil des Teams und wir kommunizieren täglich face-to-face. Wir werden an allem gemeinsam arbeiten, von den Anforderungen bis zum Code. Wir werden gemeinsam die bestmögliche Lösung für unser Problem kreieren.

Wir werden das tun, was nötig und verlangt ist, aber nicht mehr. Dies wird den Wert für das bisher gemachte Investment maximieren. Wir werfen kleine, einfache Schritte auf unser Ziel zu machen und Fehler behandeln, wenn sie auftreten.
Wir werden etwas kreieren, worauf wir stolz sind und es über lange Zeit zu vernünftigen Kosten unterhalten können.

Wir werden jedes Iterations-Commitment ernst nehmen, ndem wir funktionierende SW liefern. Wir demonstrieren unsere SW früh und oft. Dann werden wir zuhören und die nötigen Änderungen vornehmen. Wir werden über das Projekt sprechen und unseren Prozess wo nötig anpassen.

Wir werden die Wahrheit über Fortschritt und Schätzung sagen. Wir dokumentieren keine Entschuldigungen für Fehler, denn wir planen erfolgreich zu sein.
Wir haben keine Angst, denn niemand arbeitet je alleine. Wir werden uns an Änderungen anpassen, wann immer sie auftreten.

Jeder spürt und gibt den Respekt, den er als wertvolles Teammitglied verdient. JEder trägt seinen Teil bei, selbst wenn es nur Ethusiasmus ist. Entwickler repsektieren die Expertise der Kunden und vice versa.
Das Management repektiert unser Recht Verantwortung zu akzeptieren und die Autorität über unsere eigene Arbeit zu haben.

• Rapid Feedback
• Assume Simplicity
• Incremental Change
• Embracing Change
• Quality Work

• The Planning Game
• Small Releases
• Metaphor
• Simple Design
• Testing
• Refactoring
• Pair Programming
• Collective Ownership
• Continuous Integration
• 40 hours week
• On-site customer
• Coding Standards

Balance finden, zwischen business und technischen Betrachtungen.

Business Leute entscheiden über:

• Scope
• Priorität
• Zusammensetzung von Releasen
• Zeitpunkt von Releasen

Techniker entscheiden über:

• Einschätzung
• Konsequenzen
• Prozess
• detaillierte Plannung

Jeder Release sollte so klein wie möglich sein und die wertvollsten Business Requirements beinhalten.
Der Release als Ganzes muss Sinn ergeben (keine halbwegs funktionierenden Features). Es ist besser 1/Monat zu releasen, als 2/Jahr.

Jeder im Team muss ein "gemeinsames Verständnis" für das System haben. Ausserdem muss das Team ein "gemeinsames Vokabular" haben. Das betrifft sowohl technische, als auch nicht technische Leute.

Es muss klar sein, was die Basiselemente des Systems sind und wie sie in Beziehung zueinander stehen.

Das richtige Desing für ein SW System ist eines,

• bei dem alles getestet wird
• das keine duplizierte Logik hat
• das die kleinst mögliche Anzahl an Klassen und Methoden hat
• das ein aufstrebendes, wachsendes Design hat.

Ein Programmfeature ohne automatisierten Test gibt es nicht. Die Test werden Teil des Systems und erlauben es dem System, Änderungen zu akzeptieren.

Development Cycle:

• Listen (Requirements)
• Test (write first)
• Code (simplest)
• Design (refactor)

Wenn ein Feature implementiert wird, sollte man sich fragen, ob es einen Weg gibt, den existierenden Source Code so zu verbessern, damit die Implementierung dieses Features einfacher wird.

Automatisierte Tests bieten ein Sicherheitsnetz für Refactoring.

Der Produktions-Code wird von 2 Leuten geschrieben, die auf einen Bildschirm schauen (mit nur 1 Maus und 1 Tastatur).

Es gibt 2 Rollen. Der Programmierer an der Tastatur konzentriert sich auf die momentane Methode. Der andere Programmierer denkt über den breiteren  Kontext nach (Refactoring, etc.).

Die Paare sollten regelmässig wechseln.