Discussion :

[Serguei_TARASSOV]

Je crois qu'il te manque une notion : les "boucles" sont itératives....

Je crois qu'il te manque un peu de compréhension plutôt.

Waterfall. En recueillant les infos et besoins, on commence par l'analyse et conception. Quelques semaines après les nouveaux besoins sont arrivé. On reviens. Quelques semaines après on reviens encore. Quelque mois plus tard le périmètre semble exact et les besoins semblent non-contradictoires. On y va, le dév ! Et pendant plusieurs mois le client ne voit rien.

Agile. On se base sur les besoins courtes (cas d'utilisation au meilleur) et bien compréhensibles. Petit analyse, l'archi "standard", on y va le dév ! Quelques semaines après les nouveaux besoins de type "breaking chages" sont arrivés. Zut, pas du temps généraliser le modèle fonctionnel (s'il existe bien sur) et l'archi, puisque le jeudi on livre quelque chose. On y va, le dév, refactorisez le code à la volée ! Et pendant plusieurs mois le client voit comme les étages surajoutés sont construit sur le même fondation, et que le coût d'évolution monte de plus en plus.

C'est comme ça les boucles existent sans ou avec des itérations formelles dans la méthodologie.

Le scénario suivant est typique dans l'agile.

A partir des cas d’utilisations les gars généralisent les vaches et les tables car elles ont 4 pattes et puis passent tout le reste du temps en restructuration permanent de son code en utilisant les « patternes », « closures », « interceptors », « aspects » et les instruments du codage super-puissante afin de résoudre de manière « ad hoc » certains contradictions dans le modèle métier.

C'est une blague, mais dans chaque blague il n'y a qu'une partie de blague.

[souviron34]

Tu n'as pas dû approcher de près beaucoup de projets en Waterfall..

Waterfall. En recueillant les infos et besoins, on commence par l'analyse et conception. Quelques semaines après les nouveaux besoins sont arrivé. On reviens. Quelques semaines après on reviens encore. Quelque mois plus tard le périmètre semble exact et les besoins semblent non-contradictoires. On y va, le dév ! Et pendant plusieurs mois le client ne voit rien.

Déjà là tu es mal parti..

• La conception ne se fait qu'une fois l'analyse terminée.
• L'analyse ne se fait qu'une fois les besoins recueillis (via un cahier des charges)
• La conception est découpée en coneption préliminaire et conception détailée
• enfin vient la réalisation
• puis les tests

Le tout est en général > 2 ans (et pas quelques mois), et le client ne voit rien du début à la fin..

Agile. On se base sur les besoins courtes (cas d'utilisation au meilleur) et bien compréhensibles. Petit analyse, l'archi "standard", on y va le dév ! Quelques semaines après les nouveaux besoins sont arrivés. Zut, pas du temps généraliser le modèle fonctionnel (s'il existe bien sur) et l'archi, puisque le jeudi on livre quelque chose. On y va, le dév, refactorisez le code à la volée ! Et pendant plusieurs mois le client voit comme les étages surajoutés sont construit sur le même fondation, et que le coût d'évolution monte de plus en plus.

Là aussi c'est faux.

• L'analyse est la plus complète possible au départ.
• L'architecture doit prendre en compte simplement que l'analyse n'est peut-être pas finale
• La réalisation itou

Qu'il y ait des équipes/projets qui agissent comme tu le décris, c'est sans doute vrai, et c'est très certaibement le cas ET avec RUP ET avec n'importe quelle autre méthodlogie : des "chefs" qui ne savant pas diriger, qui ne savent pas dire non à un patron, il en existe es milliers...

Cela ne rentre cependant pas dans la définiton de ce qu'est une méthode agile..

C'est donc hors du cadre de cette discussion.

Pour info :

http://agilemanifesto.org/iso/fr/

http://fr.wikipedia.org/wiki/Manifeste_agile

Les quatre valeurs fondamentales Agiles sont de valoriser :

• Les individus et leurs interactions plus que les processus et les outils.
• Des logiciels opérationnels plus qu’une documentation exhaustive.
• La collaboration avec les clients plus que la négociation contractuelle.
• L’adaptation au changement plus que le suivi d’un plan.

Résumé de la mise en pratique

Le développement Agile, appelé aussi développement adaptatif, se caractérise donc par un style de conduite de projet itératif incrémental, centré sur l’autonomie des ressources humaines impliquées dans la spécification, la production et la validation d’une application intégrée et testée en continu (Méthode Agile).

C’est à partir de ces réalités pratiques, et non pas sur la base d’une théorie globale ou structurante, que l’Agilité progresse vers les sphères les plus hautes de l’organisation.

Où vois-tu qu'il n'y a pas d'itérations ?
Où vois-tu que l'analyse n'est pas la plus complète possible ?

Comme on le disait avec rad_hass, les erreurs viennent simplement de gens n'ayant pas réellement digéré la philosophie, que ce soir RUP , Scrum, XP, ou n'importe quoi..

Ce n'est absolument pas dans ce qui est sous-tendu par "agile"..

[Serguei_TARASSOV]

Bien sur, j'ai oublié dire, l'agile qui ne va pas ce n'est pas "agile en vrais"
Ensuite, les waterfalls échoues ne sont pas les waterfalls en vrais

L'analyse "la plus complète" (bon définition comme d'hab, quelle est la mesure de plénitude?) n'est possible qu'en cas d'expert métier qui peut donner le modèle/archi fonctionnel. Sinon généralisez les vaches et les tables. C'est le domaine métier qui donne 80% des besoins et pas le client (20% au plus).

[souviron34]

Bien sur, j'ai oublié dire, l'agile qui ne va pas ce n'est pas "agile en vrais"
Ensuite, les waterfalls échoues ne sont pas les waterfalls en vrais

L'analyse "la plus complète" (bon définition comme d'hab, quelle est la mesure de plénitude?) n'est possible qu'en cas d'expert métier qui peut donner le modèle/archi fonctionnel. Sinon généralisez les vaches et les tables. C'est le domaine métier qui donne 80% des besoins et pas le client (20% au plus).

je ne sais pas dans quel domaine tu travailles, d'après ta spécualité je dirais finances..

Mais en tous cas dans les métiers dans lesquels j'ai travaillé (médical, météo, guichtiers de banques ou d'EDF), ce sont bien les "clients" qui définissent les besoins (le seul cas à part à été l'équivalent EDF, et le responsable métier s'est fait corrigé moultes fois par les "clients"..)

Et ce n'est surtout pas à l'expert métier de donner un modèle archi ou fonctionnel...

Bref, tout ceci est totlament en dehors du cadre du thread..


PS: comment détourner des aguments quand on n'en a pas.... Tu ne réponds à rien de ce que j'ai soulevé, alors que j'ai totalement contré tes arguments, tu ne réponds que par une pirouette.

[Serguei_TARASSOV]

je ne sais pas dans quel domaine tu travailles, d'après ta spécualité je dirais finances..

ERP en général. Cela veux dire, l'éditeur doit proposer une solution intégrée pour plusieurs domaines métiers en même temps.
Les hiérarchies construites dans un domaines ne sont pas convenables pour les autres (et contradictoires souvent). Cela veut dire tu ne réussira jamais en partant des cas d'utilisation car tu t'en boucle. D'autre part, les modelés ERP sont pas mal décrites dans les bookins depuis les années 1970. Je pense, il existes les bookins pour les domaines métier que t'a répertorié.

[souviron34]

40 ans seulement que l'on parle de XP et l'agilité ? Plus encore ! Mon grand-père m'a raconté avoir vu leurs backlogs emportés par la grande crue de 1910.

j'avais pas vu ton message...

Non, 40 ans qu'on discute de méthodologies et des up ou down de telle ou telle...

Et que il y a des adaptations (AFNOR 1984 en est une, et ça fait donc pas loin de 30 ans) du Watefall qui précisent "à moduler suivant la taille des projets"... pas forcément tous les documents, pas forcément toutes les étapes, etc etc etc...

Donc oui cela a été formalisé il y a peu, mais comme beaucoup de choses, les idées étaient là depuis bien longtemps..

C'est d'ailleurs pour ça que je dis que "je fais de l'Agile sans méthodlogie", j'en fait depuis 1989...

[Freem]

En fin de compte, si je comprend bien, les méthodes agile et en V, c'est un peu comme le dahut, des légendes?

Enfin, pour être précis, leur utilité est légendaire, mais peu de gens ont effectivement vues ces méthodes en actions, dû au manque de rigueur des chefs?
Je n'ai pas travaillé suffisamment pour avoir une vue d'ensemble, mais c'est ce dont j'ai l'impression (même si mon propos est caricatural... quoique?):
pas d'analyse, on file quelques besoins vite fait, on en filera d'autres plus tard. Le type qui doit dev a beau demander plus de détails, on lui répond qu'il verra plus tard, à charge pour lui d'adapter au mieux ce qu'il a déjà fait.

Si ce constat est général, alors la question de pourquoi l'agilité n'a pas beaucoup pénétré est simple: la méthodologie elle-même n'a pas vraiment pénétré.

Après, pour l'éternel débat agile/V, je dirais juste que lorsqu'un design est fait un minimum proprement, en respectant les design pattern GRASP notamment, il me semble qu'il est assez aisé de pouvoir modifier une faible partie de la conception afin qu'elle colle mieux aux besoins des clients.
Et c'est vrai pour n'importe quelle méthode.

Ce n'est pas la méthode qui rend le dev crade, et les coûts de maintenance prohibitifs: c'est le manque de temps passé sur (ou le bâclage de) cette étape totalement improductive et inutile qu'est la conception d'un logiciel.

Par exemple, la ou je bosse, il n'y à aucun modèle existant. Qu'il s'agisse de la base de données (il y a même des tables dupliquées, dont le nom diffère parce qu'un dev a ajouté la date du jour à la fin) ou des logiciels eux-mêmes.
Il n'y a aucune doc du code.
Qu'ils aient utilisé une méthode agile ou V ou la Rache n'est pas ici le problème. Le problème, c'est l'absence de conception.

