Softwareentwicklung von Kopf bis Fuß

Table of contents

1. Copyright
2. Widmung
3. Die Autoren von Software entwicklung von Kopf bis Fuß
4. Über die Übersetzer dieses Buchs (die bei aller Berühmtheit nicht auf der Straße erkannt werden wollen)
5. Wie man dieses Buch benutzt Einführung
6. Gute Software entwickeln Den Kunden zufrieden stellen
   1. Toms Touren gehen online
   2. Die meisten Projekte starten mit ZWei wichtigen Fragen
   3. Entwicklung nach dem »Big Bang« – Ansatz
   4. Wir spulen vor: zwei Wochen später
   5. Big Bang-Ent wicklung endet meist mit einer üblen BAUCHLANDUNG
   6. Gute Software entwickeln
   7. Das Ziel mit ITERATIONEN erreichen
   8. Jede Iteration ist ein Mini-Projekt
   9. Jede Iteration entspricht QUALITÄTS-Software
   10. Der Kunde WIRD et was verändern
   11. Es ist Ihre Aufgabe, Anpassungen vorzunehmen
   12. Da gibt es aber ein paar MÄCHTIGE Probleme ...
   13. Iteration berücksichtigt Veränderungen automatisch (irgendwie jedenfalls)
   14. Ihre Software ist erst fertig, wenn sie VERÜFFENTLICHT ist
7. Anforderungen sammeln Wissen, was der Kunde will
   1. Ikarus Shuttle-Trips wird modernisiert
   2. Sprechen Sie mit Ihrem Kunden, um an MEHR Informationen zu kommen
   3. Blueskying – mit dem Kunden Wolken schieben
   4. Manchmal endet Blueskying so ...
   5. Finden Sie heraus, wie sich die Leute KONKRET verhalten
   6. Ihre Anforderungen müssen KUNDENzentriert sein
   7. Kundenfeedback zum Ent wickeln von Anforderungen nutzen
   8. User-Stories definieren das WAS Ihres Projekts ... Abschätzungen definieren das WANN
   9. Bürogespräch
   10. Spielen wir das Planungsspiel
   11. Machen Sie Annahmen den Prozess
   12. Für eine User-Story ist eine GROSSE Abschätzung eine SCHLECHTE Abschätzung
   13. Das Ziel heißt konvergenz
   14. Der Iterationszyklus von der Anforderung bis zur Abschätzung
   15. Jetzt endlich sind Sie so weit und können das gesamte Projekt abschätzen ...
8. Projektplanung Mit Planung zum Erfolg
   1. Kunden wollen ihre Software SOFORT!
   2. Prioritäten festlegen – mit dem Kunden zusammen
   3. Wir wissen, was in Meilenstein 1.0 hineinkommt (ja, vielleicht)
   4. Prüfen Sie die Abschätzung für Meilenstein 1.0 auf Herz und Nieren
   5. Wenn die Features nicht passen, überarbeiten Sie die Prioritäten
   6. Manchmal bedeuten mehr Leute weniger Ertrag
   7. Arbeiten Sie sich zu einem vernünftigen Meilenstein 1.0 vor
   8. Bei Iterationen liegt die Würze in der Kürze
   9. Vergleich von Planung und Realität
   10. Velocity berücksichtigt overhead in Ihren Abschätzungen
   11. Programmierer rechnen in UTOPISCHEN Tagen ...
   12. Ent wickler rechnen in REALEN Tagen ...
   13. Wann dauert Ihre Iteration zu lange?
   14. Befassen Sie sich mit dem Durchsatz, BEVOR Sie Iterationen einteilen
   15. Zeit für eine Beurteilung
   16. Mit völlig angener vten Kunden umgehen
   17. Die große Tafel da an Ihrer Wand
   18. Wie Sie den Leuten in Ihrem Team das Leben vermiesen
9. User-Stories und Tasks Jetzt aber an die Arbeit
   1. Dürfen wir vorstellen? – binHinUndWeg
   2. Addieren sich Ihre Tasks zum richtigen Ergebnis?
   3. Tragen Sie nur die Arbeit ab, die noch Übrig ist
   4. Hängen Sie Ihre Tasks an die Tafel
   5. Fangen Sie an, an Ihren Tasks zu arbeiten
   6. Ein Task ist erst dann IN ARBEIT, wenn er in Arbeit ist
   7. Und wenn ich an zwei Sachen gleichzeitig arbeite?
   8. Ihr erstes Stand-up-Meeting ...
   9. Task 1: die »Date«-Klasse anlegen
   10. Stand-up-Meeting: Tag 5, also Ende von Woche 1 ...
   11. Stand-up-Meeting: Tag 2, Woche2
   12. Wir unterbrechen dieses Kapitel ...
   13. Ungeplante Tasks müssen festgehalten werden
   14. Uner wartete Tasks lassen Ihren Burndown-Verlauf ansteigen
   15. Durchsatz ist hilfreich, aber ...
   16. Sie haben eine Menge zu tun ...
   17. ... aber Sie wissen GENAU, wo Sie stehen
10. Gut genug-Design Fertig werden – mit gutem Design
    1. binHinUndWeg steckt in ernsten Schwierigkeiten ...
    2. Dieses Design verstößt gegen das Prinzip der einen Verantwortlichkeit
    3. Mehrere Verantwortlichkeiten im Design aufspüren
    4. Von mehreren Verant wortlichkeiten zu einer Verant wortlichkeit übergehen
    5. Ihr Design sollte dem SRP folgen, aber ebenso dem DRY-Prinzip ...
    6. Das Post-Refactoring-Stand-up-Meeting ...
    7. Ungeplante Tasks sind trotz allem immer noch Tasks
    8. Die Demo ist selbst Teil Ihres Tasks
    9. Wenn alles erledigt ist, ist die Iteration beendet
11. Versionskontrolle Defensives Programmieren
    1. Sie haben einen neuen Auftrag – BeatBox Pro
    2. Und jetzt die Arbeit am GUI ...
    3. Und ein schneller Test ...
    4. Dasselbe macht Jan ...
    5. Führen Sie Ihrem Kunden die neue BeatBox vor
    6. Stand-up-Meeting
    7. Kommen wir zum Thema VERSIONSKONTROLLE
    8. Zuerst legen Sie Ihr Projekt an ...
    9. ... anschließend können Sie code ein- und auschecken
    10. Die meisten Werkzeuge zur Versionskontrolle versuchen, Probleme für Sie zu lösen
    11. Der Ser ver versucht, Ihre änderungen ZUSAMMENZUFÜHREN
    12. Wenn Ihre Software die Änderungen nicht zusammenführen kann, meldet sie einen Konflikt
    13. Das zeigen Sie jetzt dem Kunden ...
    14. Noch mehr Iterationen, noch mehr Stories ...
    15. Stand-up-Meeting
    16. Wir haben mehr als eine Version von unserer Software ...
    17. Gute commit-Kommentare machen es Ihnen leichter, ältere Software zu finden
    18. Jetzt können Sie Version 1.0 auschecken
    19. (Notfall-)Stand-up-Meeting
    20. Geben Sie Ihren Versionen ein Tag
    21. Tags, Zweige und Trunks ... au weia!
    22. Version 1.0 korrigieren ... diesmal aber wirklich!
    23. Wir haben jetzt ZWEI codestämme.
    24. Wann man KEINEN Zweig anlegen sollte ...
    25. Versionskontrolle kann nicht dafür sorgen, dass Ihr code wirklich funktioniert ...
12. Code erstellen Lasche A durch Schlitz B stecken ...
    1. Entwickler sind keine Gedankenleser
    2. Ihr Projekt in einem Schritt erstellen
    3. Ant: Ein Build-Tool für Java-Projekte
    4. Projekte, Properties, Targets, Tasks
    5. Gute Build-Skripte ...
    6. Gute Build-Skripte gehen über das Übliche HINAUS
    7. Auch Ihr Build-Skript ist code
    8. Neuer Ent wickler, Klappe, die zweite
    9. Werkzeuge für Ihre Softwareentwickler-Kiste
13. Tests und kontinuierliche Integration Damit nichts schiefgeht
    1. Schiefgehen tut es IMMER
    2. Ihr System können Sie auf dreierlei Weise betrachten
    3. Black-Box-Tests konzentrieren sich auf EINGABE und AUSGABE
    4. Grey-Box-Tests bringen Sie NÄHER an den code
    5. White-Box-Tests nutzen Insider wissen
    6. ALLES in einem Schritt testen
    7. Tests mit einem Test-Framework automatisieren
    8. Führen Sie Ihre Tests mit dem Framework aus
    9. CI im Griff mit cruisecontrol
    10. Tests sichern, dass alle funktioniert ... oder?
    11. Den gesamten code testen heißt, ALLE ZWEIGE zu testen
    12. Mit einem Abdeckungsbericht prüfen, was abgedeckt wird
    13. Eine gute Abdeckung zu erreichen ist nicht immer leicht ...
