Adaptation de l'agilité pour les équipes à temps partiel

La notion formelle de la méthode de développement logiciel Agile est presque aussi ancienne que moi (le Manifeste Agile). a été publié en février 2001). Je ne signale pas cela pour vous faire sentir vieux mais plutôt pour démontrer qu'Agile a eu beaucoup de temps pour s'infiltrer dans le développement de logiciels. Tandis que la méthodologie préconise des «équipes dédiées co-localisées», dans son omniprésence, Agile est fréquemment appliqué à des équipes partiellement ou totalement composées de travailleurs à temps partiel. Bien qu'il y ait des leçons à tirer de la pratique, Agile doit être adapté pour soutenir les équipes à temps partiel au lieu de les gêner.

Dans cet article, nous envisagerons d'appliquer Agile à une équipe de 5 à 10 personnes travaillant chacune. 20 heures par semaine sur un projet. Nous examinerons en outre l’intersection fréquente du travail à distance avec des équipes à temps partiel et des situations dans lesquelles les contributeurs travaillent à peine 5 heures par semaine sur un projet. Nous entendrons également les professeurs Armando Fox, de l'Université de Californie à Berkeley, et Barbara Johnson, du Grinnell College, qui donneront leur point de vue sur les équipes Agiles à temps partiel.

Pourquoi le travail à temps partiel se produit-il?

développeurs pendant 20 heures ”par exemple peut sembler artificiel, de nombreuses situations mènent au scénario. Vous pouvez avoir:

• Des développeurs affectés à plusieurs clients, projets ou équipes d'une même entreprise,
• Une équipe avec des sous-traitants ou des stagiaires du programme coopératif,
• Des volontaires travaillant sur un projet open source ou communautaire, ou
• Une équipe après les heures de travail travaillant sur une start-up ou un produit

Nous examinerons les nombreux défis liés à la gestion d'équipes sous ces contraintes, mais la solution de rechange plutôt que de travailler à temps partiel avec quelqu'un n'est pas à temps plein. efforts, l’alternative est de ne pas pouvoir travailler avec eux du tout. Bien que les travailleurs et les équipes à temps partiel nécessitent souvent des compromis importants, une gestion claire et efficace peut néanmoins s'avérer très positive pour une équipe et une entreprise.

Tenets Of Agile

Compte tenu de son importance dans l'industrie du développement de logiciels, tout le monde comprend Agile légèrement différemment. Pour pouvoir adapter ensemble le cadre, nous avons besoin d’un vocabulaire commun permettant de définir le «Agile régulier», vous savez, du type qui préconise des «équipes dédiées et co-localisées». Agile met en œuvre des pratiques, des rituels et des rôles pour promouvoir un travail efficace.

Agile, telle que mise en œuvre, implique certaines pratiques:

• Les «sprints» sont des unités de temps discrètes, souvent deux semaines, qui déterminent le cycle de travail des équipes Agile.
• «Histoires» ou «histoires d'utilisateurs» Unités de travail bien définies qu'un seul membre de l'équipe peut effectuer en une fraction du sprint.
• Souvent, les équipes organisent leurs reportages sur des "tableaux kanban" ou des méthodes similaires permettant de suivre leur récit: faire, en cours, en révision.

Agile s’articule autour de quatre rituels:

1. Planification des sprints
   Il s’agit d’une réunion qui ouvre chaque sprint avec des écritures, des estimations, des priorités et des assignations que l’intention de l’équipe compte réaliser. le sprint.
2. Da ily Stand-Up
   Une occasion pour les équipes de se réunir tous les jours pour discuter des progrès de la journée précédente, pour discuter du travail de la journée et dresser d'éventuels obstacles. Idéalement, la réunion est très courte (5-15 minutes) et approche du début de la journée de travail pour réduire au minimum les interruptions du temps de travail dédié.
3. Revue de sprint
   Il s’agit d’une réunion qui se termine chaque sprint avec une revue du travail accompli, des nouveaux postes de travail en retard, des estimations manquées et d'autres quantificateurs des progrès de l'équipe. Fonctionnement qualitatif de l'équipe.

Les équipes agiles ont généralement des rôles distincts et interfonctionnels. Les rôles courants sont les suivants:

