Comment nous exécutons des projets agiles en tant qu'équipe distribuée étendue des clients

Un rapport récent de Computereconomics a révélé qu'au cours de la période 2018/19, le processus de développement d'applications est apparu comme celui présentant le plus d'opportunités d'externalisation - avec 56% des organisations dans le monde externalisant leurs besoins de développement.

La raison de cette demande accrue d'externalisation des besoins de développement d'applications mobiles est la même que toujours - un coût inférieur à ce qui devrait être déboursé si l'on employait des développeurs de son propre pays, permettant une plus grande concentration sur l'activité principale et une meilleure qualité de service.

Cependant, même si l'externalisation occupe une place centrale dans l'industrie du développement d'applications, nous avons constaté que les clients manifestent certaines préoccupations communes lorsqu'ils envisagent d'externaliser leur projet de développement logiciel en dehors de leur pays géographique.

Dans cet article, nous examinerons comment Appinventiv travaille avec des clients offshore en utilisant le cycle de développement agile distribué permettant un processus de travail plus connecté avec un modèle de risque et de rémunération aligné sur l'ensemble.

Mais avant de passer à la partie où nous expliquons comment nous fonctionnons en tant qu'équipe distribuée de nos clients et travaillons de manière si transparente que nous devenons leur équipe technique interne étendue, il est important de savoir ce que signifie même une équipe agile distribuée .

Qu'entendons-nous par équipe agile distribuée  

Une équipe distribuée est un concept utilisé pour expliquer l'événement où deux équipes ou plus fonctionnent dans plusieurs emplacements géographiques au lieu d'un espace de bureau ou même de deux espaces de bureau dans une ville.
L'équipe agile distribuée s'appuie sur les technologies numériques pour interagir de manière transparente et travailler ensemble vers le même objectif - la livraison de projet en temps opportun.

Pourquoi les entreprises investissent-elles dans une équipe distribuée de développement d'applications mobiles ?

Il existe un certain nombre de raisons qui poussent les entreprises à investir dans des équipes distribuées, notamment :

1. La rareté des développeurs qualifiés dans leur pays
2. La nécessité de tester le marché avant d'investir dans la constitution d'une équipe
3. Pour bénéficier de l'équipe flexible qui peut être augmentée au moment de la mise à l'échelle de l'application et dissoute lorsque le besoin prend fin.

Avec la définition et le besoin maintenant pris en compte, regardons maintenant comment l'équipe d'Appinventiv fonctionne en tant qu'équipe distribuée de nos clients. Mais avant de sauter là, regardons rapidement à quoi ressemble notre structure d'équipe agile distribuée typique -

Approche inventive du développement agile distribué  

Souvent, nous recevons un projet où l'exigence nous oblige à travailler en étroite relation avec les ETP des clients. Dans de tels cas, il devient très important que nous ne laissions pas la distance en milliers de kilomètres entre les travaux et que nous soyons capables d'apporter des changements et d'agir sur le processus de développement en temps réel.

Comment nous assurons-nous une livraison rapide sans aucun décalage de communication ni malentendu est une question dont la réponse se trouve dans la méthodologie Agile distribuée .

Adapté aux petites et grandes entreprises, suivre les meilleures pratiques agiles distribuées est très pratique lorsque nous devons travailler aux côtés d'une équipe qui se trouve dans un autre lieu géographique avec un fuseau horaire absolument différent.

Examinons la méthode de développement agile distribuée que nous appliquons dans notre processus de développement d'applications mobiles.

Après avoir présenté tous les membres de l'équipe les uns aux autres et avoir collaboré au logiciel de gestion de projet, le travail proprement dit commence.

Nous formulons le processus de la méthodologie scrum agile quotidienne . Alors que dans son sens traditionnel, Scrum nécessite une réunion en face à face de 15 minutes où chaque participant partage l'état de ses tâches et informe l'équipe des tâches qu'il va entreprendre ensuite, il est presque impossible de suivre le même processus lorsque la moitié de l'équipe est assis dans une autre nation géographique dans un autre fuseau horaire.

Ce que nous faisons pour garder vivante l'essence de l'interaction face à face dans la mêlée, c'est que nous organisons un appel vidéo à une heure déterminée, ce qui convient à tous les membres de l'équipe travaillant sur le projet. Avec l'aide du partage d'écran, notre Agile Scrum Master parcourt le backlog de sprint virtuel à l'aide d'outils comme Trello ou Jira, permettant à chaque membre de l'équipe de donner une mise à jour sur la direction du projet.

Ce que nous avons constaté, c'est qu'il est très important de donner à tous les membres de l'équipe un accès à une plateforme de suivi des tâches facilement accessible et actualisable. Nous mettons également l'accent sur l'utilisation d'une plateforme de communication comme Skype ou Slack pour que chacun puisse partager des mises à jour ou poser ses doutes entre les deux périodes de mêlée.

Une autre approche que nous suivons pour le processus agile et scrum quotidien est que pour chaque scrum différent, nous nommons un scrum master. Ainsi, chaque équipe individuelle travaille en tant qu'équipe Scrum distincte avec un scrum master et un propriétaire de produit - un processus également connu sous le nom de Scrum of Scrums.

