Programmation : les erreurs à ne jamais commettre lors du développement d’un produit

Programmation : les erreurs à ne jamais commettre lors du développement d’un produit
Les 11 péchés mortels selon un livre d’Alan Cohen

Le développement d’un produit est une aventure pleine de risques et d’obstacles à surmonter pour garantir le succès du projet. Un projet est plein de pièges et chaque surprise non découverte à temps pourrait s’avérer fatale pour la réussite du projet. Dans un livre intitulé « Prototype to product : a practical guide for getting to market », l’auteur Alan Cohen consacre son premier chapitre à présenter « les 11 péchés mortels pour le développement d’un produit ». Une synthèse de ce chapitre a été faite sur le site Oreilly.com, mais ici nous allons nous limiter aux « péchés mortels » auxquels les développeurs sont couramment confrontés dans leurs différents projets.

La première chose à retenir est qu’il ne faut jamais remettre à demain ce que l’on peut faire aujourd’hui. Cet adage prend tout son sens dans le développement informatique car l’un des péchés mortels dans le développement d’un produit vient du vice de la paresse. Dans son livre, Alan Cohen explique en effet que c’est une erreur grave de faire les tests seulement après que les prototypes soient largement développés. Remettre les tests à la fin du développement peut conduire parfois à effectuer de grands changements alors que le projet est très avancé, ce qui est très coûteux. Les tests devraient vite commencer dans le développement, cela permettra de découvrir les surprises le plus tôt possible et d’entreprendre les actions nécessaires au bon moment.

D’autres erreurs qui pourraient miner le projet découlent des hypothèses que nous faisons sur les besoins des utilisateurs. A ce niveau, le développeur pourrait commettre 2 péchés mortels selon Cohen. Le premier est de supposer que nous connaissons les caractéristiques que le produit doit avoir pour satisfaire l’utilisateur moyen. La plupart du temps, nous ne le savons pas parce qu’en tant que développeurs, nous avons tendance à mettre l’accent sur la technologie. Nous désirons plus de fonctionnalités et plus de personnalisations, alors que l’utilisateur ne veut qu’un outil attrayant qui pourra lui permettre de travailler efficacement.

Une autre erreur à ne pas commettre est de se dire également que les utilisateurs savent ce dont ils ont besoin. Selon l’auteur du livre « Prototype to product », il se trouve souvent que ces derniers ne savent pas non plus ce qu’ils veulent mais plutôt ce qu’ils pensent qu’ils veulent. L’idéal serait donc de leur donner quelque chose à tester le plus vite possible - afin d’identifier leurs besoins réels - au lieu d’attendre jusqu’à la fin du développement.

Le flou ou le manque de spécificité dans la planification d'un produit et son effort de développement est également une source majeure d'échec du projet. Il y a 3 péchés mortels qui découlent du flou : le manque de compréhension des exigences, l’absence d’un bon plan de projet et la non assignation de responsabilité.

Si les deux dernières erreurs fatales liées au flou sont plus ou moins claires, il est important de revenir sur le manque de compréhension des exigences. A ce niveau, il faut noter qu’entre l’utilisateur final et le développeur, chaque intervenant a une certaine compréhension du produit que demande le client. Même si le client a une idée claire de ce qu’il souhaite, en exprimant son besoin, le produit qu’il décrit peut subir une modification et d’ores et déjà être différent de ce qu’il souhaite. Si le besoin est recueilli par une partie intermédiaire entre le client et le développeur, cette personne aura encore une compréhension un peu dégradée de ce que le client a exprimé ; alors le produit souhaité par le client subit une autre déformation. Jusqu’à ce que l’expression des besoins parvienne au développeur, le produit aurait déjà subi une profonde déformation. Le développeur va donc concevoir un produit selon la compréhension qu’il a eu des besoins de l’utilisateur. Il sera donc plus facile par exemple pour le client qui voulait une Lamborghini de se retrouver une Volkswagen.

D’autres erreurs à ne pas commettre dans un projet découlent du vice de perfectionnisme. Le développement d’un logiciel peut avoir de grands enjeux, au-delà de l’obligation du développeur de bien faire son travail. Un logiciel réussi peut apporter la gloire et la richesse alors qu’un échec d’un produit destiné à une utilisation à grande échelle pourrait s’avérer désastreux. Le développeur veut donc produire quelque chose de parfait et cela peut parfois l’inciter à développer de nouvelles fonctionnalités. Ce que certains développeurs ne mesurent souvent pas, c’est que l’ajout de nouvelles fonctionnalités a un coût et un risque de mise en œuvre. Une fois que les exigences sont déjà définies, le calendrier est établi et le budget verrouillé. L’ajout de nouvelles fonctionnalités va donc nécessiter plus de temps et générer des coûts supplémentaires.

