Zu viele Senioren in einem Team? [geschlossen]

Kann es sich als schlecht herausstellen, zu viele hochrangige Programmierer in einem Team zu haben?

Mit 4-5 erfahrenen Programmierern in einem Team von 6-7 Leuten. Was ist die optimale Anzahl / Verhältnis in solchen Situationen?

Kann dies zu zu viel Philosophie und Argumenten über Ideen führen?

Hat jemand eine solche Erfahrung gemacht, die man mit mir teilen kann?

Wenn ich wählen könnte, hätte ich 6-7 Senioren in einem Team (vorausgesetzt, das Projekt benötigt so viele).

Das einzige Mal, wenn ich sehe, dass dies ein Problem ist, sind die Senioren nur in ihrer Selbstwahrnehmung und nicht in ihrer Arbeitsmoral.

Es gibt nichts Besseres, als mit einer Gruppe von Menschen zusammenzuarbeiten, die es zu schätzen wissen, dass jede Softwareentwicklung wichtig ist - die Dokumentation, die Planung, der Code, der Kaffee, alles, was zählt, und es braucht reife (echte Senior-) Entwickler, um oben zu sein nichts "und erledige den Job richtig.

EDIT : Viele andere Antworten haben gesagt, dass zu viele Führungskräfte ein Problem sind - aber warum gibt es eine Wahrnehmung, die ein Senior führen muss? Ein Senior sollte reif genug sein, um einen Anführer auszuwählen und ihm zu folgen. Auf das Projekt kommt es an - hol dir eine Rolle und rock sie albern!

Das größte Problem, das ich beim Laden eines Teams mit erfahrenen Programmierern sehe, ist, dass es andere Teams schwächen könnte. Wenn Sie Nachwuchsentwickler in anderen Teams haben, die Betreuung und Anleitung benötigen, müssen Sie möglicherweise die Leute umstellen.

Kann dies zu zu viel Philosophie und Argumenten über Ideen führen?

Sicher kann es , aber sie sollten ausgereift genug sein, um zu wissen, welche Unterschiede wichtig sind und welche nicht. Wenn Sie einen angesehenen Teamleiter benannt haben, sollten diese Art von philosophischen Argumenten mit geringem Aufwand auf ein Minimum beschränkt werden.

Kann es sich als schlecht herausstellen, zu viele hochrangige Programmierer in einem Team zu haben?

Bestimmt.

Ich bin ein großer Befürworter von Fred Brooks ' Operationsmuster .

Und wenn die Senioren eines Entwicklungsteams nicht wissen, wer der "Chefchirurg" ist, geraten sie bei wichtigen Architekturentscheidungen in Konflikt und ziehen zum Nachteil des Teams in verschiedene Richtungen.

PS Das Bedürfnis eines Entwicklungsteams nach einem "Chefchirurgen" ähnelt dem eines Orchesters nach einem Dirigenten. In beiden Fällen werden Sie wahrscheinlich viele Veteranen haben. aber Sie werden ein feines Durcheinander ohne eine Person haben, die unbestritten verantwortlich ist.

Es kommt darauf an, wie die Zuständigkeiten verteilt sind. Wenn ALLE Sr. Devs die gleiche Verantwortung für Design, Codeüberprüfung usw. haben sollen, könnte dies zu einem Problem werden. Wenn ihnen unterschiedliche Verantwortlichkeiten übertragen werden, so dass sie arbeiten können, ohne sich gegenseitig um die Kontrolle über die Domänen zu bemühen, sollte dies kein Problem sein. Beispielsweise übernimmt ein Senior-Entwickler die Hauptverantwortung für das Projektdesign, ein anderer übernimmt die Verantwortung Wenn Sie ein Quell-Repository einrichten und verwalten, wird ein anderer für Unit-Tests zuständig sein, usw.

Kann es sich als schlecht herausstellen, zu viele hochrangige Programmierer in einem Team zu haben?

