Benutzer-Werkzeuge
se:extremeprogramming
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
| Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung Nächste Überarbeitung Beide Seiten der Revision | ||
|
se:extremeprogramming [2010-05-03 10:47] 127.0.0.1 Externe Bearbeitung |
se:extremeprogramming [2010-05-31 17:07] stefan |
||
|---|---|---|---|
| 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 | ||
| Zeile 65: | Zeile 65: | ||
| - Planung der nächsten Iteration bzw. des nächsten Releases | - Planung der nächsten Iteration bzw. des nächsten Releases | ||
| - | ===== Vorteile von Pair Programming ===== | + | ===== 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}** | **nach \cite[S. 319]{Goodliffe2006}** | ||
| * Wissenstransfer zwischen Entwicklern | * Wissenstransfer zwischen Entwicklern | ||
| Zeile 76: | Zeile 85: | ||
| * verteilt gute Codepraktiken und -standards unter den Entwicklern | * verteilt gute Codepraktiken und -standards unter den Entwicklern | ||
| * unterstreicht den Entwicklungsprozess | * 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