Une autre erreur fatale liée au vice de perfectionnisme est de ne pas savoir quand arrêter le développement et livrer quelque chose au client. Un logiciel n’est jamais parfait, mais il arrive un moment où il peut être déjà libéré. Le développeur doit savoir s’arrêter à ce moment et donner quelque chose d’utilisable aux clients. Il y aura toujours la possibilité de faire des mises à jour sur le terrain, après que le logiciel ait été déployé.

L’orgueil est également un vice qui peut miner un projet. Selon Cohen, ce serait une erreur grave pour le développeur d’exclure la possibilité d’un échec. Envisager la possibilité d’un échec ne contribue qu’à aider le développeur, qui sera plus avisé pour ne pas commettre les autres erreurs.

Source : oreilly.com

Et vous ?

:fleche: Qu’en pensez-vous ?

J'avoue ne pas avoir lu l'intégralité de l'article, parcourant la seconde moitié en diagonale. Mais, bien que je n'aime pas beaucoup le concept "d'évidence" balancé trop souvent à tort (tout le monde ne trouve pas naturel ce que certains prennent pour acquis), ici j'ai du mal à comprendre comment on peut ne pas trouver totalement logique et inné ce qu'affirme Cohen. Il ne nous apprend rien de concret et se contente simplement de défoncer des portes déjà largement ouvertes. Et ce sur tous les points qu'il soulève. Je doute qu'un développeur puisse aujourd'hui agir dans le sens des "pêchés mortels" qu'il évoque, à moins que ce même développeur n'ait tout simplement jamais travaillé pour qui que ce soit d'autre que lui-même. Et encore, même dans ce cas certains ne sont tout simplement pas envisageables pour peu que la personne ait le minimum des compétences requises pour mener un projet jusqu'à son terme.

Je suis assez d'accord avec DarkBakura, on n'apprend rien de nouveau... Au final, ces recommandations on les retrouve dans les méthodes Agile/Scrum.

Citation:

---

Envoyé par DarkBakura

J'avoue ne pas avoir lu l'intégralité de l'article, parcourant la seconde moitié en diagonale. Mais, bien que je n'aime pas beaucoup le concept "d'évidence" balancé trop souvent à tort (tout le monde ne trouve pas naturel ce que certains prennent pour acquis), ici j'ai du mal à comprendre comment on peut ne pas trouver totalement logique et inné ce qu'affirme Cohen. Il ne nous apprend rien de concret et se contente simplement de défoncer des portes déjà largement ouvertes. Et ce sur tous les points qu'il soulève. Je doute qu'un développeur puisse aujourd'hui agir dans le sens des "pêchés mortels" qu'il évoque, à moins que ce même développeur n'ait tout simplement jamais travaillé pour qui que ce soit d'autre que lui-même. Et encore, même dans ce cas certains ne sont tout simplement pas envisageables pour peu que la personne ait le minimum des compétences requises pour mener un projet jusqu'à son terme.

---

Citation:

---

Envoyé par hbomb

Je suis assez d'accord avec DarkBakura, on n'apprend rien de nouveau... Au final, ces recommandations on les retrouve dans les méthodes Agile/Scrum.

---

Pour vous cela semble être une évidence, mais ça l'est au moment ou on vous le met sous les yeux. Dans le feux de l'action, on a parfois tendance à l'oublier car d'autre paramètres vien vous polluer l'esprit. Le manque de temps, l'envie de trop bien faire, l'envie d'utiliser une petite techno, être à quelque jours des vacances, le faite de faire plusieurs chose à la fois, etc.

En fait, tous ces péchés peuvent être évités avec l'application correcte d'une méthode Agile comme SCRUM: cela évite l'effet tunnel, le client est proche du développement, etc...

*Edit*
Ah, je vois que j'ai été devancé sur la mention de SCRUM ;)

En fait A. Cohen fait plutôt référence au Lean Startup.

Le "Client", c'est le marché. Et les techniques de Lean Starup sont là pour aider à mettre un produit sur le marché, le plus rapidement possible et si possible qui correspondent le mieux aux besoins du marché.
On est encore dans des techniques agiles/itératives mais spécifiques au lancement d'un produit sur un marché.
Pour les parties spécifiques au développement logiciel n'importe quelle techniques agiles pourra être mise en oeuvre, Scrum, Kanban, etc...

