Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Sur les maquettes je suis mitigé, mais effectivement on peut concevoir.Envoyé par xelab
Quelque part, une maquette implique qu'il y a déjà un choix de solution (est ce que c'est une appli web, desktop, mobile, etc) lié au besoin métier (qui lui n'a pas forcément de contraintes technologiques).
Pour le coup ça dépend vraiment de la demande. Si le client veut un site internet destiné au public, c'est pas la même chose qu'une application métier répondant aux besoins spécifiques d'une entreprise. Dans le premier cas des prototypes de maquettes me semblent indispensables, pas dans le deuxième puisque là on ne sait effectivement pas quelle technologie on va utiliser.
Ce que dit Souviron sur le recueil des besoins me parle tout à fait en ce moment. Je suis actuellement dans une entreprise qui réussit le tour de force de réduire d'un tiers la taille des cahiers des charges que le client donne en préalable et qui pense qu'on peut apprécier les besoins du client qu'au fur et à mesure du développement, le cahier des charges n'étant qu'un vague débroussaillage du domaine. Je peux vous assurer que même les petits projets deviennent très flous et au final c'est un énorme plantage (du coup chômage pour moi très bientôt). Bref, je crois bien que ma boîte applique la Rache en fait...
ben je veux bien être appelé en consultation dans ta boite pour tenter de les former un peu
Sérieusement ça me désespère... Des gens ont passé un temps et une énergie considérables pour réfléchir à voir pourquoi leurs projets ne marchaient pas et en on déduit quelques principes simples...
Principes qui ont été par la suite dévoyés, d'une part en des "guides" ou "méthodologies" - les managers (et jeunes devs) ne pouvant fonctionner sans "manuels" ou "méthodes" , et d'autre part par une course marketing et jeuniste qui les ont transformés en n'importe quoi, mais surtout pas le "traditionnel"...
Pourtant c'est pas compliqué, hein, les 6 ou 7 points du Manifeste ?
Et surtout, ce qui est lamentable, c'est de ne pas voir que ces points s'appliquent à une méthodologie traditonnelle (qu'il faut donc connaitre et maitriser absolument), en la rendant souple..... Et non pas en la mettant à la poubellle...
Qui parle de "progrès" ???
On arrête pas le progrès, dit-on.
Mais cela ne donne aucune assurance qu'il aille dans la bonne direction.
La base du problème est commun à bien des dysfonctionnements propres à notre époque, et il peut être décrit simplement: l'entreprise a été pensé pour servir l'humain, aujourd'hui c'est l'inverse qui se passe.
Ton analyse me semble quelque peu orientée
Pour ma part je pense qu'effectivement c'est commun à bien des dysfonctionnements propres à notre époque, mais pas ceux que tu identifies...
Moi je vois comme points principaux :
- La volonté croissante de croire que tout le monde peut faire tout, en particulier des boulots intellectuels, comparé à avant - jusqu'à la génération de mes grands-parents (nés à la fin du XIX, jeunes à la Guerre de 14)
- La croyance croissante que un bon peut mettre sur le papier ce qu'il fait et que du coup un moins bon pourra le faire. Un anti-élitisme ras des pâquerettes mais idiot (personne ne peut être Mozart, Pink Floyd, J.M. Jarre, ou Steve Jobs à part Mozart, Pik Floyd, J.M. Jarre, ou Steve Jobs)
- La croyance persistente depuis le début des grosses boites informatiques que l'informatique est industrielle et non artisanale (l'aspect création est négligé, voire volontairement effacé)
A cause des points 1 et 3, auxquels on ajoute Internet et la déculturation croissante (par force, avoir 90% d'une classe d'age qui a le bac fait que les connaissances nécessaires sont plus faibles que quand ce n'était que 15%), une non-réflexion par rapport à ce qui est dit, écrit, ou pensé, et une ignorance de ce qui s'est passé avant....
Or, en info comme en Histoire comme en Politique, le passé est la base de la construction du présent et du futur...
La conséquence de tout ça est l'entreprise a été pensée pour servir l'humain, aujourd'hui c'est l'inverse qui se passe., car, comme pour les dictatures, cela se base sur l'ignorance et la "remplacabilité"...
Il faut combattre l'ignorance, et il suffirait de refuser cet "anti-élitisme" pour éliminer le problème "remplaçabilité"... Mais l'air du temps est à une certaine vision de la "société démocratique", plus sournoise et perverse car elle nie en apparence l'élitisme tout en le cajolant par derrière....
Ca devient philosophique cette discussion mais sur la devise de la France, "Egalité" est bien trop souvent prise au pied de la lettre.
En effet, comme le rappelle la DDHC :
Or bien trop souvent, on oublie le point souligné et on pense à une égalité en capacité (physique et mentale) qui, bien évidemment, est contre nature.Les hommes naissent et demeurent libres et égaux en droits
Mouais.
Je n'ai pas l'impression qu'il y a une croyance du "tout le monde peut tout faire". En tout cas pas dans les entreprises dans lesquelles j'ai travaillé. En général (il y a des exceptions bien sûr, mais en général), les gens savent à quoi ils sont bons, à quoi ils sont mauvais, et qu'ils ne sont pas des génies. J'ai rarement rencontré, par exemple, des développeurs qui s'estiment aussi balaise qu'un Torvald ou un Alexandrescu. Parfois on voit ça chez les débutants, mais ça disparait très vite après qu'il se soit rendu compte que ce ne sera pas lui qui développera le nouvel O.S. qui va révolutionner l'informatique.
Nan, moi je crois que le problème vient du fait que la pression du capital (besoin de rentabilité forte et à court terme) ne nous permet pas de faire bien le travail. Et cela ne concerne pas que le développeur, ça va des femmes de ménages (qui sont de plus en plus des hommes d'ailleurs) aux managers. Et ça engendre des cahiers des charges incohérents, flous, parfois juste faux bref, intenables.
En même temps, vu la question, ça pourrait presque sortir au bac de philo {^_^}.
Bonjour.
J'aime beaucoup cette intervention de Souviron.
Une preuve sur le côté artisanal : deux informaticiens qui écriront le même programme dans le même langage auront des codes sources différents. Le résultat global sera plus ou moins identique, mais avec des nuances (plus ou moins optimisé, plus ou moins maintenable, etc...).
- Il y en a qui pense qu'en lisant un article d'Einstein sur la théorie de la relativité sur internet, il est facile de comprendre cette théorie.
Dans la même idée, avec Einstein, il ne suffit pas de lire un article, il faut aussi faire le même cheminent intellectuel pour comprendre l'article. Donc oui, lire un bout de papier ne suffit pas.
Oui l'idée générale s'appelle l'expérience:
Une citation de Louis-Ferdinand Céline (ou de Confucius):
L'expérience est une lanterne qui n'éclaire que celui qui la porte.
Justement, j'ai eu un chef d'équipe (CTO) qui une fois le produit maison était quasi complet (juste de la maintenance et un peu d’évolution - ajout d'un codec, ajout d'un format de fichier ...) et avec 4-5 ans d'utilisation chez les clients, c'est reposé sur ses lauriers
Même si le client était satisfait et que le produit était fonctionnel et répondait aux besoins, je trouve cela bête de ne pas regarder comment on aurait plus coder telle ou telle fonctionnalité autrement et de ne pas anticiper l'avenir (faire de la R&D):
C'est le côté 'Je suis développeur et j'ai plein d'étoiles dans les yeux'
Mais, ayant codé des applications iPhone/ iPad dans une agence de communication, j'ai vu que si ta première version est mauvaise c'est fini.
La très grosse majorité des gens ne reviendront pas, surtout si la concurrence propose mieux.
Et il y aura presque toujours les traces des retours utilisateur sur Internet
Donc le côté artisanal cela fait rêver, faire du beau code c'est cool, implémenter telle ou telle technologie c'est intéressant.
Mais on s'en fiche: on veut des produits fonctionnels qui font ramener du client, de la communauté et de l'argent.
Et pour cela il faut mettre en place "une stratégie industrielle" à tous les niveaux.
@foetus:
ça dépend de quel type de logiciel on parle aussi.
Pour un "one shot" dans le genre une appli qui fait des pets sur smart phone, ok, on s'en fiche de la qualité du code; l'important c'est que ça marche et que ce soit sexy.
Mais si on parle de grosses applis industrielles, avec un forfait maintenance et support sur plusieurs années (ce qui signifie qu'il faudra faire des mises à jour régulièrement, donc modifier constamment le code) et plusieurs développeurs travaillant dessus (ce qui implique diverses contraintes sur la qualité du code, en particulier la modularité), alors là oui, la qualité du code est primordiale. Et donc, la qualité du cahier des charges aussi.
@r0d
Pas d'accord.Il faut penser que derrière une application iPhone - iPad/ Android c'est un prestataire, une agence mobile comme il s'auto-proclame qui fait aussi des sites Internet
Et des portions de code sont réutilisées de partout, afin d'avoir le plus de projets, de mettre une grosse partie des développeurs sans trop d'expérience.
Voire d'attirer le client avec des délais très courts (mais le prix de l'application baisse)
Et donc lorsque tu as environ 20 projets (de tout poil) avec 2 à 4 équipes de 2 à 6 développeurs et des graphistes (parce que il faut aussi gérer les assets) et peut-être que tu travailles avec un autre prestataire (pour des fonctionnalités précises: la réalité augmentée), il ne suffit pas d'un CVS ou d'un git pour que cela marche
C'est assez marrant de faire porter le chapeau aux seuls développeurs quand l'expression de besoin n'est elle-même pas ficelée.
En poussant un peu, les développeurs vont être responsables des dysfonctionnement mondiaux. Et si on parlait des investisseurs justement ??
Cet article semble dégager l'auteur de toute responsabilité.
cdlt
C'est beaucoup plus simple,l'humain, commun, est là pour servir son "élite", l'entreprise n'est qu'un moyen.Vu d'en haut, il n'y a pas de dysfonctionnement, ceux qui décident ont orienté la société selon leurs intérêts
cdlt
Je n'ai travaillé qu'en XP (ou assimilé voire à l'arrache) sur des petits projets.
Mais lorsque je vois le nombre d'offres d'emploi, ou même en entretien, que les projets sont gérés en "Cycle en V", j'ai la forte impression que c'est pour graisser et entretenir des experts (MOE, MOA, pour faire les tests).
Et qu'effectivement, les développeurs n"ont pas leur mot à dire et reçoivent tous les malheurs en cas de problème
Attention, je conçois bien que le "Cycle en V" peut être adapté pour certains projets.
C'est sur que sur un C.V. être MOE, MOA, expert ou référent technique cela attire les grosses sociétés de tout poil, une bonne situation et un gros salaire.
C'est pour cela que cela ne m'étonne pas que la grosse majorité des analystes - programmeurs, développeurs ont moins de 30 - 35 ans.
Et aussi qu'on ne parle que de "Cycle en V".
Moa aussi j'aime le moé !
Bonjour.
Je pense comprendre ce que tu dis, et je pense que l'on ne parle pas de la même chose entre artisanal et industriel.Mais on s'en fiche
Et pour cela il faut mettre en place "une stratégie industrielle" à tous les niveaux.
Je fais aussi des applications "one shot" comme le dit Rod, des applis jetables qui ne serviront qu'une fois. Des applis qui ne demandent en général aucune optimisation, aucune réflexion scientifique, limite fait à l'arrache... Pas besoin d'une stratégie industrielle, dans ces cas là (enfin c'est mon opinion).
Lorsque je voulais souligner la nuance artisanal/industriel évoquée par Souviron, c'est que dans l'industrie, lorsqu'un robot fabrique une pièce, cette pièce est toujours usinée de la même façon (OK à 99% près; les robots ont aussi des bugs...).
En informatique, lorsque plusieurs développeurs écrivent le même programme, ils "n'usinent pas" le code source de la même façon, et le résultat de la pièce usinée (le code source) à des nuances/différences.
Si l'informatique pouvait être assimilée à de l'industriel, tous les codes sources des développeurs devraient être identiques...
@moldavi: Tu as raison de dire que le code produit dépend de l'artisan
Mais c'est fini le temps où on devait coder en assembleur ou en C avec des spécifications de matériel floues, quand lorsqu'on codait l'affichage d'un cercle le CPU crachait ses tripes, voire des librairies à la MFC dans laquelle la classe CString a 100 méthodes "qui se marchent sur les pieds" (*)
Maintenant la grosses différence entre 2 produits qui ont les même fonctionnalités, ce sont la conception d'une part et de l'autre, les libraires et les solutions retenues.
Parce que ce sont eux qui vont permettent de faire intervenir différents facteurs très importants: le feedback client, utilisateur ou développeur, la prise de risque sur tel ou tel point, l'évolutivité/ la maintenance ....
Maintenant si 2 développeurs ne codent pas de la même façon c'est déjà assez limité par le fait qu'il y a qu'une façon de coder dans la majorité des cas, qu'il n'y a que "des endroits très précis" à coder.
Je pense à l'intégration des réseaux sociaux dans une application.
Je pense au patron de conception MVC d'une application iPhone/ iPad.
Ensuite, le compilateur va faire de l'optimisation silencieuse et les profilers vont détecter les fuites et les surcharges en tous genres.
Et donc le développeur qui ne code pas "correctement" va devoir refaire un code plus classique.
L'"industrialisation" des process déteint aussi sur le développeur et son code.
Il n'y a pas qu'un vieux comme moi qui fasse la différence dans son code entre un for, un while et un do while
* -> Pas forcément le bon exemple
Édit: J'auto-nuance mes propos sur un gros projet et les projets industriels (ceux qui demandent plus de 6 mois de travail)
Quoique pour un jeu vidéo, tu achètes un moteur 3D et un moteur physique et ensuite tu n'as plus qu'ajouter tes assets et tes scripts (ta logique).
Parce que sinon, pour les autres projets, tu es dans un cadre, un environnement et même si tu as un gros pourcentage de différences entre 2 développements, je ne pense pas que les différences soient notables.
Un exemple précis: Il n'y aucun impact entre un case et des if imbriqués.
Surtout que le compilateur est plus fort que l'humain pour les choses simples
Et il y a des outils pour détecter que le programmeur code comme un sagouin afin de revenir à du code classique
Et comme je l'ai dit maintenant on choisi une solution et une conception
Un exemple précis: avant pour faire du md5 ou de la base64, on aurait eu une compétition du meilleur code (j'avais dit "des étoiles dans les yeux"): plus rapide, moins de mémoire, récursif ou pas, procédure VS object ...
Maintenant: on prend Openssl. Et c'est génial: du code éprouvé qui est partout, Même dans Apache (c'est un module).
Bonjour.
Je vois ce que tu veux dire.
Je propose qu'on lance un mini challenge sur un cahier des charges précis. On compare ensuite les codes sources des challengers.
On constate alors si l'on a à faire à de l'artisanal ou de l'industriel, et on en discute.
Je ne suis pas d'accord avec toi, le client est roi, il paye, par conséquent il peut exercer un chantage au prestataire. C'est aussi une des raisons pourquoi il y a tant de SSII, parce que les décideurs ... mauvais n'arrivent pas à leur fin avec leurs salariés, alors ils font appel à la sous traitance qui est obligé d'aller dans le discours du décideur, ce qui amène à une forme de prostitution pour utiliser le bon terme.
Moi je met 80% faute du CP/gestionnaire, et 20% faute du dev.. Client 0%.. Si il n'a pas de trucs précis, c'est que le CP n'est pas arrivé à lui faire cracher...
Quand tu fais construire une baraque, tu peux dire "je veux 4 chambres une sDb et une cuisine", mais c'est l'architecte qui va te présenter un plan précis et te le faire raffiner..
D'autre part les SSII font pour certaines des contrats en béton pour se protéger contre les changements d'avis des décideurs.
Il y a des tas de clients de mauvaise foi, mais il se peut également que le CP soit chez le client.
Je ne veux pas faire de généralité, hein, je me fais l'avocat du diable.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager