Wenn eine Teamgröße über 10 Jahre alt wird, können Sie die Release-Planung trotzdem gemeinsam durchführen?

Tun Sie dies bei der Entscheidung, woran Sie für die nächste Version arbeiten möchten, und bei der Schätzung des Timings für jede User Story (und der Unteraufgaben für eine bestimmte Story) in einer Gruppe oder nur bei Managern?

Ist das für eine Teamgröße von 10 praktisch?

Wie lange dauert es?

Die Priorisierung sollte von einem einzelnen Product Owner unter Einbeziehung der verschiedenen Stakeholder durchgeführt werden, einschließlich eines leitenden Entwicklers, der ein Stakeholder für den Code ist und für nicht funktionale Anforderungen ebenso verantwortlich ist wie ein Business Stakeholder für die funktionalen Anforderungen.

Die Schätzung sollte unbedingt von den Personen vorgenommen werden, die die Arbeit erledigen werden, niemals von einem Manager, der unter dem Druck steht, etwas zu liefern. Ihr Instinkt ist jedoch richtig, dass mehr als ein halbes Dutzend Personen stundenlang darüber streiten werden. In einer idealen Welt sollten Sie das Team wirklich so aufteilen, dass es nicht weniger als 4 und nicht mehr als 7 in einem einzelnen Team gibt - 5 ist meiner Meinung nach ideal.

Wenn dies aus irgendeinem Grund absolut nicht möglich ist - und Sie müssen 5 Gründe auf diesen Grund anwenden , bevor Sie akzeptieren, dass dies unmöglich ist -, sollte das Team ein Team von 4 bis 5 Personen auswählen, um in ihrem Namen Schätzungen vorzunehmen .

Meiner Meinung nach sollten Sie die Release-Planung NICHT als Team von 10 Personen durchführen. Höchstwahrscheinlich werden Sie mit einem riesigen Treffen enden, bei dem sich 6-8 Personen in einer bestimmten Diskussion völlig unverbunden und gelangweilt fühlen. Hinzu kommt die Erschöpfung von 3-4 Stunden, die zusammen in einem Raum eingesperrt sind. Und denken Sie daran, dass Sie viel zu viel reden, wenn 10 Personen sprechen. Wenn sie nicht sprechen, erhalten Sie möglicherweise keine wertvollen Informationen.

Wir haben etwas sehr Ähnliches wie Josephs Firma gemacht. Vorherige Version hatten wir 8 Ingenieure und die Release-Planung dauerte 2 solide Wochen. Und es war absolut brutal. Ich denke, dass wir alle nach ein paar Stunden versuchen, so wenig wie möglich zu sprechen, damit das Treffen früher vorbei ist.

Mit dieser Veröffentlichung hat sich unsere Teamgröße mehr als verdoppelt. Also haben wir uns in kleinere Teams aufgeteilt, die einen Bereich eines Produkts dauerhaft in Besitz nehmen würden. Jedes der kleineren Teams hatte einen Vorsprung. Dann haben wir eine Release-Planung auf hoher Ebene nur mit den Leads durchgeführt, was viel schneller und effizienter war, da wir jetzt nur noch 4 Entwickler in einem Raum hatten. Während dieser Zeit haben wir ermittelt, welches Team welche Storys machen würde und wie das Produkt aufgeteilt wird. Auch dies ergab das Gesamtbild des gesamten Produkts.

Dann kehrte jeder Lead zu seinem eigenen Team zurück und ging den Teil der Veröffentlichung durch, für den nur dieses Team verantwortlich war. In dieser Zeit haben wir einige Details eingegeben und Story-Point-Werte zugewiesen.

Zuletzt wurde alles zusammengestellt und wir haben einen letzten Durchgang gemacht (eher eine Präsentation als eine Diskussion), damit jeder im Team weiß, was mit dem gesamten Team los ist.

Obwohl wir mit dieser Methode keine vollständige erfolgreiche Veröffentlichung hatten, denke ich, dass die Release-Planung insgesamt viel reibungsloser verlief als zuvor, und wir haben viel mehr daraus gemacht. Der Schlüssel war, dass wir in einem Meeting nie mehr als 3-4 Entwickler hatten und immer noch die Stimme aller zu hören war.

Wenn möglich, würde ich empfehlen, dass Sie Ihre 10 Entwickler in 3 Gruppen aufteilen. Wenn Sie Ihre Gesamtversion nicht in 3 meist nicht überlappende Bereiche aufteilen können, sind sogar 2 Gruppen besser als ein großes Team.

Ich bin tatsächlich Teil mehrerer Projekte (und mehrerer Teams) als Lead, und es gibt einige, die 10+ sind. Bei fast allen Projekten, an denen ich arbeite, wird die Release-Planung von den Leads und den Business-Analysten durchgeführt. In unserer Situation sind die BAs jedoch nicht die Manager, sodass die Manager nicht wirklich an der Release-Planung teilnehmen.

Die Schätzung wird jedoch vom Implementierungsteam vorgenommen, und obwohl beide Teile getrennt sind, sind sie sehr eng miteinander verbunden.

Die Schätzung gibt an, wie viel Zeit eine Aufgabe benötigt, um erledigt zu werden, während bei der Release-Planung die Bearbeitung dieser Aufgaben geplant ist.

Die Planung sollte nach geschäftlichen Gesichtspunkten erfolgen, während die Schätzung nach technischen Gesichtspunkten erfolgen sollte. Daher die Trennung von Schätzung und Planung.

Diese Aufgabe wird von einem Manager effizienter erledigt. In kleinen Teams verwechseln sich die Rollen. Jeder ist an allem beteiligt. Wenn Ihr Team jedoch wächst, wird dies unüberschaubar und die Rollen müssen klar definiert werden.

So sehr ich den Wunsch habe, an allem beteiligt zu sein, ist es einfach nicht produktiv.