Discussion :

[ovh]

Par contre, l'usager que je suis a un peu peur... Pas de tests ? Du coup, il y a une horde de bugs tapis dans le système d'information de ma banque prêts à exploser ? Pire, dans celui de mon hôpital ? De mon centre des impôts ?

Clairement, oui... C'est triste mais c'est ainsi. Et ne surtout pas croire que les grosses sociétés ou les systèmes critiques (typiquement : santé, gouvernement... ) sont à l'abri, c'est malheureusement partout pareil...

Vous avez l'air d'accepter sans sourciller que les applications soient des objets jetables qui moisissent à très court terme, ce qui me parait assez dangereux. Je crois qu'on peut quand même se responsabiliser et agir à notre niveau de développeur : (...)

Accepter non, mais à un moment on ne peut pas tout faire... Même si on essaie d'appliquer des bonnes pratiques, de les inculquer à tout le monde, d'insister auprès du client, il n'y à rien à faire : faire de la qualité, ça prend du temps. Et le client n'en a pas : il veut toujours tout, tout de suite.
Tu as beau argumenter comme tu veux, à un moment ça ne passe plus.
Je suis très loin de tout accepter sans sourciller, je mets souvent le client en garde, mais ça ne suffit pas. Au final, même dans le cas où l'interlocuteur est de bonne volonté, il a la pression d'en haut qui fait que de toute façon, on passera outre les bonnes pratiques. Quand la politique impose des dates, qu'on ajoute/change des personnes dans l'équipe mais qu'on n'alloue pas assez de temps pour former / accompagner, faire de la revue de code, etc. en plus de sa propre production, il est impossible de tout maîtriser et ça finit toujours en code pourri...
Tant que l'aspect technique sera dénigré par les décideurs (il ne faut pas se leurrer, les développeurs sont considérés comme des ouvriers... ), ça ne fonctionnera jamais.

Et on n'a même pas parlé de l'implication du client dans les tests, qui est souvent quasi nulle... Du coup, il n'est pas du tout étonnant d'avoir des applis buggées et des utilisateurs qui râlent et ont une mauvaise image de notre métier.

De plus, pour avoir de bonnes pratiques, outre le temps de dev que ça implique (c'est plus rapide de faire de la merde que de prendre le recul nécessaire à une bonne analyse / refacto quand c'est nécessaire), il faut aussi s'auto-former pour s'améliorer, prendre connaissance des progrès actuels, etc. Et hop de nouveau, quelque chose qui prend du temps, et donc qu'on n'a jamais l'occasion de faire "officiellement". (pensons en rigolant aux formations dans le contexte des SSII... )
Personnellement, j'essaie de faire une vielle techno sur le temps de midi, de faire un peu de dev sur mon temps libre à la maison, pour justement améliorer mes compétences, mais on n'a qu'une vie, et on ne peut pas la consacrer entièrement à ça, même si c'est notre passion...

[rmaker]

Par contre, l'usager que je suis a un peu peur... Pas de tests ? Du coup, il y a une horde de bugs tapis dans le système d'information de ma banque

Oui et non. La situation est ubuesque: on livre vite et mal pour que l'équipe de QA puisse trouver les bugs cachés. Souvent en Inde, la dite équipe de QA n'a pas une vision fine du métier. Normal si on ne prend pas le temps de la former... Toujours est il que les gros bugs les plus évidents sont trouvés par la dite équipe. Les bugs subtils, en revanche... C'est pour nous. Cependant, dans mon cas, comme ça ne touche pas la clientèle dite de détail (les gens comme toi et moi), je dors très bien la nuit tout en sachant que la banque fait de la m... mauvaise qualité.