Citation:

---

Envoyé par spidetra

En fait A. Cohen fait plutôt référence au Lean Startup.

Le "Client", c'est le marché. Et les techniques de Lean Starup sont là pour aider à mettre un produit sur le marché, le plus rapidement possible et si possible qui correspondent le mieux aux besoins du marché.
On est encore dans des techniques agiles/itératives mais spécifiques au lancement d'un produit sur un marché.
Pour les parties spécifiques au développement logiciel n'importe quelle techniques agiles pourra être mise en oeuvre, Scrum, Kanban, etc...

---

Effectivement, d'ailleurs je regarderai cette méthode qui du coup s'adresse plus à une démarche d'éditeur grand public, non? Quelque chose d'assez adapté aux applications SmartPhone?

Sinon, de mon expérience, SCRUM s'applique bien pendant une phase projet et Kanban pendant une phase de TMA, les rythmes et cadences étant assez différents.

Oui, l'objectif du Lean Startup c'est de designer de manière itérative des produits qui s'adressent à un large public.
Cette technique s'applique plutôt aux startups IT qui veulent attaquer rapidement un marché.

Dans le livre de A. Cohen (et les 4 ou 5 livres qui tournent autour), les différents auteurs adaptent ces techniques aux produits hardware, principalement pour le marché IoT.
L'article semble enfoncer des portes ouvertes. Mais ce n'est que le résumé du premier chapitre d'un livre.
Pour vraiment de faire une idée de ce que pense l'auteur il faudrait lire le livre en entier.

Citation:

---

Envoyé par berceker united

Pour vous cela semble être une évidence, mais ça l'est au moment ou on vous le met sous les yeux. Dans le feux de l'action, on a parfois tendance à l'oublier car d'autre paramètres vien vous polluer l'esprit. Le manque de temps, l'envie de trop bien faire, l'envie d'utiliser une petite techno, être à quelque jours des vacances, le faite de faire plusieurs chose à la fois, etc.

---

Sur un instant T je ne nie pas qu'on peut se retrouver face à cette situation. C'est même très humain selon le contexte de l'instant. Mais j'évoquais un projet sur son ensemble. Sur sa durée totale, le bon sens incite à ne pas se lancer dans les "pêchés mortels" qu'évoque Cohen. Et je pense que même sans être un adepte absolu des méthodes agiles le développeur d'aujourd'hui est conscient de cela.

Citation:

---

Envoyé par DarkBakura

Sur un instant T je ne nie pas qu'on peut se retrouver face à cette situation. C'est même très humain selon le contexte de l'instant. Mais j'évoquais un projet sur son ensemble. Sur sa durée totale, le bon sens incite à ne pas se lancer dans les "pêchés mortels" qu'évoque Cohen. Et je pense que même sans être un adepte absolu des méthodes agiles le développeur d'aujourd'hui est conscient de cela.

---

Mais le décideur? Le décideur qui a soudain besoin d'un projet informatique, lui, ne sait rien de tout cela(et c'est normal).

Citation:

---

Envoyé par el_slapper

Mais le décideur? Le décideur qui a soudain besoin d'un projet informatique, lui, ne sait rien de tout cela(et c'est normal).

---

Ca fait partie du métier, arriver à faire comprendre au décideur que la réalité technique n'est pas forcément compatible avec sa vision optimale des choses. Que le développeur qui semblerait lui faire perdre du temps vis-à-vis de son besoin ne le fait que pour optimiser le produit final et répondre au mieux à ses attentes. Il n'a pas la connaissance que nous avons, tout comme nous manquons forcément de données concernant ses enjeux et sa vision de son métier, et ce même après l'avoir questionné.

Cela dit, je suis bien conscient, pour le voir au quotidien, que ce n'est pas une tâche facile, voire même possible selon le décideur ou l'environnement. Si tout était si simple, ça se saurait. Mais comme le sujet était axé autour du développeur plus que du reste, je me suis autorisé ce constat.
Dans les faits, on sait que ce n'est pas toujours possible de mener "parfaitement" son projet, pour bien des raisons. Mais ce que je voulais dire par mes messages, c'est qu'initialement ce n'est pas censé être inhérent à la logique du développeur. Seulement lié à son environnement qui lui permet - ou non - de s'exprimer correctement dans son métier. De base, je pense qu'aucun développeur ne peut être autant à côté de la plaque que les points noirs soulevés par Cohen.

