Planung-Spiel
XP Planung befasst sich mit zwei zentralen Fragen in der software-Entwicklung: die Vorhersage, was erreicht wird, indem das Fälligkeitsdatum, und der Bestimmung, was als Nächstes zu tun ist. Der Schwerpunkt liegt auf der Steuerung des Projekts – was ziemlich einfach ist – und nicht auf der genauen Vorhersage dessen, was benötigt wird und wie lange es dauern wird – was ziemlich schwierig ist., Es gibt zwei wichtige Planungsschritte in XP, die sich mit diesen beiden Fragen befassen:
Release Planning ist eine Praxis, bei der der Kunde den Programmierern die gewünschten Funktionen präsentiert und die Programmierer ihre Schwierigkeit schätzen. Mit den Kostenvoranschlägen in der Hand und mit Kenntnis der Bedeutung der Funktionen legt der Kunde einen Plan für das Projekt fest. Erste Release-Pläne sind notwendigerweise ungenau: Weder die Prioritäten noch die Schätzungen sind wirklich solide, und bis das Team zu arbeiten beginnt, werden wir nicht wissen, wie schnell sie gehen werden., Selbst der erste Release-Plan ist jedoch genau genug für die Entscheidungsfindung, und XP-Teams überarbeiten den Release-Plan regelmäßig.
Iterationsplanung ist die Praxis, bei der dem Team alle paar Wochen eine Richtung gegeben wird. XP-Teams erstellen Software in zweiwöchigen „Iterationen“und liefern am Ende jeder Iteration nützliche Software. Während der Iterationsplanung stellt der Kunde die gewünschten Funktionen für die nächsten zwei Wochen vor. Die Programmierer teilen sie in Aufgaben auf und schätzen ihre Kosten (auf einer feineren Detailebene als in der Release-Planung)., Basierend auf dem in der vorherigen Iteration geleisteten Arbeitsaufwand meldet sich das Team für das an, was in der aktuellen Iteration durchgeführt wird.
Diese Planungsschritte sind sehr einfach, aber sie liefern sehr gute Informationen und eine hervorragende Lenksteuerung in den Händen des Kunden. Alle paar Wochen ist der Fortschritt vollständig sichtbar. Es gibt keine „neunzig Prozent getan“ in XP: ein Feature Geschichte abgeschlossen wurde, oder es war nicht., Diese Fokussierung auf Sichtbarkeit führt zu einem schönen kleinen Paradoxon: Einerseits ist der Kunde bei so viel Sichtbarkeit in der Lage, das Projekt abzubrechen, wenn der Fortschritt nicht ausreicht. Auf der anderen Seite ist der Fortschritt so sichtbar und die Fähigkeit zu entscheiden, was als nächstes getan wird, ist so vollständig, dass XP-Projekte tendenziell mehr von dem liefern, was benötigt wird, mit weniger Druck und Stress.
Kundentests
Im Rahmen der Präsentation jeder gewünschten Funktion definiert der XP-Kunde einen oder mehrere automatisierte Abnahmetests, um zu zeigen, dass die Funktion funktioniert., Das Team erstellt diese Tests und verwendet sie, um sich selbst und dem Kunden zu beweisen, dass die Funktion korrekt implementiert ist. Automatisierung ist wichtig, weil in der Presse der Zeit, manuelle Tests übersprungen werden. Das ist wie das Ausschalten des Lichts, wenn die Nacht am dunkelsten wird.
Die besten XP-Teams behandeln ihre Kundentests auf die gleiche Weise wie Programmierertests: Sobald der Test ausgeführt wird, führt das Team ihn danach korrekt aus. Dies bedeutet, dass sich das System nur verbessert, immer nach vorne kerbt, niemals zurückrutscht.,
Kleine Releases
XP-Teams üben kleine Releases auf zwei wichtige Arten:
Zuerst veröffentlicht das Team laufende, getestete Software und liefert den vom Kunden gewählten Geschäftswert, jede Iteration. Der Kunde kann diese Software für jeden Zweck verwenden, sei es für die Bewertung oder sogar für die Freigabe an Endbenutzer (sehr zu empfehlen). Der wichtigste Aspekt ist, dass die Software am Ende jeder Iteration sichtbar ist und dem Kunden gegeben wird. Dies hält alles offen und greifbar.
Zweitens veröffentlichen XP-Teams häufig auch ihre Endbenutzer., XP-Webprojekte werden so oft wie täglich, Inhouse-Projekte monatlich oder häufiger veröffentlicht. Sogar schrumpfverpackte Produkte werden so oft wie möglich versendet.
Es mag unmöglich erscheinen, so oft gute Versionen zu erstellen, aber XP-Teams auf der ganzen Welt tun es die ganze Zeit. Weitere Informationen dazu finden Sie unter Continuous Integration und beachten Sie, dass diese häufigen Releases durch XP ‚ s Testbesessenheit zuverlässig gehalten werden, wie hier in Kundentests und testgetriebener Entwicklung beschrieben.
Einfaches Design
XP Teams bauen Software zu einem einfachen, aber immer adäquaten Design., Sie beginnen einfach und durch Programmierertests und Designverbesserungen halten sie es so. Ein XP-Team hält das Design exakt passend für die aktuelle Funktionalität des Systems. Es gibt keine verschwendete Bewegung, und die Software ist immer bereit für das, was als nächstes kommt.
Design in XP ist keine einmalige Sache, oder eine Up-Front-Sache, es ist eine All-the-time-Sache. Es gibt Entwurfsschritte in der Release-Planung und Iterationsplanung, und Teams nehmen im Laufe des gesamten Projekts an schnellen Designsitzungen und Designrevisionen durch Refactoring teil., In einem inkrementellen, iterativen Prozess wie extremer Programmierung ist gutes Design unerlässlich. Deshalb liegt der Fokus während der gesamten Entwicklung so sehr auf Design.
Paar Programmierung
Alle produktion software in XP ist gebaut durch zwei programmierer, sitzen seite durch seite, an der gleichen maschine. Diese Praxis stellt sicher, dass der gesamte Produktionscode von mindestens einem anderen Programmierer überprüft wird, und führt zu einem besseren Design, besseren Tests und besserem Code.
Es mag ineffizient erscheinen, zwei Programmierer zu haben, die „die Arbeit eines Programmierers“ erledigen,aber das Gegenteil ist der Fall., Untersuchungen zur Paarprogrammierung zeigen, dass das Pairing etwa zur gleichen Zeit wie Programmierer, die einzeln arbeiten, besseren Code erzeugt. Das ist richtig: zwei Köpfe sind wirklich besser als einer!
Einige Programmierer lehnen es ab, die Programmierung zu koppeln, ohne es jemals zu versuchen. Es braucht etwas Übung, um es gut zu machen, und Sie müssen es einige Wochen lang gut machen, um die Ergebnisse zu sehen. Neunzig Prozent der Programmierer, die Paarprogrammierung lernen, bevorzugen es, daher empfehlen wir es allen Teams.
Die Paarung dient nicht nur dazu, besseren Code und bessere Tests bereitzustellen, sondern auch dazu, Wissen im gesamten Team zu kommunizieren., Wenn Paare wechseln, erhält jeder die Vorteile des Fachwissens eines jeden. Programmierer lernen, ihre Fähigkeiten verbessern sich, sie werden wertvoller für das Team und das Unternehmen. Paarung, auch auf eigene Faust außerhalb von XP, ist ein großer Gewinn für alle.
Test-Driven Development
Extreme Programming ist besessen von feedback-und software-Entwicklung, gute feedback, das erfordert eine gute Prüfung. Top XP-Teams üben „testgetriebene Entwicklung“, arbeiten in sehr kurzen Zyklen des Hinzufügens eines Tests und lassen ihn dann funktionieren., Fast mühelos produzieren Teams Code mit fast 100 Prozent Testabdeckung, was in den meisten Geschäften ein großer Schritt nach vorne ist. (Wenn Ihre Programmierer bereits noch anspruchsvollere Tests durchführen, mehr Leistung für Sie. Keep it up, es kann nur helfen!)
Es reicht nicht, Tests zu schreiben: Sie müssen sie ausführen. Auch hier ist extreme Programmierung extrem. Diese “ Programmierertests „oder“ Komponententests “ werden alle zusammen gesammelt, und jedes Mal, wenn ein Programmierer Code für das Repository freigibt (und in der Regel zweimal täglich oder länger freigibt), muss jeder einzelne der Programmierertests korrekt ausgeführt werden., Hundertprozentig, die ganze Zeit! Dies bedeutet, dass Programmierer sofort Feedback darüber erhalten, wie es ihnen geht. Darüber hinaus bieten diese Tests unschätzbare Unterstützung, da das Software-Design verbessert wird.
Designverbesserung (Refactoring)
Extreme Programming konzentriert sich auf die Bereitstellung von Geschäftswert in jeder Iteration. Um dies im Laufe des gesamten Projekts zu erreichen, muss die Software gut gestaltet sein. Die Alternative wäre, langsamer zu werden und letztendlich stecken zu bleiben., XP verwendet also einen Prozess der kontinuierlichen Designverbesserung namens Refactoring aus dem Titel von Martin Fowlers Buch „Refactoring: Improving the Design of Existing Code“.
Der Refactoring-Prozess konzentriert sich auf die Beseitigung von Duplikaten (ein sicheres Zeichen für schlechtes Design) und auf die Erhöhung des „Zusammenhalts“ des Codes bei gleichzeitiger Senkung der „Kopplung“. Hohe Kohäsion und niedrige Kopplung sind seit mindestens dreißig Jahren als Markenzeichen eines gut gestalteten Codes anerkannt. Das Ergebnis ist, dass XP-Teams mit einem guten, einfachen Design beginnen und immer ein gutes, einfaches Design für die Software haben., Dadurch können sie ihre Entwicklungsgeschwindigkeit aufrechterhalten und im Laufe des Projekts im Allgemeinen die Geschwindigkeit erhöhen.
Refactoring wird natürlich stark durch umfassende Tests unterstützt, um sicherzustellen, dass mit der Entwicklung des Designs nichts kaputt geht. Somit sind die Kundentests und Programmierertests ein kritischer Aktivierungsfaktor. Die XP-Praktiken unterstützen sich gegenseitig: Sie sind zusammen stärker als getrennt.
Kontinuierliche Integration
Extreme Programmierteams halten das System jederzeit vollständig integriert. Wir sagen, dass tägliche Builds für Weicheier sind: XP-Teams bauen mehrmals pro Tag., (Ein XP-Team von vierzig Personen baut mindestens acht oder zehn Mal pro Tag!)
Der Nutzen dieser Praxis lässt sich daran erkennen, dass Sie an Projekte zurückdenken, von denen Sie vielleicht gehört haben (oder von denen Sie sogar Teil waren), bei denen der Build-Prozess mehr oder weniger häufig stattfand und normalerweise zu „Integrationshölle“ führte, wo alles kaputt ging und niemand wusste warum.
Eine seltene Integration führt zu schwerwiegenden Problemen bei einem Softwareprojekt., Obwohl Integration für einen guten Arbeitscode von entscheidender Bedeutung ist, wird das Team zunächst nicht darin geübt und oft an Personen delegiert, die nicht mit dem gesamten System vertraut sind. Zweitens ist selten integrierter Code oft – ich würde normalerweise sagen-fehlerhafter Code. Zum Zeitpunkt der Integration treten Probleme auf, die von keinem der Tests auf einem nicht integrierten System erkannt werden. Drittens führt ein schwacher Integrationsprozess zu langen Code-Einfrierungen., Code-Freezes bedeuten, dass Sie lange Zeiträume haben, in denen die Programmierer an wichtigen shippbaren Funktionen arbeiten könnten, diese Funktionen jedoch zurückgehalten werden müssen. Dies schwächt Ihre Position auf dem Markt oder bei Ihren Endbenutzern.
Collective Code Ownership
Bei einem extremen Programmierprojekt kann jedes Programmiererpaar jeden Code jederzeit verbessern. Dies bedeutet, dass der gesamte Code die Aufmerksamkeit vieler Menschen auf sich zieht, was die Codequalität erhöht und Fehler reduziert., Es gibt noch einen weiteren wichtigen Vorteil: Wenn Code im Besitz von Einzelpersonen ist, werden erforderliche Funktionen häufig an die falsche Stelle gesetzt, da ein Programmierer feststellt, dass er irgendwo im Code ein Feature benötigt, das er nicht besitzt. Der Besitzer ist zu beschäftigt, um dies zu tun, daher fügt der Programmierer die Funktion in seinen eigenen Code ein, wo sie nicht hingehört. Dies führt zu hässlichem, schwer zu wartendem Code, voller Duplikation und mit geringem (schlechtem) Zusammenhalt.
Kollektives Eigentum könnte ein Problem sein, wenn Menschen blind an Code arbeiten, den sie nicht verstanden haben., XP vermeidet diese Probleme durch zwei Schlüsseltechniken: Die Programmierertests fangen Fehler ein, und Paarprogrammierung bedeutet, dass der beste Weg, an unbekanntem Code zu arbeiten, darin besteht, sich mit dem Experten zu paaren. Neben der Sicherstellung guter Modifikationen bei Bedarf verbreitet diese Praxis Wissen im gesamten Team.
Codierungsstandard
XP – Teams folgen einem gemeinsamen Codierungsstandard, so dass der gesamte Code im System so aussieht, als ob er von einer einzigen – sehr kompetenten-Person geschrieben wurde., Die Besonderheiten des Standards sind nicht wichtig: Wichtig ist, dass der gesamte Kodex zur Unterstützung des kollektiven Eigentums vertraut aussieht.
Metapher
Extreme Programmierteams entwickeln eine gemeinsame Vision der Funktionsweise des Programms, die wir als „Metapher“bezeichnen. Im besten Fall ist die Metapher eine einfache evokative Beschreibung der Funktionsweise des Programms, z. B. „Dieses Programm funktioniert wie ein Bienenstock, geht nach Pollen und bringt es zurück in den Bienenstock“ als Beschreibung für ein agentenbasiertes Informationsabfragesystem.
Manchmal entsteht keine ausreichend poetische Metapher., In jedem Fall verwenden XP-Teams mit oder ohne lebendige Bilder ein gemeinsames System von Namen, um sicherzustellen, dass jeder versteht, wie das System funktioniert und wo Sie suchen müssen, um die gesuchte Funktionalität zu finden, oder um den richtigen Ort zu finden, um die Funktionalität, die Sie hinzufügen möchten, zu finden.
Nachhaltiges Tempo
Extreme Programmierteams sind langfristig dabei. Sie arbeiten hart und in einem Tempo, das auf unbestimmte Zeit aufrechterhalten werden kann. Dies bedeutet, dass sie Überstunden machen, wenn es effektiv ist, und dass sie normalerweise Woche für Woche so arbeiten, dass sie die Produktivität maximieren., Es ist heutzutage ziemlich gut verstanden, dass Death March-Projekte weder produktiv sind noch qualitativ hochwertige Software produzieren. XP-Teams sind drin, um zu gewinnen, nicht zu sterben.
Schlussfolgerung
Extreme Programming ist eine Disziplin der Softwareentwicklung, die auf Werten wie Einfachheit, Kommunikation, Feedback und Mut basiert. Es funktioniert, indem das gesamte Team in Gegenwart einfacher Praktiken zusammengebracht wird, mit genügend Feedback, damit das Team sehen kann, wo es sich befindet, und die Praktiken auf ihre einzigartige Situation abstimmt.