it-swarm.com.de

Was ist der beste Weg, um die Arbeit unter den Entwicklern aufzuteilen?

Mein Team und ich bauen eine Site um, die wir vor ungefähr zehn Jahren entwickelt haben, und wir möchten dies in Agile tun.

Nachdem ich viel Zeit mit Lesen verbracht habe (wahrscheinlich nicht genug), habe ich Probleme mit der Frage, wie man die Arbeit zwischen Entwicklern aufteilt.

Ich werde genauer sein und sagen, dass die Site in separate Module unterteilt ist, die nicht viel Integration untereinander haben.

Was ist der beste/am meisten akzeptierte Weg, um die Arbeit zwischen den Entwicklern aufzuteilen?

  • Geben Sie jeder Person ein anderes Modul, an dem Sie arbeiten können.
  • Weisen Sie alle Entwickler demselben Modul zu und teilen Sie die Arbeit auf verschiedene Teile des Moduls auf (UnitTesting, DAL und Mapping, Logik, Benutzeroberfläche).
  • Weisen Sie alle Entwickler demselben Modul zu und teilen Sie die Arbeit nach verschiedenen Logiken auf (zum Beispiel ist jeder Entwickler für eine bestimmte Logik verantwortlich (wahrscheinlich eine Methode in der BL) und es ist UnitTesting, DAL und Mapping und UI ...

Oder vielleicht etwas ganz anderes?

30
Amir

Mein Team hat seit einigen Veröffentlichungen versucht, "agil" zu werden, aber es hat es nicht gerade einfach gemacht, Teil eines großen Unternehmens zu sein. Ich werde nicht so tun, als hätte ich die Antwort, aber ich kann einige meiner Beobachtungen teilen.

  • Entwickler nach Modul aufteilen:

    • Sie müssen vorsichtig sein, denn wenn Menschen zu viel isoliert arbeiten, profitiert Ihr Team nicht vom Austausch von Fähigkeiten und Wissen
    • Das Planen von Meetings und täglichen Stand-Ups kann für alle unglaublich langweilig werden, wenn sich die Leute zu sehr auf ihre eigenen Module konzentrieren und kein größeres Bild sehen. Sobald sich die Leute langweilen, checken sie aus und Sie verlieren viel von dem Nutzen, den Agilität mit sich bringt
    • Sie könnten am Ende einige Komponenten haben, die wirklich gut geschrieben sind, und andere Komponenten, na ja ... nicht so sehr. Wenn die Leute isoliert arbeiten, können Ihre Senioren die Junioren nicht trainieren.
  • Jeder arbeitet zur gleichen Zeit am selben Modul

    • Wir haben das für eine Veröffentlichung versucht, als das Management beschloss, dem gesamten Team Agilität aufzuerlegen, und es wird ganz nach ihrem Geschmack sein. Es ist ein absolutes Zugunglück. Wir haben ein Team von 9 Entwicklern in einem Jahr liefern lassen, was normalerweise von einem Entwickler getan worden wäre. (Ich übertreibe hier vielleicht, aber nicht viel).
    • Niemand hatte das Gefühl, dass es einen Raum zum Atmen gab. Diejenigen, die sich nicht für Software interessierten, fühlten sich wie zu Hause, weil sie als Teil eines größeren Pakets nur in der Gruppe verwässert werden. Diejenigen von uns, die eine Leidenschaft für Software hatten, fühlten sich absolut erstickt, da es keine Freiheit gab, sich zu bewegen oder über die Grenzen hinauszugehen, auf die sich 9 Personen geeinigt hatten.
    • Alle Treffen gingen für immer zu einem Punkt, an dem ich mich selbst erschießen wollte. Zu viele Leute mit einer Meinung im selben Raum sind gezwungen, an derselben verdammten DLL zu arbeiten. Der Horror.
  • In der letzten Version haben wir beschlossen, etwas anderes auszuprobieren
    • Teilen Sie die Entwicklungsgruppe in erster Linie in kleinere Teams von 3-4 Entwicklern auf. Jedes Team arbeitete relativ isoliert voneinander, aber innerhalb des Teams arbeiteten die Leute viel kohärenter
    • Mit diesem Ansatz sind Stand-Ups schnell und die Planung von Besprechungen dauert 1-2 Stunden im Vergleich zu soliden 4 Stunden.
    • Jeder fühlt sich engagiert, weil jedes Team nur bespricht, was den Entwicklern in diesem Team wichtig ist.
    • Der technische Leiter jedes Teams spricht regelmäßig mit anderen technischen Leitern, um sicherzustellen, dass das Gesamtprojekt auf dem richtigen Weg ist.
    • Anstatt die Leute zum "Eigentümer" eines bestimmten Moduls zu machen, haben wir den Leuten Fachgebiete zugewiesen. Als wir das Projekt zum ersten Mal starteten, hatten die Leute das Gefühl, ein eigenes Modul zu haben, aber nach einigen Monaten begannen die Entwickler, sich gegenseitig als Code anzusehen Bereiche begannen sich zu überlappen.
    • Codeüberprüfungen sind unerlässlich. Dies war die zweite Version, in der wir strenge Richtlinien zur Codeüberprüfung hatten und die alle im Team lieben. Der Experte eines bestimmten Bereichs befindet sich immer in einer Codeüberprüfung, wenn jemand anderes diesen Code ändert.
    • Mit Codeüberprüfungen haben wir eine Menge Wissensaustausch und Sie können die allgemeine Verbesserung der Codequalität unserer Teams sehen. Auch weil Code so oft überprüft wird, besteht die Möglichkeit, dass Benutzer den Code bereits einige Male gesehen haben, wenn sie in das Fachgebiet eines anderen gehen.
    • Ein größerer Teil jedes Teams wird in Besprechungen zur Entwurfsprüfung einbezogen. Selbst wenn der Code noch nie gesehen wurde, ist jeder mit dem allgemeinen Ablauf aller Module vertraut, für die sein Team verantwortlich ist.
    • Wir haben das ungefähr 10 Monate lang gemacht und es fühlt sich so an, als hätten wir mit einem isolierten Modulansatz begonnen und uns in alle verwandelt, die an allem arbeiten. Gleichzeitig fühlt sich niemand eng oder eingeschränkt. Und um sicherzustellen, dass die Jungs immer noch ein Gefühl für Autorität haben, haben wir sie als Gebietsexperten zurückgelassen, obwohl das jetzt meistens eine Formalität ist.

Wir haben das Letzte getan, und obwohl es eine Menge Raum für Verbesserungen gibt, war unser gesamtes Team insgesamt sehr glücklich und das sagt viel aus, wenn wir Teil eines riesigen Unternehmens sind.

Eine wichtige Sache, die wir beim ersten Mal, als wir "agil" wurden, falsch verstanden haben, ist, dass den Menschen jedes Mal gesagt wurde, wie sie arbeiten sollen und woran sie arbeiten sollen. Dies ist die erste Möglichkeit, Ihr Team vollständig an dem Projekt zu verlieren, und dann sind Sie in echten Schwierigkeiten.

Versuchen Sie stattdessen das Gegenteil. Sagen Sie dem Team, dass sie tun können, was sie wollen, und als Manager/Leiter (wenn Sie einer sind, wenn Ihr Manager diese Worte nicht wiederholt), müssen Sie sicherstellen, dass sie so produktiv und glücklich wie möglich sind. Prozess ist keine schlechte Sache, aber Prozess sollte da sein, um Ihrem Team zu helfen, wenn es erkennt, dass es einen braucht, nicht umgekehrt.

Wenn einige Ihrer Teammitglieder es vorziehen, isoliert zu arbeiten, lassen Sie sie (bis zu einem gewissen Grad). Wenn sie lieber paarweise arbeiten möchten, lassen Sie sie das tun. Stellen Sie sicher, dass Ihre Mitarbeiter so viel wie möglich ihre eigene Arbeit auswählen.

Schließlich, und das ist sehr wichtig und wird immer übersehen. Sie werden dieses Recht nicht bekommen (es sei denn, Sie sind Superman oder zumindest Batman). Regelmäßige Rückblicke sind äußerst wichtig. Als wir Retrospektiven herausbrachten, wurden sie von dem Buch gemacht und es fühlte sich wie ein weiterer Prozess an, den man durchstehen musste. Dafür ist Retrospektive nicht gedacht. Es dient dazu, Ihrem Team zuzuhören, Bereiche zu identifizieren, die die meisten Schmerzen verursachen, und diese zu beheben, damit jeder seine Arbeit fortsetzen kann. Anscheinend sind Softwareentwickler im Allgemeinen wie die Bereitstellung von Produkten und Funktionen und die wichtigste Nachricht, die ein nachträgliches Meeting zur Kommunikation benötigt, nur zu ihrem Vorteil. Sie möchten Hindernisse identifizieren und angehen, angefangen bei den größten (oder den einfachsten, es handelt sich um eine Art 2D-Karte), und sie aus dem Weg räumen, damit Ihre Mitarbeiter ihre Arbeit erledigen können.

37
DXM

Treffen Sie sich mit dem Team, zeigen Sie ihnen die Aufgabenliste und fragen Sie, wer was tun möchte.

16

Denken Sie nicht in Modulen. Denken Sie an Funktionselemente. Beschreiben Sie diese Funktionselemente anhand von User Stories (oder auf andere Weise) und vergessen Sie nicht, Akzeptanzkriterien zu beschreiben (wahrscheinlich definiert durch Ihre aktuelle Anwendung und Änderungen, die das Unternehmen erwartet). Stellen Sie Ihre Funktionselemente in den Rückstand. Lassen Sie das Unternehmen dann priorisieren, welche Funktionen zuerst bereitgestellt werden müssen (Sie arbeiten inkrementell und iterativ, und die Priorität gibt an, was zuerst implementiert werden muss).

Sobald Sie dies zumindest für einen Teil Ihrer ursprünglichen Anwendung haben, sind Sie bereit für die Entwicklung. Was als nächstes passiert, hängt von Ihrer gewählten agilen Methodik ab. Der wichtige Teil ist, dass jede Funktionalität normalerweise in mehrere Aufgaben unterteilt werden kann und die Teammitglieder auswählen, welche Aufgaben sie ausführen möchten - dies wird als Selbstorganisation bezeichnet. Wenn Sie mit Agilität beginnen, benötigt die Selbstorganisation möglicherweise Hilfe, um sicherzustellen, dass unpopuläre und beliebte Aufgaben vom Team gleichermaßen geteilt werden. Sobald das Team reifer ist, werden Entwickler nicht zögern, ihre Ablehnung der aktuellen Selbstorganisation zu äußern, und dies wird automatisch innerhalb des Teams behandelt.

Von Anfang an in Modulen zu denken, muss kein guter Weg sein. Sie schreiben die Anwendung aus irgendeinem Grund neu und möglicherweise ist die aktuelle Anwendungsarchitektur, die auf einer falschen Modultrennung basiert, einer der versteckten Gründe für sichtbare Probleme. Sie können auch feststellen, dass einige Funktionen aus vorhandenen Modulen vollständig neu definiert und an eine andere Stelle verschoben werden.

10
Ladislav Mrnka

Obwohl ich mit Davids Antwort einverstanden bin, hatte ich das Gefühl, dass es von einigen Ausarbeitungen profitieren könnte:

  • Agil bedeutet, dass Sie diese Entscheidungen nicht treffen und sie ins Team übertragen. Es gibt keinen solchen Projektmanager/-leiter. Nur das Team.
  • Diejenigen, die am besten wissen, wie man Arbeit teilt, sind die Teammitglieder selbst.
  • Besprechen Sie Ihren Rückstand und finden Sie heraus, was Sie in der nächsten Iteration/im nächsten Sprint realisieren möchten.
  • Verwenden Sie Planungspoker oder ähnliche Methoden, um eine Vorstellung davon zu bekommen, wie viel Arbeit Sie sowieso aufteilen werden, und beginnen Sie erst dann, die tatsächlichen Arbeitspakete aufzuteilen zusammen.

Grundsätzlich lautet das Fazit: Niemand hier auf SE kann diese Frage für Sie beantworten, und es gibt auch keinen Grund dafür, denn es ist viel besser, wenn Sie als Team eine Antwort finden.

8
Frank

Der einfachste Ansatz ist oft der beste.

Ich würde es vermeiden, Aufgaben in Gruppen wie testing/log/UI/etc zu unterteilen, es sei denn, Sie können einige sehr gute und klare Gründe dafür definieren. Meine Argumentation ist, dass wenn Sie Programmierern erlauben, außerhalb ihrer üblichen Fachgebiete zu arbeiten, dies die Dinge für sie interessanter und herausfordernder halten und ihnen ermöglichen kann, sich in ihrem Bereich zu entwickeln und zu wachsen. Wenn Sie der Meinung sind, dass Sie aufgrund von Zeitbeschränkungen die Arbeit nach Fachwissen aufteilen müssen, stellen Sie mindestens sicher, dass jeder Entwickler weiterhin seine eigenen Komponententests durchführen muss, und verwenden Sie Codeüberprüfung und Abnahmetests, um Probleme zu erkennen. Das Schreiben eigener Tests ist sehr agil und das Warten auf die Verfügbarkeit von Testern kann sehr verschwenderisch sein.

Angesichts dieses Dilemmas habe ich folgenden Ansatz gewählt:

  • Umfang des Projekts. Geben Sie sich eine Vorstellung davon, worauf Sie sich einlassen, und erstellen Sie eine Liste mit Funktionen, indem Sie das Projekt in eine Reihe von Aufgaben aufteilen.

  • Funktionen priorisieren. Entscheiden Sie, welche Funktionen frühzeitig abgeschlossen werden müssen und welche Ihren Kunden sofort einen Mehrwert bieten. Machen Sie sich keine Sorgen, wenn Ihre Entwickler am Ende an denselben Modulen arbeiten, aber stellen Sie sicher, dass Sie über einen guten Prozess und Tools zum Verwalten von Code-Zusammenführungen verfügen.

  • Binden Sie Ihr Team ein und bitten Sie Ihre Entwickler, Sie bei der Aufteilung der Funktionen in eine Liste einfacher zu verwaltender Aufgaben zu unterstützen. Überprüfen Sie als Gruppe und passen Sie die Aufgaben nach Bedarf an, damit sie leichter geschätzt werden können.

  • Bitten Sie jeden Entwickler, oben in der Prioritätswarteschlange, an der der Entwickler arbeiten möchte, eine zu implementierende Aufgabe oder eine Gruppe von Aufgaben auszuwählen, je nachdem, wie Ihre Iterationen ausgeführt werden sollen.

  • Lassen Sie jeden Entwickler nur an einer Sache arbeiten, bis diese abgeschlossen ist, bevor Sie mit der Auswahl des nächsten Elements oben in der Prioritätswarteschlange fortfahren. Sie könnten versucht sein, Ihre Mitarbeiter gelegentlich Aufgaben ändern zu lassen, dies führt jedoch zu Zeitverschwendung beim Entwickler. Wenn Sie mit Abhängigkeitsengpässen konfrontiert sind, müssen Sie Ihre Aufgabenprioritäten anpassen und die Verschwendung minimieren.

  • Haben Sie keine Angst davor, dass Entwickler mit überlappenden Iterationen arbeiten, und verwalten Sie Ihre Releases entsprechend. Dies hilft, die Zeitverschwendung zwischen Releases zu minimieren, die darauf warten, dass Aufgaben abgeschlossen werden.

Letztendlich geht es bei Agile darum, eine Lösung zu finden, die für Ihr Team, Ihr Unternehmen und Ihre Kunden gut funktioniert. Es liegt an Ihnen, Ihren Prozess zu optimieren, indem Sie das Gleichgewicht der Praktiken finden, die für Sie am besten funktionieren. Die Aufteilung Ihrer Aufgaben wird ein sehr wichtiger Teil eines viel größeren Prozesses sein, sollte jedoch so einfach wie möglich gehalten werden, um die Bereitschaft zur Teilnahme zu fördern und zu vermeiden, dass sich später schwer zu lösende prozessbedingte Probleme entwickeln.

4
S.Robins

Keine organisatorische Diskussion des Entwicklerteams wäre vollständig, ohne Dr. Fred Brooks 'Surgical Team zu erwähnen.

Die Grundformel lautet: ein Operationsteam pro Arbeitseinheit

Ein chirurgisches Team definieren

Das Konzept des Operationsteams basiert auf zwei Grundgedanken:

  1. weniger Entwickler sind pro Arbeitseinheit besser, weil Übersprechen die Produktivität beeinträchtigt.
  2. Entwickler mit hoher Leistung übertreffen Entwickler mit niedriger Leistung deutlich (und laut Brooks gibt es keinen Entwickler mit mittlerer Leistung), daher sollten Sie ihnen die wichtigste Aufgabe geben und begrenzen ihre Ablenkungen.

Ein Operationsteam besteht aus 3-10 Entwicklern:

  1. Ein Chefprogrammierer. Ein leistungsstarker Entwickler, der den größten Teil der eigentlichen Programmierung übernimmt.
  2. Ein Co-Pilot. Ein weiterer leistungsstarker Entwickler, der einige Programmier-, aber auch einige administrative Aufgaben erledigt, z. B. die Teilnahme an Besprechungen und das Sammeln von Anforderungen.
  3. 1 - 8 Assistenten. Brooks beschreibt diese als Entwickler, die für Dinge wie Dokumentation, Codebereinigung, Recherche, Schreiben von Tools/Algorithmen, Testen usw. verantwortlich sind. In den 60er Jahren schlug Brooks genau 8 Rollen vor, aber mit modernen Tools, für die Sie möglicherweise nur 1 oder 2 benötigen, sollten wahrscheinlich entsprechend den Anforderungen Ihres Projekts zugewiesen werden.

Arbeitseinheit definieren

Nun, da wir ein Team zusammenstellen können, was weisen wir ihnen zu?

  • Wenn das Projekt sehr klein ist, ist dies einfach. Sie weisen dem gesamten Projekt ein Operationsteam zu.
  • Andernfalls Dann müssen Sie mit einer Person oder einem Team beginnen, die/das für das gesamte Projekt verantwortlich ist Architektur. Es wird ihre Aufgabe sein, die Software entsprechend zu modularisieren, damit die Arbeit auf weitere Subteams aufgeteilt werden kann. Das Architekturteam kann auch andere Aufgaben übernehmen, um Entwickler nicht zu dünn zu machen.

Sie sollten drei grundlegende, akzeptable Muster erkennen:

  1. Genau 1 Subteam für jede Ebene (UI, DAL usw.)
  2. Genau 1 Subteam für jedes Modul (Homepage, Support-Site, Shop)
  3. Eine Mischung aus beiden (ein Low-Level-Framework-Team und ein UI-fokussiertes Team für jedes Modul)
3
Kevin McCormick

Abhängig von der Anzahl der Entwickler und Module (und Zeitskalen) veranlassen meine Entwickler im Allgemeinen, ein interessantes Modul (für sie) und ein herausforderndes Modul (vorzugsweise etwas, das sie nicht getan haben) auszuwählen, und dann den Rest, den ich nach Schwierigkeitsgrad und aufteile Zeitbeschränkungen. Ich finde, das gibt meinen Entwicklern etwas, an dem sie arbeiten möchten, und etwas, das sie pushen kann.

Das funktioniert natürlich nicht immer ...

2
Amy

Folgendes würde ich tun:

Wenn alle Module klein sind, können Sie jedem ein Modul zur Bearbeitung geben. Andernfalls machen Sie Folgendes:

  1. Definieren Sie jede Modulgröße, Komplexität und die dafür erforderlichen Fähigkeiten.
  2. Definieren Sie die Fähigkeiten jedes Teammitglieds.
  3. Definieren Sie, welche Personen gut zusammenarbeiten und welche nicht gut mit anderen zusammenarbeiten.
  4. Weisen Sie große Module Teams von Personen zu, die auf der Grundlage der Anforderungen an die Modulfähigkeiten und der Teamfähigkeiten gut zusammenarbeiten.
  5. Weisen Sie die verbleibenden Module Personen zu, die aufgrund der Anforderungen an die Modulfähigkeiten und der Teamfähigkeiten nicht gut mit anderen Personen zusammenarbeiten können.

Das Obige funktioniert nicht, wenn die Leute, die nicht gerne mit anderen arbeiten, die kompetentesten sind und dies ein häufiger Fall ist. Machen Sie daher eine Ausnahme von 4 und 5 entsprechend

1
NoChance