Et quand je lis un débat V/Agile/Rache je constate que ceux qui critiquent l'Agile estiment qu'il n'y a pas de conception. Je constate que ceux qui critiquent la V estiment que le client ne voit rien pendant 2 ans.
J'en sais rien, mais de ce que j'ai lu, ces méthodes ne semblent pas interdire ce que leurs opposant leur reprochent... Favoriser peut-être, et encore?

Enfin, je n'ai pas suffisamment d'expérience en entreprise pour juger. Je suis juste déjà tombé plusieurs fois dans le piège de ne pas réfléchir avant d'agir, et j'y fait maintenant attention, quitte a maintenir quelques documents supplémentaires (qui en revanche me font gagner un temps fou quand je dois revenir sur du vieux code).

PS: oui, je sais, la Rache est une pseudo méthode humoristique, je l'ai juste citée pour mettre en exergue que ce n'est peut-être pas la méthodologie choisie le souci, juste l'absence de méthodo.

[pcdwarf]

Faut reconnaitre que la seule méthode de développement que j'ai jamais vu appliquée avec succès est la "Rapid Application Conception & Heuristic Extreme Programming" ou
LA RACHE.

Prenez le temps de lire l'algo, Je ne connais pas un développeur qui n'y reconnaisse pas une situation vécue.

