Refactoring
Simple Design: Mach das einfachste was irgendwie funktioniert
Pair Programming: Zwei Leute, ein PC, Vier Augen
Coding Standards: Layout, Namenskonventionen
Collective Ownership: Jeder darf am ganzen Code Änderungen vornehmen
40h-Week
On-site Customer: Sitzt mit im Team, kann immer Entscheidungen treffen → geht aber praktisch nicht, dass Auftraggeber eigenen Mann während der Durchführung des Projekts fürs Rumsitzen und Fragenbeantworten bezahlt
Metaphor: Abstrahierung, Modellbildung
Beispiel:
Kosten: 5M (8M)
Zeit: 31.3.06 (31.12.06)
Features: MUMBA (MIMBA)
Qualität: 100% (90%)
⇒ Darum: Kunde kann nur drei Variablen festlegen, d.h. eigentlich nur zwei, denn Qualität ist nicht verhandelbar
schwierig: Erstauftrag
Pläne sind im Grunde nutzlos, das Planen ist aber dennoch wichtig (schon allein, um später aus Fehler lernen zu können)
Release early, release often
Releases = Ausliefern, Iterationen intern
user stories: Kleine Funktionalitätseinheiten, nach Möglichkeit unabhängig voneinander, testbar
Release Neuplanung ⇒ zuviele Tasks, keine Tasks, Gruppenänderungen
Grundlagen Schätzungen immer vergangene Ergebnisse
Aufschreiben, wie lange für einen Task braucht
(Fehl-)Schätzungen = Erfahrung
Konstantes Timetracking während der Iteration
auch dann releasen, wenn noch nicht alles fertig
Testwerkzeug: schnelle Ausführung, umfassend
Fortlaufende Integration: Jeden Abend nach erfolgreichem (!) Test ⇒ Checkin, wenn broken → reparieren, dann checkin, IMMER checkin
Erst Test, dann richtig coden
Test = Doku, definiert Komponente
großer Wert auf Kommunikation
Mut: z.B. auch mal Rückschritte in Kauf nehmen, um am Ende besser vorwärts zukommen (bsp. Rewrite)
Pflichtenheft: Ist, Soll, Stories, Rechtekapitel (Urheber, Vervielfältigung)
geplante Releases bzw Milestones
Schalenmodell: Core, nette Features, theoretische Konzepte