Discussion :

[Logan Mauzaize]

Je profite de vos intervention sur ce sujet pour compléter un peu et surtout revenir dans le sujet.

L'Agilité n'est pas une METHODE, ni une METHODOLOGIE, c'est un ETAT D'ESPRIT et une forme d'équipe/gestion, qui, justement, NE DEVRAIT PAS être encadrée....

J'ai envie de dire : "Et alors ?"
Une méthode agile c'est simplement une méthode qui a l'état d'esprit de l'agilité.

Que ce soit UP, RUP, XP, Scrum, ou autre, le "métier" (et la Fance est particulièrement forte sur ce point, à cause de l'importance des titres et des grades) a crée des "normes", mais ce ne sont que des visions "normatives" d'une conduite qui ne l'est pas, bien au contraire...

Je me trompes peut-être mais il me semble que tous les noms que tu cites sont plutôt anglosaxons ?

Tant que les gens qui veulent l'appliquer n'auront pas compris que justement cela implique de ne PAS avoir de norme , il y aura ces visions négatives et ces expériences de b.rdel..

Mettre des mots sur une démarche relativement précise ("Scrum" par exemple) permet de mettre tout le monde d'accord et que chacun se comprenne.
Toujours l'exemple de "Scrum", quand on parle de "Sprint" ou "Backlog" tout le monde comprend ce que cela signifie et implique.

Tu as le même problème avec CMMi qui n'est qu'un amas de principe et dont chacun doit trouver des implémentations/solutions. Dans la vie de tous les jours, la théorie n'a pas beaucoup d'écho et le pragmatisme s'en donne à coeur joie. Dès qu'un gars dit, on fait comme ci-comme ca, on passe vraiment des "ténèbres" à la "lumière" (ou du "chaos" à "l'ordre").
Et comme dans la vie de tous les jours tu n'as pas des gars attitrés à cela et que chacun voit les choses un peu différemment si on peut trouver une sorte de consensus externe, tout le monde se met d'accord plus facilement. Parce que l'idée est externe, que ses auteurs sont "reconnus", qu'ils ont déjà vécus des "exceptions" à la théorie.

Pareil pour le contenu des "sprints". Si on essaye de signer un contrat complet de type forfait à chaque sprint de 2-3 semaines, on passe plus de temps à négocier(et à mentir) qu'à travailler à faire avancer le projet.

Sauf que dans un monde B2B (Business To Business), tout est régi par des contrats ; et donc des négociations/batailles incessantes.

Ajout: D'ailleurs pour ceux qui pratiquent l'agilité comment se passe la facturation ? Quels sont les termes contractuels (délai, coût, pénalité, anomalies) ?

PS : je réponderai tout de même ultérieurement aux dernières interventions.

[souviron34]

...

J'ai repondu de l'autre côté

Ajout: D'ailleurs pour ceux qui pratiquent l'agilité comment se passe la facturation ? Quels sont les termes contractuels (délai, coût, pénalité, anomalies) ?

Suivant les "méthodologies", je ne sais pas.

Moi j'ai toujours fonctionné au forfait.. Mais je n'ai jamais utilisé une des "méthodologies", mais une "approche". Vu que c'était dans de très gros projets (plusieurs millions de lignes), et que souvent c'était en // d'un projet "traditionnel", ou alors un nouveau logiciel complet, le coût était en général sur 6 mois ou un an, du montant de l'équipe (6 à 8 personnes temps plein), à négocier la suite lors de la présentation de l'avancement...

La "pénalité" étant de ne pas avoir de contrat derrière pour terminer/continuer. Mais suivant les cas, j'ai eu de 4 à 16 renouvellements pour terminer...

Disons que le principal était la délimitation du périmètre à accomplir.. A partir du moment où cette délimitation est correctement faite, avec un délia raisonnable, l'équipe étant légère et les retours fréquents, la présentation de l'avancement se fait en ayant une bonne idée et de ce qui manque et de combien de temps/argent il faudrait pour le faire..

PS : je réponderai tout de même ultérieurement aux dernières interventions.

moi aussi, là je n'ai pas eu le temps de reprendre...

[Logan Mauzaize]

Mais le bon commercial va t'emberlificoter, et te faire croire qu'il a la solution à tous tes problèmes. Si tu n'as pas la culture qui va bien, tu n'as pas les moyens de résister. Voir la discussion sur SAP dans la taverne...

Il est vrai que j'oublie un peu le côté belle parole du commerciale. Cependant elles s'effritent rapidement avec le temps. Donc il faut songer à bien négocier l'étalement des paiements, voir paiement à la livraison au prorata des "anomalies"/"limitations".
J'avoue qu'on n'est pas méfiant tant qu'on s'est pas fait entuber ...

Sauf que l'architecture autour augmente de manière plus exponentielle que linéaire. Si j'ai 4 gars qui bossent à vitesse 10, je leur colle un chef de projet et basta. Si j'ai 40 gars qui bossent à vitesse 1, je suis obligé de monter une infrastructure énorme pour gérer les priorités, les affectations, les budgets, je passe mon temps à leur poser des questions, et ils passent leur temps à se coordonner plutôt qu'à bosser. La taille(tant du projet que de l'équipe) est le premier ennemi du développeur informatique.

Quand tu as 40 gars, il est clairement vitale de faire "au moins" 4 sous-projets. Quitte à avoir 4 tech leader à vitesse 3.

"débrouille". Ah ben voilà. Le mot est laché. tu as une équipe de gens compétents, et tu attribues l'excellence de leurs résultats à la qualité de vos process.

Je dirai plutôt qu'on se situe dans ce que j'appelerai la moyenne. Ou en tout cas ce qui devrait l'être à mes yeux. Je dois t'avouer que je trouve de plus en plus la "moyenne réelle" vraiment bas. Cependant je vois plutôt la masse comme "mauvaise" plutôt que notre équipe comme "compétente" ...

Et pour information la "qualité" actuelle n'a qu'un nom, peu de mise en pratique et aucune ambition. Bref on a que le côté paperasse ...

Et quand tu payes les gens au lance-pierres à bosser dans des open-spaces bruyants, et que tu exiges d'eux qu'ils remplissent 50 formulaires inutiles(plus un ou deux utiles, mais on ne les voit plus tellement ils sont perdus dans le flot de paperasse), et que tu leur fournit des outils de travail de l'âge de pierre, non, tu n'auras pas beaucoup de prétendants.

Je pense que c'est plus le nom que les conditions de travail qui attirent les gens vers eux.

C'était une boutade pour illustrer mon point principal(même si j'aimerais bien avoir du LISP sous MVS) : un type doué et créatif va pondre un truc bien plus efficace (et bien moins couteux) qu'un type normal.

Je voulais signaler également qu'il faut tenir compte de que tu as sous la main et que mine de rien cela peut représenter une "petite mine d'or" sans être un génie.

Je me répète : tu as une équipe bien meilleure que ce que tu ne le crois.

Je me répète avoir le minimum (ou le standard), même si c'est rare, ne veut pas dire qu'on est doué. A l'heure de la basse qualité, on prend la "merde" pour le "standard" en oubliant que c'est en-dessous de ce qui devrait être la qualité minimale ; et ensuite, on prend pour de bonne qualité quelque chose qui fait simplement le minimum.

ça, c'est quand on te donne les moyens de bosser. Pour pouvoir voir les fichiers de production, moi qui fait beaucoup de maintenance, je dois demander une autorisation spéciale à mon N+2, et la justifier. Et cette autorisation est limitée à quelques jours.
Plus généralement, c'est bien d'isoler le problème, mais si tu ne peux pas vérifier que tu as correctement isolé le problème, alors tu as un problème. Et c'est mille fois plus facile de faire tourner un coup "pour voir" en intégration qu'en production.

Disons que le principe de "suivis de production" c'est d'avoir accès à la production Le problème c'est le système comme le bancaire où les données sont confidentielles. On peut également avoir des problèmes si la quantité de données est monstrueuse genre quelque giga octets de données à corriger sur plusieurs centaines de tera ...

Dans une banque/assurance mutualiste, il y avait une personne habilitée qui analysait le problème, émettait le "ticket" et construisait un jeu de données fictifs qui reproduisait le problème. Ensuite quelqu'un développait un programme qui corrige les transactions (ou le compte/contrat directement), ensuite la correction était validé sur le jeu de données. Enfin le jeu de données était ajouté dans un pool de données pour créer une répresentation virtuelle de la prod (en gros tous les jeux données sont agglomérés), et ensuite on vérifie que la correction ne modifie que le jeu de données initiales.

La redescente en intégration est souvent un problème car c'est souvent la tâche d'un support niveau 3 mais il faut des autorisations de niveau 2 :S

Jamais vu d'intégrateur. Mais effectivement, ça peut coller.
j'ai souvent vu une étape intermédiaire ou les homologateurs(chez les gens sérieux) ou la MOA(chez les rigolos) passaient d'abord. Mais oui, ça se termine généralement par un lacher d'utilisateurs, d'abord limité, puis massif, sur l'appli. Avec souvent des surprises, négatives(le truc fait tel que demandé qui ne convient pas du tout, joie du cycle en V) comme positives(les gens qui utilisent le bétatest comme si il était définitif tellement il est mieux que la solution précédente, malgré l'absence de fonctions clefs. Vécu récent).

