Quelle est la meilleure façon de faire évoluer et de diviser une équipe agile en créant une application Web?

J'ai récemment rejoint une entreprise où je travaille en tant que Scrum Master sur un projet de développement agile créant une application web.

L'équipe est sur le point d'être la taille maximale pour une équipe agile (en attendant 9 la semaine prochaine). Nous avons parlé de la possibilité de diviser l'équipe en deux équipes, non pas tant pour raccourcir les standups (qui ne sont pas excessifs pour le moment) mais pour empêcher les gens de s'ennuyer complètement dans les sessions de planification de sprint (qui ne sont pas trop longues).

Il y a deux couches très distinctes dans le projet - développement technique de haut niveau (comme sérieusement complexe) et conception / construction / intégration d'interface utilisateur. Il semble que lorsque les gars du back-end parlent de technique, les gars de l'interface utilisateur sortent, et vice versa. Cela semble être le moyen logique de diviser l'équipe, ne serait-ce que pour gagner du temps, mais j'ai une énorme réserve en ce que tout ce que je peux vraiment faire est de réduire la collaboration et le partage des connaissances. Les deux équipes n'auront tout simplement pas vraiment une bonne idée de ce que le reste de l'équipe construit.

Quelqu'un a-t-il une expérience dans ce domaine?

C'est dommage que les gars de l'interface utilisateur ne se soucient pas des détails du travail complexe du backend. Cela ressemble plus à un sujet de discussion pour une rétrospective. La division de l'équipe en fonction de la discipline créerait un dangereux précédent, combien de temps se passerait-il avant que les gens des exigences commencent à zoner et à ne pas se soucier de ce que les gars de l'interface utilisateur font et demandent leur propre équipe.

J'ai toujours été en faveur des tranches verticales pour mes équipes. L'interface utilisateur devrait écouter ce que les techniciens ont à dire, car ce sont eux qui pourraient aider à rendre leur travail plus facile (Oh, ce widget va vous inciter à le faire, et si nous utilisions ce widget à la place).

Personnellement, je me concentrerais sur la question du zonage des gars de l'interface utilisateur, puis une fois ce dysfonctionnement résolu, je discuterais de la meilleure façon de diviser les équipes. Je n'essaie pas de vilipender les gars de l'interface utilisateur, peut-être que les techniciens pourraient également faire plus pour rendre leurs discussions plus pertinentes pour les gars de l'interface utilisateur.

Comme d'autres l'ont dit, l'équipe devrait être autorisée à s'auto-organiser pour déterminer la nouvelle structure. Les expériences passées m'ont appris que l'auto-organisation ne peut vraiment fonctionner que lorsque tout le monde est concerné par l'équipe, plutôt que par sa propre discipline ou ses intérêts.

À votre santé!

C'est en effet une bonne idée de diviser les parties indépendantes de l'équipe en nouvelles équipes. Dans un projet plus important, il est presque impossible pour les développeurs de bien connaître l'ensemble du projet, de sorte que le fractionnement est toujours présent de manière formelle ou informelle.

Chacune des nouvelles équipes devrait avoir un chef d'équipe / responsable technique, qui possède une solide connaissance de l'étendue de son équipe et qui connaît également le travail des autres équipes.

Après cela, chaque équipe peut avoir des réunions de mêlée distinctes et les chefs des autres équipes peuvent être présents. De cette façon, vous réduirez le nombre de personnes "ennuyées", mais les équipes sauront toujours sur quoi les autres travaillent et pourront collaborer avec succès.

La collaboration devient plus importante si les portées des équipes se croisent ou si une équipe dépend de l'autre. Mais là encore, il n'est pas nécessaire que toute l'équipe soit présente _ le chef d'équipe peut coordonner la collaboration.

Un aspect clé de Scrum est l' auto-organisation .

Je vous suggère de discuter de la question avec l'équipe et de la laisser la résoudre.

Vos préoccupations sont toutes fondées, mais n'oubliez pas qu'en tant que Scrum Master, votre travail consiste à coacher et à faciliter. Demandez-leur donc comment ils vont résoudre ces problèmes. Ils seront propriétaires des solutions et les feront fonctionner.

J'ajouterais: en général, les équipes interfonctionnelles sont la voie à suivre.

Lorsque je divise des équipes, j'essaie toujours de garder à l'esprit qu'une équipe doit être en mesure de fournir de la valeur au client. Dans votre cas, ce serait d'avoir des développeurs backend et frontend dans l'équipe.