• Le «chef de projet / chef d’équipe» gère l’équipe, assigne les tâches, rend compte à la direction, assiste les membres de l’équipe et s’acquitte d’autres tâches de direction.
• Un «propriétaire de produit / gestionnaire de produit» représente le client ou l'utilisateur final pour l'équipe. Ils participent activement à la rédaction d'histoires, à l'examen des fonctionnalités du produit et à la communication des progrès réalisés aux clients et des attentes à l'équipe.
• Un «contributeur individuel» est tout membre de l'équipe dont la responsabilité principale est la création du produit. Les développeurs, les concepteurs, les spécialistes de l’assurance qualité et les rédacteurs sont tous des exemples de contributeurs individuels.

Bien que ces définitions soient importantes pour notre compréhension commune, le thème principal de cet article est qu’atteindre les objectifs de votre équipe est plus important que de mettre en œuvre une «bonne» Agile. Si cela ne correspond pas exactement à votre configuration, des éléments communs vous aideront à appliquer les recommandations futures à votre expérience.

Contraintes du travail à temps partiel

Nous voyons immédiatement comment les contraintes du travail à temps partiel ont été ramenées au standard Agile. Tout d’abord, lors d’un sprint de deux semaines, chaque employé peut passer 2 heures en planification du sprint, 10 fois 15 minutes en stand-up, 1 heure en revue du sprint et 30 minutes en rétrospective du sprint, pour un total de 6 heures Réunions agiles. Pour un employé à temps plein, cela ne représente que 7,5% de ses 15 heures, alors que pour un employé à mi-temps, il passe à 15%. Ajoutez d'autres réunions et tenez compte des changements de contexte et, d'un seul coup, vos contributeurs ont très peu de temps chaque semaine pour contribuer individuellement.

Ainsi, le travail à temps partiel accentue la nécessité d'une bonne estimation de la capacité et d'une planification préalable tout en réduisant le temps nécessaire. disponible pour cela. Heureusement, la notion de points d’histoire d’Agile s’applique bien. Les points de scénario estiment l'effort plutôt que le temps et restent ainsi toujours efficaces entre les travailleurs à temps plein et à temps partiel, bien que les travailleurs à temps partiel mettent plus de temps à atteindre le même nombre de points de scénario, ce que vous pouvez comptabiliser en mesurant les performances de l'équipe. vitesse.

Même si votre équipe de développement est à temps partiel, vos clients peuvent ne pas l'être. Le support client, les corrections de bugs d'urgence, les réparations des pannes et même la communication régulière peuvent s'avérer plus difficiles avec le travail à temps partiel, ce qui augmente les coûts indirects.

Contraintes se recoupant fréquemment

Toutes les équipes à temps partiel ne connaîtront pas ces défis supplémentaires, selon mon expérience à temps partiel le travail chevauche souvent le travail à distance, des fuseaux horaires et des disponibilités différents, et la classification des travailleurs en intérim, contractuels ou stagiaires au lieu d’employés. Ce n'est pas un article sur l'une de ces choses, mais il convient de le mentionner.

Le travail à temps partiel ajoute une charge supplémentaire considérable à la tâche déjà difficile de trouver une heure régulière où tout le monde est disponible pour se rencontrer. Si certains membres de l'équipe travaillent le matin et d'autres le soir ou sont répartis dans le monde entier, la planification devient rapidement impossible. GitLab a publié une documentation exhaustive sur la communication à distance qui pourrait être utile.

Travailler avec des entrepreneurs, des stagiaires, des recrues temporaires ou d'autres équipes non permanentes ou membres d'équipe apporte ses propres avantages et défis. Cela dit, cependant, quelqu'un est arrivé à la table, le cadre Agile le considère comme un membre à part entière de l'équipe et un acteur du projet.

Redéfinir les rituels pour les équipes à temps partiel

Maintenant que nous avons défini les défis de cette partie- le temps créé par le travail, concentrons-nous sur les solutions. Bien que j'ai assisté à de nombreuses modifications apportées aux rituels Agiles pour les équipes à temps partiel, j'ai contacté le professeur Armando Fox, co-auteur de Le logiciel d'ingénierie en tant que service: une approche agile utilisant l'informatique en nuage avec David Patterson. Dans une interview par courrier électronique, il a mis l'accent sur deux objectifs principaux des rituels agiles à conserver:

«La raison pour laquelle Agile convient bien [for part-time teams] est l'idée d'utiliser les récits d'utilisateurs comme unité de travail. La clé de la réussite réside dans la planification initiale et les enregistrements continus. ”

– Armando Fox