Citation:

---

Envoyé par DarkBakura

De base, je pense qu'aucun développeur ne peut être autant à côté de la plaque que les points noirs soulevés par Cohen.

---

Sauf que le propos de A. Cohen ne s'applique pas uniquement au domaine du software. Par exemple relis uniquement le #1 de l'article original.
Dans de l'intégration hardware (en cours de dév) + software ( en cours de dév ) + sous-systèmes mécaniques ( en cours de dev ), il est très facile de tomber dans les pièges évidents qui sont énoncés. Même si tout les membres des différentes équipes ont conscience de ces pièges.

Citation:

---

Envoyé par spidetra

Même si tout les membres des différentes équipes ont conscience de ces pièges.

---

Ca rejoint donc ce que je dis. =)

J'ai parlé des développeurs mais tu as raison évidemment, toutes les équipes sont concernées. Et encore une fois, je sais bien que dans les faits, même avec la meilleure des volontés, il est compliqué de pouvoir mener un projet de bout en bout sans tomber dans certains travers. C'est même normal, puisque plus les acteurs sont multiples, plus la cohésion en pâtit. Mais tous savent, normalement, quelles sont les bonnes pratiques, même si leur mise en application n'est pas forcément possible. C'est ce que je voulais dire depuis le départ.

Citation:

---

Envoyé par Michael Guilloux

:fleche: Qu’en pensez-vous ?

---

Cet article est un plébiscite aux méthodes Agile.
Tous les "péchés mortels" sont gérés et/ou corrigés par l'Agile...
Bref, rien de révolutionnaire

je trouve que ces péchés exposé sont réelles dans chaque étapes du développement d'une application et j'en prend note..

Citation:

---

Envoyé par Saverok

Cet article est un plébiscite aux méthodes Agile.
Tous les "péchés mortels" sont gérés et/ou corrigés par l'Agile...
Bref, rien de révolutionnaire

---

C'est bien pour ça que la méthode Agile existe, l'article ne fait que dire pourquoi celui-ci existe.

Article qui n'apporte que peu de valeur.

Le premier point est déjà très bof
"La première chose à retenir est qu’il ne faut jamais remettre à demain ce que l’on peut faire aujourd’hui."

Souvent des tâches sont pas très bien définies! Il faut aussi attendre que la tâche soit "mature".

Parfois une tâche peut être mature qu'après avoir fait une autre tâche qui nous permet de comprendre la première tâche.

Si on se lance directement, on a le risque de faire du travail sans forcement avoir compris le but de ce travail. Et comme on a "commencé à coder", on a de la peine à mettre le travail effectué à la poubelle - donc on continue dans une voie qui peut être fausse.

Citation:

---

Envoyé par gabriel.klein

Article qui n'apporte que peu de valeur.

Le premier point est déjà très bof
"La première chose à retenir est qu’il ne faut jamais remettre à demain ce que l’on peut faire aujourd’hui."

Souvent des tâches sont pas très bien définies! Il faut aussi attendre que la tâche soit "mature".

Parfois une tâche peut être mature qu'après avoir fait une autre tâche qui nous permet de comprendre la première tâche.

Si on se lance directement, on a le risque de faire du travail sans forcement avoir compris le but de ce travail. Et comme on a "commencé à coder", on a de la peine à mettre le travail effectué à la poubelle - donc on continue dans une voie qui peut être fausse.

---

En faite non c'est pas idiot. "il ne faut jamais remettre à demain ce que l’on peut faire aujourd’hui". Si tu peux le faire aujourd'hui c'est que la problématique que tu décris n'existe pas. Si nous suivons ta logique, tu attendras le dernière jour avant livraison en attendant d'être sur d'avoir tout le besoin. :aie:

Citation:

---

Une autre erreur à ne pas commettre est de se dire également que les utilisateurs savent ce dont ils ont besoin. Selon l’auteur du livre « Prototype to product », il se trouve souvent que ces derniers ne savent pas non plus ce qu’ils veulent mais plutôt ce qu’ils pensent qu’ils veulent. L’idéal serait donc de leur donner quelque chose à tester le plus vite possible - afin d’identifier leurs besoins réels - au lieu d’attendre jusqu’à la fin du développement.

---

cela me rappelle une expérience :
j'avais intégré une structure pour laquelle je devais apporter de nouvelles fonctionnalités à leur applicatif (un ERP opensource fait maison et très bien conçu -aka très modifiable simplement).

