Quelle est la meilleure façon de répartir le travail entre les développeurs
Mon équipe et moi reconstruisons un site que nous avons développé il y a une dizaine d'années, et nous voulons le faire en Agile.
Donc, après avoir passé beaucoup de temps à lire (probablement pas assez), j'ai du mal à diviser le travail entre les développeurs.
Je serai plus précis et je dirai que le site est divisé en modules séparés qui n'ont pas beaucoup d'intégration entre eux.
Quelle est la meilleure façon/la plus acceptée de partager le travail entre les développeurs?
- Donner à chaque personne un module différent sur lequel travailler.
- Affectez tous les développeurs au même module et divisez le travail par différentes parties du module (UnitTesting, DAL et Mapping, Logics, UI)
- Affectez tous les développeurs au même module et divisez le travail par différentes logiques (par exemple, chaque développeur est responsable d'une logique spécifique (probablement une méthode dans le BL) et de It's UnitTesting, DAL et Mapping et UI ...
Ou peut-être quelque chose de complètement différent?
Mon équipe a essayé de devenir "agile" pour quelques versions maintenant, mais faire partie d'une grande entreprise n'a pas vraiment facilité les choses. Je ne vais pas prétendre avoir la réponse, mais je peux partager certaines de mes observations.
Diviser les développeurs par module:
- Vous devez être prudent car si les gens travaillent trop isolément, votre équipe ne bénéficie pas du partage croisé des compétences et des connaissances
- Planifier des réunions et des prises de position quotidiennes peut devenir incroyablement ennuyeux pour tout le monde si les gens se concentrent trop sur leurs propres modules et ne voient pas la situation dans son ensemble. Une fois que les gens s'ennuient, ils commencent à vérifier et vous perdez une grande partie des avantages qu'agile apporte à la table
- Vous pourriez vous retrouver avec certains composants très bien écrits, et d'autres composants, eh bien ... pas tellement. Si les gens travaillent isolément, vos seniors ne pourront pas former les juniors.
Tout le monde travaille sur le même module en même temps
- Nous avons essayé cela pour une version, lorsque la direction a décidé d'imposer l'agilité à toute l'équipe et ce sera complètement à leur façon. C'est comme une épave de train absolue. Nous avions une équipe de 9 développeurs livrant en un an ce qui aurait normalement été fait par 1 développeur. (J'exagère peut-être ici mais pas beaucoup).
- Personne n'avait l'impression qu'il y avait de la place pour respirer. Ceux qui ne se souciaient pas des logiciels se sentaient comme chez eux car faisant partie d'un plus grand pack, ils se diluaient simplement dans le groupe. Ceux d'entre nous qui étaient passionnés par les logiciels se sentaient absolument étouffés car il n'y avait pas de liberté de se déplacer ou d'aller au-delà des limites sur lesquelles 9 personnes étaient d'accord.
- Toutes les réunions se sont éternisées au point que je voulais me tirer dessus. Trop de personnes ayant une opinion dans la même pièce ont été forcées de travailler sur la même DLL bizarre. L'horreur.
- Dans la dernière version, nous avons décidé d'essayer quelque chose de différent
- Tout d'abord, divisez le groupe de développement en équipes plus petites de 3-4 développeurs. Chaque équipe a travaillé dans un isolement relatif, mais au sein de l'équipe, les gens ont travaillé de manière beaucoup plus cohérente
- Avec cette approche, les positions debout sont rapides et la planification des réunions prend 1 à 2 heures par rapport à 4 heures solides.
- Tout le monde se sent engagé parce que chaque équipe ne discute que de ce qui intéresse les développeurs de cette équipe.
- Le responsable technique de chaque équipe discute régulièrement avec d'autres responsables techniques pour s'assurer que le projet global est en bonne voie.
- Au lieu de rendre les gens "propriétaires" d'un module spécifique, nous avons assigné des domaines d'expertise aux gens, donc lorsque nous avons commencé le projet, nous avions l'impression que les gens avaient leur propre module, mais après plusieurs mois, les développeurs commenceraient à se regarder le code comme les zones ont commencé à se chevaucher.
- Les révisions de code sont essentielles. C'était la deuxième version où nous avions une politique stricte de révision de code et tout le monde dans l'équipe les aime. L'expert d'un domaine spécifique est toujours sur une révision de code lorsque quelqu'un d'autre modifie ce code.
- Avec les revues de code, nous avons une tonne de partage de connaissances et vous pouvez voir l'amélioration globale de la qualité du code de nos équipes. De plus, parce que le code est revu si souvent, lorsque les gens se rendent dans le domaine d'expertise de quelqu'un d'autre, il est probable qu'ils aient déjà vu le code au moins quelques fois déjà.
- Une plus grande partie de chaque équipe est aspirée dans les réunions de revue de conception, donc même s'ils n'ont jamais vu le code, tout le monde connaît le flux général de tous les modules dont leur équipe est responsable.
- Nous avons fait cela pendant environ 10 mois et c'est un peu comme si nous avions commencé avec une approche de module isolé et que tout le monde travaillait sur tout. Mais en même temps, personne ne se sent comme à l'étroit ou limité. Et pour nous assurer que les gars ont toujours le sens d'une certaine autorité, nous les avons laissés en tant qu'experts de la région, même si c'est surtout une formalité maintenant.
Nous avons fait cette dernière chose, et bien qu'il y ait une tonne de possibilités d'amélioration, dans l'ensemble, toute notre équipe a été très heureuse et cela en dit long, lorsque nous faisons partie d'une société géante.
Une chose importante sur laquelle nous nous sommes trompés les 3 premières fois que nous sommes "devenus agiles", c'est à chacune de ces fois que les gens ont appris comment travailler et sur quoi travailler. C'est le moyen numéro un pour que votre équipe se désintéresse complètement du projet et que vous ayez alors de vrais ennuis.
Essayez plutôt le contraire. Dites à l'équipe qu'elle peut faire ce qu'elle veut et en tant que manager/leader (si vous en êtes un, sinon faites répéter ces mots à votre manager), votre travail est de vous assurer qu'ils sont aussi productifs et heureux que possible. Le processus n'est pas une mauvaise chose, mais le processus devrait être là pour aider votre équipe lorsqu'elle se rend compte qu'elle en a besoin, et non l'inverse.
Si certains membres de votre équipe préfèrent travailler de manière isolée, laissez-les (dans une certaine mesure). S'ils préfèrent travailler par deux, laissez-les faire. Assurez-vous de laisser vos employés choisir leur propre travail autant que possible.
Enfin, et cela est très important et est toujours négligé. VOUS N'OBTENEZ PAS CE DROIT (à moins que vous ne soyez un surhomme ou au moins un batman). Il est extrêmement important d'avoir des réunions rétrospectives régulières. Lorsque nous avons déployé les rétrospectives, elles ont été réalisées par le livre et c'était comme un autre processus que vous deviez traverser. Ce n'est pas à cela que sert la rétrospective. C'est pour écouter votre équipe, identifier les zones qui causent le plus de douleur et les corriger afin que chacun puisse continuer son travail. Apparemment, les ingénieurs logiciels, en général, aiment fournir des produits et des fonctionnalités et la plus importante réunion rétrospective de messages doit communiquer, c'est que c'est uniquement pour leur bénéfice. Vous voulez identifier et surmonter les obstacles, en commençant par les plus grands (ou les plus faciles, il y a une sorte de carte 2D impliquée) et les éliminer afin que vos employés fassent leur travail.
Ayez une réunion avec l'équipe, montrez-leur la liste des choses à faire et demandez qui veut faire quoi.
Ne pensez pas dans les modules. Pensez aux éléments de fonctionnalité. Décrivez ces éléments de fonctionnalité par des user stories (ou d'une autre manière) et n'oubliez pas de décrire les critères d'acceptation (probablement définis par votre application actuelle et les changements attendus par l'entreprise). Mettez vos éléments fonctionnels en retard. Ensuite, laissez l'entreprise prioriser les fonctionnalités qui doivent être fournies en premier (vous travaillerez de manière incrémentielle et itérative et la priorité vous dira ce qui doit être mis en œuvre en premier).
Une fois que vous l'avez au moins pour une partie de votre application d'origine, vous êtes prêt pour le développement. Ce qui se passe ensuite dépend de votre méthodologie agile sélectionnée. La partie importante est que chaque fonctionnalité peut généralement être divisée en plusieurs tâches et les membres de l'équipe sélectionneront les tâches qu'ils souhaitent effectuer - c'est ce que l'on appelle l'auto-organisation. Lorsque vous commencez avec agile, l'auto-organisation peut avoir besoin d'aide pour que quelqu'un s'assure que les tâches impopulaires et populaires sont également partagées par l'équipe. Une fois que l'équipe est plus mature, les développeurs n'hésiteront pas à exprimer leur désaccord avec l'auto-organisation actuelle et cela sera géré automatiquement au sein de l'équipe.
Penser aux modules dès le départ ne doit pas être une bonne façon. Vous réécrivez l'application pour une raison quelconque et peut-être que l'architecture actuelle de l'application basée sur une séparation incorrecte des modules est l'une des raisons cachées des problèmes visibles. Vous pouvez également constater que certaines fonctionnalités des modules existants seront complètement redéfinies et déplacées ailleurs.
Bien que je sois d'accord avec la réponse de David, je pensais qu'elle pourrait bénéficier d'une élaboration:
- Agile signifie que vous ne prenez pas ces décisions et ne les poussez pas dans l'équipe. Il n'y a pas de chef de projet/chef de file comme ça. Seulement l'équipe.
- Ceux qui connaissent le mieux la répartition du travail sont les membres de l'équipe eux-mêmes.
- Discutez de votre backlog et découvrez ce que vous voulez réaliser dans la prochaine itération/sprint.
- Utilisez la planification du poker ou des méthodes similaires pour vous faire une idée de la quantité de travail que vous allez diviser de toute façon, puis commencez à diviser les lots de travaux réels ensemble.
Fondamentalement, le résultat est le suivant: personne ici sur SE ne peut répondre à cette question pour vous, et il n'y a pas grand-chose à y faire, car il vaut beaucoup mieux que vous trouviez une réponse en équipe.
L'approche la plus simple est souvent la meilleure.
J'éviterais de diviser les tâches en groupes tels que testing/log/UI/etc à moins que vous ne puissiez définir de très bonnes raisons claires pour le faire. Mon raisonnement est que lorsque vous autorisez les programmeurs à travailler en dehors de leurs domaines d'expertise habituels, cela peut garder les choses plus intéressantes et stimulantes pour eux, et leur permettre de se développer et de grandir dans leur domaine. Si vous pensez que les contraintes de temps vous obligent à diviser le travail en fonction de l'expertise, assurez-vous au minimum que chaque développeur doit toujours effectuer ses propres tests unitaires et utiliser la révision du code et les tests d'acceptation pour détecter les problèmes. Écrire vos propres tests est très agile, et attendre que les testeurs soient disponibles peut être très inutile.
Face à ce même genre de dilemme, j'ai utilisé l'approche suivante:
Étendez le projet. Donnez-vous une idée de ce dans quoi vous vous embarquez et développez une liste de fonctionnalités en décomposant le projet en une série de tâches.
Prioriser les fonctionnalités. Décidez quelles fonctionnalités doivent être terminées tôt et lesquelles apporteront une valeur immédiate à vos clients. Ne vous inquiétez pas si vos développeurs finissent par travailler sur les mêmes modules, mais assurez-vous que vous disposez d'un bon processus et d'outils pour gérer les fusions de code.
Impliquez votre équipe et demandez à vos développeurs de vous aider à décomposer les fonctionnalités en une liste de tâches plus faciles à gérer. Passez en revue en groupe et ajustez les tâches au besoin afin qu'elles puissent être estimées plus facilement.
Demandez à chaque développeur de choisir une tâche à implémenter - ou un groupe de tâches en fonction de la façon dont vos itérations vont s'exécuter - en haut de la file d'attente prioritaire, sur laquelle le développeur aimerait travailler.
Demandez à chaque développeur de travailler sur une seule chose jusqu'à ce qu'il soit terminé avant de passer à la sélection de l'élément suivant en haut de la file d'attente prioritaire. Vous pourriez être tenté de faire changer occasionnellement les tâches de votre personnel, mais cela entraînera une perte de temps pour le développeur. Si vous vous trouvez avec des goulots d'étranglement de dépendance, vous devrez ajuster vos priorités de tâche et minimiser le gaspillage.
N'ayez pas peur que les développeurs s'exécutent avec des itérations qui se chevauchent et gérez vos versions en conséquence. Cela permettra de réduire le temps perdu entre les versions en attente de fin des tâches.
En fin de compte, être Agile, c'est trouver une solution qui fonctionne bien pour votre équipe, votre entreprise et vos clients. C'est à vous de régler votre processus en trouvant l'équilibre des pratiques qui vous convient le mieux. La répartition de vos tâches sera une partie très importante d'un processus beaucoup plus vaste, mais devrait être aussi simple que possible pour encourager la participation volontaire et éviter les problèmes difficiles à résoudre liés au processus qui se développent plus tard.
Aucune discussion organisationnelle de l'équipe de développeurs ne serait complète sans mentionner le Dr Fred Brooks équipe chirurgicale.
La formule de base est: ne équipe chirurgicale par unité de travail
Définition d'une équipe chirurgicale
Le concept de l'équipe chirurgicale repose sur deux idées fondamentales:
- Moins de développeurs sont meilleurs par unité de travail car diaphonie tue la productivité.
- Les développeurs à haut rendement surpassent les développeurs à faible rendement (et selon Brooks, il n'y a pas de développeur à rendement moyen), il vaut donc mieux leur donner le travail le plus important à faire et limiter leurs distractions.
Une équipe chirurgicale est composée de 3 à 10 développeurs:
- n programmeur en chef. Un développeur à haut rendement, qui fait la plupart de la programmation réelle.
- n copilote. Un autre développeur à haut rendement, qui fait de la programmation, mais aussi des tâches administratives, comme assister aux réunions et recueillir les exigences.
- 1 à 8 assistants. Brooks les décrit comme des développeurs responsables de choses comme la documentation, le nettoyage du code, la recherche, les outils/algorithmes d'écriture, les tests, etc. Dans les années 60, Brooks proposait exactement 8 rôles, mais avec des fonctionnalités modernes outils dont vous pourriez avoir besoin d'à peine 1 ou 2, et qui devraient probablement être attribués en fonction des besoins de votre projet.
Définition d'une unité d'oeuvre
Alors maintenant que nous pouvons constituer une équipe, que leur assignons-nous?
- Si le projet est très petit, c'est facile. Vous affectez une équipe chirurgicale à l'ensemble du projet.
- Sinon, alors vous aurez besoin de commencer par une personne ou une équipe qui est en charge de l'ensemble du projet architecture. Il leur appartiendra de modulariser le logiciel de manière appropriée afin que le travail puisse être réparti entre des sous-équipes supplémentaires. L'équipe d'architecture peut également assumer d'autres tâches, afin de ne pas étaler les développeurs trop mince.
Vous devriez voir émerger trois modèles de base acceptables:
- Exactement 1 sous-équipe pour chaque couche (UI, DAL, etc.)
- Exactement 1 sous-équipe pour chaque module (page d'accueil, site d'assistance, boutique)
- Un mélange des deux (une équipe de cadre de bas niveau et une équipe axée sur l'interface utilisateur pour chaque module)
En fonction du nombre de développeurs et de modules (et des délais), je demande généralement à mes développeurs de choisir un module intéressant (pour eux) et un module difficile (de préférence quelque chose qu'ils n'ont pas fait), puis le reste, je le divise par niveau de compétence et contraintes de temps. Je trouve que cela donne à mes développeurs quelque chose sur lequel ils veulent travailler et quelque chose pour les pousser.
Bien sûr, cela ne fonctionne pas toujours ...
Voici ce que je ferais:
Si tous les modules sont petits, vous pouvez donner à chacun un module sur lequel travailler. Sinon, procédez comme suit:
- Définissez la taille, la complexité et les compétences requises pour le faire.
- Définissez les compétences de chaque membre de l'équipe.
- Définissez les personnes qui travaillent bien ensemble et celles qui ne fonctionnent pas bien avec les autres.
- Affectez de grands modules à des équipes de personnes qui travaillent bien ensemble en fonction des exigences de compétences des modules et des compétences d'équipe.
- Attribuez les modules restants aux personnes qui ne peuvent pas bien travailler avec d'autres personnes en fonction des exigences de compétences du module et des compétences de l'équipe.
Ce qui précède ne fonctionnera pas si les personnes qui n'aiment pas travailler avec les autres sont les plus compétentes et c'est un cas courant, alors faites une exception aux 4 et 5 en conséquence