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

Mein Team und ich bauen eine Site um, die wir vor etwa 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 ich die Arbeit zwischen Entwicklern aufteilen kann.

Ich werde genauer darauf eingehen und sagen, dass die Site in separate Module unterteilt ist, die nicht viel Integration untereinander aufweisen.

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

• Geben Sie jeder Person ein anderes Modul zum Bearbeiten.
• Weisen Sie alle Entwickler demselben Modul zu und teilen Sie die Arbeit nach verschiedenen Teilen des Moduls auf (UnitTesting, DAL und Mapping, Logics, UI).
• Weisen Sie alle Entwickler demselben Modul zu und teilen Sie die Arbeit nach verschiedenen Logikbereichen 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?

Mein Team hat schon seit einigen Releases versucht, "agil" zu werden, aber es war nicht gerade einfach, 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 die Leute zu isoliert arbeiten, profitiert Ihr Team nicht vom Austausch von Fähigkeiten und Wissen
  • Das Planen von Meetings und täglichen Aufständen kann für jeden 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 einen Großteil der Vorteile, die Agilität mit sich bringt
  • Es könnte sein, dass einige Komponenten wirklich gut geschrieben sind und andere ... nicht so gut. Wenn die Leute isoliert arbeiten, können Ihre älteren Leute die jüngeren nicht ausbilden.

• Jeder arbeitet zur selben Zeit am selben Modul

  • Wir haben das für eine Veröffentlichung versucht, als das Management entschied, dass sie dem gesamten Team Agilität aufzwingen und es wird ganz auf ihre Art und Weise geschehen. Es ist wie ein absolutes Zugunglück. Wir hatten ein Team von 9 Entwicklern in einem Jahr, was normalerweise von 1 Entwickler gemacht worden wäre. (Ich übertreibe hier vielleicht, aber nicht viel).
  • Niemand hatte das Gefühl, dass es irgendeinen Raum zum Atmen gab. Diejenigen, die sich nicht für Software interessierten, fühlten sich wie zu Hause, weil sie Teil eines größeren Pakets waren und sich nur in der Gruppe verwässerten. Diejenigen von uns, die eine Leidenschaft für Software hatten, fühlten sich absolut erstickt, da es keine Freiheit gab, sich zu bewegen oder die Grenzen zu überschreiten, 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 in erster Linie die Entwicklungsgruppe 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 bis 2 Stunden im Vergleich zu 4 Stunden.
  • Jeder fühlt sich engagiert, weil jedes Team nur bespricht, worum es den Entwicklern in diesem Team geht.
  • Der technische Leiter jedes Teams spricht regelmäßig mit anderen technischen Leitern, um sicherzustellen, dass das Gesamtprojekt auf dem richtigen Weg ist.
  • Anstatt Leute zu "Eigentümern" eines bestimmten Moduls zu machen, haben wir den Leuten Fachgebiete zugewiesen. Als wir das Projekt starteten, hatten die Leute das Gefühl, ein eigenes Modul zu haben, aber nach einigen Monaten begannen die Entwickler, sich gegenseitig den Code als zu betrachten Bereiche begannen sich zu überlappen.
  • Codeüberprüfungen sind unerlässlich. Dies war die zweite Veröffentlichung, in der wir strenge Richtlinien für die Codeüberprüfung hatten und die alle im Team lieben. Der Experte eines bestimmten Bereichs befindet sich immer in einer Codeüberprüfung, wenn eine andere Person diesen Code ändert.
  • Mit Code Reviews 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, ist die Wahrscheinlichkeit groß, dass die Leute den Code bereits mindestens ein paar Mal gesehen haben, wenn sie sich mit dem Fachgebiet eines anderen befassen.
  • Ein größerer Teil jedes Teams wird in Konstruktionsprüfungsbesprechungen mit einbezogen. Selbst wenn sie den Code noch nie gesehen haben, ist jeder mit dem allgemeinen Ablauf aller Module vertraut, für die sein Team verantwortlich ist.
  • Wir machen das seit ungefähr 10 Monaten und es fühlt sich so an, als hätten wir mit einem isolierten Modulansatz begonnen und uns in jeden verwandelt, der an allem arbeitet. Gleichzeitig fühlt sich niemand beengt oder eingeschränkt. Und um sicherzustellen, dass die Jungs immer noch ein Gespür für Autorität haben, haben wir sie als Gebietsexperten zurückgelassen, auch wenn dies derzeit größtenteils eine Formalität ist.

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