Les utilisateurs quotidiens me demandaient une nouvelle fonctionnalité pour leur simplifier la vie dans l'ERP: j'ai répondu qu'elle était possible et facile à développer sans problème.
Le chef des utilisateurs me demandait une autre fonctionnalité pour empêcher ses subordonnée (donc les utilisateurs du logiciel au quotidien) de faire des erreurs : cette fonctionnalité était plus difficile à mettre en oeuvre mais faisable également.

J'ai ensuite proposé à ce même chef, une autre fonctionnalité qui aurait permis au logiciel de faire tout seul le boulot (souvent eronné) que faisait ses utilisateurs avec l'ERP (en gros que les utilisateurs n'allaient plus avoir besoin de travailler avec cet ERP du tout et que le chef allait avoir le résultat instentanément en cliquant sur un bouton (+ des paramètres).

Le chef a refusé cette fonctionnalité est m'a répondu (ça m'avait marquée) : non car si ils n'ont plus de travail à faire, je n'ai donc plus de responsabilité à les surveiller et je ne serais plus chef. Et surtout qu'elle ne voulait pas être responsabilisé d'avoir appuyer sur le bouton qui fait tout à leur place.
Je lui avais rétorqué en gros qu'en leur enlevant cette tâche et en la faisant faire par l'outil informatique, ils allaient tous y gagner en temps/argent (environs 4jours/h par semaine) et qu'il pourrait profiter de ce gain temps pour leurs faire faire autre chose de plus utile en qualité/process que ces vulgaires tâches répétitives sur l'ERP (recherches,filtres,planifications suivant des règles simples).
Le chef avait eu le dernier mot en disant quelque chose comme "contrairement à vous, mon boulot ne consiste pas à remplacer le travailler des hommes par des machines" mais à maintenir mon propre travail et à me rendre utile...

Mais par définition, on n'est pas vraiment utile si le travail qu'on fait peut être exécuté par une machine...

PS : en même temps, dans mon métier (prof), on va aussi finir par être remplacés par des machines.

Citation:

---

Envoyé par Ymer Leahcim

cela me rappelle une expérience :
j'avais intégré une structure pour laquelle je devais apporter de nouvelles fonctionnalités à leur applicatif (un ERP opensource fait maison et très bien conçu -aka très modifiable simplement).

Les utilisateurs quotidiens me demandaient une nouvelle fonctionnalité pour leur simplifier la vie dans l'ERP: j'ai répondu qu'elle était possible et facile à développer sans problème.
Le chef des utilisateurs me demandait une autre fonctionnalité pour empêcher ses subordonnée (donc les utilisateurs du logiciel au quotidien) de faire des erreurs : cette fonctionnalité était plus difficile à mettre en oeuvre mais faisable également.

J'ai ensuite proposé à ce même chef, une autre fonctionnalité qui aurait permis au logiciel de faire tout seul le boulot (souvent eronné) que faisait ses utilisateurs avec l'ERP (en gros que les utilisateurs n'allaient plus avoir besoin de travailler avec cet ERP du tout et que le chef allait avoir le résultat instentanément en cliquant sur un bouton (+ des paramètres).

Le chef a refusé cette fonctionnalité est m'a répondu (ça m'avait marquée) : non car si ils n'ont plus de travail à faire, je n'ai donc plus de responsabilité à les surveiller et je ne serais plus chef. Et surtout qu'elle ne voulait pas être responsabilisé d'avoir appuyer sur le bouton qui fait tout à leur place.
Je lui avais rétorqué en gros qu'en leur enlevant cette tâche et en la faisant faire par l'outil informatique, ils allaient tous y gagner en temps/argent (environs 4jours/h par semaine) et qu'il pourrait profiter de ce gain temps pour leurs faire faire autre chose de plus utile en qualité/process que ces vulgaires tâches répétitives sur l'ERP (recherches,filtres,planifications suivant des règles simples).
Le chef avait eu le dernier mot en disant quelque chose comme "contrairement à vous, mon boulot ne consiste pas à remplacer le travailler des hommes par des machines" mais à maintenir mon propre travail et à me rendre utile...

---

De ton point de vu cela te semble ridicule mais son point de vu est compréhensible. Il a compris que si tu réduis les tâches par personne, c'est pas pour en donner d'autre. Un autre va faire le calcule suivant : 4 jours homme par semaine de gagné alors ça fait 16 jours par mois et par tête = Suppression de poste. Si tu supprimes des postes alors il faudra pas de responsable, donc lui il saute.

