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-05-31 17:07] stefan |
||
|---|---|---|---|
| Zeile 4: | Zeile 4: | ||
| [[http://c2.com/cgi/wiki?ExtremeProgramming|Wiki von Ward Cunningham]] | [[http://c2.com/cgi/wiki?ExtremeProgramming|Wiki von Ward Cunningham]] | ||
| - | **nach {[quellen:Bleek2008|S. 137ff.]}** | + | **nach \cite[S. 137ff.]{Bleek2008}** |
| * 5 Werte | * 5 Werte | ||
| * Kommunikation | * Kommunikation | ||
| Zeile 37: | Zeile 37: | ||
| * Slack: Entwickler brauchen auch während des Projekts Freiraum um sich über neue, projektferne Dinge zu informieren, um neue Anregungen in das Projekt zu bringen und nicht nur noch durch die Projektbrille schauen (und dadurch in anderen Projekten nicht mehr gut einsetzbar sind) | * Slack: Entwickler brauchen auch während des Projekts Freiraum um sich über neue, projektferne Dinge zu informieren, um neue Anregungen in das Projekt zu bringen und nicht nur noch durch die Projektbrille schauen (und dadurch in anderen Projekten nicht mehr gut einsetzbar sind) | ||
| * Ten-Minute Build: ein Build inkl. Tests darf max. 10 Minuten dauern | * Ten-Minute Build: ein Build inkl. Tests darf max. 10 Minuten dauern | ||
| - | * Continuous Integration: mehrmals am Tag integrieren die Entwickler ihre Änderungen in die Quelltextbasis | + | * [[se:continuousintegration|Continuous Integration]]: mehrmals am Tag integrieren die Entwickler ihre Änderungen in die Quelltextbasis |
| * Test-First Programming: Tests werden vor dem eigentlichen Code entwickelt | * Test-First Programming: Tests werden vor dem eigentlichen Code entwickelt | ||
| * 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 | ||
| + | |||
| + | ===== Pair Programming ===== | ||
| + | **nach \cite{Haase2006}** | ||
| + | * Ziele: Global Code Ownership, Mentoring/Training, höhere Codequalität | ||
| + | * Regeln/Voraussetzungen | ||
| + | * die Teilnehmer sollten das Keyboard alle 10-15 Minuten austauschen | ||
| + | * die Sessions sollten nicht zu lange dauern (max. 3-4 Stunden) | ||
| + | * beide Partner sollten ungefähr auf dem gleichen Wissensstand/Skilllevel sein | ||
| + | * Möglichkeit/Gelegenheit, Pair Programming "einzuführen": bei auftretenden Bugs in vorhandenem Code, den Kollegen, der diesen Code geschrieben hat, bitten, mit ihm gemeinsam den Bug zu fixen. So verteilt sich Code Ownership auf beide Kollegen. | ||
| + | |||
| + | ==== Vorteile von Pair Programming ==== | ||
| + | **nach \cite[S. 319]{Goodliffe2006}** | ||
| + | * 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
