Et donc ? Ca rend créatif, ça ? Ou quoi ?Envoyé par Sodium
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
Et donc ? Ca rend créatif, ça ? Ou quoi ?
Extérieur au projet non plus, ça ne veut pas dire incompétent.
Sodium, s'il n'y avait pas de créatifs, on avancerai pas. Car ces gens que tu dénigres completement font avancer/changer les choses.
Sans eux, l'informatique serait très loin de ce qu'elle est car le fait de ne pas se donner certaines contraintes (ce que tu appelles "avoir du recul") permet d'ouvrir de nouvelles perspectives. Et ces gens ne sont pas forcément si nul que tu veux le faire croire.
Qui sont ces créatifs ? Dennis Ritchie, Bill Gates, steeve Jobs, etc... (tu n'oserais sans doute pas affirmer que les 2 premiers manquent de technique ?) Et c'est pourtant bien le 3ème qui a exploité son ami Wozniak très technique pour changer le monde de l'informatique). Et je dis ça en étant totalement anti-apple !
ll faut des gens très technique, et il faut des créatifs ! Les deux se complètent !
Ta façon de cloisonner les gens est totalement injustifiée et à la limite de l'intolérance. Et pour faire comme toi, de la psyko à 3 sous, on pourrai croire que certaines de ces personnes t'ont fait du tord. Peut être même t'ont volé des places que tu convoitais...
Je n'ai peut-être pas une expérience fantastique en la matière mais toutes les personnes que je connais qui m'ont parlé d'Agile dans leur boite comme d'une révolution, on fini par admettre 6 mois ou 1 an plus tard qu'en fait il s'agissait de LaRache...
La plupart des entreprises qui m'ont dis ça ne faisait pas du vrai AGILE, mais un mix d'agile avec leur process à eux...
Généralement la programmation en binôme ne se pratique pas dans ces cas là...
Ça, ça sent plus la mauvaise gestion de la méthode et / ou une interférence de la hiérarchie, voire d'un manque d'implication du client.
Deux commentaires:
1- Le développement implique de la créativité, certes, mais la gestion demande de la rigueur. L'un prône l'innovation, l'autre se conforte dans les processus connu et maitrisés. Il faut comprendre que ces des aspects seront toujours conflictuelles de par leur nature. Plusieurs aimeraient n'avoir aucun conflit entre ces deux groupes. Ce serait le monde idéal selon eux. Moi, je dis le contraire. Le véritable progrès vient des équipes créatives de développement qui ont assez de rigueur pour démontrer à gestion qu'il faut s'ajuster les méthodes de gestion et des équipes de gestion qui doivent être assez créative pour faire évoluer les méthodes administratives. Le conflit est le moteur du changement. Le jour où il n'aura plus de conflit, il n'aura plus de progrès.
2- Pas plus tard que la semaine dernière, j'ai entendu des propos similaire à "Sodium", que les créatifs sont déconnectés de la réalité, peu sensible aux contraintes et budgets, etc. Ce sont souvent des idées reçues véhiculées par des administrateurs qui veulent justifiées leur immobilisme dans l'évolution de leur méthodes de gestions. Malheureusement, cette pensé est aussi reprise par certains développeurs, habituellement peu créatif, qui ne souhaite pas que l'on idéalise les créatifs car cela mettrait leurs incompétences à ce niveau. D'un autre côté, je partage un peu les idées de "Sodium" aux propos des "créatifs" mais pas pour les mêmes raisons. Je crois que beaucoup des gens se disent créatifs. C'est en demande par les entreprises et un terme à la mode. Par conséquent, tout le monde se dit créatif. Un "faux" créatif aura tendance à générer des idées déconnectées de la réalité ou irréaliste en temps et en budget. Il se targuera qu'il est une personne très créative mais qu'il est incompris par l'entreprise. Pour moi, une développeur créatif se mesure, non pas à ses idées mais à ses réalisations. Un "bon" créatif est quelqu'un de curieux qui propose des solutions concrète pour améliorer un projet en qualité, temps de réalisation, etc. De ce point de vue, il a toujours les objectifs administratifs en tête lorsqu'il proposes ses innovations.
Toi tu trouves qu'on cherche des créatifs ??? J'ai surtout l'impression qu'on en veut pas. Dans le dev du moins...
Le manifeste AGILE est pratiquement impossible à mettre en oeuvre
C'est plus un but vers lequel tendre qu'un registre de règle à appliquer point par point
Il est normal et logique de l'adapter
Même le SCRUM n'est pas du pur AGILE
Il ne faut pas être extrémiste dans son application mais au contraire, y aller étape par étape de manière raisonnée et rationnelle
On ne peut pas passer du tout procédural au tout agile d'un seul coup
C'est trop violent (un peu comme passer d'un bain d'eau brûlante à de l'eau glacée : tu fais un AVC direct)
Il faut y aller petit à petit
D'autant plus que l'agile embarque énormément de monde : les DP, CP, concepteurs, développeurs, clients, RH, ...
Ce n'est pas juste un changement de méthode, c'est un changement d'état d'esprit et ça prend du temps à changer
Je voulais pas être aussi catégorique dans mon post
Mais il est vrai qu'à la base quand on exclu le développeur du métier ( sur des petits projets/sous projets) , on ne peut pas se prétendre agile :
- Le temps est perdu car c'est le chef de projet qui doit comprendre la demande (ping-pong avec le métier) , la spécifier, l'expliquer au dev (ping pong avec le dev), etc...
Cela créer trop d'aller retour et les informations se perdent, ça créer du stress de tout les cotés.
je ne dit pas qu'il faut se passer des specs et autres process, mais il faut les répartir de manière différente :
Un développeur impliqué dans un projet est généralement productif et heureux
Cela dit il est vrai qu'on ne peut pas appliquer l'agilité sur tout les projets ...
La base de l'agile, le minimum syndical même, est de fusionner la MOA et la MOEJe voulais pas être aussi catégorique dans mon post
Mais il est vrai qu'à la base quand on exclu le développeur du métier , on ne peut pas se prétendre agile :
- Le temps est perdu car le chef de projet doit comprendre la demande , la spécifier, l'expliquer au dev, etc...
Cela créer pas mal d'aller retour et les informations se perdent, ça créer du stress de tout les cotés.
je ne dit pas qu'il faut se passer des specs et autres process, mais il faut les répartir de manière différente :
Un développeur impliqué dans un projet est généralement productif et heureux
Cela dit il est vrai qu'on ne peut pas appliquer l'agilité sur tout les projets ...
Tant qu'il y a un intermédiaire entre le métier et le dev, ce n'est pas de l'agile, même partiellement
Ensuite, l'agile ne convient pas à tous les projets et même, ne convient pas à tous les aspects d'un projet.
Par exemple : les flux
Des flux, c'est très techniques et ça doit être limpide
Il est donc normal de bien spécifier le format de chaque champ, leur ordre, la fréquence du flux, la volumétrie
L'agile n'apporte rien à la spécification des flux, c'est même tout le contraire
Note : ne pas confondre flexibilité et agilité.
sur les flux, on peut être flexible en permettant que les flux évoluent mais ça n'en fait pas de l'agile pour autant
Bonjour à toutes et à tous.
Je suis un vieux machin de 47 ans, donc j'en ai vu des vertes et des pas mûres en informatique.
Au lieu de critiquer et/ou de défendre qui que ce soit, je vais vous livrer quelques remarques issues de ma longue carrière.
J'ai été abonne au monde informatique (si si le truc papier en format A3) qui tous les 6 mois faisait la une sur "LA nouvelle méthode qui allait sauver la planète entière" :
- Merise, juste avant que la "nouvelle super méthode" SDMS n'arrive, puis les autres orientées objets ou machin
- BASIC, ASM, COBOL, Pascal (mon préféré), SQL, HTML, XML, Java, Javascript, Perl, C, C++, C#, Python et certainement 350 autres
- Appli locale, Client-serveur (avec client léger, moyen, lourd, welter, poussin mouche...), applis 3/3, applis n-tiers
- fichiers locaux, bases de données (hiérarchiques, relationnelles, distribuées...), entrepôt de données, porte container de données, zone portuaire de données
- Terminal X, PC, PC réseau, super PC, PC light avec citrix, PC encore plus léger avec émulations, PC verrouillé, AaaS, Waas, Daas et autres consors "as a service" sauf Azure bien évidemment qui n'était pas en service
- Disquette, DD, Netware, NAS, Intranet, Cloud interne, Cloud externe, Cloud mixte, Cloud hybride (avec des moteurs diésel pour venir au secours des alims des datacenters)
Bon j'arrête là vous avez compris le principe. Une des seules choses qui soit resté est qu au final l'ordi manipule des 0 et des 1 de façon séquentielle (mais contrôlée, du moins presque...).
De toutes ces méthodes révolutionnaires, certaines sont restées, d'autres ont disparu ou sont tombées en désuétude.
Par contre il est une chose qui n'a cessé de croître et se développer : la frénésie d'avoir toujours le dernier truc en cours. Et c'est là que les problèmes commencent : a vouloir rouler de plus en plus vite, on finit par rater un virage. Les interactions entre systèmes sont tellement vastes complexes et rapides que je mets quiconque au défi de totalement maîtriser son informatique comme le faisait un DSI il y a 25 ans.
La dernière nouveauté, c'est Agile. Tout le monde en parle, tout le monde en fait, tout le monde est content et fier de faire de l'agile.
La vision de Agile que j'ai telle qu'elle est faite dans les entreprises, c'est ce que les vieux comme moi appelaient à l'époque la programmation à la Monsieur Cadburry ("Dis monsieur tu peux me la faire plus grande ?"). Les connaisseurs apprécieront. Ça a toujours fini par produire des usines à gaz qui à un moment devenaient incontrôlables. A moins bien entendu de faire de l'agile propre, avec documentations, études, mais dans ce cas, c'est beaucoup moins agile...
Agile est encore un peu jeune et donc on ne connait pas encore l'étendue des dégâts de cette façon hystérique de gérer l'informatique.
Il fut un temps ou MS-DOS était numéroté X.Y
Windows était numéroté X.YY
Skype est numéroté sur mon MAC 5.8.0.1027 ça ça me fait un peu peur !
C'est un peu comme le mec qui réaménage une tour en tapant dans les piliers pour avoir plus de place, creuse en dessous pour rajouter un étage de parking ou ajoute des balcons sur la façade. LE concept est intéressant, mais moi j'habiterai pas la dedans !
Ah oui dernier point concernant les "créatifs" : ne pas confondre avec les zèbres c'est pas du tout la même chose !
Le mec qui développe des micro applis pour iPhone et qui programme chez lui pour son plaisir, oui il doit être créatif.
Celui qui est développeur dans une boite, il doit faire ce qu'on lui dit de faire, de telle manière que l'application soit stable, performante et maintenable, donc sa créativité, comme on dit vulgairement il peut se la...
Voila je vais encore me faire un tas de copains moi...
"L'incohérence de ceux qui dirigent et l'incompétence de ceux qui critiquent sont un vibrant hommage à ceux qui exécutent."
Général George S. PATTON. Messine 1943.
Concernant l'histoire du zèbre : il s'agissait juste d'une réflexion à propos de cette phrase de l'article :
Sans aucun rapport avec la créativité, ni même le sujet du débat sur les méthodes agiles et sans connotation quelconque. Je me disais juste que quelqu'un comme cela me faisait penser à un zèbre.Ce sont ces généralistes bricoleurs multifacettes qui poussent toujours les chefs d’équipes à repenser leurs produits ou services.
L'histoire du zèbre ça me parait être un peu éloigné du sujet principal de l'article.
Pour ma part, et d'après mes quelques années d'expérience, oui le management mis en place dans beaucoup d'entreprises,
n'est par forcément adapté à la mise en place de méthodes agiles, comme SCRUM.
Ce qui donne actuellement sur notre projet un résultat "bancal".
Je suis en train de passer une certif SCRUM master, financée par mon employeur,
pour améliorer mon "adhérence" au SCRUM.
Le problème c'est connaissant mieux le fonctionnement, et les règles de SCRUM,
je me rend également compte que les règles pourtant simples, ne sont pas appliquées
correctement.
Plusieurs choses que je peux constater sont :
- le management qui refuse de "lâcher prise" sur l'autonomie de l'équipe de dév.
- un product owner qui n'est pas impliqué comme il devrait
Ces aspects qui sont ancrés dans la culture de l'entreprise sont difficiles à changer.
Ce qui apporte beaucoup de démotivation dans l'équipe,
et donc le résultat inverse de celui attendu.
Après comme dit arkhamon :
C'est pas complètement faux non plus, mais c'est encore un autre débat...Agile est encore un peu jeune et donc on ne connait pas encore l'étendue des dégâts de cette façon hystérique de gérer l'informatique.
JAVA le dire a tout le monde
@arkhamon
J'ai bien aimé ton post
On y voit bien le "vieux briscard" qui a roulé sa bille
Je vais cependant réagir sur 2 extraits de ton post avec lesquels je ne suis pas phase
Pourquoi "hystérique" ?
L'informatique se doit d'être en phase avec le monde d'aujourd'hui et ce monde va de plus en plus vite et il est en constante évolution
Contrairement à il y a 20 ans, le net s'est généralisé
La concurrence y est ultra rude et surtout mondiale
L'éventail des technos disponibles n'a jamais été aussi vaste et constamment en évolution
Le temps où il était possible de cadrer totalement un projet et d'en effectuer la réa sur 6 mois est révolu
Le marché évolue, les besoins évoluent, les attentes évoluent, les demandes évoluent et les projets info doivent également évoluer
Qu'on soit d'accord ou non avec cela n'entre pas en ligne de compte
Soit notre manière de mener les projets évolue pour suivre le marché soit on est amené à disparaître
Justement, non
Un développeur se doit d'avoir un regard critique sur ce qu'il fait sinon c'est le meilleur moyen pour : développer "à côté de la plaque" (et devoir retoucher à tout va pour faire coïncider le dev avec le besoin ce qui nuira à la stabilité, aux perf et à la maintenabilité du code) et de ne pas satisfaire le client
Le sens critique permet également d'être force de proposition ce qui est un grand signe de satisfaction client (que les propositions soient retenues ou non n'est pas important. Ce qui compte, c'est de proposer, de montrer que l'on s'intéresse au projet dans son ensemble).
Un client ne veut pas ce qu'il demande, il veut ce dont il a besoin
Parfois, il peut y avoir un sacré gap entre les 2 et l'agile permet justement de s'y retrouver
J'ai 34 ans, 14 ans d'informatique seulement et je pense que tu as raison.
Un de mes profs du CNAM avait commencé un cours par : "L'informatique n'échappe pas à la règle. Comme partout, il y a des modes"
Grave urgent !!!
Merci j'ai pas l'impression d'être complètement à côté de la plaque...
D'accord avec toi dans le principe de s'adapter. Mais ne court-on pas le risque dans cette frénésie (apparemment hystérique était un peu fort) de perdre le contrôle sur ce qui est en passe de devenir aussi vital que l'eau et l'air ? En 1987, un automate d'animation de marché a provoqué une crise boursière à cause d'un bug. Bon tu me diras celui là il était pas développe en Agile
En fait, mon propos est de me demander si cette utilisation d'Agile ne risque pas de provoquer des catastrophes. L'implémentation de Agile est actuellement de mon point de vue faite de manière trop peu encadrée et sert souvent de justification au manque de docs qui sont pourtant indispensables. J'ai l'impression qu'on se prépare des applis dont personne ne sera capable de comprendre le fonctionnement global par manque de docs dessus.
Rhâââââââ et ils sont où les chefs de projets ?C'est le boulot des chefs de projets de faire l'interface avec le client, pas celui des développeurs ! L'architecte dessine le bâtiment et Bouygues le construit tel que dit par l'architecte. Si il décide de rajouter des trucs ou d'en modifier, il corrompt le produit !
Ce mythe du développeur aux commandes du produit me semble être une HAINEAURME erreur ! Qu'au sein de son travail il optimise les traitements oui c'est son boulot. Mais pas de relations avec le client. Sinon qui a la vue globale du produit ? Qui est garant de son intégrité ? 45 développeurs dont la moitié en presta et l'autre moitié en Inde ?
Dans ce sens, Agile me semble dangereux car il donne trop de pouvoir aux développeurs. ET quand le développeur a le pouvoir il a tendance à se faire plaisir. JE le sais, je le fus...
Y a un très bon sketch de Mr Bean à ce propos où il veut offrir un bijou à une femme mariée. Il veut juste le bijou, mais la vendeuse arrête pas de lui proposer plein de trucs en plus résultat il se fait piquer par le mari trompé...
Le mécano de chez Renault met une vis fraisée là où la doc lui dit de mettre une vis fraisée. Et il le fait même si il trouve qu'une vis plate est plus jolie ou moins lourde ou plus solide. Sinon ça risque de devenir dangereux de monter dans la voiture !
"L'incohérence de ceux qui dirigent et l'incompétence de ceux qui critiquent sont un vibrant hommage à ceux qui exécutent."
Général George S. PATTON. Messine 1943.
As-tu déjà vu une application de plus de 3 ans d'âge avec une doc à jour ?
Personnellement, connaît pas.
La doc, c'est le code et c'est un code bien commenté.
Commenter son code est un principe de développement qui reste parfaitement valide en Agile.
En Agile, tu as le rôle du "product owner" qui est tenu par le client et c'est lui qui a la vue globale du projet.Rhâââââââ et ils sont où les chefs de projets ?
Ce mythe du développeur aux commandes du produit me semble être une HAINEAURME erreur ! Qu'au sein de son travail il optimise les traitements oui c'est son boulot. Mais pas de relations avec le client. Sinon qui a la vue globale du produit ? Qui est garant de son intégrité ? 45 développeurs dont la moitié en presta et l'autre moitié en Inde ?
Dans ce sens, Agile me semble dangereux car il donne trop de pouvoir aux développeurs. ET quand le développeur a le pouvoir il a tendance à se faire plaisir. JE le sais, je le fus...
Y a un très bon sketch de Mr Bean à ce propos où il veut offrir un bijou à une femme mariée. Il veut juste le bijou, mais la vendeuse arrête pas de lui proposer plein de trucs en plus résultat il se fait piquer par le mari trompé...
Le mécano de chez Renault met une vis fraisée là où la doc lui dit de mettre une vis fraisée. Et il le fait même si il trouve qu'une vis plate est plus jolie ou moins lourde ou plus solide. Sinon ça risque de devenir dangereux de monter dans la voiture !
Je dirai même que cette façon de faire est beaucoup plus cohérente qu'avant car très souvent, le CP était également une ressource externe.
Autrement dit, la personne détenante de la vue globale du projet partait avec la fin du projet...
Ensuite, on ne demande pas à un développeur de changer les spéc à sa guise, dans son coin, sans en parler à personne
On demande au développeur d'avoir un esprit critique sur ce qu'il fait
Prendre le temps de réfléchir à ce qu'il fait avant de le faire et ainsi d'identifier en amont (et pas en cours de route) les éventuels points de blocages ou de flou.
Et si modification de la fonctionnalité il y a, cela se fait en concertation avec toutes les personnes concernées.
Croire que les seules bonnes idées viennent des gens "d'en haut" est une vision d'un autre temps.
Je dirai même qu'on devrait plus souvent être à l'écoute des exécutants car ils peuvent attirer l'attention des décideurs sur des aspects du projet auxquels ils ne pensent pas forcément.
Cela pourrait parfois éviter quelques absurdités totales (comme 3 marches d'escaliers installées devant l'accès à des toilettes pour handicapés, exemple réel)
Le projet sur lequel je travaille, c'est 15 ans d'historique, des commentaires faux partout, un million de lignes de code, et surtout le même projet vendu a des dizaines de clients. Et heureusement, on a un architecte qui a une vue globale du projet.
On devrait passer à la méthoede agile bientôt, et vraiment, je ne vois pas qui va avoir cette vision globale : les plus vieux développeurs de l'équipe n'ont "que" 8 ou 10 ans d'ancienneté sur ce produit, et il semble inconcevable qu'une équipe de moins de 10 personnes (c'est bien la taille des équipes Agile non ?) ne soit l'interface avec ne serait-ce que 50 clients.
Ça, normalement, c'est le cas quelle que soit la méthodologie : on pense avant de faire, on étudie les impacts, et on en parle à plusieurs pour être certain de limiter les oublis.Ensuite, on ne demande pas à un développeur de changer les spéc à sa guise, dans son coin, sans en parler à personne
On demande au développeur d'avoir un esprit critique sur ce qu'il fait
Prendre le temps de réfléchir à ce qu'il fait avant de le faire et ainsi d'identifier en amont (et pas en cours de route) les éventuels points de blocages ou de flou.
Et si modification de la fonctionnalité il y a, cela se fait en concertation avec toutes les personnes concernées.
Je suis persuadé que les développeurs ont une bonne vue du logiciel, mais je pense aussi que sur de gros projets, une personne avec une vue d'ensemble n'est pas dénué d'intérêt, surtout lorsque le produit en question est distribué à de nombreux clients qui ne peuvent donc logiquement pas avoir une vue globale.Je dirai même qu'on devrait plus souvent être à l'écoute des exécutants car ils peuvent attirer l'attention des décideurs sur des aspects du projet auxquels ils ne pensent pas forcément.
Cela pourrait parfois éviter quelques absurdités totales (comme 3 marches d'escaliers installées devant l'accès à des toilettes pour handicapés, exemple réel)
Comme dit très souvent, l'Agile ne convient pas à tous les projets
Dans certains cas, ça n'apporte strictement rien.
Faire de l'agile pour de l'agile n'a pas de sens.
Il faut se poser la question de pourquoi mettre en oeuvre cette méthode pour le projet ? (qu'elles sont les bénéfices espérés ?)
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