Mais qu'à cela ne tienne. Qui dit bug dit possibilité de demander du budget l'année prochaine pour fixer les bugs, et donc, passer pour le sauveur (et en faisant oublier qu'on en est la cause).

Vous avez l'air d'accepter sans sourciller que les applications soient des objets jetables qui moisissent à très court terme, ce qui me parait assez dangereux. Je crois qu'on peut quand même se responsabiliser et agir à notre niveau de développeur :

• L'ajout de tests ou le refactoring n'a pas besoin d'être énorme pour être bénéfique. De petites améliorations peu impactantes sur la charge de travail peuvent apporter un gain de qualité non négligeable et faire boule de neige avec le temps.
  
• En tant qu'expert, on n'a pas à se justifier de produire de la qualité. Elle devrait être intrinsèque à notre façon de travailler et bien souvent ça ne se remarquera même pas de l'extérieur (un peu ce que el_slapper expliquait).
  
• Ne pas hésiter à diffuser la connaissance. Plus les bonnes pratiques de développement seront connues, promues, discutées, enseignées, plus on aura de chances de les considérer comme état de l'art et les adopter en début de projet. Par exemple, aujourd'hui un outil de source control et un serveur d'intégration continue sont généralement considérés comme des minimum syndicaux. C'est le sens du progrès que ces exigences augmentent.
  
• C'est normal que les managers défendent "leurs intérêts" en essayant d'imposer des deadlines courtes. A nous de défendre les nôtres, de négocier. Il ne s'agit pas de dire "non" tout court mais de faire une contre-proposition argumentée. Combien osent le faire au lieu de se résigner et dire "je vais essayer" ?

Je ne suis pas d'accord avec toi sur les points 3 et 4. Les deux premiers ok.

Point 3: nous, ça nous permet de vendre du coaching agile qui consiste en gros à écouter les doléances des dévs, rallonger du blé, mettre en place une usine de build, et vaguement quelques tests. Ca fait du blé dans ma boite, et on est contents. MAIS ce n'est pas du tout un minimum syndical! Ce sont des chefs de projet anciens devs qui vont le lancer, mais sur leur temps et sans en parler. En douce. En tous cas chez nous, c'est ça. Tout l'enjeu c'est en fait QUI le dit. Si c'est un gars de la maison, un dev, personne ne l'écoute. Ca devient une lubie de développeur. Si ça vient d'un auditeur extérieur, oar contre, ça prend. Un coach agile notamment. Et quand un directeur de projets, dont la seule compétence est excel et MS project, entend parler de l'agile, il est chaud patate. Ca dure quelques temps. C'est comme ça que ça bouge chez nous. Mais ça n'est que chez nous. Pas de généralité.

Point 4: ça dépend beaucoup de la mission. Et du moment où le manager est sous stress ou pas. Quand il l'est, il ne sait pas être raisonnable. Il veut que ça marche. Point. Et quand une équipe est sous stress parce que son chef l'est, elle revient aux anciens réflexes: pas de test, pas de BDD, rien du tout. Aucune écoute rationnelle ne peut se faire dans la tempête. En revanche, on a une chance sur les périodes de calme, entre deux grosses versions. Là, on peut négocier. Et on peut dire non.

[souviron34]

Je ne suis pas d'accord avec toi sur les points 3 et 4. Les deux premiers ok.

Point 3: nous, ça nous permet de vendre du coaching agile ....

Point 4: ça dépend beaucoup de la mission. Et du moment où le manager est sous stress ou pas. Quand il l'est, il ne sait pas être raisonnable. Il veut que ça marche. Point. Et quand une équipe est sous stress parce que son chef l'est, elle revient aux anciens réflexes: pas de test, pas de BDD, rien du tout. Aucune écoute rationnelle ne peut se faire dans la tempête. En revanche, on a une chance sur les périodes de calme, entre deux grosses versions. Là, on peut négocier. Et on peut dire non.

Je commence à comprendre pourquoi je ne trouve pas de boulot.....

[gangsoleil]

Vous avez l'air d'accepter sans sourciller que les applications soient des objets jetables qui moisissent à très court terme, ce qui me parait assez dangereux.

Non, ce n'est pas plus, ni moins, jetable que le reste. Et ce n'est pas non plus moins moisi, mais pas plus non plus.

[*]L'ajout de tests ou le refactoring n'a pas besoin d'être énorme pour être bénéfique. De petites améliorations peu impactantes sur la charge de travail peuvent apporter un gain de qualité non négligeable et faire boule de neige avec le temps.

Dans le monde des bisounours, ca pourrait peut-etre se passer comme ca. Dans la vraie vie, ce que j'ai vu se passe comme ca :
Un client veut A. Il envoie donc un mail a un commercial pour savoir combien ca coute et quand ca sera pret.
Le commercial planche sur le sujet, avec des gens issus de la technique ou bien avec des technico-commerciaux, et se retrouve avec un projet a 200 jours (dont 65 de dev), qu'il soumet au client ; a 1 000 euro le jour, c'est un projet a 200 000 euro tout de meme.
Le client etait pret a payer 50 000 euro, donc commence une longue negociation avec le commercial sur "non mais pour ca vous n'avez pas besoin de tant de jours", etc...
Et comme le commercial veut vendre son truc, il fait des efforts, et le client aussi : le compromis est trouve a 120 jours, avec un peu moins de fonctionalites que prevu.
SAUF qu'enlever des fonctionalites a hauteur de 75 jours, ca n'enleve pas 75 jours du projet, mais ce point n'est pas pris en compte.
Donc l'equipe de dev se retrouve avec 40 jours de budget (1/3 du total environ, puisqu'il y a 1/3 pour les non-productifs (commerciaux, chefs) et 1/3 pour les tests/docs/qualite/packaging autre), au lieu des 65 prevus.
Bien sur, il y a 3 personnes sur le projet, donc c'est fini dans 2 semaines et demi (40/3 = 13,3 jours exactement, donc mettons 13,5 ). C'est bien connu qu'avec 9 femmes, on fait un bebe en un mois.
Ah, et puis les devs se rendent compte que la fonctionalite qui a ete supprimee, et bien en fait le client la veut, et le commercial lui a promis que si, c'etait faisable, ca ne coute rien a faire, juste un petit truc dans le coin...
Donc, on a actuellement une equipe de 3 personnes qui doivent faire un projet de 40 jours en deux semaines et demi avec des specs pour au moins 50 jours, si ce n'est 60. L'equipe provoque donc une reunion avec le chef, pour dire que vraiment ce n'est pas faisable et tout et tout. Le chef discute avec sa hierarchie et avec le commercial, et on decide de basculer 20 jours des docs/test/qualite sur le dev -- dans le meilleur des cas. Dans le pire des cas, on dit que oui, mais non, c'est faisable, ils n'ont qu'a ce demerder ces dev, ils nous embetent a jamais etre content avec ce qu'on leur donne.
Donc au final, avec un budget de 60 jours, les devs peuvent faire un truc correct (pas plus), qui ne sera que tres partiellement teste et documente, et qui est deja en retard par rapport a ce qu'attendait le client.
Et encore, je suis dans un cas plutot favorable.

