Benutzer-Werkzeuge

Webseiten-Werkzeuge


se:extremeprogramming

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
se:extremeprogramming [2010-05-04 10:38]
stefan
se:extremeprogramming [2014-04-05 11:42] (aktuell)
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
  
-===== 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.1272962315.txt.gz · Zuletzt geändert: 2014-04-05 11:42 (Externe Bearbeitung)