Cet article semble n'être vu que sous l'angle technique.
Certains point sont une conséquence justement d'un relâchement dans la qualité des livrables avant développement.
La méthode scrum ne doit pas être un justificatif, ni un palliatif aux mauvaises analyses.
Le développeur ne devrait travailler qu'avec des livrables et pas faire ce qui lui plaît.

Citation:

---

Envoyé par berceker united

De ton point de vu cela te semble ridicule mais son point de vu est compréhensible. Il a compris que si tu réduis les tâches par personne, c'est pas pour en donner d'autre. Un autre va faire le calcule suivant : 4 jours homme par semaine de gagné alors ça fait 16 jours par mois et par tête = Suppression de poste. Si tu supprimes des postes alors il faudra pas de responsable, donc lui il saute.

---

oh mais je l'avais compris.
là où j'ai pas compris, c'est la peur de la personne "chef" et sa non-volonté à vouloir améliorer l'entreprise où elle bosse et la vie de ses saalriés subordonnés en leur faisant faire autrechose de qualitatif.
Depuis j'ai compris que lorsqu'on se rend compte d'une solution comme ça (réduisant les tâches itératives d'un groupe de personnes), il ne faut surtout pas en parler au chef, mais au supérieur hierarchique du chef (1 degrés de subordination plus haut).

Citation:

---

Envoyé par Ymer Leahcim

oh mais je l'avais compris.
là où j'ai pas compris, c'est la peur de la personne "chef" et sa non-volonté à vouloir améliorer l'entreprise où elle bosse et la vie de ses saalriés subordonnés en leur faisant faire autrechose de qualitatif.
Depuis j'ai compris que lorsqu'on se rend compte d'une solution comme ça (réduisant les tâches itératives d'un groupe de personnes), il ne faut surtout pas en parler au chef, mais au supérieur hierarchique du chef (1 degrés de subordination plus haut).

---

Heu je suis pas sure. Bypasser un chef peut être mal perçu selon les cas. :aie:
En faite, c'est un situation complexe. Cela dépend de plusieurs paramètres qui sont en dehors du domaine technique. J'ai découvers ce cas dans le secteur bancaire ou je suis actuellement.
- Arriver à un certain âge, des utilisateurs n'aiment pas le changement, même si ça va dans le bon sens. Changement = bouleversement.
- Si tu proposes quelque chose qui fait gagner du temps en améliorant le process, tu créés du vide, et il faut le remplir. Vide = payer à rien faire et on connait les risques.
- L'orgeil du chef et le risque de voir de l'arrogance sur une personne qui arrive avec des idées.

Il faut être diplomate heu non, fourbe
http://pangloss.blog.lemonde.fr/file....thumbnail.jpg

Citation:

---

Envoyé par josuekakomba

je trouve que ces péchés exposé sont réelles dans chaque étapes du développement d'une application et j'en prend note..

---

Moi également.

Citation:

---

Envoyé par Ymer Leahcim

Le chef a refusé cette fonctionnalité est m'a répondu (ça m'avait marquée) : non car si ils n'ont plus de travail à faire, je n'ai donc plus de responsabilité à les surveiller et je ne serais plus chef. Et surtout qu'elle ne voulait pas être responsabilisé d'avoir appuyer sur le bouton qui fait tout à leur place.

---

Peut être que toi aussi tu aurais été viré.Bon juste pour rire :mrgreen:

Citation:

---

Envoyé par landry161

Peut être que toi aussi tu aurais été viré.Bon juste pour rire :mrgreen:

---

je double-rire !
car en fait c'est ce qu'il s'est passé pour moi dernièrement : je me suis rendue inutile en format tout le monde aux tâches informatiques de base, en résolvant tous les bugs applicatif, proposant dans mon agence (une SSII) de vendre plutôt des CMS au lieu d'avoir des sites sur mesure....
et au fil du temps, mon ex-patron avait moin de choses lourdes et concrêtes à me faire faire.
un site conçu intégralement c'est 100% d'ingenierie
un CMS c'est 90% de tâches bureatiques et 10% de tâches d'admin-ingénierie

En gros, j'ai été le maçon qui a éveillé et conseillé son patron à la vente de maison préfabriquées. c'était il y a 4ans.
aujourd'hui quand je vois la conception des sites internet, c'est 9/10 qui sont des CMS et 95% ont un template acheté à 30$ légèrement modifié par un stagiaire webdesigner....

