Ist Extreme Programming nur für Erfahrene? [geschlossen]

Ein Aspekt der extremen Programmierung, der helfen kann, ist die Paarprogrammierung. Wenn Sie schwache Programmierer mit starken Programmierern paaren, sollten die schwachen Programmierer in der Lage sein, sehr viel mehr Erfahrung zu sammeln und die richtige Art und Weise zu lernen, Dinge viel schneller zu machen. Ein unerfahrener Programmierer, der allein zum Programmieren gegangen ist, kann sehr schlecht sein. Ein unerfahrener Programmierer, der diszipliniert sein muss, Komponententests erstellen, Programme paaren und einer String-Entwicklungsmethodik folgen muss, kann viel effektiver sein.

Ich würde in etwas Training für das Team mit einem geplanten "tune up" investieren, nachdem sie eine Weile gelaufen sind, um sie auf Kurs zu halten. Agile Entwicklung und insbesondere XP erfordern Disziplin, damit es richtig funktioniert. Es hat keinen Sinn, schlechte Gewohnheiten zu lernen, die dich heimsuchen werden. Schau dir das Training an, das von Industrial Logic zur Verfügung steht. Ich habe mit diesen Leuten auf Branchenveranstaltungen gesprochen und sie scheinen wirklich ihre Sachen zu kennen. Ich versuche einen Weg zu finden, unternehmensweit die Möglichkeit zu schaffen, ihre Trainingsmaterialien lokal zu verwenden.

BEARBEITEN : Ich bin nicht allzu nervös wegen der 3-jährigen Erfahrung. Ich würde mich mehr darum sorgen, dass sie eine neue Methode lernen. Die Techniken sind nicht besonders schwierig, aber um sie richtig zu machen, braucht es Übung. Ohne erfahrene Person im Team und wenig Erfahrung mit Agile wäre die Zeit und das Geld, das Sie für die Beratung durch Experten benötigen, Ihre Mühe wert.

EDIT 2 : Soweit Entwickler mit Kunden sprechen. Ich stimme einigen anderen hier darin zu, dass ich glaube, dass Sie eine "gehen zu" Person brauchen, die der Kunde als die Person identifizieren kann, mit der zu sprechen, außer Ihr Kunde ist ein Teil des Teams. Diese Person könnte ein Teamleiter oder ein tatsächlicher Projektmanager sein. Ich denke, Entwickler müssen in direkte Gespräche mit dem Kunden einbezogen werden. Den Kunden im Team zu haben, ist der beste Weg, dies zu tun. Wenn dies nicht möglich ist, sollten Sie sie in Besprechungen usw. einbeziehen.

Viele Leute denken "extreme Programmierung" bedeutet wilder Westen, keine Regeln. XP ist nicht undiszipliniert, es ist nur eine andere Form der Disziplin als Wasserfall usw. Ein Teil von XP schreibt viele Tests. Wie kann es für einen unerfahrenen Programmierer schlecht sein, viele Tests zu schreiben? Ein anderer Teil von XP ist die Paarprogrammierung. Was könnte für einen unerfahrenen Programmierer besser sein als ein Programm mit jemand anderem zu paaren? (Aber einige Leute im Team müssen erfahren sein.)

Ich sehe XP als extrem disziplinierten Ansatz. Es gibt jedoch kein Wunder, wenn man ein unerfahrenes Team in ein hochproduktives Team verwandelt. Drei Jahre Erfahrung sagen nichts über ihre Fähigkeiten aus. Wenn sie für diese Zeit mikromanaged sind, werden sie wahrscheinlich nicht ohne Hilfe von außen erfolgreich sein.

Starten eines XP-Projekts - wie fast jedes agile Projekt, sorry, genau wie jedes Software-Projekt - wird mit einem Coach zur Verfügung stehen, der sich um den Prozess kümmert.

Sei aber vorsichtig mit den Namensproben. Manchmal ist XP eine Entschuldigung für Cowboy-Codierung ohne Dokumentation (wir machen keine Dokumente, dafür wir XP). Ziele nicht auf XP, sondern auf ein produktives und effizientes, wertschöpfendes Projekt.

Im Ernst, ich verachte den Begriff "Extreme Programming". Es ist asinin. Agil ist gut, die Implikationen sind ausgereift und der Prozess funktioniert. Ich schwöre, Extreme Programming (Grunt?) Wurde vorgeschlagen, um die Software-Entwickler-Community einfach aufzurütteln. Agile Entwicklung und die Scrum-Methode wären mein Vorschlag.

