Agence logicielle · Ingénierie
Intégration d'un développeur sur un projet client
Menez vite un développeur qui rejoint un projet en cours jusqu'à sa première modification fusionnée, sans perdre des jours en accès et en installation. Le client approuve le nouveau membre de l'équipe et donne les accès via un lien public, et le travail de sprint reste verrouillé jusqu'à ce que le responsable technique confirme que le développeur est prêt.
- Durée: 1 à 2 semaines
- Fréquence: Chaque fois qu'un développeur rejoint un projet
- Étapes: 9 étapes
- Agents IA: 1 agent IA
- Approbations: 1 approbation
Plan gratuit, sans carte de crédit.
Ce que ce modèle change
Sans le modèle
Le nouveau développeur attend des jours ses accès côté client.
Le guide d'installation est dépassé, et chaque nouvel arrivant y perd une journée.
L'intégration se résume à un appel et un lien vers le dépôt.
Le client découvre un nouveau membre de l'équipe lors d'une démo de sprint.
Avec le modèle
Le client approuve et donne les accès via un seul lien, avant la date d'arrivée.
Chaque développeur note les lacunes, et le guide est mis à jour avant sa validation.
Un parrain fait visiter le code au développeur et relit sa première modification.
Le client approuve chaque nouveau développeur avant qu'il obtienne des accès.
Le modèle, étape par étape
Chaque étape indique qui la réalise : une personne de votre équipe, un agent IA ou le client via un lien public. Une approbation garde toutes les étapes suivantes verrouillées jusqu'à ce qu'elle soit donnée.
- Réalisé par votre équipe
- Réalisé par un agent IA
- Réalisé par le client, via un lien public
Démarre quand
Un développeur rejoint un projet client en cours, nouvelle recrue ou venu d'un autre projet. Le chef de projet lance une exécution avec le nom du développeur et sa date d'arrivée.
- 1
Annoncer le développeur et partager le lien client
Avant le jour 1Chef de projet · Équipe
Écrivez au client qui arrive, à partir de quand, dans quel rôle et avec quelle adresse e-mail, et envoyez le lien public pour son accord et les accès qu'il doit donner.
Checklist
- Le contrat autorise le changement dans l'équipe
- Accord de confidentialité signé par le développeur
- Lien public envoyé au client
Champs à remplir
- Nom du développeur (obligatoire)
- E-mail du développeur (obligatoire)
- Date d'arrivée sur le projet (obligatoire)
- 2
Le client approuve le développeur et donne les accès
Avant le jour 1Contact client · Lien public
Via le lien public, le client approuve le nouveau membre de l'équipe et donne l'accès à ses systèmes, ou note ce qui doit se passer avant, comme sa propre formation à la sécurité.
Checklist
- Accès au dépôt de code donné
- Accès à l'environnement de préproduction donné
- Comptes client ou VPN configurés
Champs à remplir
- Accord (obligatoire)
- Conditions avant l'accès
- 3
Configurer les accès et l'environnement local
Jours 1 à 2Développeur · Équipe
Acceptez chaque invitation, installez le projet en local avec le guide d'installation et notez où le guide était faux ou incomplet. S'il manque un accès, marquez l'exécution comme bloquée et notez lequel.
Checklist
- L'app tourne en local
- Les tests tournent en local
- La préproduction et l'outil de suivi des tickets fonctionnent
Champs à remplir
- Lacunes du guide d'installation
- 4
Faire visiter le code
Jours 2 à 3Parrain technique · Équipe
Présentez au développeur l'architecture, les principaux parcours, le déploiement et les conventions de l'équipe, ainsi que les contacts et les rendez-vous réguliers du client.
Checklist
- Architecture et principaux parcours expliqués
- Règles de branches, de relecture et de versions expliquées
- Contacts et rendez-vous du client présentés
Champs à remplir
- Sujets à revoir
- 5
Livrer une première petite modification
Jours 3 à 5Développeur · Équipe
Choisissez un petit ticket avec le parrain, développez-le avec des tests et ouvrez une pull request.
Checklist
- Ticket convenu avec le parrain
- Tests ajoutés
- Pull request ouverte
Champs à remplir
- Lien vers la pull request (obligatoire)
- 6
Relire ensemble la première modification
Masqué sur le lien publicJours 4 à 5Parrain technique · Équipe
Relisez la pull request avec le développeur, expliquez vos remarques et fusionnez-la quand elle respecte les standards de l'équipe.
Checklist
- Relue avec le développeur
- Remarques expliquées
- Fusionnée
Champs à remplir
- Sur quoi se concentrer ensuite
- 7
Vérifier la préparation
Masqué sur le lien publicJour 5Vérificateur de préparation · Agent IA
Le vérificateur de préparation compare les checklists et les champs de chaque étape précédente à la liste d'intégration de ses instructions, liste ce qui reste ouvert et rédige un court résumé de préparation.
Champs à remplir
- Points ouverts
- Résumé de préparation (obligatoire)
Contrôle humain: Le responsable technique règle les points ouverts et confirme la préparation à l'étape 8.
- 8
Confirmer que le développeur est prêt
Masqué sur le lien publicJour 5Responsable technique · Équipe
Lisez le résumé de préparation, réglez ou planifiez les points ouverts et confirmez que le développeur peut prendre du travail de sprint.
Checklist
- Points ouverts réglés ou planifiés
- Guide d'installation mis à jour avec les lacunes trouvées
Approbation: Le travail de sprint reste verrouillé jusqu'à ce que le responsable technique confirme que le développeur est prêt.
- 9
Ajouter le développeur au sprint et prévenir le client
Semaine 2Chef de projet · Équipe
Ajoutez le développeur au prochain sprint et à la liste d'équipe du projet, et prévenez le client que l'intégration est terminée.
Checklist
- Ajouté au planning du sprint
- Ajouté à la liste d'équipe
- Client prévenu
Champs à remplir
- Début du premier sprint (obligatoire)
Terminé quand
Le développeur a des accès qui fonctionnent, connaît le code et a une première modification relue et fusionnée, et le client sait qui a rejoint l'équipe.
Adaptez-le. Renommez les étapes, changez les responsables et ajoutez des points de checklist, des champs ou des approbations. Le modèle est un point de départ pour la façon de travailler de votre équipe.
Les agents IA de ce modèle
Un agent ne travaille que sur ses propres étapes, et une personne de votre équipe vérifie ce qu'il a fait. Tout ce qu'un agent écrit dans une application connectée attend une approbation, sauf si vous l'autorisez.
Vérificateur de préparation
Vérifie ce qui reste ouvert dans l'intégration et résume où en est le développeur.
Ce qu'il fait
- Lit les checklists et les champs de chaque étape précédente
- Les compare à la liste d'intégration de ses instructions
- Liste les points ouverts et rédige un court résumé de préparation
- Termine son étape pour que le responsable technique puisse relire
Contrôle humain: Le responsable technique règle les points ouverts et confirme la préparation à l'étape 8.
Les questions auxquelles ce modèle répond
Obtenez d'abord l'accord et les accès du client, puis un environnement local qui fonctionne, une visite du code et une petite première modification. Ce modèle suit cet ordre, de l'accord du client à l'étape 2 jusqu'à la vérification du responsable technique à l'étape 8.
Visez une petite modification relue dès la première semaine, pour faire apparaître tôt les problèmes d'environnement et les lacunes de compréhension. À l'étape 5, le développeur livre une première petite modification avec des tests, et à l'étape 6 le parrain technique la relit avec lui.
Dites au client qui arrive et à partir de quand, et laissez-le approuver avant d'ouvrir le moindre accès. À l'étape 2, le client approuve le nouveau membre de l'équipe et donne les accès via le lien public, ou note d'abord ses conditions.
Faites-le suivre à la lettre par chaque nouveau développeur et notez où il était faux. À l'étape 3, le développeur note les lacunes du guide d'installation, et à l'étape 8 le responsable technique vérifie que le guide a été mis à jour.
Laissez l'IA vérifier ce qui reste ouvert dans l'intégration et le résumer, et gardez la décision pour le responsable technique. À l'étape 7, le vérificateur de préparation liste les points ouverts et rédige un résumé, et l'étape 8 est un contrôle d'approbation où le responsable technique confirme que le développeur est prêt.
Donnez à chaque changement la même intégration, avec un parrain et une vérification de préparation, plutôt qu'un rapide appel de passation. Aux étapes 4 à 6, le parrain technique fait visiter le code au développeur et relit sa première modification, et l'exécution montre ce qui a été couvert.
Exécutez ce workflow dans OKiDO
Configurez les étapes, les responsables et les approbations une fois, puis lancez une exécution pour chaque nouveau cas.