Welche Rolle spielt der Hauptentwickler in einem agilen Team?

In einem nicht agilen Entwicklungsteam hat ein leitender Entwickler im Allgemeinen folgende Aufgaben :

• Setzt den Standard (Kodierung und sonstiges)
• Erforscht neue Technologien für das Team
• Legt die technische Richtung für das Team fest
• Hat das letzte Wort in Sachen
• Entwirft die Architektur eines Systems

Ein agiles Team arbeitet jedoch anders:

• Ein agiles Team verlässt sich eher auf aufstrebendes Design als auf das Wesentliche
• Ein agiles Team entwirft gemeinsam, anstatt dass das Design von einer Person vorgegeben wird
• Ein agiles Team entscheidet selbst über die technische Ausrichtung, um ein Projekt am besten umzusetzen

Wo bleibt ein leitender Entwickler in einem agilen Team? Ist es möglich, einen leitenden Entwickler in einem agilen Team zu haben? Fordert ein agiles Team von einem Lead andere Verantwortlichkeiten?

Nichts in Agile ändert die Funktionsweise des Hauptentwicklers. Sie sollten den Rest des Teams in Entscheidungen zur Systemarchitektur und zur technischen Ausrichtung einbeziehen, unabhängig davon, welchem ​​Entwicklungsmodell gefolgt wird.

Das Verteilen von Entscheidungen per Erlass ist für jedes Entwicklerteam eine schreckliche Methode. Mit Agile wird das Eingehen von Buy-ins vom Rest des Teams nur noch expliziter, und ein leitender Entwickler hätte das sowieso tun sollen.

Nur weil es in einer Scrum-Methodik keine festgelegte Hauptentwicklerrolle gibt, bedeutet dies nicht, dass die Meinungen erfahrener Programmierer nicht am meisten respektiert werden. Agile lässt nicht zu, dass sich jeder auf sein eigenes Ding einlässt, und versucht dann, alles zusammenzubringen. Es gibt immer noch eine einheitliche Vision und Richtung, die festgelegt werden muss.

In einem agilen Team soll jeder sein Ego beiseite legen.

Wenn ein Mitglied eines agilen Teams mehr Erfahrung als die anderen hat, ist es wahrscheinlich, dass das erfahrene Mitglied an den meisten Codeüberprüfungen beteiligt ist und die Mitarbeiter bei Teamentscheidungen häufig auf die Erfahrung dieser Person zurückgreifen.

Ein "führender" Entwickler wird also weiterhin "führen", jedoch als natürliche Folge seiner Erfahrung und nicht als mandatierte Funktion seines Titels.

Das ist in einer idealen Welt, in der die Menschen ihr Ego beiseite legen können. Viel Glück!

Zusätzlich zu Ryathals Antwort :

Du sprichst von aufstrebendem Design und Teamleitung, als würden sie in perfekter Einheit und Harmonie aus dem Team fließen. Besonders Gruppen von Menschen, Gruppen von Programmierern haben Konflikte . Als Teamleiter ist Ihr Job in einem agilen Team eher ein Schiedsrichter oder Katalysator als ein Wasserfall. Wenn es im Team zu Konflikten bezüglich des zu verwendenden Designs kommt, stellen Sie sicher, dass die Leute das gleiche Mitspracherecht haben und streiten über die Verdienste. Und am Ende sind Sie der Schiedsrichter, zu welcher vorgeschlagenen Lösung das Team gehen wird, wenn der Weg nicht klar ist.

Dies ist eine der wichtigsten Aufgaben des Leaders, aber es sind noch viele andere Dinge erforderlich, um eine Gruppe von Leuten zu einem Team zu machen. Sie müssen immer noch ein Beispiel geben, wenn es um gute Codierung geht, und dies häufig durchsetzen (entweder direkt oder durch die Schaffung einer entsprechenden Kultur). Sie müssen die Kommunikation zwischen all Ihren Teammitgliedern vereinfachen, denn einmal am Tag im Standup wird dies nicht schaden.

Das andere wichtige, was Sie übersehen haben, sind Besprechungen. Es ist unpraktisch, das gesamte Team zu jeder Besprechung mitzunehmen, bei der das Team mit Geschäftsleuten, anderen technischen Teams usw. interagieren muss. Als Teamleiter sind Sie der Vertreter des Teams. Sie gehen zu den Besprechungen, damit sie an ihren Schreibtischen bleiben und Dinge erledigen können. Sie sind die Anlaufstelle, damit sie nicht von Personen unterbrochen werden, die direkt vorbeischauen. Und Sie arbeiten daran, Informationen von der Außenwelt zu übernehmen (woran andere Teams arbeiten, wie die agilen Teams beim nächsten Sprint aussehen, wie der Status dieser offenen Anforderung lautet usw.), sie für sie zu analysieren und zu kommunizieren.

Kurz gesagt, Sie sind der Schmierstoff, der dafür sorgt, dass sie reibungslos funktionieren.

Ihre nicht agile Beschreibung macht Ihre agile Beschreibung nicht ungültig.

Ein agiles Team verlässt sich eher auf aufstrebendes Design als auf das Wesentliche.

Nichts über Ihre Definition eines leitenden Entwicklers besagt, dass Design im Vordergrund stehen muss. Er kann die Richtung vorgeben und er kann immer noch einen ersten Entwurf entwerfen. Dieser Entwurf ist definitiv aufgetaucht.

Ein agiles Team entwirft gemeinsam, anstatt dass das Design von einer Person vorgegeben wird