En cela, tous les représentants de scrum fournissent une réponse aux questions suivantes dans le scrum -

• Le travail que l'équipe a accompli depuis le dernier Scrum of Scrums
• L'équipe de travail prévoit de faire avant la prochaine réunion Scrum of Scrums
• Le bloqueur actuel auquel l'équipe est confrontée
• Le bloqueur qui peut mener à une autre équipe Scrum.

La méthode permet à toutes les personnes principales travaillant sur le projet d'interagir directement les unes avec les autres, ce qui se traduit toujours par un dévouement de la phase d'initiation à la période de lancement. Cela garantit une communication ouverte, claire et transparente entre toutes les équipes, où chacun a la parole.
Le processus en dehors de scrum de scrums est le même que celui que nous suivons dans le cadre de la méthodologie Agile typique.
Mais le simple fait que la distance entre notre équipe et l'équipe de nos clients soit à des kilomètres et que nous devions travailler de la manière la plus transparente possible, a apporté une série d'apprentissages que nous avons entraînés par l'adoption de Distributed Agile. Voyons quels sont ces apprentissages -

Les leçons que nous avons tirées en travaillant sur le processus de développement Agile distribué

1. La création d'une équipe distribuée consiste à créer une culture et non un processus

Ce qui définit le succès d'un projet travaillant dans le cadre de l' approche agile pour les équipes distribuées ne dépend pas de la compétence des membres de l'équipe, mais de leur capacité à travailler ensemble, du sentiment d'appartenance avec lequel ils travaillent et, finalement, de la façon dont ils sont étroitement alignés sur l'objectif du projet - quelque chose qui vient avec la culture et non une formation de processus.

2. Seuls les projets SMART réussissent

Lorsqu'un projet doit être réalisé par une équipe qui n'est même pas dans le même pays et encore moins dans le bureau, il est très important que les objectifs que vous avez fixés pour le projet suivent le SMART - Spécifique, Mesurable, Atteignable, Réaliste et Temporel -encadré, concept au t.

3. Il n'y a pas d'alternative aux outils de collaboration en ligne

Peu importe combien cela vous coûte, vous devrez compter sur des outils de collaboration en ligne qui sont en temps réel et qui ont des décalages minimes à nuls. En matière de finalisation des plateformes de gestion de projet et de communication en ligne, vous ne pouvez en aucun cas couper le mou. Vous devrez vous assurer qu'ils sont techniquement capables de répondre à vos besoins.

Maintenant que nous avons vu les enseignements que nous avons tirés de notre vaste expérience de travail en tant qu'équipe distribuée, il est temps d'examiner certains des défis que nous avons rencontrés au cours du processus et comment nous les avons résolus pour devenir une application agile distribuée de confiance. Société de développement .

Défis de l'approche de développement agile distribué et comment nous les résolvons

1. Différence de culture

Généralement , l'approche de développement logiciel agile et distribuée demande de travailler avec des équipes venant d'horizons culturels différents. Cette différence provoque des frictions en raison de valeurs et de figures de style différentes.
Notre solution : Nous travaillons en étroite collaboration avec l'équipe du client dans les premiers jours afin de nous habituer à leur entre les lignes et les contextes.

2. Une différence de fuseaux horaires

Le cœur de la méthodologie agile distribuée est constitué d'équipes travaillant dans différentes nations géographiques. Dans une situation comme celle-ci, l'apparition d'un fossé de communication émergeant en raison du décalage horaire est très courante.
Notre solution : Nous suivons le concept d'agilité pour une équipe distribuée jusqu'à son noyau. Nous fixons un moment où les équipes de toutes les nations sont présentes et actives. Pour atteindre une concentration et une attention totales, nous demandons à nos coéquipiers de changer leur horaire de bureau le jour de la mêlée, afin qu'ils dorment bien et soient attentifs.

3. Absence d'une idée commune de la « vue d'ensemble »

En raison d'une différence de situation géographique, de structure de travail et de politiques, il peut y avoir une divergence dans l'idée de la vue d'ensemble - l'objectif final de l'application mobile. Cette différence peut entraîner un manque d'intérêt de la part de certains membres de l'équipe et un intérêt accru de la part d'autres.
Notre solution : Une réunion de visionnement au début de l'initiation du projet et un rappel à chaque mêlée, pour que tout le monde travaille vers le même objectif.

4. Une absence de propriété du code

L'absence de propriété collective du code signifie que personne ne possède le code, il appartient à toute l'équipe et donc quand quelque chose ne va pas, le jeu du blâme commence.
Notre solution : Nous appliquons un système de contrôle de version pour vérifier qui travaille sur un code et quand et quel en est l'effet. De cette façon, il y a une transparence et une honnêteté totales dans l'image.

Donc, c'est l'histoire de la façon dont nous, à Appinventiv, sommes devenus une équipe distribuée de clients qui appartiennent partout dans le monde.
Vous souhaitez discuter de la manière d'élever le niveau de votre développement de logiciels agiles distribués ? Contactez nos stratèges d'applications mobiles.