it-swarm.com.de

Welche Rolle spielt der Hauptentwickler in einem agilen Team?

In einem nicht agilen Entwicklungsteam ein Hauptentwickler allgemein:

  • Setzt den Standard (Codierung 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 wird sich eher auf aufstrebendes Design als auf das von vornherein verlassen
  • Ein agiles Team entwirft gemeinsam, anstatt dass das Design von einer Person diktiert wird
  • Ein agiles Team entscheidet über seine eigene technische Richtung, die am besten für die Durchführung eines Projekts geeignet ist

Wo bleibt ein führender 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?

42
Peter Bridger

Nichts an Agilität ändert die Funktionsweise des Hauptentwicklers. Sie sollten den Rest des Teams in Entscheidungen zur Systemarchitektur und in die technische Ausrichtung einbeziehen, unabhängig davon, welches Entwicklungsmodell verfolgt wird.

Das Verteilen von Entscheidungen per Edikt ist für jedes Entwicklungsteam eine schreckliche Möglichkeit. Agile macht es einfach expliziter, sich vom Rest des Teams einzukaufen, und ein leitender Entwickler hätte das sowieso tun sollen.

Nur weil es in einer Scrum-Methodik keine festgelegte Rolle als Hauptentwickler gibt, bedeutet dies nicht, dass die Meinungen erfahrener Programmierer nicht am meisten respektiert werden. Agile lässt nicht jeden auf sein eigenes Ding los und versucht dann, alles zusammenzuhalten. Es gibt immer noch eine einheitliche Vision und Richtung, die festgelegt werden muss.

47
Ryathal

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 vorgeschriebene Funktion seines Titels.

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

31
MetaFight

Zusätzlich zu Ryathals Antwort :

Sie sprechen über aufstrebendes Design und Teamführung, als ob sie in perfekter Übereinstimmung und Harmonie aus dem Team fließen. Gruppen von Menschen, insbesondere Gruppen von Programmierern, haben Konflikte . Als Teamleiter ist Ihr Job in einem agilen Team eher ein Schiedsrichter oder Katalysator als ein Wasserfall. Wenn das Team beispielsweise Konflikte darüber hat, welches Design verwendet werden soll, stellen Sie sicher, dass die Mitarbeiter das gleiche Mitspracherecht haben, und streiten Sie sich weiterhin über die Verdienste. Und am Ende sind Sie der Schiedsrichter für die vorgeschlagene Lösung, mit der das Team zusammenarbeiten wird, wenn der Weg nicht klar ist.

Dies ist eine der wichtigsten Aufgaben des Leads, aber es sind noch viele andere Dinge erforderlich, um eine Gruppe von Menschen zu einem Team zu machen. Sie müssen immer noch ein Beispiel geben, was eine gute Codierung betrifft, und dies häufig durchsetzen (entweder direkt oder durch Erstellen einer Kultur, um dies zu tun). Sie müssen die Kommunikation zwischen all Ihren Teammitgliedern erleichtern, da ein einmaliger Standup-Vorgang nicht zu einer Unterbrechung führt.

Das andere wichtige, was Sie übersehen haben, sind Besprechungen. Es ist unpraktisch, das gesamte Team zu jedem Meeting zu bringen, bei dem 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 der Ansprechpartner, damit sie nicht von Personen unterbrochen werden, die direkt vorbeischauen. Und Sie arbeiten daran, Informationen aus der Außenwelt zu übernehmen (woran andere Teams arbeiten, wie die agilen Teams beim nächsten Sprint aussehen, wie der Status dieser offenen Anforderung ist usw.), sie für sie zusammenzufassen und zu kommunizieren.

Kurz gesagt, Sie sind das Schmiermittel, um sicherzustellen, dass sie reibungslos funktionieren.

20
Telastyn

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

Ein agiles Team wird sich eher auf aufstrebendes Design als auf das von vornherein verlassen.

Nichts an Ihrer Definition eines Hauptentwicklers besagt, dass Design im Voraus festgelegt werden muss. Er kann die Richtung vorgeben, und er kann immer noch einen ersten Entwurf entwerfen. Dieses Design ist definitiv aufstrebend.

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

Nichts über Ihre Definition eines Hauptentwicklers sagt aus, dass er diktiert Design. Obwohl er darf das letzte Wort hat, würde nur ein schlechter Vorsprung die Gedanken seiner Mehrheitskameraden völlig außer Acht lassen. Auf der anderen Seite würde nur ein armes Team die Gedanken des Hauptentwicklers völlig ignorieren.

Ein agiles Team entscheidet über seine eigene technische Richtung, die am besten für die Durchführung eines Projekts geeignet ist

Auch dies bedeutet nicht, dass der Lead anfangs nicht set diese Richtung hat. Die Führung ist Teil dieses agilen Teams. Selbst in einer nicht agilen Umgebung würde nur ein schlechter Vorsprung ein Team weiter in diese Richtung führen, wenn dies wissentlich nicht mehr möglich ist oder wenn neue Informationen vorgelegt wurden, um diese Richtung ungültig zu machen.

6
BrandonV

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

Agile Teams verteilen sich keine Abzeichen oder Hüte, auf denen steht: "Herzlichen Glückwunsch, Sie sind unser Supergenie - Sie sind der einzige, der supergeheime Doppelgenie-Arbeit leisten darf." Der Fokus liegt vielmehr auf DER ARBEIT AT HAND. Wenn Sie in der Tat erfahrener sind, sollte diese Erfahrung zeigen, wie gut Ihre Entwürfe die Arbeit vorantreiben. Ihre selbst gewählten Aufgaben ( Karten) sollten die Bereiche widerspiegeln, in denen Sie am besten ausgebildet sind. Auf der anderen Seite, wenn ein Kind direkt nach dem College eine bessere Idee hat und es besser zum Kontext passt als etwas, das sich ein 40-jähriger Veteran einfallen lässt, warum um alles in der Welt Wir gehen mit dem schlechteren Design? 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 kann 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 betreffenden Sache sind. Wenn Sie eine großartige Idee haben, können Sie besser demonstrieren, warum es besser ist. Wenn Sie das nicht können, gibt es keinen Grund für das Team zu glauben, dass Ihre Idee besser ist. Agile fördert die Meritokratie.

Was passiert also mit dem "Leiter des Entwicklungsteams"? in agil? Nichts - sie werden diesem Namen einfach besser gerecht - sie sind tatsächlich besser in der Lage, bessere Software zu produzieren als die anderen Leute im Team. Ansonsten gibt es keinen Grund, sie als "Blei" zu bezeichnen - 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 lustige Hüte. Sie arbeiten daran, großartige Software zu erstellen, und sie planen dies, bis sie krächzen - ihr Ziel ist es, jeden Tag besser Software zu erstellen. Wenn Sie es nicht sind, möchten Sie sich vielleicht mit dem Projektmanagement befassen. Du wirst wahrscheinlich glücklicher sein.

6
Calphool

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

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

In unserem Projekt gab der leitende Entwickler die Auswahl der Technologie vor und entwarf, wie Systemkomponenten miteinander interagieren würden. In agilen Planungsmeetings ging es darum, wie diese Komponenten im Rahmen seiner übergeordneten Mandate entworfen werden können. Abgesehen davon bleibt die Reichweite ansonsten lästiger Planungsbesprechungen begrenzt.

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.

3
Bob Tway