Keine Sorge, wir tauchen hier nicht in die Vergangenheit von Microsofts Betriebssystemen ab. Und auch die Erfahrungspunkte für Rollenspieler sind hier eher nicht so relevant. Christus ist uns für heute auch eher fern, und wer an ein Rohprotein denken muss, hat sich ohnehin hierher verirrt. Vielleicht. Vielleicht auch nicht. Also: In unserem Kontext steht XP für Extreme Programming.

Wenn Mensch ein Konzept umsetzen möchte, hier die agile Softwareentwicklung, helfen ihr dabei oft Prinzipien und Praktiken, derer man sich bedienen kann und die idealerweise von klugen Köpfen kommen. Eine der Kernmethoden ist dabei das Extreme Programming. Sie stammt aus dem Jahr 1996, also einer Zeit, in der gerade Scrum (ein Framework) entstand, und bildet heute eine der Grundlagen agilen Arbeitens.

XP betont Teamwork, Kundinnenzufriedenheit und zeitnahe Lieferung(en). Kommt euch bekannt vor? Genau. Im Grunde sammelt sich das Team um ein Problem und geht die Lösung mit Kommunikation, Feedback, Einfachheit, Respekt und Selbstvertrauen an, die zentralen Werte von XP.

Das Team kommuniziert mit den Kundinnen direkt sowie natürlich untereinander. Anschließend arbeitet es das Feedback direkt in die Entwicklung ein. Idealerweise ab dem ersten Tag, was sich zum Beispiel darin äußern kann, dass mit den Kundinnen zusammen eine Klärung der unmittelbar anstehenden Aufgaben durchgeführt wird. Und dann im Folgenden dadurch, dass Teillösungen schnell geliefert und mit erneutem Feedback der Kundinnen versehen weiterentwickelt werden.

Das Design der Lösung ist dabei einfach und sauber, aber nicht zwingend effizient. Die Einfachheit und Verständlichkeit steht hier deshalb im Fokus, um Software so zu schreiben, dass auch andere Entwicklerinnen sich schnell einarbeiten und Änderungen herbeiführen können, wenn es sein muss. Effizienz im Code kostet nicht nur Zeit in der Entwicklung, sondern auch bei Änderungen, die früher oder später fast zwangsweise auftreten. Effektivität ist deutlich entscheidender, welche durch die Kommunikation mit den Kundinnen sichergestellt wird.

Der Respekt vor der Arbeit der Teamkolleginnen stellt sich durch die schnellen, kleinen Erfolge fast automatisch ein. Er führt auch dazu, dass ein Klima herrscht, in dem auch innerhalb des Teams offen und fachorientiert Feedback gegeben werden kann. So entwickelt das Team im Laufe der Zeit das notwendige Selbstbewusstsein und den notwendigen Mut, mit sich verändernden Anforderungen und Technologien umzugehen.

Um es noch ein wenig einfacher zu machen, gibt es ein paar Regeln, auf die ich hier punktuell eingehen möchte. Ich empfehle euch, ruhig mal alle auf der XP-Website durchzugehen.

So ist zum Beispiel im Bereich der Planung der Einsatz von User Storys anstelle von Anforderungen vorgesehen, die von den Kundinnen geschrieben werden und beschreiben, was das System für sie tun soll. Veröffentlichungen der Software werden in kurzen Zyklen geplant, die als Iterationen bezeichnet werden.

Für die Teams ist unter anderem ein offener Arbeitsbereich vorgesehen, in dem sich alle so zusammensetzen (oder -stellen) können, wie es gerade notwendig ist. Auch für die Messung der Geschwindigkeit finden sich Regeln.

Das Design ist bestimmt von Einfachheit. Es wird nur das umgesetzt, was gebraucht wird, und nichts, was irgendwann mal gebraucht werden könnte. Der Code wird stetig überarbeitet, wann immer es passt und möglich ist.

Während der Entwicklung ist die Kundin jederzeit für Rückfragen verfügbar. Auch für Code-Standards und konsequentes Programmieren zu zweit finden sich Regeln. Das Testen spielt eine besondere Rolle, und XP schreibt hier zwingend Tests für jegliche Code-Einheit vor. Auch Akzeptanztests finden sich in den Regeln.

Insgesamt lässt sich zusammenfassen, dass XP schon Mitte der 90er sehr viel von dem enthielt, was sich heute in zeitgemäßer Softwareentwicklung wiederfindet. Mehr noch: In den meisten Methoden und Frameworks finden sich die Regeln und Werte von XP wieder. Manche nehmen sogar explizit Bezug darauf.

Wie schaut’s aus? Finden sich bei euch in den Teams Dinge aus XP wieder? Unabhängig davon, ob ihr in der Softwareentwicklung arbeitet, oder in einem anderen Bereich? Empfindet ihr sie als nützlich, oder eher als hinderlich? Schreibt’s in die Kommentare! 😉

[waglerit-newsletter-block]