Dans ton premier donc ce n'est plus ce que tu fais ?
Non je suis allé prendre mon poste d'agrégé au lycée en septembre après avoir épuisé tous les congés possibles mais je ne pense pas y rester très longtemps ... (c'est une autre discussion cependant!)
Une vingtaine je trouve ça énorme par contre,
Oui c'est assez grand mais c'est transitoire: il y a une période de transfert de compétence avec 4-5 nouveaux collègues qui ont commencé dans les tous derniers mois puis un partage de l'équipe en deux. C'est aussi des équipes pluridisciplinaires, quasi des mini-entreprises autonomes dont on parle. Sur tout le projet il y a quelques centaines de personnes qui travaillent, avec deux très gros tiers de développeurs, répartis sur une dizaine de sites, dans quatre pays! La plupart sont dans de groupes entre 8 et 20, mais quand ça monte au dessus de 13 c'est souvent pour préparer une "scission."
Je ne sais pas trop comment on peut annoncer ça.
Ça demande aux parties prenantes de se mettre d'accord sur la façon de travailler, en choisissant des méthodes qui minimisent l'inventaire (développement non livré). Ensuite on avait le confort énorme de travailler en "back office" ce qui fait qu'on a une "feedback loop" très courte, pas comme si on devait faire des enquêtes de satisfaction de l'utilisateur avec une société de communication par exemple, puisqu'on est à quelques mètres des utilisateurs.
Il faut aussi se mettre d'accord sur la façon de mesurer le "time to market." Dans les contextes où j'ai exercé le bon signal de fin semble être "la première fois que la fonction entre en production" même si après il faut remettre son ouvrage sur le métier, c'est normal c'est la nature du logiciel de ne jamais être terminé. Pour une agence de développement qui dit à ses clients "on aura fini dans trois mois" je suppose qu'un point de vue légèrement différent s'impose. Il y a certainement plein d'autres environnements qui vont tirer vers d'autres équilibres.
Les tests d'intégration je trouve ça compliqué.
C'est effectivement ce qui nous demandait le plus de travail. Notre démarche était pre 1. d'avoir un environnement "stage" pour les tests et 2. d'avoir un test d'intégration dès les premières itérations du développement, même s'il s'agit de faire un simple curl sur le "health dashboard" de notre application tier3.
Pour le 1, même si cela semble assez basique il y a toujours des voix pour s'opposer (parceque c'est "cher") mais j'ai toujours pensé que c'était important d'avoir ce genre d'environnement à disposition, notamment pour pouvoir faire du "disaster recovery" et pouvoir garantir à son client qu'on peut recréer toute l'infra en temps fini si besoin.
Pour le 2, même si les premiers tests ne semblent pas spectaculaires ça aide d'avoir un véhicule pour ajouter les nouveaux tests d'intégration au fur et à mesure que l'application s'étoffe. Selon l'avancement du projet et les besoins de l'équipe les tests d'intégration peuvent être sophistiqués ou très basiques, par exemple se concentrer sur une ou deux fonctions cruciales dans le cas favorable (sans trop regarder les conditions d'erreur), et tout de même avoir leur utilité, surtout du côté infra (connectivité réseau, droits d'accès, etc.)
[^] # Re: L'opensource et maven fonctionne très bien
Posté par Michaël (site web personnel) . En réponse au journal log4shell : Et après ?. Évalué à 2.
Non je suis allé prendre mon poste d'agrégé au lycée en septembre après avoir épuisé tous les congés possibles mais je ne pense pas y rester très longtemps ... (c'est une autre discussion cependant!)
Oui c'est assez grand mais c'est transitoire: il y a une période de transfert de compétence avec 4-5 nouveaux collègues qui ont commencé dans les tous derniers mois puis un partage de l'équipe en deux. C'est aussi des équipes pluridisciplinaires, quasi des mini-entreprises autonomes dont on parle. Sur tout le projet il y a quelques centaines de personnes qui travaillent, avec deux très gros tiers de développeurs, répartis sur une dizaine de sites, dans quatre pays! La plupart sont dans de groupes entre 8 et 20, mais quand ça monte au dessus de 13 c'est souvent pour préparer une "scission."
Ça demande aux parties prenantes de se mettre d'accord sur la façon de travailler, en choisissant des méthodes qui minimisent l'inventaire (développement non livré). Ensuite on avait le confort énorme de travailler en "back office" ce qui fait qu'on a une "feedback loop" très courte, pas comme si on devait faire des enquêtes de satisfaction de l'utilisateur avec une société de communication par exemple, puisqu'on est à quelques mètres des utilisateurs.
Il faut aussi se mettre d'accord sur la façon de mesurer le "time to market." Dans les contextes où j'ai exercé le bon signal de fin semble être "la première fois que la fonction entre en production" même si après il faut remettre son ouvrage sur le métier, c'est normal c'est la nature du logiciel de ne jamais être terminé. Pour une agence de développement qui dit à ses clients "on aura fini dans trois mois" je suppose qu'un point de vue légèrement différent s'impose. Il y a certainement plein d'autres environnements qui vont tirer vers d'autres équilibres.
C'est effectivement ce qui nous demandait le plus de travail. Notre démarche était pre 1. d'avoir un environnement "stage" pour les tests et 2. d'avoir un test d'intégration dès les premières itérations du développement, même s'il s'agit de faire un simple curl sur le "health dashboard" de notre application tier3.
Pour le 1, même si cela semble assez basique il y a toujours des voix pour s'opposer (parceque c'est "cher") mais j'ai toujours pensé que c'était important d'avoir ce genre d'environnement à disposition, notamment pour pouvoir faire du "disaster recovery" et pouvoir garantir à son client qu'on peut recréer toute l'infra en temps fini si besoin.
Pour le 2, même si les premiers tests ne semblent pas spectaculaires ça aide d'avoir un véhicule pour ajouter les nouveaux tests d'intégration au fur et à mesure que l'application s'étoffe. Selon l'avancement du projet et les besoins de l'équipe les tests d'intégration peuvent être sophistiqués ou très basiques, par exemple se concentrer sur une ou deux fonctions cruciales dans le cas favorable (sans trop regarder les conditions d'erreur), et tout de même avoir leur utilité, surtout du côté infra (connectivité réseau, droits d'accès, etc.)