Benutzer-Werkzeuge

Webseiten-Werkzeuge


se:extremeprogramming

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

se:extremeprogramming [2010-05-31 17:07]
stefan
se:extremeprogramming [2014-04-05 11:42]
Zeile 1: Zeile 1:
-====== Extreme Programming ====== 
-Agiler Softwareentwicklungsprozess von Kent Beck. 
- 
-[[http://​c2.com/​cgi/​wiki?​ExtremeProgramming|Wiki von Ward Cunningham]] 
- 
-**nach \cite[S. 137ff.]{Bleek2008}** 
-  * 5 Werte 
-    * Kommunikation 
-    * Rückkopplung 
-    * Einfachheit 
-    * Mut 
-    * Respekt 
-  * 14 Prinzipien 
-    * Menschlichkeit:​ Software wird von Menschen entwickelt 
-    * Wirtschaftlichkeit:​ Softwareprojekte müssen sich lohnen, Nutzen > Kosten 
-    * gegenseitiger Vorteil: Zusammenarbeit anstatt Aurichtung auf eigenen Vorteil 
-    * Selbstähnlichkeit:​ bereits Vorhandenes kann meist auf neue Projekte übertragen werden 
-    * Verbesserung:​ sowohl der Prozess als auch das Produkt werden kontinuierlich weiterentwickelt 
-    * Mannigfaltigkeit:​ unterschiedliche Meinungen und Erfahrungen sind willkommen, da nur so Innovation möglich ist 
-    * Reflexion: Lernen und Verbesserung 
-    * Fluss: die Arbeit soll flüssig von der Hand gehen und nicht ins Stocken geraten 
-    * Gelegenheit:​ Probleme sind Gelegenheiten etwas Neues zu lernen und zu wachsen (positive Grundhaltung) 
-    * Redundanz: bezogen auf das Entwicklungsteam (Stichwort "​Truckfaktor"​) 
-    * Fehlschlag: Probleme und Fehlschläge gehören dazu und müssen akzeptiert werden, da meist nur durch sie bessere Lösungen gefunden werden können (anstatt immer die bewährten Wege zu gehen) 
-    * Qualität: das Team muss sich komplett der Qualität verschreiben und ggfs. gegen andere Faktoren (z.B. Termindruck) entscheiden 
-    * Babyschritte:​ kleine Schritte ergeben im Fehlerfall nur kleine Rückschläge,​ große lassen evtl. das Projekt scheitern 
-    * akzeptierte Verantwortlichkeit:​ jeder Projektteilnehmer muss die ihm übertragene und auch seine implizite Verantwortung erkennen und akzeptieren 
-  * 13 Primärpraktiken 
-    * Sit Together: die Teammitglieder sollten nah beieinander sitzen um die Kommunikation zu optimieren 
-    * Whole Team: das Team muss alle im Projekt benötigten fachlichen und technischen Fähigkeiten umfassen 
-    * Informative Workspace: die Arbeitsumgebung muss über den aktuellen Fortschritt des Projekts informieren (z.B. durch Flipcharts) 
-    * Energized Work: alle Teammitglieder sind engagiert 
-    * Pair Programming:​ zwei Entwickler programmieren im Team 
-    * Stories: Anforderungen werden als Geschichten erfasst 
-    * Weekly Cycle: eine Iteration dauert eine Woche 
-    * Quarterly Cycle: ein Release dauert 3 Monate 
-    * 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 
-    * [[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 
-    * Incremental Design: beim Entwurf werden immer nur die aktuell relevanten Anforderungen berücksichtigt 
-  * 11 Folgepraktiken 
-    * Real Customer Involvement:​ der Kunde wird in die Arbeit mit Storys und den Entwurf integriert 
-    * Incremental Deployment: erstellte Releases sollen auch produktiv eingesetzt werden 
-    * Team Continuity: Teammitglieder sollten zu 100% im Projekt arbeiten und die Personalfluktuation sollte minimiert werden 
-    * 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: systematische Suche nach den Ursachen eines Problems 
-    * Shared Code: jeder Entwickler darf den kompletten Quelltext verändern 
-    * Code and Tests: außer dem Quelltext und den Tests werden keine weiteren Artefakte erstellt (insb. keine Dokumentation) 
-    * Single Code Base: es gibt nur eine Quelltextbasis und Entwicklungszweige werden nur kurzfristig verwendet 
-    * Daily Deployment: der aktuelle Entwicklungsstand sollte täglich an die Anwender verteilt werden 
-    * Negotiated Scope Contract: es wird ein festes Budget und ein verhandelbarer Funktionsumfang festgehalten 
-    * 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)