Citation:

---

Envoyé par Ymer Leahcim

je double-rire !
car en fait c'est ce qu'il s'est passé pour moi dernièrement : je me suis rendue inutile en format tout le monde aux tâches informatiques de base, en résolvant tous les bugs applicatif, proposant dans mon agence (une SSII) de vendre plutôt des CMS au lieu d'avoir des sites sur mesure....
et au fil du temps, mon ex-patron avait moin de choses lourdes et concrêtes à me faire faire.
un site conçu intégralement c'est 100% d'ingenierie
un CMS c'est 90% de tâches bureatiques et 10% de tâches d'admin-ingénierie

En gros, j'ai été le maçon qui a éveillé et conseillé son patron à la vente de maison préfabriquées. c'était il y a 4ans.
aujourd'hui quand je vois la conception des sites internet, c'est 9/10 qui sont des CMS et 95% ont un template acheté à 30$ légèrement modifié par un stagiaire webdesigner....

---

Beh désolé :calim2:

Je suis d'accord avec le fait que Cohen défonce les portes déjà grandement ouvertes, mais dans un domaine où l'autre de la vie, il y a toujours un débutant pour qui des conseils peuvent être donnés !

Citation:

---

Envoyé par Ymer Leahcim

je double-rire !
car en fait c'est ce qu'il s'est passé pour moi dernièrement : je me suis rendue inutile en format tout le monde aux tâches informatiques de base, en résolvant tous les bugs applicatif, proposant dans mon agence (une SSII) de vendre plutôt des CMS au lieu d'avoir des sites sur mesure....
et au fil du temps, mon ex-patron avait moin de choses lourdes et concrêtes à me faire faire.
un site conçu intégralement c'est 100% d'ingenierie
un CMS c'est 90% de tâches bureatiques et 10% de tâches d'admin-ingénierie

En gros, j'ai été le maçon qui a éveillé et conseillé son patron à la vente de maison préfabriquées. c'était il y a 4ans.
aujourd'hui quand je vois la conception des sites internet, c'est 9/10 qui sont des CMS et 95% ont un template acheté à 30$ légèrement modifié par un stagiaire webdesigner....

---

Mais tu as fais ton ton boulot et dans le bon sens. Il y a des endroits ou des personnes freinent des 4 fers pour maintenir une certaine dépendance envers eux. Donc quand un jeune coq arrive avec de bonne idées pour améliorer la productivité ça vole dans les plumes.

Citation:

---

Envoyé par Ymer Leahcim

En gros, j'ai été le maçon qui a éveillé et conseillé son patron à la vente de maison préfabriquées. c'était il y a 4ans.
aujourd'hui quand je vois la conception des sites internet, c'est 9/10 qui sont des CMS et 95% ont un template acheté à 30$ légèrement modifié par un stagiaire webdesigner....

---

Effectivement...et la grande question, c'est combien de ces sites sont-ils vraiment vivants et bien référencés. Depuis que je bosse dans le web, j'ai vu je ne sais combien de fois arriver un client avec un plaquette (pour les pires) et me dire "je veux ça sur mon site web". J'ai passé un temps fou à expliquer que ce ne sont pas les mêmes médias et surtout qu'un site doit être vivant sinon il tombe aux oubliettes. Et là j'ai eu plus que souvent la réponse "mais je n'ai personne pour alimenter le site", sans parler du "mais qu'est-ce qu'on va mettre dedans?"

Donc un site fait "à la va comme je te pousse" sans réflexion, ça ne sert à rien. Autant le faire en HTML statique (je grossis le trait volontairement). En fait ces sites ne sont pas réfléchis et les gens ne veulent pas y consacrer de temps ni d'argent.

Cet article est un assez bon résumé de ce que j'ai pu rencontrer comme difficultés en trente années de carrière.
Parler de péchés à des informaticiens est évidemment une habile provocation. Le cerveau des informaticien est tout particulièrement rôdé à pourfendre les croyances par l'épreuve des faits. Cela est assez peu compatible avec une quelconque piété.
Cependant les avanies de la relation client/développeur ne sont qu'une des variations du thème de la conflagration des univers mentaux.
Un récent exemple m'a montré que bien des biais apparaissent quand des médecins élaborent un texte réglementaire avec des sportifs.
Il n'est pourtant pas inutile de s'atteler à en démontrer les mécanismes.