Le papier est tout aussi excellent à lire.

[Drawingrom]

Je suis assez d'accord avec Freem sur la problématique liée à la conception.

On peut voir des projet cycle en V avec une mauvaise conception ou une désynchronisation entre code et spécification dans la durée.

On peut voir des projets en scrum qui partent en vrille car on a tellement peu fait attention à la conception que le code est difficilement modifiable, la vélocité diminue inexorablement, on ne peut plus faire ce qu'on voulait au départ, c'est à dire répondre au changement...

Le concept d'agillité, c'est d'abord des mecs qui se sont fait un week-end à la montagne et qui ont pondu des idées pour que le développement logiciel se débarrasse du paradigme du BTP. Cela c'est fait à partir des écrits / méthodes développés par certains à un moment donné. C'est cette valeur là qu'il faut garder plutôt que penser à faire du Scrum à tout pris.

Dans le développement logiciel, pouvoir répondre au changement sans passer par X mois de murissement, specification, devis devient nécessaire car le marché évolue super rapidement (ce n'est pas rare de voir des gros du web sortir une killer app très régulièrement). Avec un cycle en V, vous êtes aussi obligés de pouvoir changer rapidement des parties de votre applis parce que votre client sera de moins en moins prêt à voir sa facture grossir indéfiniment.

C'est vrai qu'on ne va pas pouvoir facilement détruire et reconstruire un bâtiment. Un bout de code, c'est quand même différent.

Utiliser telle ou telle méthode de gestion de projet, c'est un peu anecdotique. Il faut avant tout de bons développeurs .

[souviron34]

Utiliser telle ou telle méthode de gestion de projet, c'est un peu anecdotique. Il faut avant tout de bons développeurs .

Ce qui est très exactement la première règle du Manifeste Agile (voir mon post #62)

Et ce qui n'est pas du tout intégré par l'écrasante majortié des structures / équipes / CP / etc etc.. (même pour la plupart des soi-disants "devs agiles")..

Je re-citerais ce qu'un Directeur Technique m'a dit : "mon objectif est de faire quelque chose d'extraordinaire avec des gens ordinaires", ce à quoi je lui avais répondu : "Vous n'y arriverez pas. Pour faire quelque chose d'extraordinaire, il faut des gens extraordinaires"..

Et la boîte a coulé

Alors, que ce soit des gens extra-ordinaires en termes d'intelligence, d'organisation, de savoir-faire, ou d'heures de travail, peu importe : il faut l'ensemble.

Mais c'est une très grossière erreur (malheureusement extrêmement répandue) de penser comme ce Directeur Technique.. quelle que soit la méthodologie utilisée..

Et c'est, à mon avis, la principale source d'échecs.. Notre métier est et devrait être considéré comme de l'artisanat d'art. On en est très loin...

[el_slapper]

+1 avec Souviron(comme trop souvent, c'est grave docteur?), mais il me semble qu'un point essentiel a été omis dans ce débat : l'agileté n'est pas une méthodologie, c'est une agileté DANS la méthodologie. en d'autres termes, il est nécéssaire de régulièrement se remettre en question pour améliorer le process. Pour changer la méthodologie.

A ce titre, il m'est arrivé de faire de l'agile dans des projets waterfall : au milieu du gué, on s'aperçoit qu'on ne sait pas valider ce qui sort du nouveau batch, on prend 6 semaines(non planifiées au départ) pour mettre en place un outillage de test complet, on corrige les bugs en masse, et on livre le projet dans les temps.

L'important, ici, n'a pas été la méthodologie choisie(une variante perverse du cycle en V ou le programmeur fait du reverse engineering pour établir la spec, qui est validée et amendée par la MOA, avant de commencer à coder ladite spec, puis de passer le bébé aux homologateurs), mais la capacité des intervenants à la modifier en cours de route(ah zut, on va dans le mur, qu'est-ce qu'on fait?).

Qu'il faille des gens extraordinaires, c'est possible. Il faut surtout des gens qui n'aient pas d'oeillères. Des imbéciles brillants qui réfléchissent plus vite qu'un polytechnicien, mais seulement capables d'appliquer le petit manuel, j'en ai trop souffert(et je crains de ne pas être le seul). Des gens juste correctement intelligents, mais capables de se dire "nous faisons fausse route", ça c'est important.

Et c'est là, je crois, que l'agile est en train de faire fausse route : on prend ce qui a marché ailleurs pour le retranscrire sans se poser de questions : le passeport vers l'echec est garanti. Le waterfall échoue souvent pour la même raison, d'ailleurs, sans cette agilité d'esprit, le projet que je cite ci-dessus serait allé dans le décor. La solution que nous avons appliquée n'est applicable que dans de rares cas(en gros, une refonte complète d'appli sans specs autres que le vieux code). En l'occurence, une méthodologie pourrie, mais appliquée avec discernement, nous a mené à un succès qui n'avait rien de garanti.

L'important, ce sont les gens : ils doivent communiquer, être motivés, capables de se remettre en question, et accessoirement être bons. Si c'est le cas, la méthodologie suivra. Tous ces points peuvent être influençés par le management : on travaillera sur l'environnement de travail pour favoriser la communication, on encouragera les initiatives pour motiver les gens, on les titillera sur leur dogmes pour les pousser à se remettre en question, et on les formera. Mais, pour celà, il faut aller plus loin qu'appliquer mécaniquement le petit manuel du bon manager agile/waterfall/rache/cowboy/jenesaisquoi.

Et ce petit manuel, c'est exactement ce que le post original tente de nous vendre. Pouah.

[Luckyluke34]

Utiliser telle ou telle méthode de gestion de projet, c'est un peu anecdotique. Il faut avant tout de bons développeurs .

Ce qui est très exactement la première règle du Manifeste Agile (voir mon post #62)

Je re-citerais ce qu'un Directeur Technique m'a dit : "mon objectif est de faire quelque chose d'extraordinaire avec des gens ordinaires", ce à quoi je lui avais répondu : "Vous n'y arriverez pas. Pour faire quelque chose d'extraordinaire, il faut des gens extraordinaires"..

Tu surinterprètes totalement la première valeur du manifeste agile.

Individuals & interactions over processes & tools

• Ne veut pas dire que les process et outils sont anecdotiques et sans importance, juste que ce n'est pas ce sur quoi on met la priorité. Mais ils ont quand même de la valeur. Pareil avec working software over comprehensive documentation, etc...
  
  Pour reprendre tes termes, ça non plus n'est "pas du tout intégré par l'écrasante majorité" des gens et c'est bien dommage

• N'a jamais voulu dire qu'il faut des gens extraordinaires pour produire du bon logiciel. Juste qu'il faut mettre l'accent sur les talents individuels, la communication entre les parties prenantes.

Et la boîte a coulé

Bien sûr, c'était certainement dû à ça

[souviron34]

Tu surinterprètes totalement la première valeur du manifeste agile.

Individuals & interactions over processes & tools

• Ne veut pas dire que les process et outils sont anecdotiques et sans importance, juste que ce n'est pas ce sur quoi on met la priorité. Mais ils ont quand même de la valeur. Pareil avec working software over comprehensive documentation, etc...
  
  Pour reprendre tes termes, ça non plus n'est "pas du tout intégré par l'écrasante majorité" des gens et c'est bien dommage
  
  
• ...

d'accord avec toi . Je ramenais juste une anecdote, mais il n'empêche que les gens sont essentiels.. Et là ça pêche....

Car, comme démontré dans les annonces de boulot, ou comme le dit el_slapper, les rôles et leur attibution ne tiennent pas compte ni du projet, ni de la"priorité", et, comme le montrent beaucoup d'exemples cités ici, on dirait que c'et compris comme équivalent à soit "brouillon", soit "une autre manière de faire un truc rigide"..

Bien sûr, c'était certainement dû à ça

Ben dans ce cas-ci, oui : 60 gusses faisant depuis 15 ans un projet "à la cool", "dans les règles en V", en échec total au bout de 15 ans, contre 6 personnes "brillantes" en 9 mois, en succès total... Avec pour réponse que ces 6 personnes coûtaient trop cher et qu'il fallait embaucher 20 personnes "normales" de plus.. Et la boîte a bel et bien coulé à cause de ça (un audit du gouvrenement lui a coupé les subventions 6 mois plus tard, puisqu'ils n'atteignaient pas leur objectif).


(et ça a coûté 87 millions au contribuable)

[Logan Mauzaize]

Trouvez-vous que la France ait pris du retard dans les méthodes Agiles ?

Le mot étant devenu bien à la mode que je pense que d'un point de vue "information" on n'est pas en retard.
Même ma boîte qui fait du bon vieux cycle en V a fait participé tous les chefs et directeur de projet au "Agile Tour 2011". Histoire d'être "formé" (disons plutôt au parfum).

Seulement côté client ca ne suit pas du tout. En SSII, soit les clients "directs" sont des services informatiques qui agissent déjà en sous-traitance pour un autre service, soit ce sont des néophytes complets dans le domaine de l'informatique (et le génie logiciel n'en parlont pas). Bref dans la plupart des cas, il sera difficile d'être "proche" du "Product Owner" (selon les termes de Scrum).
Et puis certaines SSII ont tendance à vouloir gardé les compartiments "developpeur" et "client" bien séparés. J'ai connu une SSII où on avait aucun contact avec le client, tout passait par les chefs de projet.

Enfin contractuellement c'est plus difficile à vendre car tous les cliens (surtout en période de crise) veulent du forfait (garantie de résultat et non de moyen). Cependant en contractualisant chaque itération de manière autonome je pense que c'est tout à fait vendable.
Bon je ne connais que les "principes" de Scrum (une vision certainement bien limitée de tout ce que représente) mais chaque itération mène à un "produit" qui correspond aux exigences du client à un temps T.
D'un autre côté plus les cycles de développements sont courts plus la SSII prend de risques car 2 jours de marge sur 30 jours, c'est pas la même chose que sur 60 ...

Finalement je terminerai sur une question pour les spécialistes de l'agilité, est-ce que l'agilité est applicable aux éditeurs de logiciel ? Car c'est un peu dans ce contexte que je travaille, je produit des logiciels qui sont ensuite "revendus"/"loués" à des compagnies aériennes, des sociétés de maintenance, etc.

[souviron34]

Finalement je terminerai sur une question pour les spécialistes de l'agilité, est-ce que l'agilité est applicable aux éditeurs de logiciel ? Car c'est un peu dans ce contexte que je travaille, je produit des logiciels qui sont ensuite "revendus"/"loués" à des compagnies aériennes, des sociétés de maintenance, etc.

Comme je l'ai dit, je ne suis pas un spécialiste des méthodologies en vogue..

Cependant, normalement je dirais bien sûr, c'est même au contraire le champ d'action privilégié :

une boîte qui fabrique vraiment le logiciel...

Que le logiciel soit revendu, loué, par des compagnies ou par des personnes ou des entités, c'est du pareil au même.. Par exemple dans le cas des compagnies aériennes, c'est le personnel de ces compagnes auquel le soft est destiné qui sera ton utlisateur de base..

Pour indication, le logiciel dont je parlais plus haut était pour les hôpitaux. Mais c'était une boîte privée, qui donc allait les vendre aux hôpitaux..

Pourquoi ? A quel(s) domane(s) pensais-tu que cela s'appliquerait ??

[Logan Mauzaize]

Si j'ai bien compris les méthodes agiles reposent sur une certaine "proximité" entre les intervenants y compris les utilisateurs.
Or,

1. les développeurs d'un éditeur de logiciel sont souvent "éloignés" des utilisateurs finaux
2. les utilisateurs finaux sont nombreux

Avec ces contraintes les méthodes agiles me semblent surtout adaptés aux développements "internes" (principe de la forge et ses boîtes à outils) ou aux développements spécifiques (si le client est prêt à s'impliquer).

Dans mon cas c'est assez extrême : je développe et livre pour un service de mon client qui rédige les spécifications. Celui-ci relivre à un autre service qui émet le "cahier des charges" écrit conjointement avec l'équipe support, les commerciaux et d'autres personnes sur la base des échanges qu'ont ces intervenants avec les utilisateurs et/ou décideurs de ceux-ci ...

[souviron34]

Si j'ai bien compris les méthodes agiles reposent sur une certaine "proximité" entre les intervenants y compris les utilisateurs.
Or,

1. les développeurs d'un éditeur de logiciel sont souvent "éloignés" des utilisateurs finaux
2. les utilisateurs finaux sont nombreux

Et alors ?

Les développeurs du logiciel doivent avoir un contact autre que la cahier des charges ou la spec..

C'est ça la base..

Que les utilisateurs soient nombreux, ce n'est pas du tout un problème : des études en amont (interview, films, enregistrements) , et la sélection (permanente ou récurrente) d'un groupe d'utilisateurs tests durant le développement ne sont - ne doivent pas être - en aucun cas un frein.

Si c'est le cas, c'est que c'est l'organisation qui ne VEUT pas..

Si l'organisation (la boîte) est d'accord, c'est au contraire parfaitement faisable. Je l'ai fait dans de hopitaux, dans des centraux équivalent 115, dans une boîte équivalent EDF..

Avec ces contraintes les méthodes agiles me semblent surtout adaptés aux développements "internes" (principe de la forge et ses boîtes à outils) ou aux développements spécifiques (si le client est prêt à s'impliquer).

Ce n'est pas une question "d'implication"..

Il suffit que la boîte de développement dise "c'est notre manière de faire pour avoir un bon produit".

Mais un certain nombre de dirigeants/commerciaux ne voient que l'intérêt court-terme et se foutent pas mal du fait que le client soit satisfait ou non au bout du compte, du moment qu'il a payé..

Ce n'est donc pas du côté du client qu'il faut une implication, c'est du côté du fournisseur/fabricant..

Dans mon cas c'est assez extrême : je développe et livre pour un service de mon client qui rédige les spécifications. Celui-ci relivre à un autre service qui émet le "cahier des charges" écrit conjointement avec l'équipe support, les commerciaux et d'autres personnes sur la base des échanges qu'ont ces intervenants avec les utilisateurs et/ou décideurs de ceux-ci ...

C'est là que ça pêche : vous avez une structure bâtarde de système en V,

Dans une vraie structure en V, le client fourni le cahier des charges, point barre. C'est le service du réalisateur qui fait la spec en réponse.

Maintenant, si tu voulais appliquer l'agilité dans ta boîte, ce serait d'abord de faire admettre que l'établissement de la spec doit se faire au minimum en partenariat entre vous et le service du client.

Que cette spec doit elle-même être établie non par vos 2 seules équipes, mais conjointement avec un groupe d'utilisateurs.

Et que, au sein de cette entité "équipe spec" doit figurer au moins un utilisateur "expert" ou "reconnu par ses pairs", qui devra également ensuite être appelé régulièrement (voire participer 1 fois/semaine) dans l'équipe de développement..

Ceci passe donc, dans ta boîte, par le fait que ton entreprise soit impliquée, c'est à dire exige cet ordre des choses, afin de donner un bon produit.

Cela s'appelle du professionalisme, par rapport à s'aplatir pour avoir des sous.. (pour les commerciaux et la direction)

[Logan Mauzaize]

Merci pour ces explications ca commence à être un peu plus clair dans ma tête


Non c'est bien un beau cycle en V. En fait pour bien décrire la structure dans laquelle je travaille. Le service A (je pars du plus proche de moi jusqu'au plus éloigné) est en fait la vraie SSII. Et elle fait sous-traiter la réalisation à des vraies SSII ; et nous sous-traitons une partie des développements .
Nous codons et testons par rapport aux spécifications, le service A écrit les spécifications et testent par rapport aux cahiers des charges, le service B écrit le cahier des charges et testent par rapport aux besoins du client.


Les sous-traitants de A représente au moins 200 développeurs, 20 chefs de projets, 8 directeurs de projet et environ autant de commerciaux ; je pense que c'est uniquement la partie visible de l'iceberg .
On est clairement pas dans une démarche client/fournisseur mais commanditaire/sous-traitant !
Je me demandais surtout à quoi ressemblerait l'organisation/la hiérarchie/la répartition des rôles/les activités si on devait travailler agilement.

[souviron34]

Non c'est bien un beau cycle en V.

eh non

Un vrai cycle en V, c'est la boîte qui répond au cahier des charges qui fait spec, analyse, conception préliminaire, conception détaillée, et (éventuellement) sous-traite le codage au vu de la conception détaillée, et (éventuellement) sous-traite les tests au vu de scénarios/jeux de test.

Typiquement un vrai cycle en V se fait au sein d'une seule entreprise...

En fait pour bien décrire la structure dans laquelle je travaille. Le service A (je pars du plus proche de moi jusqu'au plus éloigné) est en fait la vraie SSII. Et elle fait sous-traiter la réalisation à des vraies SSII ; et nous sous-traitons une partie des développements

C'est bien ce que je dis : ce n'est pas un vrai cycle en V, c'est du bricolage de cycle en V..

Nous codons et testons par rapport aux spécifications, le service A écrit les spécifications et testent par rapport aux cahiers des charges, le service B écrit le cahier des charges et testent par rapport aux besoins du client.

Déjà, comme je l'ai dit il y a un (gros) problème : le cahier des charges est à écrire par le client, PAS par une SSI.. Sauf si elle est spécifiquement engagée par le client pour l'aider et le fait AVEC le client..

Que ce soit en Agile ou en V...

ça c'est du bricolage de SSII...

(et c'est même borderline du truandage : répondreà un appel d'offre en étant au courant de la concption du cahier des charges.. ça s'apparente à du délit d'inité..)

Les sous-traitants de A représente au moins 200 développeurs, 20 chefs de projets, 8 directeurs de projet et environ autant de commerciaux ; je pense que c'est uniquement la partie visible de l'iceberg .
On est clairement pas dans une démarche client/fournisseur mais commanditaire/sous-traitant !

Même pas, sans doute...

J'espère au moins que chacun travaille sur des projets différents, parce qu'avoir plusieurs chefs de projets sur le même, ça craint ...

De plus, la distinction "directeur de projet", "chef de projet" est tout à fait subtile et accessible uniquement à des SSII...

'fin bref, c'est effectivement impossible de faire de l'agilité comme ça, avec une relation "client-fournisseur" (ou commanditaire-sous-traitant, peu importe) à étages... (les cycles et l'acceptation du fait que tout n'est pas toujours fixe ne peut pas rentrer dans ce cadre)

Mais c'est également impossible de faire du dev en V correct avec ça...
Alors...

Je n'ose imaginer les écarts entre le besoin et la réalisation...

Ni entre un délai/coût normal et le délai/coût final avec une telle structure...


Je supppose d'ailleurs bien entendu que pour se dire "à la page" tout ce petit monde utilise à qui mieux mieux du XML, des "méthodologies" et des outils tierces, voire du CMMMi, non ??

[el_slapper]

(.../...)

Déjà, comme je l'ai dit il y a un (gros) problème : le cahier des charges est à écrire par le client, PAS par une SSII.. Sauf si elle est spécifiquement engagée par le client pour l'aider et le fait AVEC le client..(.../...)

+1. Sauf que dans la réalité, souvent, le client ne veut pas se priver de ses précieuses ressources, et demande donc au client de lui apprendre son métier. C'est évidemment catastrophique, mais c'est courant. Et comme c'est le client qui paye.....

J'espère au moins que chacun travaille sur des projets différents, parce qu'avoir plusieurs chefs de projets sur le même, ça craint ...

comment dire.....ah oui : +1

De plus, la distinction "directeur de projet", "chef de projet" est tout à fait subtile et accessible uniquement à des SSII...

Ca, par contre, c'est faux. Mon client actuel a une hiérarchie chef de projet, manager de projet, directeur de projet, dans cet ordre. Ce qui est ridicule, surtout pour nôtre équipe de maintenance, mais bon, la maintenance, ça n'existe pas. re -

'fin bref, c'est effectivement impossible de faire de l'agilité comme ça, avec une relation "client-fournisseur" (ou commanditaire-sous-traitant, peu importe) à étages... (les cycles et l'acceptation du fait que tout n'est pas toujours fixe ne peut pas rentrer dans ce cadre)

Mais c'est également impossible de faire du dev en V correct avec ça...
Alors...

Je n'ose imaginer les écarts entre le besoin et la réalisation...

Ni entre un délai/coût normal et le délai/coût final avec une telle structure...

C'est possible, mais on multiplie les couts et les risques, en effet. Nemek parle de 200 personnes, Je suis sur qu'une dizaine de gugusses de qualité corecte directement chez le client feraient mieux. Et je comprends mieux pourquoi il parle en permanence de démarches qualité : dans ce contexte, impossible de se passer de tracabilité.

Je supppose d'ailleurs bien entendu que pour se dire "à la page" tout ce petit monde utilise à qui mieux mieux du XML, des "méthodologies" et des outils tierces, voire du CMMMi, non ??

Il l'a confirmé sur un autre thread(sauf pour le XML, dont je ne vois pas pourquoi tu en parles). La râche n'est pas une option, dans ces conditions - sous peine d'une avalanche de procès.