Par exemple, aujourd'hui un outil de source control et un serveur d'intégration continue sont généralement considérés comme des minimum syndicaux. C'est le sens du progrès que ces exigences augmentent.

C'est une tres bonne idee, mais non ce n'est pas du tout le minimum syndical ! Il y a enormement d'entreprises, et notamment des grosses, qui n'ont jamais mis ca en place car ca couterait trop cher, et puis les developpeurs ils en veulent toujours plus, et si on leur file pas une machine de test/integration continue, c'est toujours ca d'economiser.
Et puis en fait, si on leur donne pas, ils ralent mais font quand meme le projet, donc c'est pas si grave.

C'est normal que les managers défendent "leurs intérêts" en essayant d'imposer des deadlines courtes. A nous de défendre les nôtres, de négocier. Il ne s'agit pas de dire "non" tout court mais de faire une contre-proposition argumentée. Combien osent le faire au lieu de se résigner et dire "je vais essayer" ?

C'est ce que j'ai vu faire dans chaque projet de chaque entreprise : on te dit "il faut faire ca", tu fais un chiffrage, on te dit que non, tu as moins, tu negocies, et au final comme c'est la hierarchie qui a raison (N+1 ou +2, commerciaux, ...), tu as moins que ce dont tu as besoin, et c'est tout.

[ManusDei]

Vous avez l'air d'accepter sans sourciller que les applications soient des objets jetables qui moisissent à très court terme, ce qui me parait assez dangereux.

Accepter ? Non. mais la décision n'est pas de notre ressort.
Et si tu payes de nèfles, tu récupères des glands, c'est tout.

[el_slapper]

Accepter ? Non. mais la décision n'est pas de notre ressort.
Et si tu payes de nèfles, tu récupères des glands, c'est tout.

Mouarf, j'aime beaucoup. Je connaissais "si tu payes des cacahuètes, les gens travailleront comme des singes".

Un autre problème est l'hyper-découpage des taches à certains endroits. Je viens de passer(et la réponse sera probablement négative, j'ai fait une connerie à l'entretien) un entretien pour une mission à faire de la "conception technique générale". Y'a un gugusse qui émet un besoin. Un autre qui crée un cahier des charges. Un autre qui crée des spécification fonctionnelles générales. Un autre qui crée des spécifications fonctionnelles détaillées. Moi, j'aurais conçu l'archi et la conception technique générale. Puis le tout aurait été transféré au centre de service pour que leur spécialiste fasse une conception technique détaillée(avec le nom de chaque paragraphe appelé ou à créer). puis un débutant de chez eux aurait codé......