Identification ronflante de problèmes déjà connus depuis longtemps et que tous les méthodes de développement essaie de résoudre... Si on parle toujours et toujours de ces problèmes de développement, c'est peut-être parce qu'aucune méthodologie de développement, Agile ou autre, apporte un véritable solution pleinement satisfaisante à ces problèmes! Il faudrait peut-être arrêter de parler de problèmes et de s'attaquer à de véritables solutions innovatrices. Pour ma part, Agile a fait des efforts mais n'en déplaisent à ses admirateurs n'est pas LA solution.

<troll> "... l'auteur, Harlan Coben, ...". Lololol :) </troll>

Citation:

---

Envoyé par ChristianRoberge

Pour ma part, Agile a fait des efforts mais n'en déplaisent à ses admirateurs n'est pas LA solution.

---

Agile permet de simplifier les choses et de faire communiquer les différents intervenants...à condition de se poser les bonnes questions.

D'expérience quand un sujet a du mal à arriver à terme, je finis par poser la question "C'est quoi le besoin" et là, assez régulièrement, j'ai pu constater une différence assez notable entre la réponse donnée à cet instant et ce qui a été écrit dans les spèc. On en revient souvent à ce" problème d'expression, voire d'identification, du besoin.

Citation:

---

Envoyé par tanatiel

D'expérience quand un sujet a du mal à arriver à terme, je finis par poser la question "C'est quoi le besoin" et là, assez régulièrement, j'ai pu constater une différence assez notable entre la réponse donnée à cet instant et ce qui a été écrit dans les spèc. On en revient souvent à ce" problème d'expression, voire d'identification, du besoin.

---

Oui mais là, tu n'abordes qu'une partie du sujet.
Il y a aussi le cas où le besoin évolue, tout simplement.
Lorsque l'on met le client en situation de marché, avec la concurrence mondiale qui ne s'arrête jamais, il faut s'avoir s'adapter.


Sur un projet court, ça n'a pas de raison d'arriver
mais dès que le projet s'étale dans le temps...

Citation:

---

Envoyé par Saverok

avec la concurrence mondiale qui ne s'arrête jamais, il faut s'avoir s'adapter.

Sur un projet court, ça n'a pas de raison d'arriver
mais dès que le projet s'étale dans le temps...

---

Forcement

Citation:

---

Envoyé par landry161

Forcement

---

Ecrit comme ça, oui.
Mais dans les faits, beaucoup ont du mal à le comprendre et/ou à l'accepter.

Il y a quelque temps, quand j'ai quitté le monde des sociétés de services pour passer côté client, j'ai eu à mon arrivée une discussion de ce type :
"
* Ce que tu me demandes ne correspond pas au SFD
* oui, mais le SFD a été écrit il y a 4 mois...
* je m'en fous, le SFD c'est le SFD !!
"
Je te laisse deviner lequel des interlocuteurs j'étais et ce qu'il est advenu du presta lorsqu'il est arrivé le moment de renouveler sa mission...

Citation:

---

Envoyé par Saverok

Ecrit comme ça, oui.
Mais dans les faits, beaucoup ont du mal à le comprendre et/ou à l'accepter.

Il y a quelque temps, quand j'ai quitté le monde des sociétés de services pour passer côté client, j'ai eu à mon arrivée une discussion de ce type :
"
* Ce que tu me demandes ne correspond pas au SFD
* oui, mais le SFD a été écrit il y a 4 mois...
* je m'en fous, le SFD c'est le SFD !!
"
Je te laisse deviner lequel des interlocuteurs j'étais et ce qu'il est advenu du presta lorsqu'il est arrivé le moment de renouveler sa mission...

---

Disons que dans un projet où tout va bien, il est facile de faire des concessions et donc d'assouplir les règles et par conséquent d'accepter des modifications des SFD. Par contre quand le projet va mal et que tout le monde se braque et se cache derrière son contrat, le moindre changement peut poser problème...

Personnellement, quand je pose la question du "C'est quoi le besoin", c'est pour forcer l'interlocuteur à reformuler et ainsi à confirmer son besoin. Ensuite si son besoin correspond bien à ce qui était écrit, pas de souci on continue. Si ça diffère, on se pose et on réfléchit aux impacts de ce changement et à comment le prendre en compte. Agile n'est qu'une boite à outil permettant de gérer cette situation en donnant des règles simples et partagées pour la prise de décision.

La gestion des erreurs dans la développement d'une application est a notée pas facile:mouarf::ptdr: