Benutzer-Werkzeuge
se:extremeprogramming
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
| Nächste Überarbeitung | Vorhergehende Überarbeitung Nächste Überarbeitung Beide Seiten der Revision | ||
|
se:extremeprogramming [2008-12-27 21:08] stefan angelegt |
se:extremeprogramming [2010-01-18 11:31] 127.0.0.1 Externe Bearbeitung |
||
|---|---|---|---|
| Zeile 41: | Zeile 41: | ||
| * Incremental Design: beim Entwurf werden immer nur die aktuell relevanten Anforderungen berücksichtigt | * Incremental Design: beim Entwurf werden immer nur die aktuell relevanten Anforderungen berücksichtigt | ||
| * 11 Folgepraktiken | * 11 Folgepraktiken | ||
| - | * Real Customer Involvement | + | * Real Customer Involvement: der Kunde wird in die Arbeit mit Storys und den Entwurf integriert |
| - | * Incremental Deployment | + | * Incremental Deployment: erstellte Releases sollen auch produktiv eingesetzt werden |
| - | * Team Continuity | + | * Team Continuity: Teammitglieder sollten zu 100% im Projekt arbeiten und die Personalfluktuation sollte minimiert werden |
| - | * Shrinking Teams | + | * Shrinking Teams: die Produktivität der Entwickler soll schrittweise soweit erhöht werden, dass ein Teammitglied in ein anderes Projekt wechseln kann |
| - | * Root-Cause Analysis | + | * Root-Cause Analysis: systematische Suche nach den Ursachen eines Problems |
| - | * Shared Code | + | * Shared Code: jeder Entwickler darf den kompletten Quelltext verändern |
| - | * Code and Tests | + | * Code and Tests: außer dem Quelltext und den Tests werden keine weiteren Artefakte erstellt (insb. keine Dokumentation) |
| - | * Single Code Base | + | * Single Code Base: es gibt nur eine Quelltextbasis und Entwicklungszweige werden nur kurzfristig verwendet |
| - | * Daily Deployment | + | * Daily Deployment: der aktuelle Entwicklungsstand sollte täglich an die Anwender verteilt werden |
| - | * Negotiated Scope Contract | + | * Negotiated Scope Contract: es wird ein festes Budget und ein verhandelbarer Funktionsumfang festgehalten |
| - | * Pay per Use | + | * Pay per Use: es wird nicht pro Release bezahlt, sondern pro Nutzung einer Funktion |
| + | * Rollen | ||
| + | * Entwickler | ||
| + | * Kunde | ||
| + | * Tracker | ||
| + | * XP-Coach | ||
| + | * Projektablauf | ||
| + | - Kunde wählt Anforderungen für Release (3 Monate) | ||
| + | - Entwickler schätzen Aufwände und geben Rückkopplung | ||
| + | - Kunde wählt konkrete Anforderungen für Release und erste Iteration | ||
| + | - Entwickler implementieren und fragen ggfs. nach Details | ||
| + | - am Ende der Iteration werden die Ergebnisse dem Kunden präsentiert und dieser gibt Rückkopplung | ||
| + | - Planung der nächsten Iteration bzw. des nächsten Releases | ||
| + | ===== Vorteile von Pair Programming ===== | ||
| + | **nach {[quellen:Goodliffe2008|S. 319]}** | ||
| + | * Wissenstransfer zwischen Entwicklern | ||
| + | * zentriert den Fokus auf das Entwickeln (und vermeidet Tagträume) | ||
| + | * erhöht die Disziplin | ||
| + | * vermindert die Unterbrechungshäufigkeit (man stört zwei Personen, die arbeiten nicht so gerne, wie eine einzelne) | ||
| + | * quasi "Echtzeit-Reviews" -> besserer Code als Ergebnis | ||
| + | * sozialer Faktor: die Entwickler lernen sich besser kennen und das fördert die Moral | ||
| + | * Collective Code Ownership | ||
| + | * verteilt gute Codepraktiken und -standards unter den Entwicklern | ||
| + | * unterstreicht den Entwicklungsprozess | ||
se/extremeprogramming.txt · Zuletzt geändert: 2014-04-05 11:42 (Externe Bearbeitung)
Seiten-Werkzeuge
Falls nicht anders bezeichnet, ist der Inhalt dieses Wikis unter der folgenden Lizenz veröffentlicht: CC Attribution-Noncommercial-Share Alike 4.0 International