Dans cas les "les homologateurs(chez les gens sérieux) ou la MOA(chez les rigolos)" sont assez proches de la notion d'intégrateur. Mais uniquement à un niveau fonctionnel (UC/données).

La notion de cercle grandissant n'est pas à mons avis un problème des "cycles en V" (par opposition à l'agilité - je m'habitue à ne plus mettre "méthode ;-)) mais de tout déploiement de logiciel. D'ailleurs on peut noter que le modèle agile utilisé chez Google pour le développement de Chrome repose également par une jeu de poupée de russe. (Lien)

"sauf"? Je crois qu'on est d'accord, en fait(avec un vocabulaire différent semble-t-il) : il faut distinguer TU et intégration, dont le périmètre et les outils sont différents. Et oui, à l'intégration, on a déjà des surprises(on en a à chaque étape, en fait).

Ce que je voulais dire c'est que le développeur avec ses tests (uniquement des TU s'il y a une équipe d'intégration) ne teste que son code et rarement quelque chose proche du fonctionnel/réel que ce soit en terme de volumétrie ou alors de cas non-explicités (voir contraire) dans les spécifications (vécu récent aussi).
L'intégration dans ce cas n'est pas l'affaire des développeurs.

Sauf que si c'est faux, l'optimisation, on s'en fout. D'abord, c'est juste, et ensuite, c'est utilisable. Moi aussi je peux optimiser des traitements faux, il suffit de bouchonner la réponse en dur(ne pas rire, j'ai vu des forfaits écrire en dur les réponses au cahier de tests contractuel au lieu de développer la fonction).

Je rigole pas, j'ai vécu ça avec un concurrent qui s'occupait du paramétrage de l'application qu'on développait. Ils ont livré nos données de TU au client

Vécu récemment, un truc était tellement long avec les données réelles que le client n'a même pas cherché à valider les données calculées. Et ça ne prenait que 2-5 minutes...

Moi j'ai toujours fonctionné au forfait.. Mais je n'ai jamais utilisé une des "méthodologies", mais une "approche". Vu que c'était dans de très gros projets (plusieurs millions de lignes), et que souvent c'était en // d'un projet "traditionnel", ou alors un nouveau logiciel complet, le coût était en général sur 6 mois ou un an, du montant de l'équipe (6 à 8 personnes temps plein), à négocier la suite lors de la présentation de l'avancement...

Si je comprends bien tu fonctionnes au temps passé ? Sans réel engagement de résultat ? Pas de réel forfait ?

Si je comprends bien l'agilité, j'essaie de résumer ce qui serait bien :

• Les points d'entrée sont des "tickets"/besoin/demande/etc.
• Le client paye au temps passé/estimé pour chaque "ticket"
• Un ou plusieurs utilisateurs "représentatifs" sont détachés au sein de l'équipe pour prioriser les "tickets", valider les analyses et "recetter" les développements.
• Une petite équipe (au max 8 développeurs) relative autonome (peu de process, peu d'obligation)
• Le tout bien équipé en matériel et outils

Merci de compléter si j'en oublie ou dit trop de sôtises.

Par conséquent, je me pose quelques questions :

1. Ou se situe (en terme de rôle et d'activité) le chef de projet ? le(s) architecte(s) ? le(s) expert(s) technique(s) (eg tech-leader) ? le(s) expert(s) technico-fonctionnel(s) ?
2. Est-ce que le(s) client(s) et/ou les utilisateurs s'impliquent ? Et est-ce qu'ils se sentent impliquer ?
3. Est-ce que cela peut fonctionner sur des gros projets ou des groupes de projet dans lequel des "sous-équipes" doivent se synchroniser ? Et dans ce cas quelle(s) personne(s) s'en assure(nt) ?

Voilà de quoi remettre la discussion sur le fil