1. À quelle distance est le front-end du backend? On pouvait s'y attendre, le fractionnement n'est un bon conseil que si la distance est trop éloignée.

   • Si le backend parle de schéma de base de données, ce n'est pas trop loin . Le front-end et le back-end doivent écouter les discussions sur le schéma de la base de données.

   • Si le backend parle de partitionnement, de caches de mémoire, de latence de disque, etc., c'est un peu trop loin (où le backend se concentre sur la sympathie mécanique et l'optimisation, tandis que le front-end se concentre sur l'esthétique humaine).

2. Existe-t-il une interface de programmation stable et sans ambiguïté entre le front-end et le backend?

   • Par stable et sans ambiguïté, cela signifie que les utilisateurs de cette interface de programmation (les développeurs frontaux) ne seront pas embourbés par les modifications et n'auront pas besoin de lire les murs de texte pour apprendre à l'utiliser correctement.

   • L'équipe backend doit fournir une bonne API et une implémentation fictive dès le début, et seulement après cela, commencer le vrai développement.

   • Cela ne veut pas dire que l'API doit être figée. Ce n'est qu'une atténuation des conséquences de la division d'une équipe en deux.

3. Pourquoi tant d'articles agiles recommandent-ils d'avoir des tranches verticales? Voici quelques informations générales:

   • La plupart des articles agiles recommandent en fait d'éviter le travail backend, du point de vue des coûts.

   • N'oubliez pas non plus qu'une fraction des articles agiles ont un biais implicite envers les startups.

   • Et n'oubliez pas la dure réalité du marketing - la plupart des clients ne paient que pour les frontaux.

   • Le travail d'arrière-plan a tendance à être coûteux et a été lent à payer. Sauf si une entreprise est déjà établie à long terme et génère un profit décent, il est préférable de «sous-traiter» le backend en s'en tenant à la technologie standard et aux bibliothèques open source.

   • La plupart des articles agiles recommandent également d'implémenter le front-end afin qu'il puisse survivre à un commutateur principal. Ce conseil va de pair avec le précédent: si la technologie standard ne répond pas à toutes les exigences, essayez-en une autre.

4. Des pratiques qui peuvent atténuer les mauvaises conséquences de la division d'une équipe

   • Back-end stables
   • API stable
   • Back-end à faible taux de défauts
     • Raison: pour éviter la frustration
     • Comment: tests unitaires
     • Ne signifie pas: performances ou optimisation; il doit juste être fonctionnellement correct.
   • Intégration continue
   • Transparence dans la communication, le progrès et la prise de décision
   • Encourager les discussions informelles entre les deux équipes
   • Encouragez les membres de l'équipe (ceux qui ne se séparent pas) à assister aux réunions de l'autre équipe.
   • Organisez des réunions conjointes occasionnelles et des rétrospectives conjointes
   • Autres activités de consolidation d'équipe

Comme d'autres, je suggérerais certainement d'aller avec des tranches verticales. Celles-ci sont parfois appelées «équipes de fonction». Je recommanderais de lire les avantages / inconvénients sur le site Scaled Agile Framework: http://scaledagileframework.com/scaled-agile-framework/team/features-components/

Au début, lorsque vous vous séparez, votre Product Owner et SDF Master peuvent être en mesure de gérer le Release Backlog pour les deux équipes ainsi que les backlogs individuels pour chaque équipe de fonctionnalités. Cependant, au fur et à mesure de votre croissance, vous devrez probablement implémenter un backlog de fonctionnalités de produit qui sera ensuite alimenté par plusieurs équipes agiles. Une fois que vous aurez évolué à ce niveau, vous aurez probablement besoin d'une équipe distincte gérant le backlog des fonctionnalités, puis apportant les fonctionnalités aux équipes individuelles pour la mise en œuvre. Dans cette structure, vous pouvez avoir quelque chose comme ceci:

1. Équipe Agile 1: SM, PO, équipe interfonctionnelle. A son propre carnet de commandes pour ses histoires.
2. Équipe Agile 2: SM, PO, équipe interfonctionnelle. A son propre carnet de commandes pour ses histoires.
3. Équipe de gestion du programme: chef de produit, gestionnaires de versions, architectes d'entreprise. Possède son propre carnet de commandes d'épopées et de fonctionnalités de niveau supérieur qui seront organisées, analysées, puis transmises aux équipes.

Le site Web de SAFe propose de nombreuses fonctionnalités intéressantes pour organiser de plus grandes équipes, et certaines pourraient vous être utiles lorsque vous passerez à une plus grande échelle d'équipes d'équipes.