Je passe sur la suite, je n'ai pas bien compris leur process, et je suis finalement pas trop attristé de savoir qu'ils ne me prendront probablement pas(trop "technique"). Il est impossible de faire du bon travail dans des conditions pareilles. Surtout, quand on a perdu autant de temps à faire autant d'étapes inutiles, il ne reste plus le temps de faire les choses bien.

Et je crois que c'est une question de pouvoir. Si vous avez juste un expert métier qui exprime le besoin, qui communique en permanence avec un expert technique qui le réalise, avec éventuellement un expert en test qui valide ce à quoi les deux autres n'ont pas pensé, alors les chefs n'ont plus aucun pouvoir. Si par contre vous saucissonnez tout ça, certes ça va marcher beaucoup moins bien, ça va couter beaucoup plus cher, mais au moins vous garder le contrôle de vos moutons.

Évidemment, dans ces conditions, la dette technique, tout le monde s'en fout. Enfin, tous ceux qui ont voix au chapitre.

[gangsoleil]

Si vous avez juste un expert métier qui exprime le besoin, qui communique en permanence avec un expert technique qui le réalise, avec éventuellement un expert en test qui valide ce à quoi les deux autres n'ont pas pensé, alors les chefs n'ont plus aucun pouvoir.

Ca porte meme un nom, ca s'appelle diviser pour regner. Les plus courageux d'entre nous se precipiteront (pas trop vite non plus) sur Le prince, de Machiavel, en esperant que tant de verites ne soient pas trop dures a digerer.

[ManusDei]

Un autre problème est l'hyper-découpage des taches à certains endroits. Je viens de passer(et la réponse sera probablement négative, j'ai fait une connerie à l'entretien) un entretien pour une mission à faire de la "conception technique générale". Y'a un gugusse qui émet un besoin. Un autre qui crée un cahier des charges. Un autre qui crée des spécification fonctionnelles générales. Un autre qui crée des spécifications fonctionnelles détaillées.

Je travaille dans un environnement de ce genre, et pour mon cas précis c'est justifié. Parce qu'il faut être extrêmement précis, pour que le gus qui crée les spécifications fonctionnelles détaillées travaille sur le même projet que celui qui émet le besoin .
Il y a pas mal d'aller-retour entre les différents intervenants au début, parce qu'il y a des imprécisions, mais une fois que la doc est prête (et c'est long), ben tu peux tout figer, pas de "ah mais non c'est pas ça que je voulais, je voulais dire ça en fait" à 3 jours de la livraison. Ou si il y a, tu peux répondre au client "C'est pas ce qu'il y a dans la spec, ça coûtera XXXXX€ et YY jours pour le changer. Signez là."

PS : en plus c'est un projet long, on sait déjà que les gens qui sont là au début ne seront plus là à la fin, donc qu'il va falloir assurer sur la doc pour celui qui arrive quelques années après.

[nault]

Les choses commences à bouger un peu où je travail Je me suis beaucoup inspiré de ce thread pour cogité sur l'application de gestion des dettes techniques dans mon équipe.

Juste de manière a faire un récapitulatif concis ;
- Nous étions tanner de coder comme des singes
- De fixer des bugs de nos prédécesseurs et nos propres bugs coder sous pression
- De ne pouvoir coder une feature plus que 2 jours sans avoir des injections de bugs et changer notre focus sans arrêt.

Ce qu'on a du comprendre en tant que développeur:
- On peu pas tout fixer
- Une nouvelle 'feature' a vouloir n'est pas une dette technique.
- Dans certaine circonstance livrer un projet avec des dettes techniques, ca peu arriver et ce n'est pas la fin du mode si cette dette vaut la peine.
- Il faut tout documenter nos dettes.

Quand je dit tout documenter, ça peut paraître simple, mais totalement pas. Premièrement, il faut que toute l'équipe soit motivé, ces bien beau amener une bonne pratique si on est le seul à la suivre, ça sert a rien. Une foi que nous nous somme mis d'accord, nous avons choisi de commencer a documenter seulement les nouvelles dettes techniques au fur et a mesure. Avant de documenter les anciennes, on attend de voir si les nouvelles sont pris déjà au sérieux.

Sinon l'étape de négociation pour les fixer est assez simple, nous les documentons avec des informations utiles comme: description +- technique, risques potentielles, nombres d'heure qu'on pourrait gagner par itération en la fixant. Si notre chargé de projet a des questions on peut rajouter quelques détails.

Ça ne fait pas très longtemps que la documentation des dettes est commencé et peut-être que tout va prendre le champ. Reste que ça la motivé mon équipe et notre chargé de projet est venu nous voir sur quelques points déjà. J'attends la suite...