Discussion :

[kilroyFR]

C'est venu a plusieurs reprises de nos developpeurs dans ma boite.
Ils s'assoient sur le fonctionnel, passent leur journées a faire des POC et essayer la derniere techno a la mode ou par exemple, on leur demande un type d'interface et eux t'en implémentent 4-5 (formats divers et variés xml/json/ftp/ws etc.).
Au final tu leur dis que c'est bien ce qui a ete fait mais ca n'a pas ete vendu ni budgeté (donc le client prendra mais n'en sera pas reconnaissant pour autant); pour finalement prendre du retard et nous planter avec un truc ni fait ni a faire (mais codé dans l'etat de l'art).
C'est facile a reperer chez nous, generalement ils ne lisent les specs et les interprete a leur façon sans jamais s'interroger si l'interpretation est correcte. Aucune remarque, SUM pas de soucis et le jour de la livraison tu vois qu'ils ont volontairement viré des trucs qu'ils jugaient inutiles ou pas a eu de les faire -> revision des specs pour s'aligner sur ce qu'ils ont bien voulu faire.
Bref le monde a l'envers.
Chez nous l'agilité ca a plutot renfermé les devs dans leur monde sur leurs plateaux et a se generer du taf et ne communiquant sans grande transparence (on decouvre les choses realisées mais non demandées trop tard).
Generalement ils sont en prestations donc terminent leur mission et nous laissent avec le tas de code.
Tous ne sont pas comme ca heureusement il y en a qui s'interesse au fonctionnel ou en tout cas qui se limitent a ce qu'on a vendu (le plus s'il est techniquement interessant n'a aucun interet car ce sont des depenses supplementaires que le client final ne paiera pas de toutes facons) mais ce n'est pas la majorité.

[sirthie]

C'est venu a plusieurs reprises de nos developpeurs dans ma boite.
Ils s'assoient sur le fonctionnel, passent leur journées a faire des POC et essayer la derniere techno a la mode ou par exemple, on leur demande un type d'interface et eux t'en implémentent 4-5 (formats divers et variés xml/json/ftp/ws etc.).
Au final tu leur dis que c'est bien ce qui a ete fait mais ca n'a pas ete vendu ni budgeté (donc le client prendra mais n'en sera pas reconnaissant pour autant); pour finalement prendre du retard et nous planter avec un truc ni fait ni a faire (mais codé dans l'etat de l'art).
C'est facile a reperer chez nous, generalement ils ne lisent les specs et les interprete a leur façon sans jamais s'interroger si l'interpretation est correcte. Aucune remarque, SUM pas de soucis et le jour de la livraison tu vois qu'ils ont volontairement viré des trucs qu'ils jugaient inutiles ou pas a eu de les faire -> revision des specs pour s'aligner sur ce qu'ils ont bien voulu faire.
Bref le monde a l'envers.
Chez nous l'agilité ca a plutot renfermé les devs dans leur monde sur leurs plateaux et a se generer du taf et ne communiquant sans grande transparence (on decouvre les choses realisées mais non demandées trop tard).
Generalement ils sont en prestations donc terminent leur mission et nous laissent avec le tas de code.
Tous ne sont pas comme ca heureusement il y en a qui s'interesse au fonctionnel ou en tout cas qui se limitent a ce qu'on a vendu (le plus s'il est techniquement interessant n'a aucun interet car ce sont des depenses supplementaires que le client final ne paiera pas de toutes facons) mais ce n'est pas la majorité.

Si, comme tu le dis, le comportement de divas de vos développeurs est récurrent, faut-il dès lors leur en attribuer l'entière responsabilité ? N'y a-t-il pas des mesures correctives qui ont été prises afin d'éviter ce phénomène, par exemple en motivant davantage les devs, en donnant davantage de sens à leur travail (délais réalistes), en leur permettant d'exercer leur créativité hors des projets de la boite, etc. et en instaurant une meilleure supervision de leur travail ?

Voir ici : Soin et alimentation des ingénieurs informatique (ou pourquoi les ingénieurs sont grincheux)

Parce que, bon, si tu te plains que les gens font n'importe quoi sur les routes mais que tu ne crées pas de code de la route, de signalisation, de police, etc. Gouverner, c'est prévoir, et tout ça...

A moins que de telles mesures aient été prises et que ça n'ait pas marché ?

[LeBressaud]

Si, comme tu le dis, le comportement de divas de vos développeurs est récurrent, faut-il dès lors leur en attribuer l'entière responsabilité ? N'y a-t-il pas des mesures correctives qui ont été prises afin d'éviter ce phénomène, par exemple en motivant davantage les devs, en donnant davantage de sens à leur travail (délais réalistes), en leur permettant d'exercer leur créativité hors des projets de la boite, etc. et en instaurant une meilleure supervision de leur travail ?

En les engueulant ?

[sebastiano]

Quels sont selon vous les facteurs d'échec les plus importants d'un projet IT ?

- Client qui croit savoir ce qu'il veut et qui passe à côté de l'essentiel ;
- Manquement au devoir de conseil du prestataire (et ça induit toute la chaîne, du DP au Dev en passant par le CP, le commercial etc.) ;
- Développeurs qui comprennent mal le besoin par manque de visibilité globale du projet ;
- Service commercial qui fait passer des choses en douce et/ou sans savoir l'impact sur le projet en cours ;
- Client qui change d'avis en plein projet (et je ne parle pas de modifier une fonctionnalité mais d'un impact sur tout un pan du logiciel) ;
- Méconnaissance du métier du client par le prestataire ;
- Méconnaissance du métier informatique par le client.

[kilroyFR]

Si, comme tu le dis, le comportement de divas de vos développeurs est récurrent, faut-il dès lors leur en attribuer l'entière responsabilité ? N'y a-t-il pas des mesures correctives qui ont été prises afin d'éviter ce phénomène, par exemple en motivant davantage les devs, en donnant davantage de sens à leur travail (délais réalistes), en leur permettant d'exercer leur créativité hors des projets de la boite, etc. et en instaurant une meilleure supervision de leur travail ?

Parce que, bon, si tu te plains que les gens font n'importe quoi sur les routes mais que tu ne crées pas de code de la route, de signalisation, de police, etc. Gouverner, c'est prévoir, et tout ça...

A moins que de telles mesures aient été prises et que ça n'ait pas marché ?

Ben ils sont payés tres correctement, des conditions de travail plus que correctes, ce ne sont pas des enfants non plus mais des ingenieurs, on ne va pas les materner ni leur acheter des bonbons quand ils ont bien fait leur boulot. Alors oui on n'a pas de salle "Pokemon" avec des doudous grandeur nature comme ca existe dans quelques boites.
A la base ils sont la pour produire quelque chose pour gagner des projets et les mener dans les budgets/delais attendus.
Donc en 2018, il faudrait attribuer des gratifications aux gens parce qu'ils ont fait le boulot pour lequel ils etaient payés ?
Les gratification c'est pour l'exceptionnel qui sort du cadre d'un projet mais là en l'occurence ce n'est pas la cas puisqu'on doit renegocier les specifications avec nos clients (qui ne sont pas chiants heureusement) pour rattraper le coup. On a eu le cas d'un contrat avec une boite americaine et là ce qui etait ecrit dans les specs devait exactement etre realisé (normal non ?); donc pas possible de renegocier les specs parce qu'un dev avait decidé d'implementer a sa façon ou ajouté des outils non demandés (en l'occurrence archi ELK avec tout ce que ca sous entend comme infra derriere).

La meilleure preuve qu'ils ont assez de budgets c'est qu'on leur fait confiance et qu'on n'est pas derriere leur dos en permanence. S'ils arrivent a faire des choses en plus (non demandées), c'est qu'a la base ils ont assez de budget pour faire ce qui a ete vendu.
On a des ateliers coding dojo, etc. on les incite meme a faire du dev et proposer des choses pour la boite. J'ai moi meme realisé plusieurs dev pour client et interne (hors de mes heures de travail) et posé 2 brevets + touchées les primes associées (1500 euros) versées par ma boite. Tout le monde peut le faire. Tres tres peu le font en pratique; je pense qu'ils sont dans leur confort.
Quand au code de la route, des gens leur ecrivent les specs, discutent avec eux de la mise en musique, se font payer tous les outils qu'ils demandent; bref on a vu pire comme cadre de travail.

PS : je suis chez un grand compte t non pas une SSII, donc la "pression" des clients est toute relative.

Moralité, plus on en donne et plus ils en prennent.
Oui on a partiellement trouvé une solution (fonctionne depuis 4 ans) a ce probleme car c'etait recurrent et couteux sur les derniers projets.
On est passé en archi SOA micro services et du coup on met le paquet sur une poignée de dev experiementés qui fabriquent des modeles (templates) ou qui s'occupent des sujets les plus complexes. Les autres devs sont sous traités a l'etranger (ile maurice = francophones) et font du dev a base de template - donc effectivement pas besoin d'un ingé BAC+5 avec experience. Donc pas de risque qu'ils reinventent la roue carrée. Plus facile a intégrer et tester egalement. Oui c'est une uberisation du metier de dev mais c'est la seule reponse qui marche face a ce genre de comportement.
Certains de nos devps se sont rendus compte qu'ils n'etaient pas aussi essentiels que ca et un petit nombre en a profité pour changer de fonction (car le dev bete ne les interessait plus). Bref mon constat est que l'on aurait pu rester sur le mode de fonctionnement traditionnel mais qu'ils se sont tirés une balle dans le pied tout seuls en se croyant indispensables. Oui personne n'est indispensable et les devs n'y echappent pas.

PS : je suis passé architecte il y a quelques années car je sentais le vent tourner pour faire juste de la programmation et avec l'avenement des archis SOA micros services. Le focus n'est plus sur la technique mais l'archi. N'importe quel dev meme de niveau tres moyen peut suffire dans ces archis (il ne touche pas les composants les plus sensibles et complexes).

[Grogro]

PS : je suis passé architecte il y a quelques années car je sentais le vent tourner pour faire juste de la programmation et avec l'avenement des archis SOA micros services. Le focus n'est plus sur la technique mais l'archi. N'importe quel dev meme de niveau tres moyen peut suffire dans ces archis (il ne touche pas les composants les plus sensibles et complexes).

J'entends ton discours et je comprends tes problématiques. Ce sont des éléments que j'ai moi-même constaté dans mon contexte professionnel (je ne suis plus développeur). Mais qui est responsable ? L'oeuf ou la poule ? T'es tu demandé pourquoi une organisation humaine plus ou moins cloisonnée génère ce genre de comportements ? Connais-tu le principe de Conway ?

[kilroyFR]

J'entends ton discours et je comprends tes problématiques. Ce sont des éléments que j'ai moi-même constaté dans mon contexte professionnel (je ne suis plus développeur). Mais qui est responsable ? L'oeuf ou la poule ? T'es tu demandé pourquoi une organisation humaine plus ou moins cloisonnée génère ce genre de comportements ? Connais-tu le principe de Conway ?

Oui je connais ce principe mais ne me sent pas concerné; on fonctionne en agile depuis 6 ans minimum + plateaux + SUM + coding dojo + etc. donc on a une organisation qui pousse au maximum d'echanges entre les gens mais concernant les devs on n'est pas derriere eux a les surveiller. Et sur des livraisons mensuelles ou plus on decouvre des choses trop tard et on nous met devant le fait accompli (c'etait pas grand chose, j'ai fais meme si c'etait pas demandé). Tout ca cumulé + sans compter que les sprints se decalent (mais pas en donnat les vraies raisons mais mettre a dos des pbs d'infra etc. et autre ayant causée des pertes de temps d'ou decalage sur prochain sprint etc). Oui suivre a la culotte est certainement la meilleure solution mais c'est irrealisable. Donc le plus ismple c'est d'avoir des devs dociles qui executent betement ce qu'on leur donne avec les contraintes de delais.
Notre problème ca a ete surtout de faire confiance; maintenant on est certes passé dans l'exces inverse cad que nos devs sont desormais relegués a de simples executants/ouvriers en "col blanc" (notre bureau d'etudes est d'ailleurs devenu une "usine de production logiciel" comme on l'appelle dans notre organisation).

[pmithrandir]

***

A vous lire, je pense qu'on peut détecter plusieurs facteurs qui explique ces tensions.

- Les spec sont définie à l'avance : je ne vois pas comment on peut travailler en agile. Le principe de base reste la construction en itération courte pour progressivement se rapprocher de la solution cible. Et c'est bien le PO qui dit ce qui peut être fait. Les dev ont par exemple 10 US a faire sur un sprint, et on peut facilement mesurer le taux de succés et les challenger dessus. Les taches techniques comme construire un cluster ELK doivent faire partie des stories.
- Il y a un manque criant de communication, donc vous manquez de personnes avec ce genre de soft skill pour améliorer vos interfaces entre les équipes.
- Votre scrum master ne fait ni son boulot d'amélioration continue, ni son boulot d'evengelisateur agile.

Après, je vous rejoins sur l'inutilité d'un bac+5 pour faire du dev. La plupart du temps un bac +3 suffirait largement et genererait moins de frustration.

Mais 6 ans avec un modèle aussi bizarre, je suis impressionné. Il y a surement aussi une très grosse difficulté à la remise en cause, et une transparence totalement inexistante dans l'équipe.

[kilroyFR]

A vous lire, je pense qu'on peut détecter plusieurs facteurs qui explique ces tensions.

- Les spec sont définie à l'avance : je ne vois pas comment on peut travailler en agile. Le principe de base reste la construction en itération courte pour progressivement se rapprocher de la solution cible. Et c'est bien le PO qui dit ce qui peut être fait. Les dev ont par exemple 10 US a faire sur un sprint, et on peut facilement mesurer le taux de succés et les challenger dessus. Les taches techniques comme construire un cluster ELK doivent faire partie des stories.
- Il y a un manque criant de communication, donc vous manquez de personnes avec ce genre de soft skill pour améliorer vos interfaces entre les équipes.
- Votre scrum master ne fait ni son boulot d'amélioration continue, ni son boulot d'evengelisateur agile.

Après, je vous rejoins sur l'inutilité d'un bac+5 pour faire du dev. La plupart du temps un bac +3 suffirait largement et genererait moins de frustration.

Mais 6 ans avec un modèle aussi bizarre, je suis impressionné. Il y a surement aussi une très grosse difficulté à la remise en cause, et une transparence totalement inexistante dans l'équipe.

Oui mais forcement il existe un point de depart du fonctionnel attendu a minima; on ne part pas d'un cahier des charges (feuille blanche) que l'on construit au fur et a mesure. Le fonctionnel evolue a chaque iteration (ajout/abandon de fonctions dans un certain perimetre). Le PO definit le cadre de maniere macroscopique et pas dans les details.
Le cas de l'ELK n'etait pas demandé sur dernier projet, ca a ete réalisé par un dev de l'equipe (c'etait simple a mettre en oeuvre) donc ne coutait rien. Il a juste oublié que le mettre en place ca n'impactait pas juste le developpeur mais jusqu'a mise en prod+exploitation. Un detail ou plutot une vision reduite de ce qu'il fait a son simple perimetre de developpeur.

Oui nos scrum masters font souvent de la veille technos egalement et essaient de placer leurs travaux dans les projets (c'est aussi une façon pour eux de se faire mousser). Les devs ne refusent pas de jouer avec de nouveaux jouets donc se laissent influencer facilement quitte a prendre des initiatives pas forcement souhaitées.

On est conscient qu'on n'est pas dans une demarche d'agilité pure et dure mais nous ne sommes pas convaincus non plus de laisser les rennes a des devs; c'est la derive assurée.

[sirthie]

Donc en 2018, il faudrait attribuer des gratifications aux gens parce qu'ils ont fait le boulot pour lequel ils etaient payés ?

Je n'ai jamais parlé d'attribuer des gratifications aux devs parce qu'ils avaient fait leur boulot, j'ai parlé de les motiver davantage, de donner plus de sens à leur travail (en les impliquant davantage dans la conception du projet) et de mieux superviser leur travail. Je ne vois pas où tu vois des gratifications là-dedans.

[kilroyFR]

Je n'ai jamais parlé d'attribuer des gratifications aux devs parce qu'ils avaient fait leur boulot, j'ai parlé de les motiver davantage, de donner plus de sens à leur travail (en les impliquant davantage dans la conception du projet) et de mieux superviser leur travail. Je ne vois pas où tu vois des gratifications là-dedans.

Ok effectivement je croyais que faisais allusion a une gratification supplementaire.
Comme deja dit, ils disposent de tout (outillage, environnement), participation active au fonctionnel/technique, deplacements etc.
Le constat etant que pour la plupart seule la technique les interesse (et essaye ensuite d'y trouver une justification en deformant le besoin fonctionnel pour justifier l'utilisation des choix technos ou archi - bref ce n'est plus la technologie qui subvient aux besoins fonctionnels mais le contraire).
C'est par ce genre de comportement repeté x nb projets qu'on a decidé de reduire leur tache a du travail bete puisqu'ils n'apportaient pas de reponses a nos demandes mais essayaient de deformer notre demande pour placer leurs envies (et ca derivait sur chaque plateau, donc multiplication des sujets, egarements inutiles etc).
Tout n'etait pas mauvais pour autant mais dans la grande majorité c'etait du superflu (invendable de plus car non exprimé par client).
Voila. Notre gestion de projet est plus directive mais elle a l'avantage d'etre canalisée. Moins de surprises. On a pu baisser la pretentions des devs; eux s'y retrouvent nous aussi et on livre ce qu'on a vendu, sans chichis. Moins de devs, plus d'executants et un pole technique d'architectes (service innovation) tres reduit qui envisagent des evolutions avec l'idee de la continuité du produit (evolutivité en douceur, migration, validation des innovations et intégration dans archi en cours, support au marketing pour proposition solution innovante etc).
Bref on s'eparpille moins, on maitrise plus facilement et les sujets sensibles sont ultra localisés. Enfin ca marche depuis 6 ans comme ca et on ne s'en plaint pas; ca marche (pourvu que ca dure).

[Grogro]

Oui mais forcement il existe un point de depart du fonctionnel attendu a minima; on ne part pas d'un cahier des charges (feuille blanche) que l'on construit au fur et a mesure. Le fonctionnel evolue a chaque iteration (ajout/abandon de fonctions dans un certain perimetre). Le PO definit le cadre de maniere macroscopique et pas dans les details.
Le cas de l'ELK n'etait pas demandé sur dernier projet, ca a ete réalisé par un dev de l'equipe (c'etait simple a mettre en oeuvre) donc ne coutait rien. Il a juste oublié que le mettre en place ca n'impactait pas juste le developpeur mais jusqu'a mise en prod+exploitation. Un detail ou plutot une vision reduite de ce qu'il fait a son simple perimetre de developpeur.

On en revient à la même problématique : vos développeurs travaillent dans un silo métier qui s'il n'est plus isolé, demeure fermé. Comme nous dans nos entreprises comme 99% d'entre nous je pense. Et encore, est-ce que vos devs sont intégrés aux équipes métiers, ou est-ce que l'équipe devs et les équipes métiers sont supposés collaborer ? Vos devs travaillent également indépendamment de l'infra et de la maintenance. D'où l'exemple de la stack ELK qui est un cauchemar pour votre équipe infra.
Et résultat des courses, comme la confiance réciproque entre les devs et le top management a été perdue, vous en venez à les considérer comme de simples exécutants à qui vous interdisez toute initiative.

Tu connais l'approche devops ?

Quel est votre métier au fait ?

[Cyrilange]

Les 2 problèmes majeurs que je rencontre :

1- Le cahier des charge est incomplet, change en cours de développement et manque de précisions.
2- Le client veut reproduire ce qu'il faisait sur papier dans le monde du numérique. Du coup, le logiciel lui complique plus la vie que ça ne lui simplifie.

Le client refuse souvent de changer sa méthode de travail et continue de penser "papier" au lieu de penser "numérique". Il constate trop tard que le logiciel va lui compliquer la vie car il était plus rapide avec son stylo et son papier qu'avec un clavier et un écran. Il n'y a rien de plus difficile que de changer les habitudes des utilisateurs et c'est pour moi le plus grand obstacle au développement d'un logiciel répondant au besoin du client. Heureusement, cela disparaîtra lorsque les vieux dirigeant prendront leur retraite. Enfin j'espère...

[kilroyFR]

Tu connais l'approche devops ?

Quel est votre métier au fait ?

Oui mais tout laisser dans les mains des devs jusqu'a la livraison/deploiement sur site ca n'est pas imaginable. On ne fait pas des logiciels pour nous mais pour des clients. A ce jour aucun de nos clients ne nous permettrait de faire du deploiement automatisé sur une PROD toutes les semaines. L'acces aux infras est strictement reglementé. On a des lots planifiés tous les mois avec du fonctionnel attendu.
Ceux qui font de la maintenance sont egalement sur plateau dédié toutes affaires. Generalement ils sont passés par l'etape de dev donc sont aguerris.
Ils sont sur meme infra que les autres. Nous ne pouvons acceder aux infras des clients que via VPN et lorsque le client decide de nous autoriser un deploiement sinon impensable de prendre le risque de mettre le wild dans des archis de prod (meme si en micro services, les dependances entre composants/api sont reelles, donc on ne met jamais a jour qu'une simple DLL comme on le lit dans la litterature). On a plus de 100 microservices fonctionnels.
DevOps ca va bien quand tu deploies des logiciels interne a ta boite (comme le font amazon, les grands comptes pour des applis internes etc). La partie deploiement n'est automatisée chez nous que pour nos tests (mais jamais vers les infras de PROD). Contractuellement interdiction d'acces en direct de maniere automatisé chez nos clients.

Je suis architecte (dans un petit groupe d'architectes - je suis de formation ecole d'ingenieurs EPITA a la base) dont la fonction principale est la conception/realisation de templates de logiciels (histoire que nos applis suivent toutes les memes regles, meme look, memes composants communs etc), de developpement de composants de haut niveau vus comme des boites noires pour les devs.
Donc on anticipe leurs besoins en connaissant le fonctionnel attendu, les technos en place ou celles retenues pour le projet (lorsque le client a des exigences particulieres imposées). Ils ne font principalement que de l'assemblage. C'est ce que permet l'informatique en 2018 avec une liberté qu'on n'avait pas avant.

Les problématiques complexes restent de notre domaine (ex: JAMAIS on ne va les laisser faire des deploiements en PROD directement, l'ajout de nouvelles technos ou modification de l'archi reste de notre perimetre; ce doit etre transparent pour eux).

On ne fonctionnait pas comme ca il y a 6 ans. On est toujours par plateau mais on a beaucoup moins de surprises a la fin. Celui qui sort du cadre se fait rappeler a l'ordre. Tyrannique d'une certaine façon mais pour une partie des devs qui ne sont pas des creatifs et qui ont besoin de guides ou tout simplement toujours le besoin qu'on leur tienne la main c'est ideal; ils deroulent. On a principalement besoin de bras. Le metier s'est uberisé, comme les autres. Le dev est a la portee de quiconque desormais. J'ai moi meme dans mon entourage des gens developpant (certes a leur niveau) des applications android sans qu'ils n'aient pour autant eu la formation adequate. L'autoformation pour des gens motivés et la richesse des supports disponibles permet a quiconque, motivé, curieux d'etre developpeurs aujourd'hui. Les bonnes pratiques arrivent comme dans tout metier en pratiquant et en suivant des templates.
C'est cette optique qu'on a retenue. Nos devs sont en offshore mais francophone. Ils sont aussi bons que pas mal de gens que j'ai pu rencontré dans ma carriere. Ils n'ont pas a rougir, loin de là.
Ils ne font pas de choses compliquées mais plutot des choses dont le périmetre technique/fonctionnel est ciblé. On ne cherche plus a les interesser totalement au fonctionnel. On fonctionne en micro services donc le perimetre fonctionnel est ultra bete. La complexité intrinseque a ces archis ils n'en ont aucune connaissance ni visibilité; c'est notre boulot de le gerer; eux je dirai c'est vulgairement de pisser du code. On a mis en place pas mal de templates pour generation de codes en respectant/implementant les patterns disponibles. Le code genere leur sert de base; ils s'autoforment en meme temps.

Si tu ne cadres pas un dev, naturellement il aura tendance a aller vers la facilité et le plaisir de coder. Il a son temps perso chez lui pour sa. Comme deja dit ils ont moyen de valoriser leur creativité et proposer des choses mais pas dans le cadre des heures de boulot. Il y a des primes etc. et eventuellement la possibilité d'intégrer des composants dans notre framework maison donc une forme de reconnaissance.
De toutes les methodes de dev rencontrées a ce jour, c'est la seule reellement efficace et on le constate au jour le jour. Nous n'avons a ce jour quasiment plsu de mauvaises surprises et les delais/qualités sont respectés. Archi micro services + dev off shore ca fonctionne idealement je dirai.
Voila ce n'est que l'experience dans ma boite mais je sais que pas mal de boites alentours se tournent vers ces archis car elles ont compris l'interet qu'on pouvait en retirer tres rapidement.

[dukoid]

les tests unitaires c'est de la merde.
durant le développement si tu veux refaire les choses parceque tu remarques que tu peux faire mieux , tu te dis: putin de merde, si je veux refaire mon code, faut que je me retape l'écriture de ces tests à la cons de TDD de merde ! alors tant pis, j'abandonne...

par contre, faire les tests à la fin QUE pour des fonctions ou des calculs importants, d'accord !
et vouloir tout tester c'est une aberration, une perte de temps.


les tests fonctionnelles ça c'est important ! j'adhère

[Gluups]

Personnellement, au niveau des grandes entreprises, ce qui est le plus impactant pour les nouvelles ou les modifications d'applications existantes, ce sont les délais demandés par les métiers.

Très souvent ces délais sont ridiculement faibles comparé aux temps de développement. Dernièrement, dans une grande entreprise, le métier m'a expliqué que 90 jours de charges de développement d'un nouveau projet informatique c'était beaucoup trop, ils le voulait fini en moins d'un 1 mois. Leur solution (véridique) : mettre 9 développeurs et c'est fini en 10 jours...

Oh, oui, j'imagine qu'en dix jours il doit être possible de commencer à avoir une certaine appréhension du problème, pour pouvoir se mettre au travail la semaine d'après.
Un développeur aurait appréhendé le problème en deux à cinq jours j'imagine, mais si il faut coordonner neuf personnes, ça prend un délai supplémentaire.

[Gluups]

- Client qui croit savoir ce qu'il veut et qui passe à côté de l'essentiel ;
- Manquement au devoir de conseil du prestataire (et ça induit toute la chaîne, du DP au Dev en passant par le CP, le commercial etc.) ;
- Développeurs qui comprennent mal le besoin par manque de visibilité globale du projet ;
- Service commercial qui fait passer des choses en douce et/ou sans savoir l'impact sur le projet en cours ;
- Client qui change d'avis en plein projet (et je ne parle pas de modifier une fonctionnalité mais d'un impact sur tout un pan du logiciel) ;
- Méconnaissance du métier du client par le prestataire ;
- Méconnaissance du métier informatique par le client.

Oui, j'ai vu faire. Un prestataire qui a de la marge, mais qui par manque de confiance du client finit par ne pas terminer le projet car on lui impose des temps de réunion de cadrage, des tests avec une certaine couleur même en étant prévenu que ça prend trois semaines supplémentaires.

[kilroyFR]

les tests unitaires c'est de la merde.
durant le développement si tu veux refaire les choses parceque tu remarques que tu peux faire mieux , tu te dis: putin de merde, si je veux refaire mon code, faut que je me retape l'écriture de ces tests à la cons de TDD de merde ! alors tant pis, j'abandonne...

par contre, faire les tests à la fin QUE pour des fonctions ou des calculs importants, d'accord !
et vouloir tout tester c'est une aberration, une perte de temps.


les tests fonctionnelles ça c'est important ! j'adhère

Totalement d'accord avec toi la dessus; enfin quelqu'un de pragmatique et non pas dogmatique comme c'est souvent le cas maintenant.
Les tests unitaires ca rassure les devs mais ca ne teste que les choses les plus simples - souvent ceux pour lesquels il n'y a pas beaucoup d'intelligence dans le code.
Les use case complets pour realiser des tests d'integration/fonctionnels sont pour moi ce qu'il y a de plus essentiels (et ce n'est pas une perte de temps).

[pmithrandir]

Ok effectivement je croyais que faisais allusion a une gratification supplementaire.
Comme deja dit, ils disposent de tout (outillage, environnement), participation active au fonctionnel/technique, deplacements etc.
Le constat etant que pour la plupart seule la technique les interesse (et essaye ensuite d'y trouver une justification en deformant le besoin fonctionnel pour justifier l'utilisation des choix technos ou archi - bref ce n'est plus la technologie qui subvient aux besoins fonctionnels mais le contraire).
C'est par ce genre de comportement repeté x nb projets qu'on a decidé de reduire leur tache a du travail bete puisqu'ils n'apportaient pas de reponses a nos demandes mais essayaient de deformer notre demande pour placer leurs envies (et ca derivait sur chaque plateau, donc multiplication des sujets, egarements inutiles etc).
Tout n'etait pas mauvais pour autant mais dans la grande majorité c'etait du superflu (invendable de plus car non exprimé par client).
Voila. Notre gestion de projet est plus directive mais elle a l'avantage d'etre canalisée. Moins de surprises. On a pu baisser la pretentions des devs; eux s'y retrouvent nous aussi et on livre ce qu'on a vendu, sans chichis. Moins de devs, plus d'executants et un pole technique d'architectes (service innovation) tres reduit qui envisagent des evolutions avec l'idee de la continuité du produit (evolutivité en douceur, migration, validation des innovations et intégration dans archi en cours, support au marketing pour proposition solution innovante etc).
Bref on s'eparpille moins, on maitrise plus facilement et les sujets sensibles sont ultra localisés. Enfin ca marche depuis 6 ans comme ca et on ne s'en plaint pas; ca marche (pourvu que ca dure).

Oui mais tout laisser dans les mains des devs jusqu'a la livraison/deploiement sur site ca n'est pas imaginable. On ne fait pas des logiciels pour nous mais pour des clients. A ce jour aucun de nos clients ne nous permettrait de faire du deploiement automatisé sur une PROD toutes les semaines. L'acces aux infras est strictement reglementé. On a des lots planifiés tous les mois avec du fonctionnel attendu.
Ceux qui font de la maintenance sont egalement sur plateau dédié toutes affaires. Generalement ils sont passés par l'etape de dev donc sont aguerris.
Ils sont sur meme infra que les autres. Nous ne pouvons acceder aux infras des clients que via VPN et lorsque le client decide de nous autoriser un deploiement sinon impensable de prendre le risque de mettre le wild dans des archis de prod (meme si en micro services, les dependances entre composants/api sont reelles, donc on ne met jamais a jour qu'une simple DLL comme on le lit dans la litterature). On a plus de 100 microservices fonctionnels.
DevOps ca va bien quand tu deploies des logiciels interne a ta boite (comme le font amazon, les grands comptes pour des applis internes etc). La partie deploiement n'est automatisée chez nous que pour nos tests (mais jamais vers les infras de PROD). Contractuellement interdiction d'acces en direct de maniere automatisé chez nos clients.

Je suis architecte (dans un petit groupe d'architectes - je suis de formation ecole d'ingenieurs EPITA a la base) dont la fonction principale est la conception/realisation de templates de logiciels (histoire que nos applis suivent toutes les memes regles, meme look, memes composants communs etc), de developpement de composants de haut niveau vus comme des boites noires pour les devs.
Donc on anticipe leurs besoins en connaissant le fonctionnel attendu, les technos en place ou celles retenues pour le projet (lorsque le client a des exigences particulieres imposées). Ils ne font principalement que de l'assemblage. C'est ce que permet l'informatique en 2018 avec une liberté qu'on n'avait pas avant.

Les problématiques complexes restent de notre domaine (ex: JAMAIS on ne va les laisser faire des deploiements en PROD directement, l'ajout de nouvelles technos ou modification de l'archi reste de notre perimetre; ce doit etre transparent pour eux).

On ne fonctionnait pas comme ca il y a 6 ans. On est toujours par plateau mais on a beaucoup moins de surprises a la fin. Celui qui sort du cadre se fait rappeler a l'ordre. Tyrannique d'une certaine façon mais pour une partie des devs qui ne sont pas des creatifs et qui ont besoin de guides ou tout simplement toujours le besoin qu'on leur tienne la main c'est ideal; ils deroulent. On a principalement besoin de bras. Le metier s'est uberisé, comme les autres. Le dev est a la portee de quiconque desormais. J'ai moi meme dans mon entourage des gens developpant (certes a leur niveau) des applications android sans qu'ils n'aient pour autant eu la formation adequate. L'autoformation pour des gens motivés et la richesse des supports disponibles permet a quiconque, motivé, curieux d'etre developpeurs aujourd'hui. Les bonnes pratiques arrivent comme dans tout metier en pratiquant et en suivant des templates.
C'est cette optique qu'on a retenue. Nos devs sont en offshore mais francophone. Ils sont aussi bons que pas mal de gens que j'ai pu rencontré dans ma carriere. Ils n'ont pas a rougir, loin de là.
Ils ne font pas de choses compliquées mais plutot des choses dont le périmetre technique/fonctionnel est ciblé. On ne cherche plus a les interesser totalement au fonctionnel. On fonctionne en micro services donc le perimetre fonctionnel est ultra bete. La complexité intrinseque a ces archis ils n'en ont aucune connaissance ni visibilité; c'est notre boulot de le gerer; eux je dirai c'est vulgairement de pisser du code. On a mis en place pas mal de templates pour generation de codes en respectant/implementant les patterns disponibles. Le code genere leur sert de base; ils s'autoforment en meme temps.

Si tu ne cadres pas un dev, naturellement il aura tendance a aller vers la facilité et le plaisir de coder. Il a son temps perso chez lui pour sa. Comme deja dit ils ont moyen de valoriser leur creativité et proposer des choses mais pas dans le cadre des heures de boulot. Il y a des primes etc. et eventuellement la possibilité d'intégrer des composants dans notre framework maison donc une forme de reconnaissance.
De toutes les methodes de dev rencontrées a ce jour, c'est la seule reellement efficace et on le constate au jour le jour. Nous n'avons a ce jour quasiment plsu de mauvaises surprises et les delais/qualités sont respectés. Archi micro services + dev off shore ca fonctionne idealement je dirai.
Voila ce n'est que l'experience dans ma boite mais je sais que pas mal de boites alentours se tournent vers ces archis car elles ont compris l'interet qu'on pouvait en retirer tres rapidement.

Si vous etes intéressé par un feedback, lisez la suite.

Tous vos post reflete un état d'esprit. Je ne sais pourquoi, mais vous donnez l'impression d'etre supérieur aux autres, d'assimiler tous les dev aux même travers.
Ce n'est pas une équipe qui est dénaturée, mais toutes les équipes... De mon coté, j'ai tendance a essayer de trouver lr point commun a ces situations, et ce n'est pas obligatoirement qu'ils sont tous dev...

De mon experience, j'ai toujours rencontré des dev qui voulaient en savoir plus. Même ceux qui pretendaient le contraire creusait le besoin fonctionnel quand on leur en donnait l'occasion.

Oui, ils aiment parfois développer des choses nouvelles, mais souvent c'est parce que :
- leurs suggestions honnetes ne sont jamais acceptées(ce n'est pas une priorité métier)
- on les prend pour de la merde, donc ils construisent leur CV.

En général, ca va de pair avec un turn over important.

Je ne vous connais pas, vous n'aurez peut être rien a faire de mon feedback, mais je vous conseille de faire une introspection forte de votre manière de travailler, de l'image que vous vehiculez, etc... Demandez juste des feedback par exemple tous les 6 mois 2 ou 3 fois de suite. Et réagissez par un plan d'action aux difficultés remontées. Vous serez je pense étonné de la justesse de certains retour, et surement de leur coté généralisé.

Bon courage si vous prenez ce chemin, il va être dur à suivre et difficile à encaisser... mais dans 18 mois je peux vous promettre que vous serez à un tout autre niveau professionnel.

[maritime]

Bonjour,
Je livre mon expérience de vouloir faire le travail sois même.
N’étant pas développeur professionnel j'ai décidé il y a quelques années de développer moi même un programme spécifique.
Il s'agit du domaine de la navigation maritime plus précisément de Astro-navigation, car demander a un programmeur de vous faire un tel logiciel nécessite une présence (professionnellement compétant) pour épauler celui qui écrit le code, reste le test (débogage) qui demande pratiquement autant de temps que l’écriture du code.
Sauf que je ne suis pas encore sorti de l'auberge, c'est pour cela que j'ai utilisé le mot "épauler un programmeur professionnel".
les applications spécifiques sont toujours compliquées et longues a réaliser surtout quand il s'agit de sortir des sentiers battus.