Discussion :

[CaféFort]

Les méthodes agiles définissent comme précepte (entre autres) que :

1. C’est une erreur de vouloir définir le plus possible les spécifications d’un projet. Il vaudrait mieux démarrer vite et adapter au fur et à mesure.

2. La documentation du projet est un aspect secondaire. Il vaudrait mieux avoir un logiciel qui fonctionne qu’une documentation (du reste, pourquoi cette opposition (extraite du manifeste agile) antinaturelle au possible).

Le point 1 revient à dire :
- Je pars de Paris et je veux aller à Marseilles
- On me donne une carte pour les 500 premiers kilomètres (et encore, 500 c’est bcp)
- Je demanderai tous les 50 km s’il faut que j’aille à droite, à gauche ou tout droit.

C'est Agile ou c'est guimauve ? Ce principe semble valable uniquement dans des cas bien particuliers, alors qu'Agile en fait une généralité.


Le point 2 (extrait du manifeste agile) signifie que la documentation sera forcément créée de manière partielle.
Dans la vraie vie, plus de 70% du temps de développement est du temps consacré aux évolutions. Par ailleurs, les personnes changent d’entreprise.
Dans ce contexte (pas ou peu de documentation, les personnes ne restent pas forcément), est ce que l’entreprise est agile ? Termine-t-elle ses projets dans les meilleures conditions possibles et peut-elle faire évoluer facilement son système d’information ?

A l'inverse, est-ce que le travail des développeurs reprenant un projet agile (en maintenance) n'est pas forcément de plus en plus difficile ?