14. Testgetriebene Entwicklung Ihren Code verantwortlich machen
    1. Testen Sie ERST, nicht zum Schluss
    2. Wir werden also ERST testen ...
    3. Willkommen bei der testgesteuerten Entwicklung
    4. Ihr erster Test ...
    5. ... schlägt kläglich fehl.
    6. Machen Sie Ihre Tests GRÜN
    7. Rot, grün, Refactoring ...
    8. Bei TDD LENKEN Tests Ihre Implementierung
    9. Gehen Sie weiter, wenn Ihr Test erfolgreich ist!
    10. Andere Aufgabe, gleiches Verfahren
    11. Rot: (Scheiternde) Tests schreiben
    12. Grün: code schreiben, damit der Test erfolgreich ist
    13. Einfachheit heißt, Abhängigkeiten zu vermeiden
    14. Schreiben Sie immer testbaren code
    15. Schauen Sie sich Ihren Entwurf an, wenn das Testen schwer wird
    16. Das Strategy-Muster ermöglicht mehrere Implementierungen eines Interface
    17. Halten Sie Ihren Testcode bei Ihren Tests
    18. Testen führt zu besserem code
    19. Mehr Tests bedeuten immer viel mehr code
    20. Strategy-Muster, lockere Bindung, Mock-objekte ...
    21. Wir brauchen viele unterschiedliche, aber ähnliche objekte
    22. Können wir nicht objekte generieren?
    23. Ein Mock-objekt vertritt echte objekt
    24. Mock-objekte sind funktionierende objekt vertreter
    25. Gute Software ist testbar
    26. Es ist nicht immer leicht, grün zu sein ...
    27. Ein Tag im Leben eines testgesteuerten Entwicklers
15. Eine Iteration abschließen Alles fügt sich zusammen ...
    1. Ihre Iteration ist fast abgeschlossen ...
    2. ... aber es gibt eine Menge, was Sie noch tun könnten
    3. Systemtests sind NOTWENDIG ...
    4. ... aber WER führt sie durch?
    5. Systemtests benötigen ein vollständiges System
    6. Gute Systemtests erfordern ZWEI Iterationszyklen
    7. Mehr Iterationen führen zu mehr Problemen
    8. 10 Kennzeichen effektiver Systemtests
    9. Leben (und Sterben) eines Bugs
    10. Sie haben also einen Bug gefunden ...
    11. Anatomie eines Bug-Reports
    12. Aber es gibt eine Menge Dinge, die Sie noch tun KÖNNTEN ...
    13. Zeit für den Iterationsrückblick
    14. Einige Fragen für den Iterationsrückblick
    15. Eine ALLGEMEINE Prioritätsliste zur Erledigung ZUSÄTZLICHER Dinge ...
16. Die nächste Iteration Es ist nicht kaputt ... reparieren Sie es trotzdem
    1. Was ist funktionierende Software?
    2. Sie müssen die nächste Iteration planen
    3. Der Durchsatz trägt dem WAHREN LEBEN Rechnung
    4. Es geht IMMER noch um den Kunden
    5. Auch die Software eines anderen ist BLOß Software
    6. Kundenzustimmung? Prüfen!
    7. Ihren code testen
    8. Houston, wir haben ein ernsthaf tes Problem ...
    9. Vertrauen Sie KEINEM
    10. Sie ohne Ihren Prozess
    11. Sie mit Ihrem Prozess
17. Bugs beheben wie ein Profi
    1. Zunächst müssen Sie mit dem Kunden reden
    2. Priorität eins: Die Dinge erstellbar machen
    3. Wir könnten den code reparieren ...
    4. ... müssen aber die Funktionalität reparieren
    5. Herausfinden, welche Funktionalität funktioniert
    6. JETZT wissen Sie, was nicht funktioniert
    7. Was würden Sie tun?
    8. Spike-Test zum Abschätzen
    9. Was sagen Ihnen die Ergebnisse der Spike-Tests?
    10. Das Bauchgefühl Ihres Teams zählt
    11. Geben Sie Ihrem Kunden die Bug-Fix-Abschätzung
    12. Die Dinge sehen gut aus ...
    13. ... und Sie schließen die Iteration erfolgreich ab!
    14. UND was am wichtigsten ist der Kunde ist zufrieden
18. Das wahre Leben Ein Prozess fürs Leben
    1. Einen Software entwicklungsprozess fixieren
    2. Ein guter Prozess liefert gute Software aus
    3. Förmliche Kleidung erforderlich ...
    4. Einige zusätzliche Ressourcen ...
    5. Mehr Wissen = bessere Prozesse
19. Was übrig bleibt Die Top Five der Themen (die wir nicht behandelt haben)
    1. UML-Klassendiagramme
    2. Sequenzdiagramme
    3. User-Stories und Anwendungsfälle
    4. System-Tests vs. Unit-Tests
    5. Refactoring
20. Techniken und Prinzipien Werkzeuge für den erfahrenen Softwareentwickler
    1. Entwicklungstechniken
    2. Entwicklungsprinzipien