Extreme Ideen fürs Projektmanagement?

Januar 22nd, 2006 by eric kubitz | Posted in Projekte |

Was können wir Projektmanager vom "Extreme Programming" lernen? Ich glaube eine ganze Menge - denn "XP" ist eine moderne und erfolgsorientierte Methode, deren Regeln gerde durch ihre Klarheit auch in andere Bereiche übertragbar sind.

Doch ein Schritt nach dem anderen. Im folgenden Artikel stelle ich die mir wichtig erscheinenden Werte, Methoden und Regeln von XP vor. Erfahrene Software-Entwickler werden die Aufzählung unvollständig und an manchen Stellen auch etwas frei interpretiert finden. Das mag daran liegen, dass ich hier keinen Kurs in "Extreme Programming" mache, sondern schauen will, wie viel XP auch für Nicht-Software-Projekte gut ist. Los geht’s:

Die höchsten Werte in XP sind:

• Kommunikation: Da das Scheitern der meisten Projekte vermutlich auf zwischenmenschlichen Problemen beruht, ist im Extreme Programming die Kommunikation extrem Wichtig. Sei es bei den täglichen Meetings, beim Pärchen-Programmieren und beim Kunden vor Ort (siehe unten).
• Einfachheit: Wenn es zwei Möglichkeiten gibt, ein Problem zu lösen, wird immer die einfacherere Möglichkeit vorgezogen - auch wenn sie vielleicht nicht alle möglichen zukünftigen Entwicklungen verweg nimmt. Es wird immer genau das implementiert, was heute gebraucht wird; denn morgen kann die Anforderung schon eine andere sein.
• Feedback: Die Entwickler und Kunden erhalten gegenseitig z.B. bei den Akzeptantztests Feedback. Das ist vertrauensfördernd und verstärkt die Kommunikation.
• Mut: Ja, genau. Mit Mut soll jedes Projektmitglied erkannte Probleme angehen. Auch wenn es schwer fällt, andere auf Fehler hinzuweisen oder eigene Fehler öffentlich zu machen. Mut wird übrigens auch dann benötigt, wenn überflüssiger Code entfernt werden muss.
• Lernen, Respekt und Qualität: Auch diese Werte werden bei XP immer wieder genannt. Warum diese Werte wichtig sind (nicht nur beim Programmieren), kann hoffentlich jeder meiner Leser selber sagen…

Daneben gibt es eine Vielzahl von Prizipien und Regeln. Ich habe die ausgesucht, die meiner Meinung nach für das "normale" Projektmanagement von Wert sind. 

• Inkrementelle Vorgehensweise: Große Änderungen bergen (zu) große Risiken. Deshalb werden beim Extreme Programming die Dinge kontinuierlich in kleinen Schritten verändert.
• Änderungen sind positiv: Grunsätzlich sind Änderungen gut. Und es muss gute Gründe geben, bei einem Änderungswunsch (des Kunden bzw. eines Kollegen) am Bisherigen festzuhalten.
• Qualitätsarbeit: Das ist die Voraussetzung für gute Ergebnisse und - nicht zu vergessen - für eine hohe Identifikation im Team.
• Lernen lehren: Von doktrinären Aussagen und Vorgaben wird grundsätzlich abgesehen. Lernen und "besser werden" stehen im Zentrum und nicht das Wissen um eine denkbare Perfektion.
• Experimentieren, spielen: "Dienst nach Vorschrift" ist der Tod des Projektes und etwas Risikobereitschaft beim Experimentieren ist entscheidend für den Projekterfolg.
• Verantwortung übernehmen: Verantwortung wird nicht beim anderen abgelegt sondern akzeptiert. Natürlich darf auch bei XP nicht jeder machen was er will. Aber es ist unmöglich, gegen das innere Gefühl der Team-Mitglieder zu arbeiten.
• Reisen mit leichtem Gepäck: Alle überflüssigen Projektvorgaben werden vermieden.
• Ehrliches Messen: Nur bei ehrlichen Schätzungen und dem offenen Kommunizieren von Ergebnissen und dem Fortschritt lässt sich das Projekt erfolgreich abschließen.
• Einfaches Design: Da man davon ausgeht, dass sich Kundenanforderungen ändern werden, wird nicht nach dem besten und langlebigsten Design gesucht, sondern nach dem einfachsten. Das Design muss alle Anforderungen erfüllen und alle Tests bestehen. Mehr aber nicht.
• Refactoring: Wenn festgestellt wurde, dass das Design kompliziert geworden ist, wird das geändert. Beim Refactoring werden keine neuen Features programmiert sondern ausschließlich vereinfacht. Und zwar von ständigen Tests begleitet.
• Programmieren in Paaren: Vermutlich die bekannteste Regel im Extreme Programming. Zwei Programmierer arbeiten mit einer Tastatur und einer Maus an einem Rechner. Der eine ist der Fahrer, der andere der Beifahrer. Wie das funktionieren kann, sollten Entwickler woanders nachlesen.
• Kunde vor Ort: Der Kunde ist jederzeit leicht zu erreichen und ansprechbar. Er soll Fragen beantworten und Prioritäten setzen. Dazu verfügt er über realtives Fachwissen und ist entscheidungsbevollmächtigt.
• Gemeinsame Codeverantwortung: Es gibt keinen Codeteil für den nur eine Person verantwortlich ist. Wird Code integriert und besteht er die Tests ist er fortan "Allgemeingut".
• Programmierstandards: Namenskonventionen, Formatierungsvorgaben und weitere Standards werden exakt befolgt.
• Kontinuierliche Integration: Die Code-Teile werden nicht am Ende eines längeren Prozesses sondern alle paar Stunden integriert (und getestet). Dabei dürfen nicht zwei Programmierer(-pärchen) gleichzeitig integrieren.
• (Fast) keine Dokumentation: Neben einer ordentlichen Inline-Dokumentation im Code gibt es keine "externe" Dokumentation. Diese wäre bei den vielen Änderungen schwer zu aktualisieren und würde ohnehin zu viel Zeit kosten.
• Testen, Testen, Testen: Das Testen des Codes und der Ergebnisse hat im Extreme Programming höchste (!) Priorität. Und zwar bei der Erstellung der Funktionalität mit automatisierten Tests (bitte an anderen Orten genauer nachlesen) aber auch der Akzeptanztest mit dem Kunden.
• Tägliches Stand-Up-Meeting: 5 Minuten, jeder berichtet, was er gestern getan hat und auf welche Probleme er gestoßen ist. Probleme werden angesprochen aber nicht gelöst.
• Metaphern: Mittels eines Bildes werden komplizierte Sachverhalte vereinfacht beschrieben. Wichtig ist eine gemeinsame Sprache. Auch das Endprodukt (Projektziel) wird in einer für alle einheitlichen Metapher beschrieben. Idealerweise kann außerdem jeder Programmteil mit einer Metapher beschrieben werden.
• Überstunden sind Planungsfehler: Eine hohe Beanspruchung im Entwicklungsprozess wirkt sich auf die Leistungsfähigkeit aus und sollte vermieden werden.

Und im nächsten Artikel schauen wir mal, was wir davon für unser Projektmanagement brauchen können.