La planification de sprint condense la planification initiale à une seule réunion de grande valeur. Pour les équipes à temps partiel, le responsable produit, le scrum master et le chef d’équipe (qui ne peut être qu’une ou deux personnes, puis plus tard) doivent faire le plus de travail possible avant la réunion pour définir des tickets bien définis pour la personne. contributeurs à estimer et à prendre. Fox a déclaré: «Si les histoires sont étroitement circonscrites, les branches sont de courte durée, les histoires nécessitent de petites quantités de code pouvant être livrées avec une bonne couverture de test, et la qualité du code est maintenue grâce à une révision continue du code (demandes d'extraction) ainsi qu'à l'utilisation de Grâce aux outils de mesure de la qualité du code, l'équipe peut réussir à diviser et à conquérir même si elle ne travaille pas toujours au même moment. »C'est certainement un grand nombre d'énoncés« si », travailler de cette manière demandera un effort particulier de toute l'équipe. , mais devrait aboutir à un produit de qualité.

L’autre moitié de l’équation est constituée de vérifications en continu. Les stand-ups quotidiens d’Agile conviennent parfaitement aux équipes à plein temps situées au même endroit. Si tout le monde est au bureau à 9 ou 10 heures, la réunion se déroule plus ou moins naturellement. Il est tentant de remplacer cela par une vérification asynchrone, comme les courriels de rapport de statut, mais Fox recommande aux équipes de s’en tenir au rituel. «L’équipe doit s’enregistrer fréquemment – nous recommandons des stand-ups quotidiens de 5 minutes – afin que tous les drapeaux rouges puissent être repérés plus tôt. Même les équipes à temps partiel peuvent trouver 5 minutes par jour pendant lesquelles toute l'équipe est disponible. Le courrier électronique n’est pas bon pour cela; une réunion interactive, où les gens peuvent également mentionner des éléments bloquants et d'autres qui peuvent immédiatement exprimer leurs suggestions, est le meilleur format ", a-t-il écrit.

Pour une équipe à temps partiel, il peut également être tentant de supprimer les réunions régulières. entièrement et comptez uniquement sur les enregistrements de début et de fin de sprint. Fox avertit que "toutes les équipes entraînées à Berkeley [that he has] ont déclaré avoir vite compris que les réunions d'équipe hebdomadaires étaient loin d'être suffisantes pour que tout le monde reste sur la même page."

Agile. Si les équipes n'évaluent pas régulièrement leurs pratiques de travail et leurs performances, les mauvaises interactions se poursuivront sans contrôle et le mécontentement grandira. Toutefois, les tâches de mesure de la vélocité et de réaffectation de fin de sprint peuvent être gérées par le scrum master en dehors des heures de réunion, et le chef d'équipe peut utiliser des réunions individuelles et leur perception de l'humeur de l'équipe lors de Planification du sprint pour réduire le besoin de révision et de rétrospective de sprint.

Si vous devez absolument réduire le nombre et la durée des réunions Agiles, commencez par réduire les révisions et les rétrospectives. Cela dit, il est important de célébrer les progrès de l’équipe à chaque sprint et de laisser aux gens un espace pour exprimer leurs griefs. Un bon compromis peut consister à étendre le dernier stand-up de chaque sprint pour réaliser cette communication au sein de l'équipe.

Définition des rôles dans une équipe agile à temps partiel

Cette section dépend entièrement de la composition de l'équipe. Cependant, il existe quelques méthodes heuristiques utiles pour l'attribution de rôles. Les responsabilités attribuées devraient minimiser les coûts de communication (qui varient plus profondément que la taille de l’équipe), s’adapter aux capacités de chaque contributeur et prendre en compte les calendriers et la disponibilité des membres de l’équipe.

Pour cette section, j’ai fait appel au professeur Barbara Johnson, qui enseigne un cours de développement logiciel en équipe auquel je suis actuellement inscrit au Grinnell College. Elle a écrit: «J'ai parfois vu des équipes s'appuyer sur ce qu'on pourrait appeler un" organisateur en chef "qui combine les rôles non seulement d'un scrum master (qui organise l'équipe), mais également du responsable du produit (qui coordonne et documente les besoins du client). et commentaires). Cela réduit la charge cognitive du reste de l'équipe, qui peut alors se concentrer davantage sur la progression du code du projet et de la suite de tests avec chaque itération. "Cela correspond à mon expérience avec les équipes à temps partiel.

Si possible, condensez le manager. les postes (chef d’équipe, chef de produit, scrum master) dans un seul rôle et attribuez ce rôle au membre de l’équipe «à plein temps». Si vous avez une équipe de 10 personnes dans laquelle une seule personne est à plein temps ou a une plus grande disponibilité, elle devrait avoir autant de responsabilités d'organisation et de communication que possible. Les équipes à temps partiel nécessitent autant de communication que les équipes à plein temps et un effort logistique encore plus important, ce qui permet de concentrer énormément ce travail sur une seule personne, ce qui réduit considérablement les frais de communication.

Toutefois, cela n'est souvent pas possible, car personne ne l'a déjà fait. disponibilité supplémentaire ou parce que ces personnes sont mieux adaptées aux rôles de contributeurs individuels. Dans ce cas, je préconise toujours de condenser autant que possible les responsabilités de gestion tout en ramenant le propriétaire du produit dans son propre rôle. Dans ce cas, il est important de faire preuve de réalisme lors de l'estimation du travail supplémentaire que ces personnes pourront effectuer sur les user stories, compte tenu de leurs autres tâches pour l'équipe et le client.

La plupart des membres de l'équipe à temps partiel seront membres de l'équipe. contributeurs individuels. Il existe deux philosophies en concurrence pour les contributeurs individuels: les équipes de généralistes et les équipes de spécialistes. Imaginez que votre équipe développe une application Web. Une équipe de généralistes serait composée de développeurs entièrement complets. Ces développeurs ne seraient jamais bloqués sur le travail des autres car, en théorie, ils sont également à l’aise sur tout, de la conception au déploiement. Alternativement, si un concepteur, un ingénieur front-end, un ingénieur back-end et un ingénieur en fiabilité de site forment une équipe, ils seront rapides et efficaces dans leur propre travail car ils ne consacrent que leur temps à la tâche pour laquelle ils sont les meilleurs.

En tant qu'organisateur d'équipe, vous pouvez vous retrouver avec une équipe de généralistes, une équipe de spécialistes ou un mélange. Constituer une équipe d’exécutants solides à temps partiel est déjà assez difficile sans se limiter à un type de contributeur individuel. Heureusement, les deux types apportent quelque chose d’utile à la table. Si vous savez quels sont vos contributeurs généralistes et ceux qui sont spécialistes, vous pouvez attribuer des tâches plus efficacement pour optimiser l'impact de leur temps de travail limité.

Enfin, dans les équipes composées de personnes travaillant dix heures ou moins par semaine, il est tentant d'éliminer complètement les rôles et de simplement dire «fais ce que tu peux». Selon notre thème, ces équipes à temps partiel superflues ont besoin d'une communication encore plus structurée mais ont encore moins de temps pour cela. Si tout le monde a une disponibilité si limitée et si dispersée que vous ne pouvez pas justifier l'attribution de rôles, il vaut probablement la peine de réexaminer la structure, les objectifs et la faisabilité du projet.

Unplash ) ( Grand aperçu )

Communication avec le client

Le développement logiciel est un travail lent, complexe et nécessitant des équipes à temps partiel seulement magnifier cette vérité. Agile inclut le client dans le processus en rédigeant des récits utilisateur, un prototypage rapide, un calendrier de publication rapide et une communication cohérente.

En tant qu'équipe à temps partiel, communiquez-lui des attentes raisonnables. Pour une équipe à mi-temps, rappelez-vous que le temps de développement est réduit de plus de moitié, construisez un tampon supplémentaire en estimations doublées. Le temps de développement étant limité, il est essentiel de solliciter des spécifications complètes et précises lorsque vous rencontrez le client ou les utilisateurs finaux pour éviter de gaspiller vos efforts.

Ne laissez pas le travail à temps partiel vous retarder dans la communication avec le client. Même s'il y a très peu de progrès à signaler, le fait de demander régulièrement des commentaires et d'afficher des mises à jour à une cadence raisonnable augmentera la patience du client face à la lenteur de son développement.

Conclusion: objectifs> Méthodes

Vous pouvez faire beaucoup de choses avec horaire à temps partiel. En dehors du codage, 10 à 20 heures par semaine suffisent pour s’entraîner en vue d’un premier marathon. Avec une équipe solide et de bonnes pratiques de travail, il est temps de lancer un excellent produit sur le marché. Utiliser Agile pour encourager la planification initiale et les enregistrements continus avec des histoires d'utilisateurs, des stand-ups réguliers et des rôles bien définis permettra même aux équipes à temps partiel de surmonter les obstacles à la communication et de travailler efficacement dans le but d'atteindre un objectif commun.

Lecture de SmashingMag:

(dm, yk, il)