Nicht unbedingt. Ich habe in kleinen Teams von Senior-Entwicklern gearbeitet, die sehr produktiv waren. Das Niveau des Diskurses war sehr hoch und es gab keinen Groll.

Mit TDD gibt es nur sehr wenige große Verpflichtungen in Bezug auf die Software-Architektur, so dass es wenig Grund gibt, sich darüber zu streiten. Entwurfsentscheidungen können gelöst werden, indem einfach beide Ansätze implementiert werden und herausgefunden wird, welcher am besten funktioniert. Da die Entwickler sehr schnell sind, sind die Kosten für diese Versuche sehr gering.

Ja, es kann das Problem geben, zu viele Köche in der Küche zu haben, als dass eine Metapher zutreffen könnte. Es könnte auch recht kostspielig sein, wenn sie alle hohe Gehälter erwarten. Beachten Sie, dass dies nur die Existenz eines schlimmen Falls überprüft und nichts über dessen Wahrscheinlichkeit aussagt.

Das Optimum hängt von einer Reihe von Variablen ab, die Sie nicht offenlegen. Welche Metrik möchten Sie verwenden, um zu erkennen, dass hier eine gute Chance für Spiele besteht? Ebenso, welche Einschränkungen haben Sie in Ihrer Welt, die es möglicherweise anders machen als Google oder Microsoft im Gegensatz dazu.

Zu viele leitende Entwickler haben möglicherweise das Problem, dass entweder keine oder zu viele Konventionen vorhanden sind. Einige leitende Entwickler können sich zwar gut anpassen, aber wenn keiner von ihnen eine Konvention einführt, wo würde dann ein Team anfangen? Umgekehrt mag es einige erfahrene Entwickler geben, die sich für einige Konventionen interessieren, für deren Lösung möglicherweise eine Konfliktlösung erforderlich ist.

Ich denke, es hängt von den Persönlichkeiten der Senioren ab. Wenn sie arrogant und argumentativ sind, kann es eine schlechte Sache sein. Aber wenn sie alle respektvoll, offen für andere Sichtweisen und bereit sind, voneinander zu lernen, dann haben Sie ein großartiges Team.

Ich arbeite derzeit in einem 8-köpfigen Team, in dem 5 oder 6 Senioren sind, und es funktioniert wirklich gut für uns. Wir verstehen uns gut, lernen voneinander und es ist eine großartige Mentoring-Umgebung für die neueren Leute, die wir haben.

Ich habe in einem Team gearbeitet, in dem es 1 leitenden Entwickler, 4 leitende Entwickler und 1 mittleren Entwickler gab. Und aus dem Grund, dass ein "älteres" Mitglied des Teams keine wirklich reife Person war (obwohl ein guter Entwickler), stellte sich heraus, dass es ein Albtraum war. Er versuchte die ganze Zeit (implizit oder explizit) zu beweisen, dass andere Teammitglieder nicht älter genug sind. Außerdem verstand er die Grundprinzipien der Softwareentwicklung und die Besonderheiten unseres Produkts nicht und versuchte daher arrogant und hartnäckig zu beweisen, dass er Recht hat. Infolgedessen wurde die Effektivität des Teams ernsthaft beeinträchtigt. Der traurige Teil ist, dass es nicht zu viele Auseinandersetzungen über Ideen / Lösungen gab - es ging um nichts . Beispielsweise:

• der den Build gebrochen hat (der die meiste Zeit grün war und technisch gesehen nicht kaputt ging. Es war die Benutzeroberfläche, die aufgrund der schlechten architektonischen Lösungen sehr oft nicht richtig funktionierte)
• Warum gibt es Regressionen? (Module wurden nicht durch Unit-Tests abgedeckt, zu denen wir keinen Beitrag leisten konnten.)
• Streiten über eine architektonische Lösung in einem Modul, für die ein anderer verantwortlich ist, ohne die Anforderungen und Besonderheiten des Moduls zu kennen.
• ...

Aber ich gebe zu, es war eher eine Ausnahme. Ich möchte glauben, dass Senioren sich die meiste Zeit richtig verhalten :)