Eine wichtige Sache, die wir falsch gemacht haben, als wir die ersten drei Male "agil" wurden, ist, dass den Leuten jedes Mal gesagt wurde, wie sie arbeiten sollen und woran sie arbeiten sollen. Auf diese Weise kann Ihr Team das Interesse an dem Projekt vollständig verlieren, und Sie befinden sich in echten Schwierigkeiten.

Versuchen Sie stattdessen das Gegenteil. Sagen Sie dem Team, sie können tun, 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, und nicht umgekehrt.

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

Schließlich und das ist sehr wichtig und wird immer übersehen. SIE ERHALTEN DIESES RECHT NICHT (es sei denn, Sie sind Übermensch oder zumindest Batman). Es ist äußerst wichtig, regelmäßig nachträgliche Treffen abzuhalten. 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 gibt es keine Retrospektive. Es dient dazu, Ihrem Team zuzuhören, die Bereiche zu identifizieren, die die meisten Schmerzen verursachen, und sie zu reparieren, damit jeder seine Arbeit fortsetzen kann. Anscheinend möchten Softwareentwickler im Allgemeinen gerne Produkte und Funktionen bereitstellen und das wichtigste nachträgliche Message-Meeting kommunizieren, ist, dass es ausschließlich zu ihrem Vorteil ist. Sie möchten Hindernisse identifizieren und überwinden, beginnend mit den größten (oder einfachsten) Hindernissen.

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

Denken Sie nicht in Modulen. Denken Sie in Funktionselementen. Beschreiben Sie diese Funktionselemente durch User Stories (oder auf andere Weise) und vergessen Sie nicht, die Akzeptanzkriterien zu beschreiben (die wahrscheinlich von Ihrer aktuellen Anwendung definiert werden und die Geschäftserwartungen ändern). Stellen Sie Ihre Funktionselemente in Rückstand. Lassen Sie dann die Unternehmen Prioritäten setzen, welche Funktionen zuerst bereitgestellt werden müssen (Sie arbeiten schrittweise und iterativ, und Prioritäten geben an, welche Funktionen zuerst implementiert werden müssen).

Sobald Sie dies zumindest für einen Teil Ihrer ursprünglichen Anwendung haben, sind Sie für die Entwicklung bereit. Was als nächstes passiert, hängt von Ihrer gewählten agilen Methodik ab. Der wichtige Teil ist, dass jede Funktion in der Regel 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 unbeliebte und beliebte Aufgaben vom Team gleichermaßen geteilt werden. Sobald das Team reifer ist, werden die Entwickler nicht zögern, ihre Ablehnung der aktuellen Selbstorganisation zu äußern, und dies wird automatisch im Team 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 derzeitige Anwendungsarchitektur, die auf einer falschen Modultrennung basiert, einer der verborgenen Gründe für sichtbare Probleme. Außerdem können Sie feststellen, dass einige Funktionen aus vorhandenen Modulen vollständig neu definiert und an einen anderen Ort verschoben werden.

Obwohl ich Davids Antwort zustimme, hatte ich das Gefühl, dass es von einigen Verbesserungen profitieren könnte:

• Agil bedeutet, dass Sie diese Entscheidungen nicht treffen und sie dem Team übermitteln. Es gibt keinen solchen Projektleiter. Nur das Team.
• Diejenigen, die am besten wissen, wie man die Arbeit aufteilt, 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.
• Planung Poker oder ähnliche Methoden , um eine Vorstellung davon zu bekommen , wie viel Arbeit Sie sowieso teilen werden, und erst dann beginnen tatsächliche 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.

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 angeben. Wenn Sie es Programmierern erlauben, außerhalb ihrer üblichen Fachgebiete zu arbeiten, kann dies die Dinge für sie interessanter und herausfordernder machen und sie in die Lage versetzen, sich innerhalb ihres Fachgebiets zu entwickeln und zu wachsen. Wenn Sie das Gefühl haben, 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 die Codeüberprüfung und Abnahmetests, um Probleme zu erkennen. Das Schreiben eigener Tests ist sehr flexibel, und es kann sehr verschwenderisch sein, darauf zu warten, dass Tester Zeit zur Verfügung haben.

Angesichts dieses Dilemmas habe ich den folgenden Ansatz gewählt:

• Scope das Projekt. Machen Sie sich selbst ein Bild davon, worauf Sie sich einlassen, und entwickeln Sie eine Liste von 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 für Ihre Kunden unmittelbar von Nutzen sind. Machen Sie sich keine Sorgen, wenn Ihre Entwickler am Ende an denselben Modulen arbeiten, sondern stellen Sie sicher, dass Sie über einen guten Prozess und gute Tools zum Verwalten von Codezusammenführungen verfügen.