Ich denke, Sie brauchen wahrscheinlich nur ein Buch über Scrum (versuchen Sie "Agiles Projektmanagement mit Scrum") und das wird ein guter Weg sein. Genauer gesagt, nein, die Entwickler sprechen nicht besonders mit Stakeholdern; So liegt der Wahnsinn. Aber es gibt in Scrum einen Stakeholder-Vertreter, der die Kommunikation mit dem Stakeholder und den Servern als Informationswächter auf beide Arten vermittelt. Es ist ziemlich gut in dem Buch ausgelegt.

So habe ich C ++ gelernt - mit meiner einzigen vorherigen Erfahrung BASIC auf einem alten Tandy.

Ich denke, es ist ein großartiges Werkzeug für Anfänger - sowohl für eine Sprache als auch für die Programmierung.

Eine spezifische Methodik wird das Schicksal des Projekts nicht bestimmen, es wird es nur verstärken.

Extrem oder nicht (Ich stimme mit anderen überein, dass extreme Programmierung in Ihrem Fall funktionieren sollte), aber Entwickler sollten nicht mit Stakeholdern alleine sprechen.

Der Fluss von Anforderungen und Entwicklermeinungen sollte kontrolliert werden. Es sollte einen Vertreter geben, so dass der Interessenvertreter nicht fragen muss, "Wen sollte ich fragen, wenn ich das wissen will?", Und die Entwickler werden ihre Zeit nicht damit verschwenden, Dinge zu tun, die nicht richtig diskutiert werden eine Person mit etwas Vision darüber, was gerade gemacht wird und was Schlüsselmerkmale oder Probleme sind.

EDIT: Entwickler sollten sich der Diskussionen zwischen Stakeholdern und Teammitgliedern bewusst sein, damit sie reagieren oder reagieren können, wenn der Kunde eine Frage stellt oder ein ungewöhnliches / schwer zu implementierendes Feature vorschlägt.

Was weniger erfahrene Entwickler brauchen, sind im Grunde:

• viele Hinweise, was zu tun ist, und
• viel Feedback darüber, wie gut sie es machen

Nach meiner Erfahrung (in einem Projekt mit Entwicklern, die direkt von der Universität kommen), mit engen Rückkopplungsschleifen und den sehr spezifischen Entwicklungspraktiken, ist XP einfach perfekt für weniger erfahrene Entwickler. Sie werden immer noch viel Coaching und Mentoring benötigen, aber das wäre in jedem Fall wahr.

Es ist gut, dass die Entwickler direkt mit Stakeholdern sprechen, denn das wird ihnen helfen zu verstehen, was das System eigentlich tun muss und warum. Auch der direkte Kontakt kann sehr motivierend wirken.

Sie müssen darauf achten, dass diese Interessengruppen die Entscheidungen des Kunden nicht außer Kraft setzen (eine Rolle in XP), die das letzte Wort darüber hat, was wann entwickelt wird und über die Annahme entscheidet Kriterien (wahrscheinlich in Zusammenarbeit mit den anderen Beteiligten und dem Rest des Teams). Aber das gilt auch für erfahrene Teams.

Meine Erfahrung mit agilen Prozessen ist, dass es besser funktioniert, wenn kleinere Teams an kleineren Projekten arbeiten. Große Teams und große Projekte haben Schwierigkeiten, die für Agile erforderliche Menge und Qualität der Kommunikation zu erreichen.

Die wirkliche Frage ist also nicht so sehr, wie alt Ihre Programmierer sind, sondern wie viele Sie haben (und wie viele Sie denken, dass Sie brauchen).

Wenn Sie so viele Interessengruppen und so viele Entwickler haben, dass Sie über einen einzigen Ansprechpartner nachdenken, ist Ihr Projekt möglicherweise zu groß.

Da XP hauptsächlich aus technischen Praktiken besteht, ist es schwieriger zu lernen als die Praktiken des agilen Managements (SCRUM). Ein Team, das nur SCRUM verwendet, wird sich wahrscheinlich in Schwierigkeiten begeben. Die Entwicklung wird mit jeder neuen Iteration immer schwieriger. Ein Team, das sowohl SCRUM als auch XP verwendet, ist viel eher in der Lage, Erfolg zu haben.

Insbesondere XP, Test Driven Development (TDD) kann eine Herausforderung für ein Team darstellen, das mit XP nicht vertraut ist. Für ein XP-Team ist es am besten, einen technischen Coach einzubinden. Darüber hinaus hilft das Pairing den Entwicklern, die Entwicklungspraktiken schneller zu erlernen.

Wenn Sie Agile machen, verwenden Sie sowohl SCRUM als auch XP. Die Lernkurve ist höher für XP, aber der langfristige Erfolg wird sich auszahlen.

Sobald Sie ein gut funktionierendes Agile-Team haben, können Sie dem Team neue Entwickler hinzufügen. Durch das Drehen der Paare im Team kommen die neuen Mitglieder sehr schnell auf Touren. Ab diesem Zeitpunkt werden auch Junior-Entwickler schnell wirksam.