Avez-vous des retours d’expériences démontrant le gain en agilité de l’entreprise avec une méthode agile ? (au d'autres commentaires)

[Laurent 1973]

@CaféFort: c'est assez impressionnant que l'on a beau te répondre sur plusieurs article différent, tu ne veux absolument pas comprendre.

Il n'y a pas d'opposition entre documentation et logiciel fonctionnel en agilité, il n'y a qu'une préférence
...
pas d'opposition mais une préférence
pas d'opposition mais une préférence
pas d'opposition mais une préférence
...

Et ton analogie n'est pas du tout la bonne en plus.

Je prendrais plutôt celle du bateau qui va de Brest à New-York: il ne bloque pas sa barre du début à la fin "plein ouest" suivant sa spécification précise, il regarde régulièrement son GPS pour voir s'il ne dérive pas.
Par contre, il prépare bien sa route avant: regarde la carte, la météo, les trafic maritime, ... mais il va adapter sa route tout le long par ce qu'il sait que sa route ne peux pas être totalement déterministe suivant les vents, les courants ou tout avarie ou anomalie qu'il peux rencontrer.

Tu as compris maintenant ou il faut que tu crée un nouveau article sur le sujet?

[el_slapper]

(.../...)Tu as compris maintenant ou il faut que tu crée un nouveau article sur le sujet?

Non, en fait, je crois juste qu'il veut vendre son UML. Donc il n'a aucun intérêt à comprendre.

[CaféFort]

Non, en fait, je crois juste qu'il veut vendre son UML. Donc il n'a aucun intérêt à comprendre.

UML n'est pas une méthode, mais un langage (Unified Modeling Language).

Par ailleurs UML est tout à fait compatible avec une démarche de type Agile. On peut tout faire en mode "Agile" avec un peu de temps (Zut, fallait pas écrire ça, il risque de se fâcher).

[CaféFort]

@CaféFort: c'est assez impressionnant que l'on a beau te répondre sur plusieurs article différent, tu ne veux absolument pas comprendre.

Il n'y a pas d'opposition entre documentation et logiciel fonctionnel en agilité, il n'y a qu'une préférence
...
pas d'opposition mais une préférence
pas d'opposition mais une préférence
pas d'opposition mais une préférence
...

Et ton analogie n'est pas du tout la bonne en plus.

Je prendrais plutôt celle du bateau qui va de Brest à New-York: il ne bloque pas sa barre du début à la fin "plein ouest" suivant sa spécification précise, il regarde régulièrement son GPS pour voir s'il ne dérive pas.
Par contre, il prépare bien sa route avant: regarde la carte, la météo, les trafic maritime, ... mais il va adapter sa route tout le long par ce qu'il sait que sa route ne peux pas être totalement déterministe suivant les vents, les courants ou tout avarie ou anomalie qu'il peux rencontrer.

Tu as compris maintenant ou il faut que tu crée un nouveau article sur le sujet?

Mais dis donc, Laurent 1973, je m'aperçois que ta réponse ne correspond pas du tout à la discussion !

En plus, ce que tu écris là n'est guère aimable à mon encontre mon cher Laurent 1973, car tu écris "Tu as compris maintenant où il faut ...".
Je ne vais point demander de te censurer. Ce serait une réaction peu démocratique n'est ce pas ? Nous sommes dans l'agilité quand même !

Alors, au contraire, échangeons !!

Concernant la métaphore. C'est plutôt la tienne qui me semble assez irréelle. N'oublions pas que la finalité est de créer un produit logiciel qui sera stable. Alors autant amener cette stabilité le plus tôt possible, puisque de toute façon, stabilité il y aura (je ne pense pas que ton code s'auto-modifie). Et ce n'est pas du tout contradictoire avec le fait que l'application devra pouvoir évoluer ensuite, mais pas à 100%, ni à 50%, ni à 30 %, ni à ... etc.

Si tu veux poursuivre dans ton sens, il faudrait déjà remettre ton message dans la bonne discussion et que tu énumères les causes de dérives auxquelles tu penses parce que j'aimerais vraiment en savoir plus sur "les vents, les courants ou tout avarie ou anomalie" que tu énonces dans le cadre du développement d'un produit qui au final, sera stable (à moins que tu adores les modifications en exploitation avec changement de structure de la base de données, conversions de formats, ... et qui coûtent extrêmement cher !! Qui peut se permettre cela ?).

Je redonne le titre de la discussion : "Une gestion de projet agile, rend-elle l'entreprise agile ?"

[CaféFort]

Visiblement peu d’argument … dommage, rien sur ce sujet pourtant fondamental. Il faut dire que cette discussion a été rapidement "polluée", ce qui a par ailleurs abouti à un avertissement ... contre moi . On veut bien faire pour maintenir une discussion intéressante et vlan !! Je ne désespère pas d'obtenir des vrais raisons objectives.

Je vais ajouter à cette discussion, ce que je viens de lire à l'instant qui fait réfléchir (peut-être) :

Je viens de lire le résultat d’une étude faite par une société qui vend des outils logiciels et des prestations autour des méthodes agiles qui seraient selon eux unanimement adoptées … mais avec seulement 3 % d’évolution (c'est eux qui le disent) entre 2014 et 2015. J’en déduis que l’adoption massive a dû se faire avant parce qu’au rythme de 3% par an, ça va pas très vite et dans ce cas, l'unanimité est loin.

Voici les moteurs de l'adoption massive dont il est question dans l'article :

1. La capacité à gérer le changement de priorité.

Déjà « le changement de priorité » c’est un peu comme « la froideur d’un plat chaud sorti du four », un peu contradictoire quand même. C'est énoncé comme s'il s'agissait d'une règle. Le choix des priorités est fait par qui ? par le développeur ? Non. Par le management … et qui doit compenser ces erreurs ? On m’a compris. No culpabilité pour le management. (Management : 1, Développeur : 0). Peut-être fera-t-il mieux plus tard ce management. Quoique si on organise tout pour qu'il puisse changer facilement ses priorités, ça risque de durer longtemps. Pas grave, le développeur est agile .


2. L’augmentation de la productivité des équipes.

Bah oui, pour compenser les erreurs de management, il faut bien presser un peu plus le citron de ceux qui développent. Agile permet donc d’augmenter la productivité des équipes, mais est-ce en rendant son travail plus efficace ou en lui en demandant toujours plus ? Dans d’autres industries, on a augmenté la productivité des gens à l’aide d’outils. Est-ce le cas avec les outils Agile ? Et ces outils agiles augmentent-ils la productivité ?


3. Augmentation de la visibilité des projets.

Là, il me semble qu’on arrive à des sommets. Qui dit « visibilité », implique au moins de « savoir où on va ». Est-ce que la finalité des méthodes agiles est précisément de savoir exactement où on va ? J'ai dû mal comprendre le principe des méthodes agiles. Ou alors, il s’agit de la visibilité d’autre chose, mais alors quoi ?

[el_slapper]

1. La capacité à gérer le changement de priorité.

Ben oui, nous vivons dans un monde qui change, pour reprendre le slogan d'un de mes anciens clients. Donc, si tu ne sais pas quand il faut changer de priorité, tu est mort.

Notre principal concurrent a gagné plusieurs gros contrats grâce à une interface plus intuitive ==> nouvelle priorité, améliorer l'interface.

Le ministère à décidé d'une nouvelle réglementation en urgence, et tous nos clients nous la réclament à cors et à cris ==> nouvelle priorité, se mettre d'équerre avec la nouvelle réglementation.(et c'est du genre, urgent pour dans 15 jours)

La vie n'est faite que de ça. Changer, pour ne pas se faire bouffer.

2. L’augmentation de la productivité des équipes.

L'idée, c'est qu'on en passe pas 2 ans à développer des fonctionnalités qui ne servent à rien.

Tiens, on a un client avec lequel on a un contrat pour développer des fonctionnalités à sa demande(les autres clients en profitent). En gens sérieux, ils n'ont pas fait tout leur planning sur 3 ans comme des bourrins. Tous les six mois , ils voient ce qu'ils ont, et en profitent pour se dire que telle chose en plus serait particulièrement pertinente. On ne passe pas toute l'année à développer des trucs, pour qu'ils s'aperçoivent à la fin qu'ils n'en ont pas besoin.

Et c'est du 6 mois d'itération, ce n'est pas méchant, comme agile. Mais c'est infiniment mieux que les 10 ans du projet Louvois.

3. Augmentation de la visibilité des projets.

Typiquement, dans l'exemple au-dessus, ce client privilégié peut voir tous les 6 mois le produit s'améliorer dans le sens qu'il a demandé. Il ne se sent pas abandonné. Il peut voir, et encore, à un rythme assez lent dans notre cas, comment évolue le produit qu'il utilise au quotidien.

Après, on trouve beaucoup de mauvais agile, et ça se passe aussi mal que du mauvais cascade. Mais ça n'est pas un problème de méthodologie.

[CaféFort]

1. La capacité à gérer le changement de priorité.

Ben oui, nous vivons dans un monde qui change, pour reprendre le slogan d'un de mes anciens clients. Donc, si tu ne sais pas quand il faut changer de priorité, tu est mort.

Notre principal concurrent a gagné plusieurs gros contrats grâce à une interface plus intuitive ==> nouvelle priorité, améliorer l'interface.

Le ministère à décidé d'une nouvelle réglementation en urgence, et tous nos clients nous la réclament à cors et à cris ==> nouvelle priorité, se mettre d'équerre avec la nouvelle réglementation.(et c'est du genre, urgent pour dans 15 jours)

La vie n'est faite que de ça. Changer, pour ne pas se faire bouffer.

Tu parles de « changement de fonctionnalité » (qui peuvent parfois effectivement entraîner un changement de priorité) alors que le texte parle de « changement de priorité », sans parler des causes (ben voyons) ce qui est différent.



2. L’augmentation de la productivité des équipes.

L'idée, c'est qu'on en passe pas 2 ans à développer des fonctionnalités qui ne servent à rien.

Entièrement d’accord, comme la sur-technicité qui sont des vrais dangers ! Mais dans ce cas, ce n'est pas la productivité des équipes dont il s'agit, mais des choix stratégiques.

On ne passe pas toute l'année à développer des trucs, pour qu'ils s'aperçoivent à la fin qu'ils n'en ont pas besoin.

Oui aussi ! Mais c’est pour cela qu’on fait des maquettes avec toute l’ihm et sans les fonctionnalités. C’est rapide à faire, l’utilisateur voit le programme et surtout il s’engage en connaissance de cause. En plus, l’ihm servira ensuite dans le projet, elle n’est pas jetée.
Cela existait bien avant les méthodes agiles.

projet Louvois.

Ok !!!! L’exemple parfait du gaspillage d’argent public !!!! En plus pour un programme de paye. Je sais que leur cas est étendu, mais il existe des sujets beaucoup plus compliqués et qui fonctionnent. J’en ai vu d’autres …
Effectivement, s’ils ont fermé les yeux pendant tout le projet, forcément, ça clash à un moment et ça fait très très mal.

Mais en quoi, la méthode agile va augmenter ma productivité de développeur ? C'est la question.
J’ai lu dans le forum, ici-même, que certains on travaillé au moins 30% de temps en plus (super ?), ailleurs j'ai entendu un coach agile qui disait ouvertement à une conférence que les gens démissionnaient car ils ne pouvaient pas tenir (super ?). Sur Amazon, il existe un livre d'un américain sur les dégâts des méthodes agiles (mais malheureusement je ne me souviens plus du titre), est ce que c’est super ? Beaucoup de dégâts quand même non ??

Et surtout, est ce que l’agilité a apporté concrètement quelque chose qui aide le développeur dans son quotidien ? Puisqu'il serait plus productif.


3. Augmentation de la visibilité des projets.

Typiquement, dans l'exemple au-dessus, ce client privilégié peut voir tous les 6 mois le produit s'améliorer dans le sens qu'il a demandé. Il ne se sent pas abandonné. Il peut voir, et encore, à un rythme assez lent dans notre cas, comment évolue le produit qu'il utilise au quotidien.

Après, on trouve beaucoup de mauvais agile, et ça se passe aussi mal que du mauvais cascade. Mais ça n'est pas un problème de méthodologie.

Ok, tu confirmes donc ce que j’écris. Le client voit l’évolution. Mais ça, ce n’est pas l’agilité qui l’a apporté. Les maquettes qui s’enrichissent existent depuis la nuit des temps.

Par contre l’agilité décrète que « on n’a pas le but final » donc justement on n’a pas de visibilité et le client doit l’accepter. La maquette qui s’enrichie est aussi agile que la méthode agile, elle existait bien avant et en plus elle apporte plus de visibilité au projet qui peut être découpé pour éviter bien sûr l’effet big bang.

[Luckyluke34]

Oui aussi ! Mais c’est pour cela qu’on fait des maquettes avec toute l’ihm et sans les fonctionnalités. C’est rapide à faire, l’utilisateur voit le programme et surtout il s’engage en connaissance de cause. En plus, l’ihm servira ensuite dans le projet, elle n’est pas jetée.
Cela existait bien avant les méthodes agiles.

Tu ne comprends pas. Au fil d'un projet informatique, le donneur d'ordres raffine son besoin et redécouvre une partie de son métier sous un nouveau jour. C'est normal qu'il y ait de grosses avancées métier et process pour le client dans un projet logiciel d'envergure, et pas seulement au début. Tu auras beau faire toutes les maquettes du monde avant de commencer les développements, ce n'est pas ça qui va remplacer l'expérience acquise et les percées faites au cours de la vie du projet et à l'issue du premier choc avec la réalité quand le produit sera utilisé en production pour la première fois. Ton client est incapable de prédire ce qu'il va découvrir ou ce qui va se passer dans 3 ou 6 mois au niveau métier juste en travaillant sur des maquettes.

Quand el_slapper dit qu'on ne va pas passer 2 ans à développer des fonctionnalités qui ne servent à rien, la solution n'est pas de faire des maquettes en début de projet. La solution, c'est de se réserver la possibilité de changer de cap en cours de route parce qu'on a fait une grosse découverte fonctionnelle ou qu'un événement extérieur a remis en cause une partie des specs initiales. On évite ainsi l'effet tunnel qui conduit une équipe à avancer avec des oeillères pendant une longue période sans se demander une seule seconde s'ils sont toujours sur le bon chemin.

Mais en quoi, la méthode agile va augmenter ma productivité de développeur ? C'est la question.

Directement, elle n'augmente pas ta productivité. Ce n'est pas le propos. Les méthodes agiles répondent à d'autres problèmes ma pas celui de la productivité (= valeur produite / nb d'heures travaillées).

J’ai lu dans le forum, ici-même, que certains on travaillé au moins 30% de temps en plus (super ?)

Source ?

ailleurs j'ai entendu un coach agile qui disait ouvertement à une conférence que les gens démissionnaient car ils ne pouvaient pas tenir (super ?)

Source ?

Sur Amazon, il existe un livre d'un américain sur les dégâts des méthodes agiles (mais malheureusement je ne me souviens plus du titre)

Source ?

Pour quelqu'un qui se targue de rigueur scientifique, "on dit que", "j'ai entendu que", ce n'est pas un peu léger ? Depuis le début, on ne demande qu'à débattre sur des faits, mais encore faut-il qu'ils soient avérés et connus en détail.

Et surtout, est ce que l’agilité a apporté concrètement quelque chose qui aide le développeur dans son quotidien ? Puisqu'il serait plus productif.

Non, ce n'est pas le propos. Pour cela, il faut que tu regardes éventuellement software craftsmanship et les mouvements qui sont censés combler la relative absence de recommandations techniques dans le manifeste agile.

[CaféFort]

Tu ne comprends pas.

Heureusement, tu es là !

le donneur d'ordres raffine son besoin

Ha bon. Comme pour le pétrole, du raffinage ? => affine son besoin.

l'expérience acquise et les percées faites

Ok, on est toujours dans le forage, pas dans la logique.

l'issue du premier choc avec la réalité

Choc … pétrolier ?
Ça doit faire mal un choc avec la réalité. Il suffit peut-être d’ouvrir les yeux. La réalité est juste là, devant.

Ton client est incapable de prédire ce qu'il va découvrir ou ce qui va se passer dans 3 ou 6 mois au niveau métier juste en travaillant sur des maquettes.

On ne parle sans doute pas du même client. En tout cas, c’est lui qui assume ses erreurs, mais pas moi en tant que développeur. Ça c'est clair.

on a fait une grosse découverte fonctionnelle

Quelle aventure, décidément !

l'effet tunnel

Qui a dit que l’effet tunnel est une bonne chose ? Pas moi en tout cas.

s'ils sont toujours sur le bon chemin.

Que d’émotions !!

la productivité (= valeur produite / nb d'heures travaillées).

Pourtant, ils parlent de la productivité des équipes. Donc tu dis qu’ils partent du principe qu’avec les équipes, il y a beaucoup de déchets : c’est uniquement en introduisant les déchets des équipes que ton équation est valable. C'est bien cela que tu veux dire ? Les déchets des équipes donc.

quelqu'un qui se targue de rigueur scientifique

Non, je n’ai jamais écrit cela. A chaque fois, ça passe par ton filtre personnel et c’est transformé. C’est dommage.
Tu voudrais donc une rigueur scientifique au sujet de simples anecdotes ? Bah dans ce cas, puisque tu veux du scientifique, tu voudrais certainement aller prendre la température de ceux qui sont tombés malades ? Ce sera plus scientifique comme tu le souhaite devant ces anecdotes.
Maintenant, c’est un peu bizarre si tu n’as jamais entendu parler de tous ces problèmes. Agile = humaniste, il parait ? Non ? Ça dépend ...

les mouvements qui sont censés combler la relative absence de recommandations techniques dans le manifeste agile.

Je sais déjà que je suis loin d’être le seul à penser cela.
Ça, c’est une évidence.

[Luckyluke34]

Ha bon. Comme pour le pétrole, du raffinage ? => affine son besoin.

Ha bon. Comme pour le fromage, de l'affinage ?

Sinon, la métaphore, ça te dit quelque chose ?

Ou encore :

Raffiner

Pousser très loin ou trop loin la recherche de la qualité, de la délicatesse ou de la subtilité

http://www.larousse.fr/dictionnaires...raffiner#65429

l'expérience acquise et les percées faites

Ok, on est toujours dans le forage, pas dans la logique.

Pas vraiment, décidément tu as du mal avec les concepts immatériels on dirait :

Percée

Progrès rapide, spectaculaire, réalisé malgré les obstacles

http://www.larousse.fr/dictionnaires...c%C3%A9e#59024

Cela correspond au terme anglais "breakthrough" qui est souvent utilisé pour parler d'une avancée (d'une percée, donc) dans la compréhension du domaine métier qui peut arriver au cours de la vie d'un projet logiciel. Un projet informatique n'est pas neutre pour le client final, cela l'amène souvent à repenser ses processus et parfois mettre des mots et une description précise sur des concepts métier ou des phénomènes qu'il n'avait jamais analysé. Les percées sont bénéfiques au client qui peut mieux organiser son métier, et à l'équipe de développement qui peut refléter cela dans le logiciel.

Choc … pétrolier ?
Ça doit faire mal un choc avec la réalité. Il suffit peut-être d’ouvrir les yeux. La réalité est juste là, devant.

Justement, non. Pour resituer le contexte, il s'agit du choc imagé (oui, je sais, que d'abstraction...) que subit l'application au premier contact avec les utilisateurs finaux. Cette réalité-là, elle n'est pas juste devant les développeurs. Elle ne devient palpable qu'à la mise en production (ou l'ouverture en beta).

Par ailleurs, ce n'est pas non plus toujours l'analyste métier ou le donneur d'ordres qui peut anticiper ce choc. Ce n'est pas forcément lui l'utilisateur final et il n'a pas forcément la même appréhension du process métier que lui. Pas plus tard que ce mois-ci, sur une application dont la première mouture a récemment été mise en production, j'ai reçu de la part d'un utilisateur final qui n'était pas le demandeur d'origine des remarques et des suggestions fort appropriées (puisque nourries du terrain) sur une fonctionnalité très fastidieuse à utiliser de façon répétée. Il s'avère qu'un changement d'approche dans l'application lui fait maintenant perdre 4 fois moins de temps dans ce use case qu'il utilise 5 à 10 fois par jour. Et ça, ni l'équipe de dev ni le demandeur de l'application ne l'avaient prévu.

On ne parle sans doute pas du même client. En tout cas, c’est lui qui assume ses erreurs, mais pas moi en tant que développeur. Ça c'est clair.

"Assumer ses erreurs" = "ne jamais rien pouvoir te demander de modifier parce que c'est lui qui s'est trompé" ? On n'écrit pas du code pour le plaisir d'écrire du code, le but est de satisfaire les utilisateurs en leur offrant des fonctionnalités qui ont de la valeur dans leur boulot. S'empêcher de progresser vers ce but parce que quelqu'un s'est trompé à un moment parait assez stérile et contre-productif.

Pourtant, ils parlent de la productivité des équipes. Donc tu dis qu’ils partent du principe qu’avec les équipes, il y a beaucoup de déchets : c’est uniquement en introduisant les déchets des équipes que ton équation est valable. C'est bien cela que tu veux dire ? Les déchets des équipes donc.

"Ils" ? Qui donc ? Et je n'ai jamais parlé de déchet, pas plus que je n'ai dit que les méthodes agiles visaient directement la productivité. Je ne vois pas où tu veux en venir.

Tu voudrais donc une rigueur scientifique au sujet de simples anecdotes ?

Anecdotes ? Il me semble que je t'ai donné des liens vers des études sur les taux d'échec des projets informatiques qui tendraient à prouver à tout le moins que les méthodologies de gestion de projet utilisées jusqu'ici ne fonctionnaient majoritairement pas bien en termes de respect des délais, des coûts et des fonctionnalités. Par ailleurs, le contenu d'une méthode comme Scrum n'est pas une anecdote. Ce sont des recommandations très précises et concrètes sur une manière de travailler réunies dans un petit livret de 16 pages qui ne dit ni qu'on ne doit pas écrire de documentation, ni qu'on doit exploiter les gens ni les "faire tomber malades" comme tu l'avances bizarrement.

[Logan Mauzaize]

Je dépose mes remarques ici mais elles sont aussi valables pour l'autre discussion. Et ne le prend pas mal, il s'agit d'un simplement constat.
Soit tu es foncièrement ignorant, soit tu es foncièrement malhonnête. Dans tous les cas, tu es foncièrement idiot.
Idiot de ne pas apprendre malgré ton ignorance, ou idiot de te faire passer pour stupide ...

Globalement, tu ne tiens compte que de la réalisation du logiciel sans tenir compte de milliers d'autres aspects/facteurs (humains, monde des affaires, légaux, risques, etc.). Si tu es simplement ignorant, ce sera un plaisir de t'éclairer autrement c'est une peine perdue puisqu'il n'est pas question de "discuter".

Tout au plus ce que nous aborderons pourra éventuellement servir à certains lecteurs mais le caractère malsain et biaisé de la discussion rend à mon avis caduque son utilité dans ce cas.

Le point 1 revient à dire :
- Je pars de Paris et je veux aller à Marseilles
- On me donne une carte pour les 500 premiers kilomètres (et encore, 500 c’est bcp)
- Je demanderai tous les 50 km s’il faut que j’aille à droite, à gauche ou tout droit.

Non, cela revient à dire : qu'il n'existe pas de tracé et que je n'ai qu'une carte topograhique approximative et de vagues coordonnées de Marseille. In fine, j'irai peut-être à Nice ou à Toulon. Et j'adapterai ma destination et mon tracé en fonction de ce que je trouverai : un pré à cultiver, une femme avec qui me marier, une montagne à percer, etc.

Ce que tu indiques c'est un projet de quelques heures dans un contexte bien connu. Mais même malgré cela, je met ma main à couper que tu n'arrives pas à prédire à 10mn près ton heure d'arriver. Ni même à répéter le même temps avec la même incertitude sur une dizaine de trajets. Il y a toujours des aléas ; là, par exemple, si je regarde Google Maps, il m'indique huit incidents sur le parcours !

Ce que tu décris correspond tout au plus au développement d'un site statique. Et là, même les Web Agency ne sont pas parvenus à industrialiser.

C'est Agile ou c'est guimauve ? Ce principe semble valable uniquement dans des cas bien particuliers, alors qu'Agile en fait une généralité.

Que vient faire la guimauve ici ? C'est une affirmation gratuite et bien éloigné de la réalité constaté par les auteurs du manifeste et autres signataires ainsi que nous mêmes. Peut-être est-ce mon cas particulier mais je n'ai quasiment pas connu de projet avec une durée de vie inférieur à deux ans (seulement deux) et la moyenne se situe à plus de 10 ans (et encore avant refonte, donc le business est porté bien plus longtemps). Sans compter le nombre de personnes impliquées.

Donc la vision est long terme n'est qu'un phare dans le brouillard, la direction où aller. De la même manière que les modèles mathématiques que l'on construit tende vers un jeu de données mais ne s'y cale jamais.

Le point 2 (extrait du manifeste agile) signifie que la documentation sera forcément créée de manière partielle.

Non cela dit uniquement que si entre le logiciel et la document l'un doit être "sacrifié" alors ce sera cette dernière. En gestion (peu importe le sujet) définir des priorités ne veut pas dire que les items ne seront pas faits. Simplement qu'on leur donne un ordre afin d'assurer que les éléments importants soient traités.

Dans la vraie vie, plus de 70% du temps de développement est du temps consacré aux évolutions. Par ailleurs, les personnes changent d’entreprise.
Dans ce contexte (pas ou peu de documentation, les personnes ne restent pas forcément), est ce que l’entreprise est agile ? Termine-t-elle ses projets dans les meilleures conditions possibles et peut-elle faire évoluer facilement son système d’information ?

Oula ! Il faut s'arrêter un petit moment pour savourer ces quelques phrases.

Si l'essentiel du développement sont des évolutions alors comment définir un plan à l'avance ? Si les personnes changent alors comment préserver la constitence du plan ?

Bien que je ne comprenne pas le concept "d'entreprise agile", une entreprise de qualité (ie certifié ISO 9001:2xxx) ne prédit rien de la qualité de ses produits. Pas plus que l'inverse. La façon dont s'organise les "pans" de l'entreprise (administratif, gestion, production, pilotage, etc.) ne désignent pas nécessairement (voir rarement) comment s'organise chacune de ses activités. Ces dernières n'étant par ailleurs pas nécessairement toutes organiser de la même manière au sein d'un même "pan".

Enfin, il n'est jamais de projet qui se terminent vraiment. Même sans aucune documentation, ni plan, une entreprise peut réaliser ses projets dans les meilleures conditions possibles et faire évoluer facilement son système d'information. Seulement cela reposera sur des choses fragiles. Tout autant que de partir dans une mauvaise direction ou faire de lourds et mauvais investissements.

A l'inverse, est-ce que le travail des développeurs reprenant un projet agile (en maintenance) n'est pas forcément de plus en plus difficile ?

Je n'ai pas assez de recul sur la question mais à mon avis pas moins difficile qu'avec une autre approche. Être agile (ou pas) n'empêche pas de mettre chaque chose à sa place. Et in fine, c'est surtout cela qui permet la vision à long terme.

Avez-vous des retours d’expériences démontrant le gain en agilité de l’entreprise avec une méthode agile ? (au d'autres commentaires)

Non parce que de mon expérience, il a rarement été possible de mettre en place une organisation totalement agile. De mon expérience, on "matraque" beaucoup l'IT (réalisation logicielle) avec le contenu et quelques décideurs avec des mots-clés et des promesses mais peu de principes et de contenance. Et quand aux autres personnes (AMO, busienss, OPS, etc), elles sont ignorantes, voir carrément réfractaires.

Il faut bien comprendre qu'à l'heure actuel, ce n'est pas l'agilité qui est en échec mais sa diffusion. Dire qu'une équipe de dev travaille de manière agile est un non-sens puisqu'en agilité, le terme équipe designe tous les "stakeholders". Or à l'heure actuel, je n'ai pas vu de contexte dans lequel, on a réussi à monter "une équipe agile".

Néanmoins, l'adoption par les équipes de développement de pratiques agiles, permet de les faire rentrer dans un "moule" dans lequel de vraies bonnes pratiques se dessinent.

Mais dis donc, Laurent 1973, je m'aperçois que ta réponse ne correspond pas du tout à la discussion !

En fait si mais seulement quand on est pas de mauvaise fois

En plus, ce que tu écris là n'est guère aimable à mon encontre mon cher Laurent 1973, car tu écris "Tu as compris maintenant où il faut ...".

Il faudrait éviter de créer deux discussions sur le même sujet. Elles méritent vraiment d'être fusionnés ... A moins que tu veuilles défendre une autre thèse ici ?

Je ne vais point demander de te censurer. Ce serait une réaction peu démocratique n'est ce pas ? Nous sommes dans l'agilité quand même !

C'est quoi le rapport entre démocratie et agilité ?

Concernant la métaphore. C'est plutôt la tienne qui me semble assez irréelle. N'oublions pas que la finalité est de créer un produit logiciel qui sera stable. Alors autant amener cette stabilité le plus tôt possible, puisque de toute façon, stabilité il y aura (je ne pense pas que ton code s'auto-modifie). Et ce n'est pas du tout contradictoire avec le fait que l'application devra pouvoir évoluer ensuite, mais pas à 100%, ni à 50%, ni à 30 %, ni à ... etc.

Une application est rarement stable sauf si elle est extrêment simple. On veut toujours lui faire faire plus de choses. C'est justement parce que le code s'auto-modifie pas qu'elle sera instable. L'environnement d'une application finira indubitablement par être modifié : pérennité de la solution, volumétrie, interfaces externes, etc.

Il n'y a rien de plus de contradictoire à l'évolution que constance et rigidité. Tout comme le refus d'un certain degré d'incertitude.

Si tu veux poursuivre dans ton sens, il faudrait déjà remettre ton message dans la bonne discussion et que tu énumères les causes de dérives auxquelles tu penses parce que j'aimerais vraiment en savoir plus sur "les vents, les courants ou tout avarie ou anomalie" que tu énonces dans le cadre du développement d'un produit qui au final, sera stable (à moins que tu adores les modifications en exploitation avec changement de structure de la base de données, conversions de formats, ... et qui coûtent extrêmement cher !! Qui peut se permettre cela ?).

Premièrement, il sera stable et finit quand ton produit ? Dans 5, 7, 10, 15, 25, 50 ans ? Et tu penses que depuis le jour 0 et cette hypothétique date finale, rien n'aura changer ? Ni les gens, ni les affaires, ni les concurrents, ni la loi, ni les opportunités, ni la société, etc.

Qui te dit que les changements doivent coûter ? Qui te dit que l'adaptation doit coûter cher ? Qui te dit qu'une entreprise peut se permettre d'être figé ?

Je redonne le titre de la discussion : "Une gestion de projet agile, rend-elle l'entreprise agile ?"

Le titre de la discussion et les sujets que tu évoques ne sont pas liés pas plus que les deux propositions du titre. Manger du cochon me rend-il plus cochon ? (j'aurais bien utilisé une autre analogie mais j'aurais eu peur de paraître méchant )

Visiblement peu d’argument … dommage, rien sur ce sujet pourtant fondamental. Il faut dire que cette discussion a été rapidement "polluée", ce qui a par ailleurs abouti à un avertissement ... contre moi . On veut bien faire pour maintenir une discussion intéressante et vlan !! Je ne désespère pas d'obtenir des vrais raisons objectives.

Discussion en double avec les mêmes arguments que tu refuses d'entendre ... La discussion aurait pu être intéressantes si tu acceptais l'objectivité des arguments.

Je viens de lire le résultat d’une étude faite par une société qui vend des outils logiciels et des prestations autour des méthodes agiles qui seraient selon eux unanimement adoptées … mais avec seulement 3 % d’évolution (c'est eux qui le disent) entre 2014 et 2015. J’en déduis que l’adoption massive a dû se faire avant parce qu’au rythme de 3% par an, ça va pas très vite et dans ce cas, l'unanimité est loin.

Source ? Il faudrait définir "adopter" (projet de s'y mettre ?) et "évolution" (parts de marché de la société ?).

1. La capacité à gérer le changement de priorité.

Déjà « le changement de priorité » c’est un peu comme « la froideur d’un plat chaud sorti du four », un peu contradictoire quand même. C'est énoncé comme s'il s'agissait d'une règle. Le choix des priorités est fait par qui ? par le développeur ? Non. Par le management … et qui doit compenser ces erreurs ? On m’a compris. No culpabilité pour le management. (Management : 1, Développeur : 0). Peut-être fera-t-il mieux plus tard ce management. Quoique si on organise tout pour qu'il puisse changer facilement ses priorités, ça risque de durer longtemps. Pas grave, le développeur est agile .

Toute personne avec un minimum de bagage sait que les priorités changent. Est-ce que changer veut dire avoir fait une erreur ? Non c'est simplement s'adapter. Si tu vois/vis le changement comme un échec, tu vas droit dans le mur et surtout NE MONTE JAMAIS DE SOCIÉTÉ, voir ne prend pas responsabilité du tout.
Pouvoir changer ne dit pas devoir jeter.
De même changer de cap, ne signifie pas faire un virage à 135° sec et immédiat.

2. L’augmentation de la productivité des équipes.

Bah oui, pour compenser les erreurs de management, il faut bien presser un peu plus le citron de ceux qui développent. Agile permet donc d’augmenter la productivité des équipes, mais est-ce en rendant son travail plus efficace ou en lui en demandant toujours plus ? Dans d’autres industries, on a augmenté la productivité des gens à l’aide d’outils. Est-ce le cas avec les outils Agile ? Et ces outils agiles augmentent-ils la productivité ?

Je ne suis pas sûr de quoi il fait allusion. Mais je vois deux réductions de coûts :
- On ne développe que ce qui créé de la valeur et en premier ce qui en apporte le plus. Valeur qui est constamment ré-évaluée.
- Les aléas inévitables sont moins coûteux à gérer.

3. Augmentation de la visibilité des projets.

Là, il me semble qu’on arrive à des sommets. Qui dit « visibilité », implique au moins de « savoir où on va ». Est-ce que la finalité des méthodes agiles est précisément de savoir exactement où on va ? J'ai dû mal comprendre le principe des méthodes agiles. Ou alors, il s’agit de la visibilité d’autre chose, mais alors quoi ?

"Savoir où on va" n'a pas changé mais c'est "savoir où on est" qui change. Ce qui est bien important ici ce sont les temps ! Qu'est-ce qui a plus de valeur l'incertitude de demain ou l'exactitude d'aujourd'hui ?
L'idée c'est d'avancer de la même manière qu'un navigateur utilise une carte, un compas, un sextant et sa vigie ...

1. La capacité à gérer le changement de priorité.
Tu parles de « changement de fonctionnalité » (qui peuvent parfois effectivement entraîner un changement de priorité) alors que le texte parle de « changement de priorité », sans parler des causes (ben voyons) ce qui est différent.

Parce que les causes et conséquences sont infinies et que c'est un manifeste pas un cours sur le management (tout sujet confondu : affaire, droit, risque, etc.)

2. L’augmentation de la productivité des équipes.
Entièrement d’accord, comme la sur-technicité qui sont des vrais dangers ! Mais dans ce cas, ce n'est pas la productivité des équipes dont il s'agit, mais des choix stratégiques.

Et c'est donc mieux de faire des choix stratégiques (risqués et coûteux) long temps à l'avance et avec pas de possibilité de s'adapter ?
Et il s'agit bien de la productivité de l'équipe, si elle gaspille son temps sur des choses sans valeurs, c'est comme si elle ne produisait rien ou presque. Tu te trouves productifs quand tu travailles dans le vent ?

Oui aussi ! Mais c’est pour cela qu’on fait des maquettes avec toute l’ihm et sans les fonctionnalités. C’est rapide à faire, l’utilisateur voit le programme et surtout il s’engage en connaissance de cause. En plus, l’ihm servira ensuite dans le projet, elle n’est pas jetée.
Cela existait bien avant les méthodes agiles.

Une maquette non jetable est bien plus coûteuse. Et plus elle est réelle, plus les gens s'accrochent à des détails. Ce n'est pas pour rien que WebAgency et autres marketeux travaillent avec Photoshop ou que les outils de wireframing ont la côte.

Ensuite il y a des millions de détails qui ne sont pas vus sur une maquette (valeurs particulières, champs trop longs, informations qui disparaîtront, etc.) Enfin, tu crois que ta maquette va être validé par tous les utilisateurs ? Les supports niveaux 2 sont une incroyable source de feedback ! Théoriquement les niveaux 1 aussi mais vus que ce sont surtout des opérateurs téléphoniques, il faut pas trop espérer pour en obtenir des informations.

Ok !!!! L’exemple parfait du gaspillage d’argent public !!!! En plus pour un programme de paye. Je sais que leur cas est étendu, mais il existe des sujets beaucoup plus compliqués et qui fonctionnent. J’en ai vu d’autres …
Effectivement, s’ils ont fermé les yeux pendant tout le projet, forcément, ça clash à un moment et ça fait très très mal.

Bah "fermé les yeux pendant tout le projet", ce n'est pas ce que tu proposes ?
Heureusement qu'il y a des gros projets qui réussissent, cela ne serait pas très rassurant sinon avec plus de 80 000 vols par jour !

Mais en quoi, la méthode agile va augmenter ma productivité de développeur ? C'est la question.

En se focalisant sur la production de valeur plutôt que de lignes de code ou de fonctionnalité. En adoptant une attitude qui réduit les erreurs et les attentes.

J’ai lu dans le forum, ici-même, que certains on travaillé au moins 30% de temps en plus (super ?), ailleurs j'ai entendu un coach agile qui disait ouvertement à une conférence que les gens démissionnaient car ils ne pouvaient pas tenir (super ?). Sur Amazon, il existe un livre d'un américain sur les dégâts des méthodes agiles (mais malheureusement je ne me souviens plus du titre), est ce que c’est super ? Beaucoup de dégâts quand même non ??

En plus que quoi ? Que s'ils avaient pas fait en mode agile, ils ont développés deux fois l'application ? pour quelle valeur supplémentaire ? avec quel degré d'acceptation dans l'équipe et quelles "qualités" de méthode agile ?
S'il s'agit des exemples que j'ai déjà énnoncé où la méthode agile n'est pas pleinement appliquée et acceptée, alors cela n'a pas grande valeur et implique un tout autre constat.

L'esperanto est une langue "universelle" mais pourtant "peu" de personnes l'utilisent.

Et surtout, est ce que l’agilité a apporté concrètement quelque chose qui aide le développeur dans son quotidien ? Puisqu'il serait plus productif.

Le manifeste non mais les méthodes oui : XP, Kanban, Scrum. Toutes décrivent des pratiques qui peuvent apporter des améliorations à une équipe. Après il faut surtout adhérer aux principes. C'est une condition nécessaire mais pas suffisante.

3. Augmentation de la visibilité des projets.
Ok, tu confirmes donc ce que j’écris. Le client voit l’évolution. Mais ça, ce n’est pas l’agilité qui l’a apporté. Les maquettes qui s’enrichissent existent depuis la nuit des temps.

Les maquettes n'ont pas par définition aucun vécu. Elles sont montrées, puis "jetées". Soit elles deviennent un produit (ou un élément du produit), soit elles sont jetées. L'évolution au contraire est portée par des choses concrètes (ressentis de plusieurs utilisateurs, nouveaux objectifs/horizons, etc.).

L'agilité n'est pas l'unique moyen d'apporter de la visibilité, tout comme ce n'est pas l'unique moyen de réussir. C'est juste un support qui permet d'obtenir certaines qualités.

Par contre l’agilité décrète que « on n’a pas le but final » donc justement on n’a pas de visibilité et le client doit l’accepter. La maquette qui s’enrichie est aussi agile que la méthode agile, elle existait bien avant et en plus elle apporte plus de visibilité au projet qui peut être découpé pour éviter bien sûr l’effet big bang.

Personne n'a dit que les pratiques préconnisés par les méthodes agiles sont nouvelles. RUP qui est un processus itératif est pour certains considéré comme agile. J'estime que l'idée de l'agilité c'est d'admettre un certain nombre de qualité qui touche nos projets : l'incertitude, l'indécision, les aléas inévitables, le manque de compréhension, etc.

J'ai un exemple en tête :

Un AMO découvre avec l'aide du support niveau 2 et l'analyse des logs que l'application n'est pas conçu de la manière dont les gens l'utilisent. Il s'agit à l'origine de dématérialiser des rapports entre des documents et des avions. Le formulaire concernait un document et les avions concernés. Sauf que les sociétés de maintenance, travaille avec des ordres de travail par avion. Et in fine, l'ingénieur fait N rapports pour N document pour l'avion sur lequel il est intervenu. l'AMO planche durant plus d'un an sur une nouvelle interface (maquette à l'appui) pour prendre en compte ce use case.
Par expérience, je peux dire que la maquette et la spécification étaient extrêment précises. Tout cela est validé par les "key users", signé de leur sang (à ce qu'il parait). Contents d'avoir une excellente spécification, nous partons en développement. La recette avec l'AMO est sans surprise excellente (IT et AMO sont contents).
Quand vient la recette utilisateur, l'AMO se fait fustiger et c'est un "No Go" pour la nouvelle IHM mais le reste RAS. Aucune correction pour nous, on active le paramètre qui bloque le nouvel écran. Et l'application part en production.

Conclusion : la maquette n'a pas évité la non-acceptation. Et la non-acceptation d'un écran n'a pas empêché l'EIS des autres fonctionnalités.

Ha bon. Comme pour le fromage, de l'affinage ?

Hélàs, il a raison ... En anglais on dit "refines" mais cela se traduit par affiner / parfaire / peaufiner.

...

Je te donne quelques mots clés à étudier et revient nous voir après les avoir étudié :

• Minimum Valuable Product
• Total Productive Maintenance
• Just-in-time manufacturing

Et bien sûr quelques méthodes : Lean, Kanban, XP, Scrum.

[CaféFort]

J’ai lu les 3 premières lignes et voyant la teneur, j’ai lu aussi les 3 dernières et c’est tout.

Le début :

« Je dépose mes remarques ici mais elles sont aussi valables pour l'autre discussion. Et ne le prend pas mal, il s'agit d'un simplement constat.
Soit tu es foncièrement ignorant, soit tu es foncièrement malhonnête. Dans tous les cas, tu es foncièrement idiot. »

Je me fais insulter par un modérateur. Bravo !
Tu te permets donc de faire ce que tu interdis aux autres.
Sais-tu au moins comment cela s’appelle ?

Ce genre de réaction agressive est typique quand on veut défendre quelque chose qui ne fonctionne pas. (Attention, je n’ai pas écrit que ça ne fonctionne pas, mais on voit que tu as des doutes, sinon tu utiliserais des moyens plus intelligents)

La fin :

« Je te donne quelques mots clés à étudier et revient nous voir après les avoir étudié : »

Il y a comme un léger manque d’humilité, non ?

Je sais que tes réactions intempestives ne sont pas représentatives du monde des méthodes informatiques, heureusement.
Je trouve que tu devrais faire corriger le texte de tes réponses avant de les publier car la lecture avec toutes les fautes que tu fais (orthographe et grammaire) est très pénible.
(1 ou 2 fautes par réponse, ok, mais là ce n’est pas facile à lire)

Oui, aussi, juste au-dessus, j’ai vu ça :

« Hélàs, il a raison ... »

Tu es déçu que j’aie raison. Merci pour cette parfaite démonstration de dogmatisme. Une de plus !

Merci quand même d’avoir reconnu la valeur de ma réponse.

[Logan Mauzaize]

Le dernier message confirmant mes dires, ce sera mon dernier message sur tes fils mais si tu veux continuer en MP ou sur la taverne aucun soucis.

J'aurais simplement laisser mes indications sur la teneur de cette discussion et sur le "potentiel" fond qu'il y aurait pu y avoir d'intéressant sur le sujet.

J’ai lu les 3 premières lignes et voyant la teneur, j’ai lu aussi les 3 dernières et c’est tout.

J'avais prévenu

Je me fais insulter par un modérateur. Bravo !

Sache que :

• je suis qu'un Homme,
• bénévole et non employé d'une quelconque société affilié au site,
• il n'y a rien d'insultant à traiter quelqu'un d'ignorant ou d'assez intelligent pour jouer les bêtes,
• en tant que modérateur (même si je ne suis pas rattaché à cette section) il est de mon devoir de mettre en garde les autres lecteurs,
• j'ai obtenu ce titre uniquement par le mérite

Tu te permets donc de faire ce que tu interdis aux autres.
Sais-tu au moins comment cela s’appelle ?

Être papa ?

Ce genre de réaction agressive est typique quand on veut défendre quelque chose qui ne fonctionne pas. (Attention, je n’ai pas écrit que ça ne fonctionne pas, mais on voit que tu as des doutes, sinon tu utiliserais des moyens plus intelligents)

Quand on est agressif, on ne met ni la ligne, ni la forme, encore des moins explications ou une prose de plus de 12 000 caractères ...

Il y a comme un léger manque d’humilité, non ?

Parce que je sais des choses que tu ne sais pas (ou fais croire que ...) ? Je suis assez confiant sur le fait qu'inversement tu sais des choses que je ne sais pas et que la somme des connaissances détenues par l'ensemble des intervenants de ce forum n'est qu'une fraction de la connaissance de l'humanité ...

Je sais que tes réactions intempestives ne sont pas représentatives du monde des méthodes informatiques, heureusement.

On peut te retourner le compliment et j'ai toujours été complimenté et recommandé (par mes pairs, mes supérieurs et mes clients) pour ma manière de travailler, de réagir et mes interventions. A titre d'exemple, j'ai obtenu sur ce forum le rôle de modérateur.

Je trouve que tu devrais faire corriger le texte de tes réponses avant de les publier car la lecture avec toutes les fautes que tu fais (orthographe et grammaire) est très pénible.
(1 ou 2 fautes par réponse, ok, mais là ce n’est pas facile à lire)

Vu le peu que tu prétends avoir lu cela ne devrait pas être gênant. J'avoue pleinement mes fautes (surtout la grammaire après avoir édité certaines phrases :s) mais niveau orthographe, je pense que tu devrais également balayer devant ta porte

Tu es déçu que j’aie raison. Merci pour cette parfaite démonstration de dogmatisme. Une de plus !

Non déçu que lui ait tord pour une fois. Mais après tu tenter de faire croire ce que tu veux

Merci quand même d’avoir reconnu la valeur de ma réponse.

Pour ma part, je n'ai aucune honte à reconnaître qui a raison.

[Luckyluke34]

Hélàs, il a raison ... En anglais on dit "refines" mais cela se traduit par affiner / parfaire / peaufiner.

Ben, non. Tu as lu ma réponse avec citation de dictionnaires ? Par ailleurs, il n'est pas interdit d'user de métaphore que je sache. Si j'ai envie de dire tamiser, décanter, tailler, toiletter, distiller, baratter, dégrossir, raffiner, peu importe, on comprend toujours de quoi il s'agit. Et puis s'arrêter sur ce niveau de détail de formulation, franchement, c'est une façon tellement puérile d'essayer d'éviter le débat.

Sur le reste, je suis 100% d'accord avec toi - le mot "idiot" en moins.

[CaféFort]

Il est étonnant que sur un site de grande qualité comme developpez.net, on trouve un « modérateur » qui agit de la sorte.
Pour clore le sujet avec cet intervenant (puisqu'il dit d'avance qu'il ne répondra plus), je vais me contenter de relever les éléments les plus significatifs et nous pourrons j’espère, revenir au sujet qui nous intéresse.
Comme l’intervenant concerné a dit qu’il ne répondrait plus, je suis donc obligé d’employer le « il » au lieu de lui répondre avec le « tu ».

« Je dépose mes remarques ici mais elles sont aussi valables pour l'autre discussion. Et ne le prend pas mal, il s'agit d'un simplement constat.
Soit tu es foncièrement ignorant, soit tu es foncièrement malhonnête. Dans tous les cas, tu es foncièrement idiot. »

« Si tu es simplement ignorant, ce sera un plaisir de t'éclairer autrement c'est une peine perdue puisqu'il n'est pas question de "discuter". »

Simplement ignorant : jolie formulation ! cela donne envie d’apprendre !!

« Oula ! Il faut s'arrêter un petit moment pour savourer ces quelques phrases. »

Un minimum de respect serait le bienvenu ….

« Et quand aux autres personnes (AMO, busienss, OPS, etc), elles sont ignorantes, voir carrément réfractaires. »

Décidément, nous sommes beaucoup « d’ignorants » à ses yeux.
Pourtant, il arrive que ce ne soit pas de l’ignorance, mais un vrai choix effectué en connaissance de causes !!

Par ailleurs, il est visiblement intervenu sans prendre connaissance de l’ensemble des échanges, tellement ses propos sont surprenants.
Comment en arriver à de pareilles réponses, je me le demande :

« Il n'y a rien de plus de contradictoire à l'évolution que constance et rigidité. Tout comme le refus d'un certain degré d'incertitude. »

« Qui te dit que les changements doivent coûter ? Qui te dit que l'adaptation doit coûter cher ? Qui te dit qu'une entreprise peut se permettre d'être figé ? »

Bien sûr, un logiciel a le devoir de pouvoir évoluer et de s’adapter facilement !!!
Bien sûr aussi, que les changements coûtent cher et qu’une entreprise ne peut pas se permettre d’être figée !!!

« Manger du cochon me rend-il plus cochon ? »

Pourtant, une gestion de projet permettant de faire des évolutions rapidement rend l’entreprise plus agile.

« surtout NE MONTE JAMAIS DE SOCIÉTÉ, voir ne prend pas responsabilité du tout. »

Si tu savais !!!
Saches quand même que justement je n’ai jamais été salarié (donc …) et je ne vais pas mentionner le budget maximum qui m’ait été confié à ce jour en M€. (il parlait de société et de responsabilités, je crois …)

« revient nous voir après les avoir étudié »

Sans commentaire, quoique : L’entraide et l’échange qui sont les valeurs de ce forum lui sont visiblement inconnues.

« Sache que :
• je suis qu'un Homme,
• bénévole et non employé d'une quelconque société affilié au site,
• il n'y a rien d'insultant à traiter quelqu'un d'ignorant ou d'assez intelligent pour jouer les bêtes,
• en tant que modérateur (même si je ne suis pas rattaché à cette section) il est de mon devoir de mettre en garde les autres lecteurs,
• j'ai obtenu ce titre uniquement par le mérite »

et ces 5 points l’autoriserait à traiter les gens d’idiots, puisque c’est sa réponse !!

Sinon, il pourrait par exemple jeter un œil aux sujets traités par les grands cabinets de consulting que l’on nomme les « big five ».
Tout le monde n'est pas d'accord, mais les échanges peuvent apporter de la valeur.
C'est personnellement ce que je fais ici.

A voir ce genre de réaction intempestive, on dirait que le thème dérange fortement.

[CaféFort]

Il me semble que je t'ai donné des liens vers des études sur les taux d'échec des projets informatiques qui tendraient à prouver à tout le moins que les méthodologies de gestion de projet utilisées jusqu'ici ne fonctionnaient majoritairement pas bien en termes de respect des délais, des coûts et des fonctionnalités.

J'aimerais connaître la définition de "projet réussi" dans les méthodes agile et bien sûr une définition factuelle, rien de subjectif, pas du style "le client, il est content" .

[Luckyluke34]

J'aimerais connaître la définition de "projet réussi" dans les méthodes agile et bien sûr une définition factuelle, rien de subjectif, pas du style "le client, il est content" .

Mauvaise pioche, "le client, il est content" c'est justement la mesure principale de la réussite d'un projet. Comme je le disais, ça se décline en termes de délais, de coûts et de fonctionnalité.

Sinon tu peux aussi lire les liens qu'on te donne Tu pourras ironiser quand tu auras des points factuels et détaillés à opposer à ceux-ci.

[CaféFort]

Mauvaise pioche, "le client, il est content" c'est justement la mesure principale de la réussite d'un projet. Comme je le disais, ça se décline en termes de délais, de coûts et de fonctionnalité.

Sinon tu peux aussi lire les liens qu'on te donne Tu pourras ironiser quand tu auras des points factuels et détaillés à opposer à ceux-ci.

Au contraire, j'avais bien anticipé !! Le client est content !!

Plus sérieusement, ta réponse comprend deux versants. L’un est subjectif, l’autre est factuel :

1. Le client est content
2. Délai, coût, fonctionnalité

Il me faudrait alors la définition de :
- « réussite d’un point de vue délai »
- « réussite d’un point de vue coût »
- « réussite d’un point de vue fonctionnalité »

Malheureusement, si c’est subjectif. On peut aussi toujours avoir un taux de réussite de 100 % ! Tu vois le problème ?

[Luckyluke34]

Non, vraiment pas. On demande aux décideurs quel pourcentage de leurs projets a échoué, connu un succès mitigé ou réussi et ce sur les trois critères : fonctionnalités, coût et délais. Aucune raison d'avoir 100% de réussite.

Crois-moi, le but des gens qui commandent des projets informatiques n'est pas de répondre 100% à une étude anonyme. C'est juste d'avoir des applications qui satisfont leurs besoins métier et d'en avoir pour leur argent. Rien de bien sorcier en somme.