Nichts über Ihre Definition eines leitenden Entwicklers sagt aus, dass er das Design diktiert . Obwohl er möglicherweise das letzte Wort hat, würde nur ein schlechter Vorsprung die Gedanken seiner Teamkollegen völlig außer Acht lassen. Auf der anderen Seite würde nur ein schlechtes Team die Gedanken des leitenden Entwicklers völlig außer Acht lassen.

Ein agiles Team entscheidet selbst über die technische Ausrichtung, um ein Projekt am besten umzusetzen

Auch hier bedeutet dies nicht , dass die Leitung nicht zunächst nicht festgelegt in diese Richtung. Die Führung ist Teil dieses agilen Teams. Selbst in einem nicht agilen Umfeld würde nur eine schlechte Führung ein Team weiter in diese Richtung führen, wenn dies wissentlich nicht möglich ist oder neue Informationen vorliegen, die diese Richtung ungültig machen.

Die Frage wirft ein paar andere Fragen auf. Was qualifiziert Sie Ihrer Meinung nach dazu, einem Team von anderen Softwareentwicklern mitzuteilen, was zu tun ist? Ist es deine Erfahrung? Ist es der lustige kleine Titel, den dir dein Chef gegeben hat? Ist es dein Ego? Ihre Amtszeit bei der Firma? Ist es Ihr "Schnickschnack?" Dein Stil?" Ihre "Führungsqualitäten?"

Agile Teams verteilen einander keine Abzeichen oder Hüte mit der Aufschrift "Herzlichen Glückwunsch, Sie sind unser Supergenie - Sie sind der einzige, der Supergeheimnis-Doppelgenie-Arbeit leisten darf." Der Schwerpunkt liegt vielmehr auf DER ARBEIT IN DER HAND. Wenn Sie in der Tat erfahrener sind, sollte diese Erfahrung zeigen, wie gut Ihre Entwürfe die Arbeit zum Abschluss bringen. Ihre selbst gewählten Aufgaben (Karten) sollten die Bereiche widerspiegeln, in denen Sie am besten ausgebildet sind. Andererseits hat ein Kind, das das College abgeschlossen hat, eine bessere Idee und passt besser zum Kontext als etwas, das ein 40-jähriger Veteran vorfindet mit, warum um alles in der Welt sollten wir mit dem ärmeren Design gehen? Unsere Arbeitsplätze sind keine Therapiebüros - sie sind der Ort, an dem wir großartige Dinge bauen.

Das wirft eine andere Frage auf: Wer darf entscheiden, was "besser" bedeutet? Die Antwort: das Stakeholder-Team. Das heißt, die Entwickler, Anforderer, Tester, Geschäftsleute usw., die die Erbauer und Benutzer der fraglichen Sache sind. Wenn Sie eine großartige Idee haben, können Sie besser demonstrieren, warum es besser ist. Wenn Sie das nicht können, besteht für das Team kein Grund zu der Annahme, dass Ihre Idee besser ist. Agile fördert die Meritokratie.

Also, was passiert mit der "Leitung des Entwicklungsteams"? in agil? Nichts - sie werden diesem Namen einfach besser gerecht - sie sind WIRKLICH besser in der Lage, bessere Software zu produzieren als die anderen Leute im Team. Ansonsten gibt es keinen Grund, sie "Blei" zu nennen - es ist nur ein kleines Abzeichen oder ein lustiger Hut, und es ist bedeutungslos. Viele Leute finden das bedrohlich. Sie haben das Gefühl, für ein Abzeichen oder einen lustigen Hut "gearbeitet" zu haben. Gute Entwickler arbeiten nicht für witzige Hüte. Sie arbeiten daran, großartige Software zu entwickeln, und sie planen, dies zu tun, bis sie krächzen - ihr Ziel ist es, jeden Tag besser Software zu entwickeln. Wenn Sie es nicht sind, möchten Sie sich vielleicht mit Projektmanagement befassen. Du wirst wahrscheinlich glücklicher sein.

Nach meiner Erfahrung mit Agile wird dem Entwicklungsteam insgesamt weniger Verantwortung übertragen, als es Ihre Beispiele implizieren. Der leitende Entwickler und Architekt muss die Entscheidungen für das Design auf höchster Ebene koordinieren, das Design auf niedrigerer Ebene jedoch an das gesamte agile Team weitergeben.

Daher bleibt der Hauptentwickler für die Systemarchitektur und die Auswahl der Technologie verantwortlich. Dies ist sehr wichtig: Auch wenn Agile aufstrebendes Design und Refactoring fördert, sollte dies auf der Ebene der Codeobjekte geschehen. Das System als Ganzes muss ein höheres Maß an Vorkonstruktion und Steifigkeit aufweisen, da das Projekt sonst zu einem unkoordinierten Durcheinander werden kann.

In unserem Projekt beauftragte der leitende Entwickler die Technologieauswahl und entwarf, wie Systemkomponenten miteinander interagieren würden. In agilen Planungsmeetings ging es darum, wie diese Komponenten im Rahmen seiner übergeordneten Mandate gestaltet werden können. Angenehm ist, dass auf diese Weise ansonsten lästige Planungstermine begrenzt bleiben.

Er fungierte auch als letzter Ausweg. Wenn einzelne Programmierer auf Probleme stießen, die sie nicht beheben konnten, gingen sie an die Spitze, und die endgültige Verantwortung für die Behebung der Probleme lag bei ihm.