• Binden Sie Ihr Team ein und bitten Sie Ihre Entwickler, Sie dabei zu unterstützen, die Funktionen in eine Liste mit einfacher zu verwaltenden Aufgaben aufzuteilen. Überprüfen Sie die Aufgaben als Gruppe und passen Sie sie 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 Aufgabe auszuwählen, die implementiert werden soll, oder eine Gruppe von Aufgaben, je nachdem, wie Ihre Iterationen ausgeführt werden sollen.

• Lassen Sie jeden Entwickler nur an einer Sache arbeiten, bis sie abgeschlossen ist, bevor Sie mit der Auswahl des nächsten Elements oben in der Prioritätswarteschlange fortfahren. Es kann sein, dass Sie versucht sind, Ihre Mitarbeiter gelegentlich die Aufgaben ändern zu lassen. Dies führt jedoch zu Zeitverschwendung für den 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 ausgeführt werden, und verwalten Sie Ihre Releases entsprechend. Auf diese Weise können Sie den Zeitaufwand zwischen den Releases minimieren, die auf die Erledigung von Aufgaben warten.

Letztendlich geht es bei Agile darum, eine Lösung zu finden, die gut für Ihr Team, Ihr Unternehmen und Ihre Kunden geeignet ist. Es liegt an Ihnen, Ihren Prozess zu optimieren, indem Sie das Gleichgewicht der für Sie am besten geeigneten Vorgehensweisen finden. 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 um zu vermeiden, dass sich später auftretende prozessbedingte Probleme nur schwer lösen lassen.

Keine organisatorische Diskussion des Entwicklerteams wäre vollständig, ohne das Operationsteam von Dr. Fred Brooks zu erwähnen .

Die Grundformel lautet: Ein Operationsteam pro Arbeitseinheit

Definieren eines Operationsteams

Das Konzept des Operationsteams basiert auf zwei Grundgedanken:

1. Pro Arbeitseinheit sind weniger Entwickler besser, da Übersprechen die Produktivität beeinträchtigt.
2. Entwickler mit hoher Leistung übertreffen Entwickler mit niedriger Leistung (und laut Brooks gibt es keinen Entwickler mit mittlerer Leistung). Geben Sie ihnen also die wichtigsten Aufgaben und beschränken Sie 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 Entwickler mit hoher Leistung, der einige Programmier-, aber auch Verwaltungsaufgaben 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 benötigen Sie möglicherweise nur 1 oder 2 und sollte wahrscheinlich basierend auf den Anforderungen Ihres Projekts zugewiesen werden.

Arbeitseinheit definieren

Was ordnen wir ihnen zu, nachdem wir ein Team zusammengestellt haben?

• 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 starten, die verantwortlich für das gesamte Projekt ist Architektur . Es wird ihre Aufgabe sein, die Software entsprechend zu modularisieren, damit die Arbeit auf weitere Subteams aufgeteilt werden kann. Das achitecture-Team kann auch andere Aufgaben übernehmen, um die Entwickler nicht zu dünn zu machen.

Sie sollten drei akzeptable Grundmuster sehen:

1. Genau 1 Unterteam für jede Ebene (Benutzeroberfläche, DAL usw.)
2. Genau 1 Sub-Team für jedes Modul (Homepage, Support-Site, Shop)
3. Eine Mischung aus beidem (ein einfaches Framework-Team und ein auf die Benutzeroberfläche ausgerichtetes Team für jedes Modul)

Abhängig von der Anzahl der Entwickler und Module (und der Zeitskala) veranlasse ich meine Entwickler im Allgemeinen, ein interessantes Modul (für sie) und ein herausforderndes Modul (vorzugsweise etwas, was sie nicht getan haben) auszuwählen, und dann den Rest, den ich nach Fähigkeitsstufe und aufteile Zeitbeschränkungen. Ich finde, das gibt meinen Entwicklern etwas, woran sie arbeiten wollen, und etwas, das sie antreibt.

Natürlich funktioniert das nicht immer ...

Folgendes würde ich tun:

Wenn alle Module klein sind, können Sie jedem ein Modul zur Bearbeitung geben. Ansonsten mache folgendes:

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

Das oben Genannte funktioniert nicht, wenn die Leute, die nicht gerne mit anderen zusammenarbeiten, die kompetentesten sind. Dies ist ein häufiger Fall. Machen Sie also eine Ausnahme zu 4 und 5 entsprechend